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…
Właśnie, jak to jest? Regularnie słyszę z ust zwolenników stosowania metody, którą nazywają "zwinną", że "nie da się opisać wymagań przed rozpoczęciem projektu, należy/można je [wymagania] odkrywać w toku projektu, bo klient zna tylko cel i razem do niego dążymy, prototypy - tak właśnie radzimy sobie z nieprzewidywalnością wymagań". Przypomnę: wymagania to "warunki jakie coś musi spełnić aby było przydatne" (sł. j.polskiego PWN), jak mam tu rozumieć "brak wymagań na początku projektu", skoro jego - projektu - celem jest wytworzenie czegoś przydatnego? Co to znaczy "wymagania dzisiaj są nieprzewidywalne"? To…
Z powyższego płynie także kolejny wniosek: autor specyfikacji wymagań, powinien kontynuować projekt jako osoba zarządzająca wymaganiami, i bardzo dobrze jest jeżeli pracuje po stronie Zamawiającego, gdyż stanowi naturalny mechanizm kontroli pracy dostawcy np. oprogramowania. Zamawiający nie ma innej możliwości realnego, merytorycznego nadzoru nad dostawcą, to Zamawiający powinien zarządzać wymaganiami bo to w końcu jego wymagania!
