Źródłem kryteriów stanowiących o jakości dokumentacji wymagań jest standard IEEE 830. Zgodnie z tym standardem dokumentacja powinna charakteryzować się następującymi cechami:

A więc, specyfikacja powinna być:

1. Poprawna (ang. correct)

Specyfikacja wymagań jest poprawna tylko wtedy, gdy każde wymaganie to wymaganie, które system powinien spełniać. Aby zapewnić poprawność należy porównać specyfikację wymagań z innymi dokumentami projektu,
Standardami i regulacjami, których system musi przestrzegać (np. nie można zawrzeć żadnych wymagań, które będą sprzeczne z polskim prawem).
Kontrolę poprawności ułatwia śledzenie powiązań (ang. traceability).

2. Jednoznaczna (ang. unambiguous)

Specyfikacja jest jednoznaczna, gdy każde wymaganie można zinterpretować tylko w jeden sposób; nie ma miejsca na domyślanie się i wybieranie jednej „najbardziej prawdopodobnej” alternatywy. Wieloznaczność można w pewnym stopniu wyeliminować opracowując słownik wszystkich terminów, które mogą być niezrozumiałe, lub rozumiane na wiele sposobów – szczególnie dotyczy to terminów charakterystycznych dla danej branży (tzw. slang branżowy). Należy mieć na uwadze, że specyfikacja wymagań tworzona wyłącznie za pomocą języka naturalnego, nigdy nie będzie w pełni jednoznaczna, gdyż różni odbiorcy mogą różnie odbierać zapis tekstu. Jedynie zastosowanie metod formalnych pozwala w pełni uniknąć wieloznaczności. Większość projektów toleruje pewien akceptowalny (dla nich) poziom niejednoznaczności wynikający z pisania wymagań językiem naturalnym jest wystarczający. Projekty rozwijające np. systemy krytyczne ze względu na bezpieczeństwo, powiązane z dużym ryzykiem w przypadku niespełnienia, lub nieprawidłowej implementacji wymagań, specyfikują wymagania za pomocą metod formalnych.

3. Kompletna (ang. complete)

Specyfikacja wymagań jest kompletna tylko wtedy, gdy spełnione są trzy warunki:

• zawiera wszystkie istotne wymagania (nie tylko funkcjonalne, lecz również niefunkcjonalne),
• określa odpowiedź systemu na każdą informację wejściową, dla danych zarówno poprawnych, jak i niepoprawnych,
• zawiera referencje do wszystkich diagramów, tabel, pojęć słownikowych.

4. Spójna (ang. consistent)

Spójność rozumiemy jako spójność wewnętrzną, czyli np. zgodność z dokumentem wyższego poziomu.

Niespójność może wynikać z:

• konfliktów pomiędzy opisywanymi obiektami: np. jedno wymaganie mówi, że zestawienie danych ma być w formie tabelarycznej, natomiast drugi, że w formie tekstowej i to wyłącznie na wydruku,
• konfliktów logicznych pomiędzy czynnościami: np. jedno wymaganie mówi, że system wyliczy wartość wg wzoru X, a drugie stwierdzi, że ta wartość ma być wyliczona wg wzoru Y,
• używania różnych terminów do opisu tych samych obiektów.

5. Uporządkowana wg ważności/stabilności (ang. ranked for importance/stability)

Uporządkowanie to (określenie priorytetów) ułatwia to programistom podjęcie właściwych decyzji dot. architektury oraz skupienia się na najważniejszych wymaganiach.

Dzięki priorytetom wymagań, można prościej rozwiązać konflikty w przypadku niespójności wewnętrznej. Określenie stabilności natomiast pomaga wybrać te obszary specyfikacji wymagań, które raczej nie ulegną już zmianie – takie fragmenty mogą być implementowane w pierwszej kolejności.

6. Weryfikowalna (ang. verifiable) - gdy każde wymaganie jest weryfikowalne, czyli można w jednoznaczny sposób powiedzieć, że zostało wykonane, lub sprawdzić, czy zostało wykonane we właściwy sposób. Czyli innymi słowy – wymaganie można pokryć przypadkami testowymi i przetestować.

7. Modyfikowalna (ang. modifiable)

Wymagania mogą się zmienić. Tym samym powinna móc się zmieniać dokumentacja wymagań. Dokumentacja jest modyfikowalna jeśli jej struktura i styl pozwalają dokonać w niej zmian w prosty, kompletny i spójny sposób.

Elementy, które utrudniają modyfikowalność to:

• redundancja - jedno wymaganie jest wymienione w wielu miejscach,
• skomplikowana struktura dokumentu,
• mieszanie wymagań - jedno miejsce w specyfikacji zawiera wymagania nie powiązane ze sobą, natomiast jedno wymaganie zapisane jest w różnych miejscach.

8. Umożliwiająca śledzenie powiązań (ang. traceable)

Czyli pochodzenie każdego wymagania jest znane i dokument umożliwia zarządzanie referencjami pomiędzy wymaganiami, a innymi artefaktami.


Autor: Karolina Zmitrowicz