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

  • Statusy i priorytety wymagań Często otrzymuję pytanie jak opisuję wymagania. Otóż wielu projektach określam statusy i wymagania w następujący sposób:Status• Proponowane - wymaganie w fazie negocjacji pomiędzy klientem […]
  • Sześć myśli na temat zwinnych wymagań W ostatnich kilku projektach spotkałem się z tym, że poświęca się masę czasu na budowę modeli zaniedbując wymagania. Oto kilka dobrych rad dla zespołów stosujących zwinne modele 1. […]
  • Wprowadzenie do zarządzania wymaganiami–podstawowe definicje Wpisy na temat inżynierii wymagań zacznę od podstawowych definicji. Definicja: Wymaganie 1.Ograniczenie lub zdolność potrzebna użytkownikowi do rozwiązania problemu lub osiągnięcia […]
  • Banalne zarządzanie informacją o zmianie w Enterprise Architect Jedną z trudności, z jakimi spotykam się w EA to zarządzanie zmianą a dokładniej przyczyną zmiany. Na co dzień używam TORMIGO i tam problem ten został rozwiązany. TORMIGO monitoruje zmianę […]
  • Struktura dokumentów wymagań cz. 2 Standaryzowane struktury dokumentów powinny być dostosowywane do specyficznych wymagań projektów. Natomiast każda struktura dokumentu wymagań powinna uwzględniać następujące informacje: […]
Reklama

Zostaw komentarz

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

Przewiń do góry