Specyfikacja wymagań oprogramowania (SRS, Software Requirements Specification) to dokument opisujący kompletny zestaw wymagań na system: funkcjonalne, niefunkcjonalne, interfejsy zewnętrzne, ograniczenia i przyjęte założenia. Struktura wywodzi się ze standardów IEEE 830 i ISO/IEC/IEEE 29148.
Analityk pisze SRS tam, gdzie wymagania trzeba zamrozić i przekazać dalej w formie kontraktowej: przetargi publiczne, projekty fixed-price, zlecenie rozwoju zewnętrznemu dostawcy, branże regulowane. W zwinnych zespołach produktowych pełny SRS występuje rzadko - zastępuje go backlog z user stories - ale umiejętność jego napisania wraca za każdym razem, gdy w grę wchodzi umowa z dostawcą.
W MediFlow SRS powstał na potrzeby zapytania ofertowego na moduł rejestracji online dla 12 przychodni. Bez niego trzej dostawcy wycenili „system rezerwacji" odpowiednio na 90, 240 i 410 tysięcy złotych, bo każdy wyobraził sobie co innego. Po doprecyzowaniu wymagań (m.in. integracja z HIS, obsługa wizyt NFZ i komercyjnych, przypomnienia SMS, dostępność 99,5%) rozrzut ofert spadł trzykrotnie i dało się je w ogóle porównać.
Częsta pomyłka: mylenie SRS z BRD (Business Requirements Document). BRD opisuje cele biznesowe i problem do rozwiązania, SRS - zachowanie konkretnego systemu. Druga, równie częsta: pisanie 200-stronicowego SRS w projekcie, który będzie prowadzony zwinnie. Taki dokument dezaktualizuje się po drugim sprincie i nikt go nie utrzymuje. Wtedy lepsza jest specyfikacja przyrostowa, doprecyzowywana tuż przed implementacją.