Aby dokument wymagań mógł stanowić podstawę dla poszczególnych etapów cyklu życia oprogramowania musi on spełniać podstawowe kryteria jakości. Podstawowe kryteria jakości dla dokumentu wymagań – podążając za IEEE 830-1998 to:
- Jednoznaczność i spójność
- Przejrzysta struktura
- Modyfikowalność oraz rozszerzalność
- Kompletność
- Identyfikowalność
Jednoznaczność i spójność
Jednoznaczność i spójność dokumentu wymagań jest możliwa tylko do osiągnięcia, jeżeli wszystkie zawarte w nim wymagania są jednoznaczne i spójne. Żadne wymaganie nie może przeczyć samemu sobie, jak i wszystkim innym wymaganiom.
Przejrzysta struktura
Odpowiednio wyczerpująca i przejrzysta struktura dokumentu wymagań powoduje, że jest on łatwy do analizy przez wszystkich interesariuszy. Przejrzysta struktura pozwala na czytanie tych fragmentów dokumentu, które są istotne dla danego interesariusza, przez co zaoszczędza jego czas i poprawia zrozumienie przez niego wymagań.
Modyfikowalność oraz rozszerzalność
W trakcie życia oprogramowania wymagania na system są dodawane, zmieniane i usuwane. Dokument wymagań, jak i jego struktura, musi być łatwa w modyfikacji i rozszerzaniu. Jednocześnie zmiany w specyfikacji wymagań powinny być odpowiednio dokumentowane.
Identyfikowalność
Ważną cechą dokumentu wymagań jest możliwość identyfikacji powiązań pomiędzy tym dokumentem, a dokumentami powiązanymi (np. modelem procesów biznesowych lub planem dla testów).
Kompletność
Dokument wymagań musi być kompletny. Musi zawierać wszystkie istotne wymagania wraz z ich opisami. Każde zawarte w tym dokumencie wymaganie także musi być kompletne. Dla każdej udokumentowanej funkcjonalności specyfikacja powinna zawierać opis możliwych wejść, czynników sterujących oraz oczekiwanych rezultatów. Opis ten powinien także zawierać charakterystykę możliwych błędów i wyjątków oraz pożądane reakcje systemu na ich wystąpienie.
Kompletność dokumentu dotyczy także formalnych czynników, takich jak opisy rysunków i tabel, czy dostępności spisu treści i skorowidza.
Wymagania powinny być (podążając za IEEE 830-1998 ):
- Uzgodnione: Wymagania są uzgodnione, jeżeli zostaną ona uznane jako prawidłowe i uzasadnione przez wszystkich interesariuszy.
- Mieć nadaną rangę: Każde zdefiniowane wymaganie powinno mieć nadaną rangę określającą wagę wymagania. Waga może być uzależniona od potrzeby implementacji danej funkcjonalności, obostrzeń prawnych oraz innych czynników nadających priorytet wymaganiom. Ranga wymagania może być wykorzystana do podjęcia decyzji, które wymagania powinny zostać zaimplementowane w pierwszych fazach procesu tworzenia oprogramowania lub które wymagania mogą zostać pominięte ze względu na ograniczenia zasobów dla projektu.
- Jednoznaczne: Wymaganie musi być zrozumiałe przez wszystkich interesariuszy w ten sam sposób, nie pozostawiając możliwości ich różnej interpretacji.
- Aktualne: Udokumentowane wymagania muszą reprezentować aktualne fakty i ograniczenia dotyczące kontekstu systemu.
- Poprawne: Wymaganie jest poprawne jeśli reprezentuje idee interesariuszy. Oznacza to także, że wymaganie nie wyraża więcej niż wymagają tego interesariusze.
- Spójne: Wymagania muszą być spójne z innymi wymaganiami. Wymagania nie mogą przeczyć innym wymaganiom, a także sobie samym.
- Weryfikowalne: Wymaganie musi być opisane w takich sposób, aby możliwe było zweryfikowanie zrealizowania tego wymagania,
- Możliwe do zrealizowania: Wymaganie musi być możliwe do zaimplementowania uwzględniając ograniczenia dla projektu (prawne, techniczne, czy finansowe).
- Identyfikowalne: Wymaganie jest identyfikowalne, jeżeli możliwa jest identyfikacja jego pochodzenia, jego realizacja oraz powiązania z innymi artefaktami. Wymaganie powinno posiadać swój indywidualny identyfikator, dzięki któremu będzie możliwe odwoływanie się do tego wymagania w dokumencie wymagań lub innych powiązanych dokumentach.
- Kompletne: Każde wymaganie musi kompleksowo opisywać funkcjonalność, którą specyfikuje. W przypadku wymagań, które są aktualnie opracowywane i niekompletne powinny one zostać w odpowiedni sposób oznaczone (np. przez nadanie im odpowiedniego statusu).
- Zrozumiałe: Każde wymaganie musi być w pełni zrozumiałe dla wszystkich interesariuszy, których dotyczy.
Dążenie do zestawu wymagań po wyżej wymienionych cechach jest nadrzędnym celem inżyniera wymagań.
Tekst zainspirowany książką: Klaus Pohl, Chris Rupp „Requirements engineering fundamentals : a study guide for the Certified Professional for Requirements Engineering exam : foundation level”, IREB compliant Wydawnictwo: Rocky Nook Inc, 2011
