Często można spotkać opisy wymagań w postaci tekstu opisującego ?wymagania funkcjonalne? i ?jakieś inne? np. wydajnościowe, systemowe itp. Nie raz są to dokumenty oparte na zaleceniach opisanych w dokumencie IEEE 830-1998, który opisuje dokumentowanie wymagań. Czy zalecenia te są rozwiązaniem problemu złych specyfikacji? Tylko troszkę.

Co znajdziemy w tych zaleceniach? Otóż zapisano tam, że specyfikacja powinna być:

• Poprawna: nie może być np. niezgodna z prawem
• Jednoznaczna: o tym za moment
• Kompletna: o tym za moment
• Spójna: brak konfliktów logicznych ale o tym także za moment
• Uporządkowana wg ważności/stabilności: np. metodą triage czyli każde wymaganie ma jeden z trzech atrybutów ? musi być, powinno być, mogło by być (inna wersja to waga wymagania dla całego projektu: duża średnia, mała)
• Weryfikowalna: można jednoznacznie stwierdzić, że wymaganie zostało zrealizowane
• Modyfikowalna: to dotyczy struktury dokumentu i narzędzia jakim powstał dokument wymagań
• Umożliwiająca śledzenie powiązań: dotyczy struktury dokumentu jak i jego formatu (dokumentacja html będzie lepsza od dokumentacji tekstowej do przeglądania ale nie do druku).

A teraz ?ten moment?. Jednoznaczność, cóż to jest? Podczas pisania specyfikacji wymagań za pomocą języka naturalnego, nigdy nie osiągniemy pełnej jednoznaczności. Jedynie zapis wymagań za pomocą metod formalnych pozwala w pełni uniknąć wieloznaczności.

Dla stosunkowo niedużych projektów poziom niejednoznaczności osiągany podczas pisania wymagań językiem naturalnym jest wystarczający. Jednak do ?poważniejszych? zastosowań (np. duże systemy wspomagające zarządzanie np. CRM czy w szczególności systemy krytyczne) należy specyfikować wymagania za pomocą metod formalnych lub tak zwanych quasi-formalnych. Metody formalne to matematyczne zapisy, o których tu nie będziemy pisać gdyż są rzadko stosowane z uwagi koszty.

Metody quasi-formalne to metody zorientowane na modele. Modele można praktycznie uznać za jednoznaczne choć obecnie nie ma narzędzi to automatycznego sprawdzania ich jakości (są dla metod formalnych). Poprawny model jednak wykonany jest za pomocą poprawnej notacji a tu można weryfikować automatycznie jej gramatykę i słowniki (syntaktykę i semantykę).

A jak odpowiedzieć na pytania: Czy wymagania są kompletne (czy czegoś nie pominęliśmy)? Czy są logicznie spójne (może ich być kilkadziesiąt, kilkaset i więcej)? Czy wymagania nie są redundantne (czy nie opisują tych samych zachowań różnym językiem)?

Na moment zmiana dziedziny. Wyobraźmy sobie, że mamy projekt polegający na pomalowaniu elewacji domów w pewnym mieście. Z analizy rentowności wynika, że możliwe jest pomalowanie tylko domów mających nie więcej niż cztery kondygnacje. Potrzebny jest dokument z listą tych budynków i ich adresów. Jaki dokument otrzymamy jeżeli wykonamy go na bazie wywiadów z pewnym odsetkiem mieszkańców tego miasta? A teraz drugie pytanie: czy dokument, który powstanie na podstawie mapy miasta z danymi o wszystkich budynkach będzie lepszy?

Dlatego moim zdaniem zalecenie IEEE830-1998 jest bardzo dobrym spisem treści dokumentu wymagań wraz z komentarzami ale absolutnie nie opisuje jak taki, wysokiej jakości dokument stworzyć (nie licząc spisu treści). Tu kłania się metodyka pozyskiwania wymagań oraz sposób ich specyfikowania.

Pozyskiwanie wymagań

