Dokument wymagań systemowych (SRS) - szablon z przykładem

Co to jest dokument wymagań systemowych?

Dokument wymagań systemowych, często nazywany SRS (Software Requirements Specification), opisuje wymagania, które system musi spełnić, jego interfejsy, ograniczenia oraz sposób weryfikacji. Nie projektuje architektury. Ustala kontrakt między potrzebą biznesową a rozwiązaniem technicznym.

Dobry SRS pozwala odpowiedzieć na trzy pytania przed rozpoczęciem implementacji:

1. Co system ma robić?
2. Jakie warunki jakościowe i ograniczenia musi spełnić?
3. Jak sprawdzimy, że wymaganie zostało zrealizowane?

Jeśli dokument nie pozwala napisać testu akceptacyjnego albo podjąć decyzji o zakresie, zwykle jest jeszcze zbyt ogólny.

PRD, SRS i SDD - różnice

Te dokumenty często są wrzucane do jednego worka, ale rozwiązują inne problemy.

PRD ustala kierunek produktu. SRS zamienia ten kierunek w sprawdzalne wymagania. SDD opisuje implementację. W mniejszym projekcie mogą być trzema sekcjami jednego pliku, ale granice odpowiedzialności nadal warto zachować.

Więcej o pierwszym i trzecim dokumencie znajdziesz w tutorialu PRD - co to jest i jak przygotować SDD dla agenta AI.

Szablon dokumentu wymagań systemowych

Poniższy szablon jest celowo krótszy niż formalna specyfikacja dla systemu regulowanego. Ma wystarczyć zespołowi produktowo-technicznemu do rozpoczęcia implementacji bez zgadywania.

# SRS: [Nazwa systemu lub funkcji]

## 1. Cel dokumentu
[Jaki zakres opisuje ten dokument i dla kogo powstał]

## 2. Kontekst i zakres
### W zakresie
- [Funkcja lub proces]

### Poza zakresem
- [Świadomie odłożona funkcja]

## 3. Użytkownicy i role
| Rola | Potrzeba | Uprawnienia |
|---|---|---|
| [Rola] | [Co chce osiągnąć] | [Do czego ma dostęp] |

## 4. Wymagania funkcjonalne
### FR-001: [Nazwa wymagania]
- Opis: System musi...
- Wejście: ...
- Wynik: ...
- Warunki błędne: ...
- Priorytet: Must / Should / Could
- Kryteria akceptacji:
  - Given ... When ... Then ...

## 5. Wymagania niefunkcjonalne
### NFR-001: Wydajność
- 95 percent żądań kończy się poniżej [X] ms przy [Y] użytkownikach.

### NFR-002: Dostępność
- Miesięczna dostępność wynosi co najmniej [X] percent.

### NFR-003: Bezpieczeństwo
- [Wymaganie dotyczące uwierzytelnienia, autoryzacji lub danych]

## 6. Interfejsy i integracje
| System | Kierunek | Dane | Protokół | Zachowanie przy awarii |
|---|---|---|---|---|
| [Nazwa] | wejście/wyjście | [zakres] | REST/event/file | [retry/fallback] |

## 7. Dane
- Encje i najważniejsze pola
- Źródło prawdy dla danych
- Retencja i usuwanie
- Dane osobowe lub wrażliwe

## 8. Ograniczenia
- Wymagany stack lub platforma
- Limity prawne, kosztowe i czasowe
- Zależności od innych zespołów

## 9. Założenia i pytania otwarte
- ASSUMPTION-001: ...
- OPEN-001: ... / właściciel / termin decyzji

## 10. Macierz śledzenia
| Wymaganie | Test | Status |
|---|---|---|
| FR-001 | AT-001 | planowane |

Przykład wymagania, które da się zweryfikować

Słabe wymaganie:

System ma szybko wysyłać powiadomienia.

Nie wiadomo, co znaczy „szybko”, przy jakim obciążeniu i co dzieje się przy błędzie.

Lepszy wariant:

### NFR-004: Czas dostarczenia powiadomienia

- 95 percent powiadomień email trafia do dostawcy w ciągu 30 sekund
  od zapisania zmiany statusu zamówienia.
- Pomiar obejmuje obciążenie do 20 zmian statusu na sekundę.
- Po błędzie system wykonuje maksymalnie 3 próby z rosnącym opóźnieniem.
- Po wyczerpaniu prób zapisuje zdarzenie do kolejki błędów i wysyła alert.

Teraz zespół może zaprojektować test obciążeniowy, monitoring i obsługę awarii. Wymaganie nie narzuca jeszcze Azure Service Bus, RabbitMQ ani konkretnej biblioteki retry. To decyzje należące do SDD.

Jak pisać wymagania funkcjonalne

Każde wymaganie funkcjonalne powinno mieć stabilny identyfikator, jeden główny efekt i kryterium akceptacji. Unikaj punktów łączących pięć zachowań słowem „oraz”. Rozbicie ich ułatwia estymację, testowanie i późniejsze śledzenie zmian.

Praktyczny filtr:

• czy wymaganie opisuje obserwowalne zachowanie,
• czy wskazuje rolę lub źródło wywołania,
• czy definiuje wynik i ważne błędy,
• czy można powiązać je z testem,
• czy nie przemyca decyzji architektonicznej.

Jak pisać wymagania niefunkcjonalne

„System ma być skalowalny i bezpieczny” nie jest wymaganiem. To życzenie. Wymaganie niefunkcjonalne potrzebuje miary albo jednoznacznej reguły.

Zamiast „API ma być szybkie” podaj percentyl, czas i obciążenie. Zamiast „dane mają być bezpieczne” wskaż klasę danych, wymagane szyfrowanie, zasady dostępu i retencję. Zamiast „system ma działać zawsze” ustal SLO, RPO i RTO.

Jak używać SRS z agentem AI

Agent może pomóc wykryć sprzeczności, brakujące scenariusze błędne i wymagania, których nie da się przetestować. Nie powinien sam dopisywać potrzeb biznesowych.

Dobry prompt kontrolny:

Przejrzyj ten SRS jako analityk wymagań.
Nie projektuj architektury i nie dopisuj funkcji.
Wskaż wyłącznie:
1. wymagania niejednoznaczne,
2. brakujące przypadki błędne,
3. wymagania bez mierzalnego kryterium,
4. sprzeczności między sekcjami.
Dla każdego problemu podaj identyfikator wymagania i jedno pytanie do właściciela produktu.

Po zatwierdzeniu SRS możesz przejść do promptu projektowania architektury i SDD. Nadal potrzebujesz review człowieka: model dobrze znajduje luki językowe, ale nie zna ukrytych ustaleń organizacji ani realnego budżetu.

Checklista przed zatwierdzeniem

• Każde wymaganie ma identyfikator.
• Zakres i out of scope są jawne.
• Wymagania funkcjonalne mają kryteria akceptacji.
• Wymagania jakościowe są mierzalne.
• Integracje opisują zachowanie przy awarii.
• Pytania otwarte mają właściciela.
• Każde krytyczne wymaganie prowadzi do testu.
• Dokument nie udaje SDD i nie wybiera technologii bez potrzeby.

SRS ma zmniejszyć koszt nieporozumień. Jeśli po jego przeczytaniu developer, tester i product owner rozumieją trzy różne systemy, dokument nie jest jeszcze gotowy.

Źródło

Struktura jest zgodna z praktyką specyfikowania wymagań opisaną w ISO/IEC/IEEE 29148. Szablon jest uproszczeniem do codziennej pracy zespołów software, a nie kopią standardu.