W artykule Inżynieria wymagań między innymi opublikowałem taksonomię wymagań, jej rozwinięta postać:
Temat wymagań regularnie wypływa na forach dyskusyjnych i na konferencjach. Ostatnio w podobnej formie pojawił się na pewnym forum serwisu LinkedIn i na dzisiejszej konferencji. Na forum padło pytanie: co wybrać jako dokumentacje wymagań: SRS czy Use Case (odpowiednio [[Software Requirements Specification]] czyli [[specyfikacja wymagań na oprogramowanie]] i Przypadki Użycia oprogramowania). Na dzisiejszej konferencji zaś prawnik, podczas swojego referatu, zwrócił uwagę na fakt, że od strony umów, projekty – od analizy przedwdrożeniowej do dostarczenia zamówionego oprogramowania – należy dzielić projekt na fazy będące, zależnie od celu, umową efektu (umowa o dzieło) i umową starannego działania (umowa zlecenia).
Problem w tym, że SRS – często rozumiane jako dokument o strukturze opisanej w [[rekomendacji IEEE830]], zawiera w pewnej formie przypadki użycia (ale nie ich scenariusze) rozumiane jako opis funkcjonalności. Do tego rekomendacja ta nie jest standardem zawartości dokumentu a rekomendacją.
Pojęcie przypadku użycia ma co najmniej dwie zupełnie różne definicje: jedną rodem z książki Alistair’a Cockbourna “Jak pisać efektywne przypadki użycia”, druga w specyfikacji notacji UML. Osobiście preferuję te drugą i tylko o nie będzie tu mowa (Cockbourn zresztą jawnie wyraża niechęć do UML w swojej książce).
Dla uporządkowania dalszej treści przyjmuję, że pojęcie przypadek użycia oprogramowania i funkcjonalność oprogramowania są tożsame (a konkretnie przypadek użycia opisuje sposób realizacji funkcjonalności): obie określają to jaki efekt chce osiągnąć (do czego użyć), w konkretnym przypadku, użytkownik oprogramowania (konkretna funkcja jaką pełni oprogramowanie, to jego możliwy przypadek użycia).
Popatrzmy na etapy projektu, które wyróżniono na bazie tego, jakiej wiedzy potrzebujemy na każdym z tych etapów, by zaplanować kolejny.
Jako pierwsze powstają wymagania biznesowe opracowane na bazie oceny sytuacji biznesowej. Są one albo własnym produktem Zamawiającego albo produktem zatrudnionego do tego celu eksperta. Na bazie wymagań biznesowych (celów biznesowych) wykonuje się analizę wykonywalności tych celów, powstaje pomysł rozwiązania problemu (osiągnięcia celu) w postaci wymagań wobec rekomendowanego rozwiązania. Jeżeli istnieje (znaleziono) na rynku rozwiązanie (produkt lub standardową usługę) zostaje ono zakupione i wdrożone. Jeżeli nie (dotyczy nie tylko całości ale i części wymagań) należy rozwiązanie najpierw zaprojektować a potem dopiero zlecić wykonanie i wdrożenie (a wcześniej na bazie projektu wycenić).
Każdy z tych produktów to przedmiot osobnej umowy (lub jej etapu). Zależnie od “stopnia niewiedzy” po stronie Zamawiającego, może to być umowa o dzieło lub zlecenia. Jednak zaleca się (prawnicy zalecają) by, zawsze tam gdzie angażowany jest ekspert (usługodawca) zewnętrzny, stosować umowy o dzieło (umowa efektu), gdyż pozwala to panować i nad czasem i nad budżetem projektu oraz w przypadku sporu sądowego, możliwe było określenie przedmiotu sporu (opis tego co miało zostać wytworzone – dzieło).
Do zawarcia umowy o dzieło konieczny jest opis tego co ma powstać (opis dzieła). Patrząc od końca: zawierając umowę z dostawcą oprogramowania mamy wymagania wobec produktu gotowego (w momencie zakupu spełnia je lub nie) lub wykonany projekt tego co ma powstać. Aby powstał projekt musimy mieć określone wymagania wobec rozwiązania i wymagania (cele) biznesowe. Najtrudniej jest wycenić etap analizy sytuacji biznesowej bo tu w zasadzie nie wiemy jaka ta sytuacja jest. Wymagania biznesowe, by powstały, wymagają pozyskania wiedzy o tym jak funkcjonuje organizacja Zamawiającego i jakie zmiany planuje. To etap analizy biznesowej (model motywacji biznesowej i modele procesów biznesowych). W tym wypadku będzie to raczej umowa starannego działania z ekspertem, który tę analizę (i modele) wykona.
Pewnym rozwiązaniem problemu ryzyka umowy “czas i materiał” (nie wiemy kiedy i jakim kosztem powstanie oczekiwany produkt), jest określenie tego jaki konkretnie produkt ma powstać (opis tego, jak stwierdzimy, że prace wykonano poprawnie) i określenia czasu jaki sobie na to dajemy. Wymaga to pewnej inwestycji, poświęcenia czasu na to, ale opłaci się bo mocno obniżamy ryzyko projektu.
Konkluzja prawnika, by zawierać umowy o dzieło jeżeli tylko jest to możliwe, jest moim zdaniem słuszna. Tam gdzie nie mamy wystarczającej wiedzy by zawierać takie umowy, warto zainwestować czas by określić jednak przedmiot umowy, gdyż umowa zlecenia z ekspertem (dostawcą oprogramowania) powoduje, że Zamawiający kompletnie nie panuje nad umową: nie wie jakiego produktu oczekiwać, satysfakcja z wykonanej pracy może nadejść w trudnym do przewidzenia czasie.
Druga uwaga: jeżeli cały proces, od pierwszej analizy do dostarczenia produktu, realizuje jedna firma, mamy do czynienia z sytuacją, w której dostawca sam kontroluje stawiane mu wymagania bo sam sobie definiuje to co ma następnie wytworzyć. Taki brak kontroli rodzi poważne ryzyko nierzetelności.
