Wpadł mi niedawno do skrzynki mailowej kolejny artykuł serwisu Modern Analyst, cytat:

If you create only one view of the requirements, you must believe it. You have no other choice. If you develop multiple views, though, you can compare them to look for disconnects that reveal errors and different interpretations. (źr. Why Create Multiple Requirements Views? > Business Analyst Community & Resources | Modern Analyst > Business Analyst Articles & Systems Analysis Articles | Modern Analyst).

Autor sugeruje by łączyć wymagania funkcjonalne z przypadkami użycia, testami, modelami. W dużym uproszczeniu: jeżeli mamy tylko jedną perspektywę wymagań (np. w postaci listy wymagań funkcjonalnych i pozafunkcjonalnych) musimy im wierzyć bo nie mamy ich weryfikatora (nie mamy innego wyjścia). Troszkę to łączenie “każdy z każdym” chyba jednak nie ułatwia:

Problem kompletności i spójności wymagań jest dość trudny do rozwiązania. Wymagania niekompletne i niespójne potrafią zaś zabić projekt, wady specyfikacji (takie jak niekompletność i niespójność) skutkują odkrywaniem ich w trakcie projektu, rośnie w niekontrolowany sposób złożoność projektu.

Jeżeli wypracujemy więcej perspektyw, możemy je skonfrontować i porównać, wykrywając ewentualne nieścisłości i błędy.  Także [[BABoK]] (rodem z [[IIBA]]) zaleca utrzymywanie tak zwanej śladowalności, to jest wywodzenia np. wymagań na oprogramowanie z wymagań biznesowych, a tych z celu projektu. Nadal jednak mamy tylko jedno źródło dla każdego wymagania. To rodzi pewne ryzyko, gdyż brak weryfikatora powoduje, że ryzyko błędu pozostaje.

Od kilku lat stosuje metodę polegającą na testowaniu lub specyfikowaniu relizacji wymagań. Rok 2008, na zakończenie artykułu IEEE830-1998 ? czy produkuje dobre wymagania?  napisałem:

Metodyka, którą stosuję

1. Wymagania funkcjonalne to przypadki użycia systemu; 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?

Tak więc  mamy ciąg dalszy :). Wspomniałem o wymaganiach dziedzinowych. Osobiście traktuję je właśnie jako “trzecią nogę” wspierającą model wymagań. Funkcjonalność (usługa systemu) mówi nam czego oczekuje użytkownik, jednak “usługa systemu” opisuje system jako tak zwaną “czarną skrzynkę”. Jeżeli uzupełnimy opis wymagań elementami modelu dziedziny, dodamy weryfikator w postaci opisu wnętrza tej czarnej skrzynki (wymagamy nie tylko “tworzenia faktury VAT” ale definiujemy jej strukturę, to się nazywa opis “białej skrzynki”).

Jak wspomniałem swego czasu, opracowując wymagania na gotowe i zaawansowane oprogramowanie nie ma sensu jego projektowanie. Zbyt szczegółowa specyfikacja zbliża nas do projektu, a my chcemy jednak coś gotowego (ma być taniej i szybciej).

Standardowo, specyfikując wymagania,  należy skupić się na tym do czego będziemy używali oprogramowania a nie na tym jak ono to robi. Jednak “do czego” oznacza “co będziemy tworzyć i przetwarzać”. Co więc robić? Proszę popatrzeć:

Tak więc wymaganie:

1. kojarzymy z realizującym je modelem (przypadkiem użycia, procesem, elementem dziedziny),
2. kojarzymy z testem sprawdzającym czy zostało spełnione (z pomocą dobranego scenariusza testowego).

Powszechnie posługujemy się wymaganiami funkcjonalnymi. Czym jest wymaganie dziedzinowe? Wyobraźmy sobie, że chcemy opisać wszystkie metody i scenariusze wystawienia faktury VAT. Będzie ich bardzo dużo, zapewne możliwe będą takie, których nie “wymyśliliśmy”.  Bezpieczniej jest opisać fakturę VAT wraz z regułami rządzącymi jej poszczególnymi polami, zamiast uznać ją za “czarną skrzynkę” i próbować opisać metodą “jak można jej użyć”.

Młotek można opisać tym “do czego będzie używany” (przypadki użycia) lub “jak wygląda”. Nie raz druga metoda jest bezpieczniejsza, jednak jest to już projektowanie i należy to robić świadomie. Czy to źle? Nie, bo nie raz zaprojektowanie jest mniej ryzykowne niż opis “do czego” (zamiast złożonego opisu wielu zastosowań młotka, prościej jest go narysować).

Zawsze, przy każdym wymaganiu, należy podjąć decyzję, czy realizacja wymagania przez dostawcę stanowi ryzyko (i jakie). Sami projektujemy realizację (tworzymy model) zawsze, gdy to ryzyko jest za duże by je akceptować. Podobnie traktujemy testy. Projektujemy je, gdy koszt niespełnienia danego wymagania przekracza dopuszczalny poziom. Testem może być także model (np. procesu biznesowego).

Takie podejście powoduje, że zanim jeszcze dotkniemy gotowego produktu (tu niestety już po jego wyborze) możemy po pierwsze: przetestować samą specyfikację a po drugie przekazać potencjalnemu dostawcy (na etapie zapytania) pełną informację o tym, czego oczekujemy od produktu i jak to sprawdzimy.

Powyższe podejście w postaci ‘full wypas” może być pracochłonne, dlatego możliwe są warianty pośrednie, czyli tylko dla wymagań oznaczonych jako ryzykowne budujemy testy lub modele, jednak mamy narzędzie do panowania nad tym ryzykiem. Po drugie zyskujemy narzędzie do weryfikacji, odbiór oprogramowania nie będzie sprawdzaniem pokaźnej i ryzykownej zarazem listy dziesiątek cech, będzie “jazdą próbną na sucho”, a więc relatywnie tanią i pewną metodą testów: dostawca deklaruje (oferta na nasze zapytanie) zgodność z naszymi wymaganiami, a te są weryfikowalne. Należy rozważać zawsze kojarzenie modeli z testami.

Kiedy jeszcze piszemy realizację”? Gdy chcemy pozostać jej autorami i chronić nasz know-how.