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
Zintegrowane środowisko wytwarzania aplikacji web’owych na platformie .NET

W artykule przedstawiono opis pakietu narzędziowego VS.NET (Microsoft) z Rational XDE (IBM) do wytwarzania aplikacji webowych pracujących w środowisku urządzeń więcej

Rational Software Architect Pierwszy Krok

Technorati Tagi: Rational Software Architect,inżynieria oprogramowania W artykule zaprezentowano jak rozpocząć pracę z i opis elementów tego narzędzia CASE. Środowisko więcej

Wstęp do projektowania aplikacji w Rational Software Architect

Rational Software Architect jest kolejną po Rational Rose i Rational XDE generacją narzędzi wspierających twórców oprogramowania w czasie projektowania. RSA więcej

Rational Unified Process – Wstęp

Rational Unified Process jest zunifikowanym procesem wytwórczym oprogramowania dostarczającym praktycznych wskazówek, wzorców dokumentów i narzędzi, szablonów dokumentów oraz przykładów postępowania więcej

Reklama
MODESTO - licencje Enterprise Architect
Scroll to Top