Odpowiedź.

SRS to usystematyzowany dokument opisujący wszystkie wymagania dotyczące systemu, który ma zostać opracowany. Jego celem jest jak najdokładniejsze i najpełniejsze "przetłumaczenie" oczekiwań biznesowych na język zespołu projektowego. Główne sekcje:

1. Wprowadzenie (cele, zakres zastosowania, terminologia)
2. Opis produktu i kontekst biznesowy
3. Opis użytkowników i ich ról
4. Wymagania funkcjonalne (use cases, user stories)
5. Wymagania niefunkcjonalne (bezpieczeństwo, wydajność, użyteczność)
6. Ograniczenia
7. Interfejsy
8. Zewnętrzne zależności
9. Kryteria akceptacji wymagań
10. Słownik terminów

Kluczowe cechy:

SRS zawiera zarówno wymagania funkcjonalne, jak i niefunkcjonalne.
Wymagania są formułowane jednoznacznie, z minimalną dwuznacznością.
W SRS obowiązkowo odzwierciedlono scenariusze użycia, ograniczenia, kryteria sukcesu.

Aby kontrolować kompletność i jakość, analityk wykorzystuje listy kontrolne weryfikacji, szablony, standardy IEEE 830 oraz regularne uzgodnienia z kluczowymi interesariuszami.

Pytania z podchwytliwością.

Czy wystarczy opisać tylko user stories, aby mieć pełnoprawną SRS?

Nie. User stories pokazują stronę funkcjonalną, ale nie obejmują wymagań niefunkcjonalnych, ograniczeń, interfejsów, scenariuszy wyjątków i kryteriów akceptacji.

Czy można używać różnych terminów dla tej samej jednostki w dokumencie?

Nie. Należy obowiązkowo zachować jednolitość terminologii: w tym celu tworzy się słownik terminów i przeprowadza się wzajemną recenzję dokumentu.

Czy SRS powinna zawierać wymagania dotyczące bezpieczeństwa i wydajności?

Tak. Wymagania niefunkcjonalne są krytycznie ważne: ich brak prowadzi do długu technologicznego lub braku możliwości eksploatacji systemu.

Typowe błędy i antywzorce

Niedostateczna szczegółowość wymagań, brak przykładów i kryteriów akceptacji.
Używanie niejednoznacznych sformułowań: "szybko", "wygodnie", "niezawodnie" bez cech ilościowych.
Ignorowanie wymagań niefunkcjonalnych.

Przykłady z życia

Negatywny przypadek

SRS napisana tylko na podstawie user stories, pominięto wymagania dotyczące wydajności i bezpieczeństwa.

Zalety:

Szybkie przygotowanie dokumentacji.

Wady:

Projekt nie przeszedł audytu bezpieczeństwa, nie wytrzymuje wymaganego liczby jednoczesnych użytkowników.

Pozytywny przypadek

SRS obejmuje kompletną listę niezbędnych atrybutów - funkcjonalność, wymagania niefunkcjonalne, kryteria akceptacji, glosariusz.