Pomijając ich warianty, stosowane są dwie metody (grupy metod) dokumentowania wymagań i zarządzania nimi. Zakładamy, że są to wymagania wobec produktu (rozwiązania) jaki ma dostarczyć jego dostawca. W BABoK (Business Analysis Body of Knowledge), wymagania te musi spełnić dostarczony produkt, jednak oczywiście rozliczany jest dostawca rozwiązania.
Stosowane są trzy metody (grupy metod) specyfikowania wymagań:
- Specyfikacja wymagań funkcjonalnych i poza-funkcjonalnych (i warianty tej metody).
- Specyfikowanie tak zwanej “czarnej skrzynki” (przypadki użycia).
- Specyfikowanie tak zwanej “białe skrzynki” (przypadki użycia + model dziedziny systemu).
Pierwsza i najstarsza metoda bazuje na założeniu, że zamawiający i (lub) przyszły użytkownik wie czego chce. Wymagania w postaci listy (funkcjonalne i poza-funkcjonalne) kolekcjonowane są na warsztatach, burzach mózgów, tak zwanych sesjach JAD (ang. [[Joint Application Development]]), bywa, że z pomocą ankiet. Powstaje lista (tabela) z odpowiednio oznaczonymi i sklasyfikowanymi wymaganiami.
“Czarna skrzynka” to wymagania opracowane w postaci opisu rozwiązania skupiającego się wyłącznie na jego zewnętrznych cechach, zmusza do wyspecyfikowania tego do czego ma ono służyć, jednak nie opisuje mechanizmu jego działania, specyfikacja przypadków użycia w zasadzie zamyka się na udokumentowaniu bodźca i efektu (stan początkowy i końcowy) każdego przypadku użycia (usługi specyfikowanej aplikacji), wyjaśnienie np. sposobu wykonania obliczeń – owszem – dokumentowane jest w postaci np. wzorów matematycznych czy algorytmów, jednak taka cecha jak np. “możliwość skojarzenia wszystkich zamówień, na bazie których powstała zbiorcza faktura na koniec miesiąca” pozostaje tylko nazwanym wymaganiem, specyfikacja taka nie zawiera opisu mechanizmu pozwalającego na taka operację.
“Biała skrzynka” to specyfikacja jak wyżej, uzupełniona o opis (model) np. mechanizmu pozwalającego na skojarzenie tych zamówień z właściwą fakturą.
BABoK generalnie wskazuje (skupia się) na dwóch ostatnich metodach.
W każdym projekcie trwającym w czasie i dopuszczającym zmiany w jego zakresie (w wymaganiach) pojawia się potrzeba zarządzania zmianami, zaspokajana praktycznie zawsze z pomocą tak zwanego wersjonowania. Wersjonowanie wymagań w postaci płaskiej listy wymagań funkcjonalnych i poza-funkcjonalnych, jest żmudne, sprowadza się do niezależnego wersjonowania treści (brzmienia) każdego wymagania wraz z możliwością pojawienia się nowego i usunięcia już istniejącego (lub nadania mu statusu “odrzucone”). Opisał to ładnie Miał Wolski:
Zmiany w wymaganiach wymaga ich wersjonowania. Wersje wymagań pomagają uzyskać dostęp do określonego stanu wymagania w trakcie życia oprogramowania. Najczęściej wersje wymagań określane są za pomocą kolejnych ich numerów. Najbardziej popularnym sposobem nadawania numerów wymagań jest złożenie numeru z wersji wymagania oraz przyrostu, oddzielonych znakiem kropki. Wersja 1.3 oznacza wtedy 1 wersję wymagania i 3 przyrost. (Źródło: Wymagania ? Zarządzanie wersjami | Michał Wolski)
Zupełnie inaczej wygląda w pozostałych dwóch metodach. Zarówno “czarna skrzynka” jak i jej “biała” odmiana, to są już projekty rozwiązania (np. aplikacji), “biała skrzynka” zawiera wewnętrzną architekturę. Wobec tego jest to “jeden projekt” a nie np. “czterysta wymagań”. Wersjonowaniu podlega tu jeden projekt, dzięki temu sam proces wersjonowania i zarządzanie nim staje się znacznie prostszy (można to robić np. z pomocą systemów zarządzania wersjami takimi jak [[CVS]], [[SVR]] itp.). Owszem, projekt może zawierać wiele detali, żeby ułatwić znalezienie różnicy między wersjami (tego co zostało właśnie zmienione) na początku dokumentu (specyfikacji projektu) umieszcza się tak zwany regestr zmian (dotyczy całego projektu).
Opracowanie listy wymagań funkcjonalnych i poza funkcjonalnych jest relatywnie najprostsze, nie wymaga od pracowników zamawiającego dodatkowych kwalifikacji, mogą w tym procesie brać udział przyszli użytkownicy, jednak utrzymanie kompletności, spójności i niesprzeczności takiej specyfikacji jest najtrudniejsze.
W przypadku “skrzynek” już sam fakt, że są one projektem (pewną konstrukcją) pozwala stosować do ich opisu typowe inżynierskie metody takie jak modelowanie. Model można testować więc zagwarantowanie spójności, kompletności i niesprzeczności jest łatwiejsze, problemem pozostaje co najwyżej kompletność, czyli odpowiedź na pytanie “Czy to są wszystkie wymagane funkcje”. Ryzyko jakie stwarza “czarna skrzynka” to pozostawienie dostawcy (wykonawcy, developerowi) decyzji o postaci mechanizmu działania (jego zaprojektowanie). Dostawca może go zbyt uprościć lub wręcz nie rozumieć i powstanie coś co nie realizuje w 100% logiki biznesowej danej organizacji. “Biała skrzynka” niweluje to ryzyko: powstaje tu projekt wewnętrznej logiki: mechanizm działania aplikacji.
Konsekwencje. Wydawało by się, że pierwsza metoda jest najtańsza, bo projektowanie jest kosztowniejszą pracą bo wymaga znacznie większych kompetencji niż prowadzenie warsztatów, sam przyszły użytkownik z reguły nie posiada tych kompetencji i musi za nie zapłacić. Niestety jest to prawda dla małych projektów, tam gdzie pojawiają się wymagania w ilości setek i nie raz tysięcy, samo zarządzanie nimi jest tak pracochłonne, że koszt rośnie szybciej niż liczba tych wymagań.
Po przekroczeniu pewnego poziomu złożoności znacznie lepsze są metody systemowe oparte na projektowaniu (“skrzynki”), i tu ważna uwaga: projektowanie to etap specyfikowania wymagań, jeżeli projekt opracuje zamawiający, niweluje ryzyka jakie niesie ze sobą zlecenie projektowania developerowi: prawdopodobnie będzie upraszczał projekt (obniżał swój koszt) i bardzo prawdopodobne, że będzie forsował swoje dotychczasowe doświadczenie z firmy o podobnym charakterze co niestety bardzo często prowadzi do nieuprawnionego powielenie cudzej i niekoniecznie dobrej, logiki biznesowej. Do tego pojawia się problem (duże ryzyko) zawłaszczenia przez dostawcę praw autorskich do projektu tej biznesowej logiki i całego mechanizmu działania aplikacji a tym samym organizacji (o czym nie raz tu już pisałem).
