Jakość opisu wymagań jest bardzo ważna i tego nie muszę nikomu tłumaczyć. Standard ANSI/IEEE 830 formułuje szereg zaleceń, jakie powinna spełniać dobrze napisana specyfikacja wymagań. Dobrze opracowaną specyfikację charakteryzują
następujące cechy (na podstawie “Inżynieria oprogramowania” Krzysztof Sacha):
- Poprawność – specyfikacja powinna opisywać tylko te wymagania, które są potrzebne użytkownikom. Jeżeli oprogramowanie jest elementem większego systemu, to specyfikacja wymagań musi wynikać z projektu systemu i nie może być sprzeczna z jakimkolwiek innym dokumentem projektowym. W innych przypadkach weryfikacja poprawności specyfikacji może polegać tylko na subiektywnej ocenie użytkownika.
- Jednoznaczność – zapis każdego wymagania powinien mieć tylko jedną interpretację. Cecha ta jest prawie niemożliwa do osiągnięcia w dokumencie pisanym w języku naturalnym. Jako minimum można jednak wymagać unikania synonimów dla określenia tego samego pojęcia, a w razie specyficznego użycia nazw wieloznacznych – umieszczenia ich definicji w słowniku, stanowiącym uzupełnienie specyfikacji.
- Kompletność – specyfikacja powinna wymieniać wszystkie wymagania funkcjonalne i niefunkcjonalne, które muszą być spełnione. Opis wymagań powinien definiować odpowiedź systemu na wszystkie możliwe wartości danych wejściowych zarówno poprawne, jak i niepoprawne, we wszystkich stanach programu. Redakcja dokumentu powinna uwzględniać podpisy i odnośnik w tekście dla wszystkich tabel i rysunków.
- Spójność – opisy wymagań znajdujące się w specyfikacji nie mogą zawierać sprzeczności. Redakcyjnym zabiegiem wspomagającym osiągnięcie tego celu jest takie uporządkowanie tekstu, aby każde wymaganie było opisane tylko w jednym miejscu. Ponadto, we wszystkich opisach odnoszących się do tych samych działań lub obiektów powinna być użyta ta sama terminologia.
- Uporządkowanie – jeśli nie wszystkie wymagania opisane w specyfikacji są tak samo ważne dla użytkownika, to powinny być jawnie sklasyfikowane pod względem ważności, np.: wymagania niezbędne, pożądane i mile widziane. Określenie ważności wymagań poprawia czytelność dokumentu i umożliwia właściwe rozłożenie wysiłku podczas wytwarzania oprogramowania przy ograniczonych zasobach.
- Weryfikowalność – opisy wymagań powinny być tak formułowane, aby możliwe było jednoznaczne rozstrzygnięcie, czy finalny produkt spełnia te wymagania, czy nie. Problem dotyczy przede wszystkim wymagań niefunkcjonalnych. Na przykład, wymaganie: „czas odpowiedzi systemu nie powinien zazwyczaj przekraczać 10 s”, jest nieweryfikowalne, gdyż nie wiadomo dokładnie, co to znaczy „zazwyczaj”.
- Modyfikowalność – struktura i styl napisania specyfikacji powinny umożliwiać wprowadzanie zmian bez naruszania spójności dokumentu. W tym celu specyfikacja powinna być podzielona na rozdziały i punkty opisujące poszczególne wymagania, przy czym każde wymaganie powinno być opisane tylko w jednym punkcie. Związki między pokrewnymi punktami powinny być pokazane za pomocą odsyłaczy.
- Powiązanie (traceability) – każde wymaganie zamieszczone w specyfikacji wymagań powinno mieć wskazane źródło pochodzenia, w postaci np. numeru punktu jakiegoś wcześniejszego dokumentu analitycznego, aktu prawnego lub normy branżowej. W celu umożliwienia późniejszego powiązania specyfikacji z dokumentami projektowymi wszystkie punkty specyfikacji wymagań powinny być numerowane.
Oczywiście to cele do których powinniśmy dążyć opisując wymagania. Zdrowy rozsądek jest najważniejszy.
Reklama
