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.

Zostaw odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Możesz użyć tych HTML tagów i atrybutów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Close