Wymagania określają, co produkt musi robić — jest to udokumentowane oczekiwanie dotyczące wyniku realizacji projektu. Dokument ten odzwierciedla oczekiwania klienta oraz twórcy w odniesieniu do programu, jego funkcji oraz projektu jako całości. Wymagania obejmują cechy, koszt, harmonogram i ryzyko. Tym samym wymagania stanowią stwierdzenie tego, co należy opracować, czyli precyzyjny, ilościowy opis tego, co ma zostać osiągnięte w wyniku realizacji projektu. Słabo określone wymagania są główną przyczyną problemów podczas realizacji projektu.
Wymagania określają, co należy zrobić, jak dobrze i przy jakich ograniczeniach. Jeśli wymagania są błędne, projekt i produkt będą wadliwe. Wymagania, ograniczenia i założenia dzielą problem na części. To decyduje o ogólnym powodzeniu projektu.
Rodzaje wymagań:
- Wymagania funkcjonalne określają, co musi robić dany element systemu.
- Wymagania dotyczące wydajności określają ilościowe parametry odpowiednich funkcji realizowanych przez system.
- Wymagania dotyczące ograniczeń wynikają z ograniczeń trybu działania, warunków otoczenia, względów bezpieczeństwa lub zgodności z przepisami.
- Wymagania dotyczące weryfikacji dają pewność, że system posiada określone cechy w rzeczywistym środowisku eksploatacji.
- Wymagania dotyczące interfejsów określają funkcje, cechy, tolerancje i ograniczenia wszystkich interfejsów.
- Wymagania operacyjne określają gotowość operacyjną systemu, koncentrując się na jego działaniu, a także definiują sposób interakcji systemu z użytkownikami.
W literaturze anglojęzycznej do zapamiętania cech dobrych wymagań stosuje się akronim SMART.
- Specific (konkretne) — wymaganie powinno dotyczyć tylko jednej cechy projektu lub jednej charakterystyki systemu. Powinno być sformułowane w kategoriach tego, co należy zrobić i jak dobrze, a nigdy w kategoriach możliwego rozwiązania — czyli jak to zrobić.
- Measurable (mierzalne) — mierzalny parametr wyrażany jest obiektywnie i ilościowo.
- Achievable (osiągalne) — wymaganie musi być technicznie osiągalne przy rozsądnym koszcie.
- Relevant (istotne) — wymaganie musi odpowiadać wybranemu poziomowi systemu.
- Traceable (identyfikowalne) — wymagania niższego poziomu muszą wyraźnie wynikać z wymagań wyższego poziomu i/lub być przez nie wspierane. Wymagania bez wymagań „nadrzędnych” traktowane są jako „sieroty” i należy ocenić konieczność ich realizacji.
Konieczność. Jeśli istnieją wątpliwości co do tego, czy dane wymaganie jest potrzebne, wystarczy zadać pytanie: „Jaka szkoda spotka system, jeśli to wymaganie nie zostanie uwzględnione na liście?”. Jeśli nie ma odpowiedzi, wymaganie jest prawdopodobnie zbędne.
Sprawdzalność. Zaraz po sformułowaniu wymagania należy określić, w jaki sposób można je zweryfikować. W tym celu trzeba dobrać odpowiednie kryterium zgodności.
Osiągalność. Aby wymaganie było osiągalne, musi być technicznie wykonalne w ramach danego harmonogramu i budżetu, z uwzględnieniem dodatkowych ograniczeń. Jeśli istnieje niepewność co do technicznej wykonalności wymagania, należy przeprowadzić odpowiednie badanie lub dalszą analizę. Jeśli niepewność pozostaje nawet po tym, należy sformułować cel, a nie wymaganie. Jasne jest, że nawet jeśli wymaganie jest technicznie wykonalne, może być nieosiągalne ze względu na koszt, harmonogram lub inne ograniczenia, takie jak masa. Formułowanie wymagania dotyczącego czegoś niemożliwego do zrealizowania jest bezcelowe — należy zachować pragmatyzm.
Jasność. Każde wymaganie musi wyrażać jedną myśl oraz być zwięzłe i proste. Ważne jest, aby wymaganie było jasne i jednoznaczne. Dobre wymagania często nie wymagają niczego więcej niż prostych zdań.
Wymaganie powinno być sformułowane w sposób pozytywny i nigdy nie powinno zaczynać się od przeczenia. Musi być poprawne gramatycznie, wolne od błędów typograficznych i pominięć. Na wszystkich poziomach systemu należy stosować spójną terminologię.