Wymagania, czy to systemowe, czy biznesowe, są w projektach informatycznych bardzo specyficznym artefaktem.
Na przestrzeni lat opracowano szereg technik do ich pozyskiwania, które sprawdzają się bardziej lub mniej w projektach o określonym charakterze. Ale co dalej, kiedy już te wymagania pozyskamy? Czy to czas, kiedy Analityk może wreszcie odpocząć? A no niestety nie. Poza zbieraniem wymagań dwoma ogromnymi zagadnieniami są analiza wymagań oraz zarządzanie nimi. Jako pierwszej przyjrzyjmy się analizie.
Po spotkaniach z interesariuszami, czy będą to oficjalne warsztaty, czy refinement przeprowadzony swobodnie online, Analityk zazwyczaj wraca do siebie z porcją informacji, co powinno zostać zaimplementowane, aby zaspokoić pewną potrzebę biznesową. Jednak taką porcję informacji zazwyczaj trzeba „przetrawić”. Co to oznacza? A mianowicie trzeba zastanowić się, jak ta porcja informacji ma się do całości. Być może wymagania dotyczą zupełnie nowej funkcjonalności, a być może projekt już się toczy i nowe wymagania dotyczą zmian do istniejącego produktu. Jaki by nie był kontekst, nad wymaganiami trzeba siąść i je przemyśleć.
Ponieważ w projekcie wymagań pojawia się zazwyczaj mnóstwo – w projektach średnich i dużych rozmiarów są to liczby rzędu setek lub tysięcy – zazwyczaj na początku konieczne jest zorganizowanie wymagań. Polega ono na przyjęciu pewnej określonej struktury opisu, która będzie zrozumiała dla wszystkich stron i będzie ułatwiać późniejszą pracę nad wymaganiami. Do tej pory taka struktura zazwyczaj obejmowała opis składający się z określonych atrybutów, np. w postaci tabelarycznej w dokumencie. Obecnie forma ta dostosowuje się do metodyk zwinnych. Może być to więc User Story, w którym określamy kryteria akceptacji oraz dla którego opracowujemy mockup, czy też issue w narzędziu pokoju JIRY, w którym opisujemy sposób implementacji. Organizowanie wymagań nie jest jeszcze pracą z wymaganiami samą w sobie, ale pracochłonnym przygotowaniem do takowej.
Zebrane wymagania specyfikujemy, czyli po prostu je spisujemy, w jakiejkolwiek formie ten opis by nie był. Wraz ze specyfikacją często opracowujemy modele. Jakiś czas temu, kiedy miał miejsce burzliwy rozwój i duże wykorzystanie UMLa, w dokumentacji projektowej znajdowały się wszystkie możliwe diagramy. Obecnie istnieje tendencja do modelowania, ale z zastosowaniem tylko tych typów diagramów, które są najbardziej potrzebne (tzw. Agile modeling). Tak więc wycinek diagramu klas opisujący encje, których akurat dotyczy Story, model proces biznesowego, czy nawet tylko jego wycinka, a przede wszystkim prototypy, które są najbardziej wyraziste w komunikacji pomiędzy interesariuszami. Wszystkie diagramy traktujemy jako narzędzie do bieżącej pracy. Jeśli się zdezaktualizują, lub przestaną być potrzebne, nie mamy skrupułów, aby je „wyrzucić do kosza”. Nie magazynujemy ich skrzętnie w ogromnych ilościach dokumentacji.
Kiedy wymagania zaczynają nabierać formy i powoli jesteśmy w posiadaniu „paczki”, która będzie implementowana, niezbędna jest zazwyczaj weryfikacja tych wymagań. Weryfikacja jest czynnością monitorującą odpowiednią jakość wymagań, które mają zostać zaimplementowane. Standardy, które wydają się być ponadczasowe, mówią, że wymagania powinny być prawidłowe (czyli bezbłędne), wzajemnie bezsprzeczne, wykonalne technicznie, możliwe do testowania oraz jednoznaczne. Czy będzie to wymaganie opisane w tradycyjny sposób, czy historyjka, te atrybuty nadal mają zastosowanie. Po wyspecyfikowaniu wymagań powinniśmy sprawdzić ich zgodność z przyjętą strukturą oraz to, czy spełniają standardy dobrych wymagań. Jeśli tak nie jest, szybko wrócą do nas, np. od programisty, który znajdzie w nich błąd, niejasność lub brak.
Ostatnim aspektem analizy, o którym warto wspomnieć, jest walidacja. W projektach prowadzonych metodami zwinnymi walidacja z etapu projektu stała się bardziej chlebem powszednim. Zauważono bowiem, że to na żyjących produktach najlepiej ocenić użytkownikowi końcowemu i innym przedstawicielom biznesu faktyczną wartość rozwiązania i jego zgodność z potrzebą biznesową. Jednak walidacja wymagań samych w sobie również jest realizowana, np. podczas sesji refinementu, czy też na planningu. Walidacja ma na celu potwierdzenie akuratności wymagań, tego, czy „trafiają w sedno” potrzeby biznesowej. Zweryfikowane wymaganie może być poprawnie spisane, ale może okazać się, że jego autorowi wcale nie o to chodziło. Walidacja ma więc na celu wyeliminowanie późniejszej straty czasu nad implementacją, testowaniem, czy też samą analizą wpływu tego wymagania np. na inne, w sytuacji, kiedy okazałoby się, że wymaganie jest nieważne. Do tej czynności niezbędna jest część biznesowa projektu, bo tylko ona może taką ważność ocenić.
Jak widać, pozyskanie wymagań to tylko początek drogi 🙂 W kolejnym poście pochylimy się nad zagadnieniem zarządzania wymaganiami.
Zostaw komentarz