Cechy perfekcyjnych wymagań na system

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.

Podobne wpisy

  • Wymagania są najważniejsze Podczas mojej pracy zauważyłem, że spory problem stanowią wymagania. Trudnością nie jest ich spisanie. Trudnością jest ich wyartykułowanie. Pomijam turbulencje związane z celem zamiany czy […]
  • Dedykowana metodyka prowadzenia projektu Koniec roku pozwala mi wreszcie odetchnąć. Ostatnie tygodnie były mega pracowite. To czym chcę się pochwalić to fakt iż w tym roku udało się opracować dedykowane metodyki prowadzenia […]
  • Plan zarządzania wymaganiami Plan zarządzania wymaganiami to dokument, który opisuje zasady postępowania z wymaganiami. W moim odczuciu to jeden z najważniejszych dokumentów, gdyż w jawny sposób opisuje szereg ważnych […]
  • Zarządzanie wymaganiami – dobre praktyki Ian Sommerville i Pete Sawyer w "Requirements Engineering: A Good Practice Guide" opisali, ponad 15 lat temu, metodę oceny i doskonalenia procesów inżynierii wymagań. Opiera się ona na […]
  • Zarządzanie relacjami pomiędzy wymaganiami Zarządzanie wymaganiami to ważny element procesu wytwórczego oprogramowania. Jednym z jego elementów budowanie i zarządzanie relacjami pomiędzy wymaganiami. Najczęściej spotykanym jest […]
Reklama

Leave a Comment

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