Dokumenty wymagań zawierają dużą ilość różnych informacji. Aby umożliwić sprawne posługiwanie się tym dokumentem powinien on spełniać pewne standardy dotyczące jego układu oraz treści. W trakcie tworzenia dokumentu wymagań inżynierowie powinni określić i stosować określoną strukturę dokumentu. Struktura ta powinna być dopasowana do właściwości danego projektu i przestrzegać ograniczeń na niego nałożonych. Inżynierowie wymagań podczas tworzenia specyfikacji wymagań mogą skorzystać ze standaryzowanych struktur dokumentów lub zdefiniować własną strukturę, która będzie dopasowana do specyficznych wymagań projektu i interesariuszy.
Zalety wykorzystania standaryzowanych struktur dokumentów są ogólnie znane. Robiąc małe zestawienie to zastosowanie standardowej struktury pozwala na:
- szybsze włączenie nowych członków zespołu do projektu
- odnalezienie w dokumentacji pożądanej informacji
- selektywne czytanie oraz selektywną walidację dokumentu wymagań
- automatyczną weryfikację dokumentu wymagań (np. w odniesieniu do kompletności)
- proste ponowne użycie zawartości dokumentu wymagań
Struktury dokumentów są znane metodyk i standardów. Nie mniej jednak poniżej krótkie zestawienie.
Rational Unified Process
W metodyce Rational Unified Process, która jest często stosowana podczas tworzenia systemów wykorzystując metody zorientowane obiektowo, klient przygotowuje model biznesowy organizacji. Model biznesowy zawiera artefakty środowiska biznesowego, w którym funkcjonuje organizacja. Artefaktami mogą być np. zasady biznesowe, biznesowe przypadki użycia, czy też cele biznesowe. Na podstawie tego modelu inżynierowie wymagań przygotowują specyfikację wymagań na system (SRS), która dokumentuje wszystkie wymagania dla tworzonego oprogramowania. Struktura specyfikacji wymagań na system jest bardzo zbliżona do struktury proponowanej przez standard IEEE 830.
Standard IEEE 830-1998
Standard IEEE 830-1998 dotyczy zalecanych praktyk dla specyfikacji wymagań na system. Standard ten sugeruje podział dokumentu wymagań na trzy główne rozdziały:
- Rozdział zawierający informacje wprowadzające (np. cele systemu, granicę systemu)
- Rozdział zawierający ogólny opis tworzonego systemu (np. perspektywa systemu, opis przyszłych użytkowników, ograniczenia dla procesu produkcyjnego)
- Rozdział zawierający specyfikację wymagań (np. wymagania funkcjonalne, wymagania dotyczące wydajności, interfejsy)
V-Model
V-Model opisuje proces tworzenia oprogramowania zaproponowany przez niemieckie Federalne Ministerstwo Spraw Wewnętrznych, które definiuje różne struktury dla dokumentu wymagań w zależności od tego, kto je tworzy.
Specyfikacja Wymagań Klienta jest tworzona przez klienta i zawiera opis pożądanych przez klienta cech dotyczących tworzonego oprogramowania. Może także zawierać wymagania użytkowników oraz ograniczenia systemu i procesu produkcyjnego. Odpowiada na pytanie: Co jest robione i po co?
Specyfikacja Wymagań na System bazuje na Specyfikacji Wymagań Klienta i zawiera propozycję implementacji zaproponowanych przez klienta potrzeb. Specyfikacja Wymagań na System jest uściśleniem wymagań i ograniczeń zawartych w Specyfikacji Wymagań Klienta.
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