Podobnie jak w przypadku opisanej powyżej listy budynków kompletne i spójne wymagania najłatwiej zrobić na bazie modelu organizacji, firmy itp.. Zwracam uwagę, że plan miasta to nic innego jak jego model z perspektywy topologii. Należy więc najpierw wykonać model organizacji, a jest nim tu model procesów biznesowych. Na tym modelu (podobnie jak budynki na planie) zaznaczamy czynności zakwalifikowane do zakresu projektu. Czynności te staną się przypadkami użycia oprogramowania. Każdy taki przypadek ma automatycznie swój kontekst (miejsce na mapie procesów) i aktora (rola na napie procesów), wystarczy opisać jego scenariusz i zbudować prototyp ekranu lub dokumentu. Lista taka wykonana na bazie modelu procesów z zasady jest spójna i kompletna.

Paradoksalnie wykonanie takiego modelu jest tu największą trudnością. Dlaczego? Tworząc go należy bezwzględnie panować na jego złożonością, panować nad subiektywizmem osób z którymi prowadzimy wywiady, rozumieć strategię modelowanej firmy i jej model biznesowy, wiele innych. Identyfikacja procesów sama w sobie jest trudna, wymaga posiadania metod ich identyfikacji i weryfikacji poprawności samej analizy i modelu, to jednak temat na książkę a nie na taki artykuł.

Wymagania pozafunkcjonalne i interfejsy

Tu pojawia się pierwszy rozdźwięk pomiędzy metodyką, którą np. ja stosuję (nie ja jeden!) a zaleceniami IEEE. Otóż takie cechy jak wydajność, niezawodność czy bezpieczeństwo w kategoriach metodyki, którą stosuję stanowią ograniczenia nakładane na funkcjonalności. Jeżeli np. chcemy powiedzieć, że raport X musi się wykonywać w czasie nie dłuższym niż N sekund to jest to nic innego jak ograniczenie nałożone na przypadek użycia Tworzenie raportu X czyż nie? Podobnie niezawodność np. dostępność czynności związanych z tworzeniem raportów finansowych nie może zejść poniżej 99,99% czasu w skali roku. I tak dalej?

Interfejsy to także nic innego jak przypadki użycia. Np. system musi udostępniać dane magazynowe w postaci XML dla każdego uprawnionego zewnętrznego systemu (jest nawet aktor: zewnętrzny system). Przypadkiem użycia jest tu przypadek żądania tych danych przez zewnętrzny system. Przykłady można mnożyć. Dzięki takiemu podejściu unikamy np. wymagań w rodzaju: system ma być dostępny co najmniej 99,99% czasu w skali roku bo tą metodą wszystkie funkcjonalności, nawet mało istotne, zrównujemy w górę czyli po prostu podnosimy koszty systemu właściwie bez uzasadnienia.

A gdzie przetwarzane dane?

Powyższe zalecenia nie wymagają wyspecyfikowania modelu danych, podstawowej informacji. Oczekiwanie, że model danych zaprojektują dopiero programiści to oczekiwanie od ludzi nie znających zamawiającego, że opiszą jego biznes.

Tyle na dzisiaj, ale na zakończenie.

Nie jest to krytyka zaleceń IEEE830-1998 a zwrócenie uwagi na to, że same one nie stanowią lekarstwa podobnie jak sam tytuł i spis treści powieści nie czyni jeszcze z pisarza kandydata do nagrody Pen Clubu.

Co piszą inni?

Powołam się tu na zawartość książki Iana Sommervill?a ?Inżynieria oprogramowania?. Wymagania dzielimy na:

1. Funkcjonalne czyli jakie usługi ma oferować system
2. Niefunkcjonalne to ograniczenia usług i funkcji systemu
3. Dziedzinowe, które pochodzą z dziedziny zastosowania systemu

?Standard IEEE nie jest idealny, zawiera jednak bardzo wiele cennych rad, jak pisać wymagania i unikać problemów. Jest zbyt ogólny, aby sam mógł być standardem firmowym? (Ian Sommerville ? Inżynieria oprogramowania, WNT Warszawa 2003).

Metodyka, którą stosuję

1. Wymagania funkcjonalne to przypadki użycia systemu
   1. Przypadki użycia systemu to czynności wyselekcjonowane z modelu procesów na bazie zakresu projektu.
2. Wymagania niefunkcjonalne to ograniczenia nakładane na poszczególne przypadki użycia (mogą być grupowane np. maksymalny czas odpowiedzi systemu nie może przekroczyć 1 s. z wyjątkiem raportów, gdzie maksymalny czas odpowiedzi to 1 minuta)
3. Wymagania dziedzinowe opisywane są modelem dziedziny systemu (diagram klas lub ERD)

c.d. kiedyś nastąpi…