Wymagania, czy to systemowe, czy biznesowe, s\u0105 w projektach informatycznych bardzo specyficznym artefaktem.<\/p>\n\n\n\n
Na przestrzeni lat opracowano szereg technik do ich pozyskiwania, kt\u00f3re sprawdzaj\u0105 si\u0119 bardziej lub mniej w projektach o okre\u015blonym charakterze. Ale co dalej, kiedy ju\u017c te wymagania pozyskamy? Czy to czas, kiedy Analityk mo\u017ce wreszcie odpocz\u0105\u0107? A no niestety nie. Poza zbieraniem wymaga\u0144 dwoma ogromnymi zagadnieniami s\u0105 analiza wymaga\u0144 oraz zarz\u0105dzanie nimi. Jako pierwszej przyjrzyjmy si\u0119 analizie.<\/p>\n\n\n\n
Po spotkaniach z interesariuszami, czy b\u0119d\u0105 to oficjalne warsztaty, czy refinement przeprowadzony swobodnie online, Analityk zazwyczaj wraca do siebie z porcj\u0105 informacji, co powinno zosta\u0107 zaimplementowane, aby zaspokoi\u0107 pewn\u0105 potrzeb\u0119 biznesow\u0105. Jednak tak\u0105 porcj\u0119 informacji zazwyczaj trzeba \u201eprzetrawi\u0107\u201d. Co to oznacza? A mianowicie trzeba zastanowi\u0107 si\u0119, jak ta porcja informacji ma si\u0119 do ca\u0142o\u015bci. By\u0107 mo\u017ce wymagania dotycz\u0105 zupe\u0142nie nowej funkcjonalno\u015bci, a by\u0107 mo\u017ce projekt ju\u017c si\u0119 toczy i nowe wymagania dotycz\u0105 zmian do istniej\u0105cego produktu. Jaki by nie by\u0142 kontekst, nad wymaganiami trzeba si\u0105\u015b\u0107 i je przemy\u015ble\u0107.<\/p>\n\n\n\n
Poniewa\u017c w projekcie wymaga\u0144 pojawia si\u0119 zazwyczaj mn\u00f3stwo \u2013 w projektach \u015brednich i du\u017cych rozmiar\u00f3w s\u0105 to liczby rz\u0119du setek lub tysi\u0119cy \u2013 zazwyczaj na pocz\u0105tku konieczne jest zorganizowanie wymaga\u0144. Polega ono na przyj\u0119ciu pewnej okre\u015blonej struktury opisu, kt\u00f3ra b\u0119dzie zrozumia\u0142a dla wszystkich stron i b\u0119dzie u\u0142atwia\u0107 p\u00f3\u017aniejsz\u0105 prac\u0119 nad wymaganiami. Do tej pory taka struktura zazwyczaj obejmowa\u0142a opis sk\u0142adaj\u0105cy si\u0119 z okre\u015blonych atrybut\u00f3w, np. w postaci tabelarycznej w dokumencie. Obecnie forma ta dostosowuje si\u0119 do metodyk zwinnych. Mo\u017ce by\u0107 to wi\u0119c User Story, w kt\u00f3rym okre\u015blamy kryteria akceptacji oraz dla kt\u00f3rego opracowujemy mockup, czy te\u017c issue w narz\u0119dziu pokoju JIRY, w kt\u00f3rym opisujemy spos\u00f3b implementacji. Organizowanie wymaga\u0144 nie jest jeszcze prac\u0105 z wymaganiami sam\u0105 w sobie, ale pracoch\u0142onnym przygotowaniem do takowej.<\/p>\n\n\n\n
Zebrane wymagania specyfikujemy, czyli po prostu je spisujemy, w jakiejkolwiek formie ten opis by nie by\u0142. Wraz ze specyfikacj\u0105 cz\u0119sto opracowujemy modele. Jaki\u015b czas temu, kiedy mia\u0142 miejsce burzliwy rozw\u00f3j i du\u017ce wykorzystanie UMLa, w dokumentacji projektowej znajdowa\u0142y si\u0119 wszystkie mo\u017cliwe diagramy. Obecnie istnieje tendencja do modelowania, ale z zastosowaniem tylko tych typ\u00f3w diagram\u00f3w, kt\u00f3re s\u0105 najbardziej potrzebne (tzw. Agile modeling). Tak wi\u0119c wycinek diagramu klas opisuj\u0105cy encje, kt\u00f3rych akurat dotyczy Story, model proces biznesowego, czy nawet tylko jego wycinka, a przede wszystkim prototypy, kt\u00f3re s\u0105 najbardziej wyraziste w komunikacji pomi\u0119dzy interesariuszami. Wszystkie diagramy traktujemy jako narz\u0119dzie do bie\u017c\u0105cej pracy. Je\u015bli si\u0119 zdezaktualizuj\u0105, lub przestan\u0105 by\u0107 potrzebne, nie mamy skrupu\u0142\u00f3w, aby je \u201ewyrzuci\u0107 do kosza\u201d. Nie magazynujemy ich skrz\u0119tnie w ogromnych ilo\u015bciach dokumentacji.<\/p>\n\n\n\n
Kiedy wymagania zaczynaj\u0105 nabiera\u0107 formy i powoli jeste\u015bmy w posiadaniu \u201epaczki\u201d, kt\u00f3ra b\u0119dzie implementowana, niezb\u0119dna jest zazwyczaj weryfikacja tych wymaga\u0144. Weryfikacja jest czynno\u015bci\u0105 monitoruj\u0105c\u0105 odpowiedni\u0105 jako\u015b\u0107 wymaga\u0144, kt\u00f3re maj\u0105 zosta\u0107 zaimplementowane. Standardy, kt\u00f3re wydaj\u0105 si\u0119 by\u0107 ponadczasowe, m\u00f3wi\u0105, \u017ce wymagania powinny by\u0107 prawid\u0142owe (czyli bezb\u0142\u0119dne), wzajemnie bezsprzeczne, wykonalne technicznie, mo\u017cliwe do testowania oraz jednoznaczne. Czy b\u0119dzie to wymaganie opisane w tradycyjny spos\u00f3b, czy historyjka, te atrybuty nadal maj\u0105 zastosowanie. Po wyspecyfikowaniu wymaga\u0144 powinni\u015bmy sprawdzi\u0107 ich zgodno\u015b\u0107 z przyj\u0119t\u0105 struktur\u0105 oraz to, czy spe\u0142niaj\u0105 standardy dobrych wymaga\u0144. Je\u015bli tak nie jest, szybko wr\u00f3c\u0105 do nas, np. od programisty, kt\u00f3ry znajdzie w nich b\u0142\u0105d, niejasno\u015b\u0107 lub brak.<\/p>\n\n\n\n
Ostatnim aspektem analizy, o kt\u00f3rym warto wspomnie\u0107, jest walidacja. W projektach prowadzonych metodami zwinnymi walidacja z etapu projektu sta\u0142a si\u0119 bardziej chlebem powszednim. Zauwa\u017cono bowiem, \u017ce to na \u017cyj\u0105cych produktach najlepiej oceni\u0107 u\u017cytkownikowi ko\u0144cowemu i innym przedstawicielom biznesu faktyczn\u0105 warto\u015b\u0107 rozwi\u0105zania i jego zgodno\u015b\u0107 z potrzeb\u0105 biznesow\u0105. Jednak walidacja wymaga\u0144 samych w sobie r\u00f3wnie\u017c jest realizowana, np. podczas sesji refinementu, czy te\u017c na planningu. Walidacja ma na celu potwierdzenie akuratno\u015bci wymaga\u0144, tego, czy \u201etrafiaj\u0105 w sedno\u201d potrzeby biznesowej. Zweryfikowane wymaganie mo\u017ce by\u0107 poprawnie spisane, ale mo\u017ce okaza\u0107 si\u0119, \u017ce jego autorowi wcale nie o to chodzi\u0142o. Walidacja ma wi\u0119c na celu wyeliminowanie p\u00f3\u017aniejszej straty czasu nad implementacj\u0105, testowaniem, czy te\u017c sam\u0105 analiz\u0105 wp\u0142ywu tego wymagania np. na inne, w sytuacji, kiedy okaza\u0142oby si\u0119, \u017ce wymaganie jest niewa\u017cne. Do tej czynno\u015bci niezb\u0119dna jest cz\u0119\u015b\u0107 biznesowa projektu, bo tylko ona mo\u017ce tak\u0105 wa\u017cno\u015b\u0107 oceni\u0107.<\/p>\n\n\n\n
Jak wida\u0107, pozyskanie wymaga\u0144 to tylko pocz\u0105tek drogi \ud83d\ude42 W kolejnym po\u015bcie pochylimy si\u0119 nad zagadnieniem zarz\u0105dzania wymaganiami.<\/p>\n\n\n