Zespół deweloperski dostał wymaganie: „System ma być szybki". Tester zapytał, co to znaczy „szybki". Cisza. Programista założył, że chodzi o ładowanie strony poniżej sekundy. Klient miał na myśli, że raport miesięczny ma się generować w mniej niż pięć minut zamiast obecnej godziny. Po wdrożeniu okazało się, że strona ładuje się błyskawicznie, a raport nadal mieli czterdzieści minut. Wymaganie było „spełnione" i jednocześnie kompletnie chybione. Jedno niejednoznaczne słowo kosztowało tydzień przeróbek - a wystarczyło napisać je tak, żeby dało się je przetestować.
Specyfikacja wymagań (SRS - Software Requirements Specification) istnieje właśnie po to, żeby takie sytuacje się nie zdarzały. To dokument, który precyzyjnie określa, co system ma robić i jak ma się zachowywać - na tyle jednoznacznie, że deweloper, tester i klient rozumieją to samo. W tym artykule pokażę Ci, jak napisać dobrą SRS zgodnie ze standardem ISO/IEC/IEEE 29148, dam gotowy szablon, przykłady wymagań funkcjonalnych i niefunkcjonalnych, kryteria jakości pojedynczego wymagania oraz najczęstsze błędy, które widziałem w realnych dokumentach.
Czym jest specyfikacja wymagań (SRS)
SRS to formalny dokument opisujący wszystkie wymagania wobec systemu lub oprogramowania. Działa jak punkt odniesienia między klientem a zespołem: definiuje zakres, funkcjonalność, wydajność, bezpieczeństwo i pozostałe istotne aspekty. Najprościej: SRS odpowiada na pytanie „co dokładnie mamy zbudować?". Na wcześniejsze pytanie - „po co w ogóle to budujemy" - odpowiada inny dokument, BRD, czyli specyfikacja wymagań biznesowych.
Standardem, który definiuje, jak powinna wyglądać dobra specyfikacja, jest ISO/IEC/IEEE 29148 - międzynarodowa norma dla inżynierii wymagań. Zastąpiła starszy, dobrze znany IEEE 830, i to do niej warto się odwoływać. Nie musisz znać jej na pamięć, ale warto wiedzieć, że definiuje zarówno strukturę dokumentu, jak i - co ważniejsze - cechy dobrze napisanego pojedynczego wymagania. Do tych cech wrócę osobno, bo to one decydują o jakości specyfikacji bardziej niż jej spis treści.
Dlaczego SRS jest ważna
Dobra specyfikacja zwraca się wielokrotnie. Konkretnie daje:
- Redukcję ryzyka - jednoznaczne wymagania minimalizują nieporozumienia, a więc i kosztowne poprawki na końcu projektu.
- Wspólny język - klient, deweloper, tester i analityk mają jeden punkt odniesienia i tak samo rozumieją cele.
- Sprawniejszą budowę - deweloper implementuje konkret zamiast zgadywać, co klient miał na myśli.
- Podstawę testów - każde dobre wymaganie jest testowalne, więc SRS wprost zasila przypadki testowe.
- Bazę do wyceny i planowania - z dobrze opisanym zakresem da się rzetelnie oszacować koszt i harmonogram.
Sam pamiętam projekt, w którym ruszyliśmy z kodem na podstawie mglistych wyobrażeń klienta, bez porządnej SRS. Po kilku miesiącach okazało się, że zbudowaliśmy coś, co zupełnie nie odpowiada jego potrzebom. Od tamtej pory traktuję specyfikację jak inwestycję, nie biurokrację.
Cechy dobrego wymagania wg ISO/IEC/IEEE 29148
To jest sedno, które odróżnia dobrą SRS od stosu życzeń. Norma definiuje cechy, jakie powinno mieć każde pojedyncze wymaganie. Zapamiętaj je - to Twój filtr jakości:
- Jednoznaczne (unambiguous) - ma tylko jedną możliwą interpretację. „Szybki", „intuicyjny", „wydajny" tej cechy nie spełniają.
- Testowalne / weryfikowalne (verifiable) - da się obiektywnie sprawdzić, czy zostało spełnione. Jeśli nie potrafisz napisać testu, wymaganie jest źle sformułowane.
- Kompletne (complete) - opisuje pełne zachowanie, łącznie ze ścieżkami błędów i warunkami brzegowymi.
- Spójne (consistent) - nie jest sprzeczne z innym wymaganiem w dokumencie.
- Wykonalne (feasible) - możliwe do zrealizowania w ramach budżetu, czasu i technologii.
- Śledzalne (traceable) - ma unikalny identyfikator i da się je powiązać z potrzebą biznesową oraz z testem.
- Niezbędne (necessary) - gdyby zniknęło, brakowałoby czegoś istotnego. Nie opisuje rozwiązania „bo fajne".
Zwróć uwagę na cechę „śledzalne" - to ona spina SRS z resztą projektu. Każde wymaganie z identyfikatorem trafia do macierzy śledzenia wymagań, dzięki której wiadomo, czy zostało zaprojektowane, zbudowane i przetestowane.
Przykłady: źle → dobrze
Teoria nabiera sensu na konkretach. Oto te same intencje zapisane raz źle, raz dobrze.
| Źle (niejednoznaczne, nietestowalne) | Dobrze (jednoznaczne, testowalne) |
|---|---|
| System ma być szybki. | System wyświetli listę wolnych terminów w czasie nie dłuższym niż 2 sekundy dla 95% zapytań przy 200 użytkownikach jednocześnie. |
| Interfejs ma być intuicyjny. | Nowy użytkownik bez szkolenia zarezerwuje wizytę w maksymalnie 3 krokach, ukończonych przez co najmniej 9 z 10 testerów podczas testu użyteczności. |
| System ma obsługiwać logowanie. | System umożliwi zalogowanie za pomocą adresu e-mail i hasła; po 5 nieudanych próbach zablokuje konto na 15 minut i wyśle powiadomienie na adres e-mail. |
| Dane mają być bezpieczne. | System zaszyfruje dane osobowe pacjenta w spoczynku (AES-256) i w transmisji (TLS 1.2+); dostęp do danych medycznych wymaga roli „personel medyczny". |
Różnica jest praktyczna, nie kosmetyczna. Każde wymaganie z prawej kolumny da się przetestować jednym, jasnym scenariuszem. Każde z lewej kolumny rodzi spór przy odbiorze.
Szablon SRS - struktura dokumentu
Nie ma jednego uniwersalnego szablonu, ale struktura zgodna z ISO/IEC/IEEE 29148 zazwyczaj wygląda tak:
1. Wprowadzenie
- Cel dokumentu - po co powstała ta SRS i co ma osiągać.
- Zakres - co projekt obejmuje, a czego świadomie nie obejmuje (to drugie bywa ważniejsze).
- Grupa docelowa - dla kogo dokument (deweloperzy, testerzy, klient).
- Definicje i akronimy - słownik terminów, żeby uniknąć nieporozumień.
2. Opis ogólny
- Perspektywa produktu - jak system wpisuje się w szerszy kontekst i istniejące systemy.
- Funkcje produktu - główne grupy funkcjonalności (wysokopoziomowo).
- Charakterystyka użytkowników - kim są, jakie mają umiejętności i potrzeby.
- Ograniczenia - techniczne, budżetowe, czasowe, regulacyjne.
- Założenia i zależności - na czym opiera się projekt i od czego zależy.
3. Wymagania szczegółowe
- Wymagania funkcjonalne - co system ma robić. Każde z unikalnym ID, jednoznaczne i testowalne.
- Wymagania niefunkcjonalne - jak dobrze system ma działać (wydajność, bezpieczeństwo, użyteczność, niezawodność, skalowalność). Szczegółowo opisuję je w osobnym artykule o wymaganiach niefunkcjonalnych.
- Wymagania interfejsów - jak system komunikuje się z innymi systemami.
- Wymagania dotyczące danych - struktura, formaty, przechowywanie, archiwizacja.
4. Modele i diagramy (opcjonalne)
Diagramy przypadków użycia, klas, sekwencji, stanów - wizualizują to, co trudno opisać tekstem.
5. Aneksy (opcjonalne)
Słownik, prototypy interfejsu, dokumentacja API.
Wymagania funkcjonalne vs niefunkcjonalne - przykłady
To rozróżnienie myli się początkującym, więc trzy pary na konkretach:
System rejestracji wizyt:
- Funkcjonalne: Pacjent może wyszukać wolne terminy według lekarza, przychodni i daty.
- Niefunkcjonalne (wydajność): Wyniki wyszukiwania pojawiają się w czasie poniżej 2 sekund dla 95% zapytań.
Aplikacja do zamawiania jedzenia:
- Funkcjonalne: Użytkownik dodaje produkty do koszyka i składa zamówienie.
- Niefunkcjonalne (bezpieczeństwo): Dane płatnicze są szyfrowane w transmisji (TLS 1.2+) i nie są przechowywane na urządzeniu.
System magazynowy:
- Funkcjonalne: System rejestruje przyjęcie nowego towaru z kodem, ilością i datą.
- Niefunkcjonalne (niezawodność): System jest dostępny 99,9% czasu w skali miesiąca.
Reguła kciuka: funkcjonalne odpowiada na „co system robi", niefunkcjonalne na „jak dobrze to robi". Oba są równie ważne - projekty częściej wykładają się na zaniedbanych wymaganiach niefunkcjonalnych niż na brakujących funkcjach.
Anatomia dobrego wymagania - wzorzec EARS
Wiedza, jakie cechy ma mieć wymaganie, to jedno. Drugie to praktyczny wzorzec, który pomaga je tak pisać. Najpopularniejszym jest EARS (Easy Approach to Requirements Syntax) - zestaw szablonów zdań, które wymuszają jednoznaczność. Pięć podstawowych form:
- Ubiquitous (zawsze): „System powinien [zachowanie]." - np. „System przechowuje dane pacjenta w formie zaszyfrowanej."
- Event-driven (po zdarzeniu): „Gdy [wyzwalacz], system powinien [zachowanie]." - np. „Gdy pacjent zarezerwuje termin, system wyśle potwierdzenie SMS-em w ciągu 1 minuty."
- State-driven (w stanie): „Dopóki [stan], system powinien [zachowanie]." - np. „Dopóki konto jest zablokowane, system odrzuca próby logowania."
- Unwanted behaviour (ścieżka błędu): „Jeśli [warunek niepożądany], to system powinien [reakcja]." - np. „Jeśli stary system rejestracji jest niedostępny, to system wyświetli komunikat i umożliwi rezerwację telefoniczną."
- Optional (warunkowe): „Gdzie [funkcja obecna], system powinien [zachowanie]." - np. „Gdzie pacjent ma podany numer telefonu, system wysyła przypomnienie SMS-em."
Najcenniejsza z tych form to czwarta - ścieżka błędu. To właśnie tę formę pomijają początkujący, opisując wyłącznie szczęśliwą ścieżkę. EARS wymusza zadanie pytania „a co, jeśli się nie uda?" przy każdym wymaganiu. Nie musisz trzymać się tej składni sztywno, ale jako filtr myślowy jest świetny: jeśli Twoje wymaganie nie pasuje do żadnego z tych wzorców, prawdopodobnie jest niejednoznaczne.
Priorytet i typy wymagań w SRS
Nie wszystkie wymagania są równe i dobra SRS to odzwierciedla. Dwa wymiary, które warto przypisać każdemu wymaganiu:
- Priorytet - najczęściej metodą MoSCoW: Must have (bez tego projekt nie ma sensu), Should have (ważne, ale nie krytyczne), Could have (miło mieć), Won't have (świadomie poza zakresem tej wersji). Dzięki temu, gdy budżet lub czas się kurczą, wiadomo, co wycina się pierwsze.
- Typ - funkcjonalne, niefunkcjonalne, ograniczenia (constraints, np. „musi działać na istniejącej infrastrukturze"), reguły biznesowe (np. „rabat tylko dla pacjentów z aktywnym abonamentem"). Rozdzielenie typów ułatwia przegląd i pilnuje, by żadna kategoria nie wypadła.
Wymaganie z ID, priorytetem i typem jest gotowe do wpięcia w macierz śledzenia i do wyceny. Wymaganie bez tych atrybutów to luźne zdanie, które trudno zaplanować i zweryfikować.
Jak zbierać wymagania do SRS
SRS jest tak dobra, jak proces, który ją poprzedził. Zanim zaczniesz pisać, przejdź przez analizę wymagań:
- Zidentyfikuj interesariuszy - kto ma potrzeby wobec systemu: klienci, użytkownicy końcowi, menedżerowie, dział prawny.
- Zbierz wymagania - użyj różnych technik: wywiadów, warsztatów, analizy dokumentów, obserwacji. Przegląd metod znajdziesz w artykule o technikach elicytacji wymagań.
- Przeanalizuj - sprawdź kompletność, spójność i jednoznaczność, usuń duplikaty, rozwiąż konflikty.
- Spriorytetyzuj - np. metodą MoSCoW (Must / Should / Could / Won't have), żeby było wiadomo, co jest krytyczne.
- Udokumentuj - dopiero teraz zapisujesz przeanalizowane wymagania w SRS.
Częste błędy w pisaniu SRS
- Słowa-gumki. „Szybki", „intuicyjny", „przyjazny", „wydajny", „elastyczny" - każde z nich znaczy co innego dla każdego czytelnika. Zastąp je liczbą lub mierzalnym kryterium.
- Opisywanie rozwiązania zamiast potrzeby. „System ma mieć przycisk w prawym górnym rogu" to projekt, nie wymaganie. Wymaganie mówi, co użytkownik ma móc osiągnąć, nie jak ma wyglądać interfejs.
- Łączenie kilku wymagań w jedno zdanie. „System loguje użytkownika i wysyła powiadomienie i generuje raport" - to trzy wymagania. Rozdziel, by każde dało się osobno przetestować i śledzić.
- Pomijanie ścieżek błędów. Specyfikacja opisuje, co się dzieje, gdy wszystko idzie dobrze, ale milczy o tym, co przy nieprawidłowych danych czy awarii. Połowa pracy systemu to obsługa wyjątków.
- Brak identyfikatorów. Wymagania bez ID są nieśledzalne. Bez „REQ-014" nie połączysz ich z testem ani nie ocenisz wpływu zmiany.
- SRS pisana raz i zamrażana. Wymagania się zmieniają. Specyfikacja bez zarządzania wersją i historią zmian szybko rozjeżdża się z rzeczywistością.
Mini-case: fragment SRS dla rejestracji online w MediFlow
MediFlow, sieć 12 przychodni, wdraża rejestrację wizyt online. Oto jak wyglądałby fragment SRS - kilka wymagań zapisanych zgodnie z cechami z normy.
Wymagania funkcjonalne:
- REQ-F-001: System umożliwi pacjentowi wyszukanie wolnych terminów według wybranego lekarza, przychodni i przedziału dat.
- REQ-F-002: System umożliwi pacjentowi zarezerwowanie wolnego terminu po zalogowaniu; po rezerwacji termin zostanie oznaczony jako zajęty dla pozostałych użytkowników w czasie rzeczywistym.
- REQ-F-003: System wyśle pacjentowi potwierdzenie rezerwacji SMS-em i e-mailem w ciągu 1 minuty od jej dokonania.
- REQ-F-004: Jeżeli dwóch pacjentów spróbuje zarezerwować ten sam termin jednocześnie, system przyzna go pierwszemu zatwierdzonemu żądaniu i poinformuje drugiego o niedostępności.
Wymagania niefunkcjonalne:
- REQ-NF-001 (wydajność): System wyświetli listę wolnych terminów w czasie poniżej 2 sekund dla 95% zapytań przy 200 jednoczesnych użytkownikach.
- REQ-NF-002 (bezpieczeństwo): Dane medyczne pacjenta będą szyfrowane w spoczynku (AES-256) i w transmisji (TLS 1.2+); dostęp wymaga roli „personel medyczny".
- REQ-NF-003 (dostępność): System będzie dostępny przez 99,5% czasu w godzinach 6:00-22:00.
Zwróć uwagę na REQ-F-004 - to wymaganie obsługi sytuacji brzegowej (konflikt rezerwacji), o której początkujący analitycy zapominają. Właśnie takie wymagania ratują projekt przed błędami, które ujawniają się dopiero pod obciążeniem na produkcji.
Jak zrecenzować SRS przed zatwierdzeniem
Napisanie SRS to połowa pracy. Druga połowa to upewnienie się, że jest dobra - zanim zespół zacznie na niej budować. Przegląd specyfikacji warto poprowadzić jak strukturalną recenzję, a nie pobieżne „przeczytajcie i dajcie znać". Lista kontrolna, której używam:
- Czy każde wymaganie jest testowalne? Przejdź po kolei i przy każdym zadaj pytanie: „jak sprawdzę, że to zostało spełnione?". Jeśli nie potrafisz odpowiedzieć w jednym zdaniu - wymaganie do poprawki.
- Czy są ścieżki błędów? Dla każdej funkcji sprawdź, czy opisano, co się dzieje przy nieprawidłowych danych, awarii lub konflikcie. Brak ścieżek błędów to najczęstsza luka.
- Czy nie ma sprzeczności? Szukaj wymagań, które się wykluczają (np. „dane przechowywane bezterminowo" vs „dane usuwane po 2 latach zgodnie z RODO").
- Czy każde wymaganie ma jedno znaczenie? Daj specyfikację komuś spoza projektu i poproś o interpretację najważniejszych wymagań. Rozbieżne odczyty zdradzają niejednoznaczność.
- Czy zakres jest jasno odcięty? Sekcja „czego projekt NIE obejmuje" bywa ważniejsza od listy funkcji - to ona zapobiega pełzaniu zakresu.
- Czy biznes i technika zatwierdzili? SRS bez akceptacji obu stron to dokument bez mocy.
Przegląd najlepiej zrobić w gronie kilku osób o różnych perspektywach: analityk, ktoś z biznesu, architekt i tester. Tester wyłapie nietestowalne wymagania, architekt - niewykonalne, biznes - niezgodne z potrzebą. To samo, czego pojedyncza para oczu nie zobaczy. Recenzja SRS to część szerszego testowania i weryfikacji wymagań, którą warto traktować poważnie - błąd złapany w specyfikacji kosztuje ułamek tego, co ten sam błąd złapany na produkcji.
FAQ - specyfikacja wymagań SRS
Czym różni się ISO/IEC/IEEE 29148 od IEEE 830?
IEEE 830 to starszy standard specyfikacji wymagań, formalnie wycofany. ISO/IEC/IEEE 29148 go zastąpił i rozszerzył - obejmuje cały proces inżynierii wymagań (nie tylko dokument SRS) oraz definiuje cechy dobrego wymagania. Jeśli zaczynasz dziś, odwołuj się do 29148.
Czy SRS jest potrzebna w projektach Agile?
W czystym Agile pełna SRS z góry zwykle nie powstaje - jej rolę przejmują user stories z kryteriami akceptacji, doprecyzowywane na bieżąco. Ale wymagania niefunkcjonalne, reguły biznesowe i kontrakty interfejsów warto utrwalić niezależnie od metodyki. Różnice w podejściu do dokumentacji opisuję w artykule o roli analityka w Agile i Waterfall.
Jak długa powinna być SRS?
Tyle, ile potrzeba, by jednoznacznie opisać system - ani strony więcej. W małych projektach to kilkanaście stron, w dużych regulowanych - setki. Długość nie jest miarą jakości; jednoznaczność i kompletność są.
W jakim narzędziu pisać SRS?
W mniejszych projektach wystarczy edytor tekstu i arkusz do listy wymagań. W większych przydają się dedykowane narzędzia do zarządzania wymaganiami (np. Jama, DOORS, Polarion), które dają śledzenie zmian i powiązań. Narzędzie jest wtórne wobec dyscypliny pisania dobrych wymagań.
Kto powinien zatwierdzać SRS?
Najważniejsi interesariusze biznesowi (sponsor, właściciel procesu) oraz strona techniczna (architekt, lead). Formalne zatwierdzenie jest ważne zwłaszcza w Waterfall, gdzie SRS pełni rolę uzgodnionego zakresu i punktu odniesienia przy odbiorze.
Podsumowanie
Dobra SRS to nie kwestia ładnego spisu treści, tylko jakości pojedynczego wymagania. Jeśli zapamiętasz jedną zasadę z tego artykułu, niech to będzie test weryfikowalności: jeśli nie potrafisz napisać testu, który sprawdzi, czy wymaganie zostało spełnione - wymaganie jest źle sformułowane. Norma ISO/IEC/IEEE 29148 daje resztę ram: jednoznaczność, kompletność, spójność, śledzalność. Reszta to dyscyplina.
Specyfikacja wymagań zwraca się wielokrotnie w oszczędności czasu, pieniędzy i nerwów. Chcesz przećwiczyć pisanie testowalnych wymagań na realnym przykładzie i dostać informację zwrotną? Znajdziesz takie zadania w szkoleniach Analify - wraz z gotowymi szablonami dokumentów, w tym SRS, do wykorzystania w pracy.