BRD, FRD i SRS: który dokument i kiedy jest potrzebny

Zamawiający podpisuje dokument i uważa, że ustalił, jaki będzie produkt. Zespół czyta ten sam dokument i widzi w nim cele: co właściwie chcemy zmienić. Po miesiącu obie strony mówią „przecież to było w wymaganiach” i „tego tam nigdy nie było” — o tym samym pliku.

BRD, FRD i SRS to trzy różne dokumenty dla trzech różnych czytelników i trzech różnych momentów projektu. BRD wyjaśnia zamawiającemu i sponsorowi, po co w ogóle zaczynamy zmianę, i pojawia się najwcześniej, zanim wybrano rozwiązanie. FRD mówi zespołowi, co system ma robić, i pisze się go, gdy rozwiązanie jest już wybrane. SRS odpowiada tym, którzy budują i sprawdzają: jak dokładnie to ma działać, żeby dało się to zrealizować i napisać test. To cała odpowiedź, dalej — szczegóły.

Szczegóły są potrzebne, bo trzy czwarte zamieszania na rozmowie kwalifikacyjnej nie bierze się z nieznajomości tych trzech linijek. Znają je wszyscy. Potykają się o coś innego.

Zamieszanie zaczyna się od słowa „wymagania biznesowe”

Najczęstsza odpowiedź, jaką słyszę: „BRD to wymagania biznesowe”. Brzmi logicznie, litery się zgadzają. I to jest podmiana, z której wyrasta cała reszta.

Wymagania biznesowe to typ wymagań. BRD to dokument. W zbiorze wiedzy BABOK wymagania dzieli się na typy: wymagania biznesowe (cele i rezultaty, dla których zaczyna się zmianę), wymagania interesariuszy, wymagania dotyczące rozwiązania — funkcjonalne i niefunkcjonalne — oraz przejściowe, które są potrzebne tylko na czas przejścia i po nim zanikają. Żadne z tych słów nie nazywa pliku. To klasyfikacja treści: co dokładnie zapisałeś, a nie gdzie.

Dalej widać, gdzie jest pułapka. Jeden dokument spokojnie zawiera kilka typów wymagań naraz: w normalnym BRD obok celów żyją wymagania interesariuszy, a w SRS razem z funkcjonalnymi leżą niefunkcjonalne. I odwrotnie, jeden typ wymagań rozkłada się na trzy dokumenty. Dlatego pytanie „w którym dokumencie leżą wymagania biznesowe” nie ma jednej odpowiedzi, a pytanie „który dokument odpowiada na pytanie zamawiającego, po co to robimy” — ma.

Jeśli na rozmowie kwalifikacyjnej przenieść rozmowę z plików na typy wymagań i z powrotem, różnica między kandydatami staje się słyszalna od razu. Jeden recytuje trzy skróty. Drugi wyjaśnia, kto co czyta.

Co mówi standard — i czego nie mówi

Tu zaczyna się nieoczekiwana część, do której zwykle rozmowa nie dochodzi.

Międzynarodowy standard pracy z wymaganiami — ISO/IEC/IEEE 29148

— rzeczywiście opisuje dokumenty wymagań. W rozdziale 8 są cztery: specyfikacja wymagań biznesowych BRS, specyfikacja wymagań interesariuszy StRS, specyfikacja wymagań systemowych SyRS i specyfikacja wymagań dotyczących oprogramowania SRS. Dla każdej podano przykładową strukturę.

Zauważasz, czego nie ma na tej liście? BRD i FRD. Nie ma ich wcale.

Z trzech skrótów, wokół których toczy się spór, standard zna jeden — SRS: jego struktura jest opisana w rozdziale 8.5. Definicję standard podaje natomiast sąsiedniemu dokumentowi, systemowej specyfikacji wymagań SyRS: uporządkowany zbiór wymagań — funkcji, charakterystyk wydajności, ograniczeń projektowych i innych atrybutów — wobec systemu, jego środowisk operacyjnych i interfejsów zewnętrznych. BRD i FRD to praktyka branżowa: nazwy, co do których umówiły się firmy i konsulting, a nie terminy ze zbioru wiedzy.

Stąd praktyczny wniosek, który warto zabrać ze sobą. Pytanie „a jak poprawnie według standardu sporządzić BRD” nie ma sensu — nie istnieje poprawna odpowiedź. W każdej firmie BRD nazywa się trochę inaczej i w nowym projekcie warto najpierw zapytać, co tu rozumie się przez to słowo, a nie zakładać.

Na marginesie, o „właściwym szablonie SRS”. Często bierze się go z IEEE 830 — dokumentu z 1998 roku, na którym wciąż opierają się kursy. Na stronie IEEE ten standard ma status Superseded: został zastąpiony przez ISO/IEC/IEEE 29148 jeszcze w wersji z 2011 roku. Szablon z niego nie stał się zły, ale powoływanie się na niego jako na obowiązujący standard to zauważalny błąd.

Trzy dokumenty w pięciu pytaniach

Tabela porównawcza „czym się różni” jest w co drugim artykule i niewiele z niej wynika: odpowiada na pytanie egzaminatora, a nie na twoje. Dlatego przeanalizujmy każdy dokument w pięciu pytaniach, które pojawiają się w pracy. Piąte — najważniejsze — zwykle się pomija.

BRD

Kto pisze: analityk biznesowy razem z zamawiającym lub sponsorem zmiany. Kto czyta: ci, którzy dają pieniądze i podejmują decyzję „robimy czy nie”. Jaką decyzję zamyka: czy w ogóle warto to zaczynać i jak poznamy, że się udało. Kiedy powstaje: najwcześniej, przed wyborem rozwiązania. Jeśli w dokumencie jest już nazwany system, nie piszesz BRD. Czego brak bez niego: kryterium, po którym za pół roku można powiedzieć, że projekt się udał. Bez BRD sukces określa nastrój zamawiającego na demo i nie ma z czym dyskutować.

FRD

Kto pisze: analityk, który już wie, jakie rozwiązanie wybrano. Kto czyta: zespół deweloperski i testerski, czasem zamawiający, który chce sprawdzić, czy został zrozumiany. Jaką decyzję zamyka: co system ma robić, żeby cele z BRD zostały osiągnięte. Kiedy powstaje: po decyzji o rozwiązaniu, przed szacowaniem pracochłonności. Czego brak bez niego: granic zakresu prac. Szacowanie bez FRD to szacowanie tego, co każdy uczestnik spotkania sam sobie wyobraził, a rozbieżność wyjdzie na odbiorze.

SRS

Kto pisze: analityk razem z architektem lub deweloperem. Kto czyta: ci, którzy budują i sprawdzają: deweloperzy, testerzy, integratorzy. Jaką decyzję zamyka: jak to ma działać, żeby dało się to zrealizować i sprawdzić. Kiedy powstaje: przed realizacją i żyje dłużej niż dwa poprzednie — aktualizuje się go, dopóki system żyje. Czego brak bez niego: możliwości napisania przypadku testowego bez pójścia do autora. Każda niejednoznaczność zamienia się w pytanie na czacie, a odpowiedź na nie nigdzie się nie zapisuje.

Punkt piąty to ten, który odróżnia osobę, która prowadziła dokumenty, od osoby, która o nich czytała. „Co się psuje, jeśli tego dokumentu nie ma” nie da się wykuć na pamięć, to widać tylko z praktyki.

Dwa sposoby, żeby to wszystko zepsuć, które widzę najczęściej

Dokumenty się rozjechały. Nie dzieje się to z lenistwa. Dokumenty mają różnych czytelników i różny rytm życia: górna część zmienia się na spotkaniu z zamawiającym, szczegółowa — wewnątrz sprintu. Nikt nie ma obowiązku ich synchronizować, dopóki nie nadejdzie moment uzgodnienia. I wtedy wychodzi prawdziwa cena — nie przepisywanie, ale wyrównywanie: trzeba na nowo ustalić, która wersja jest prawdziwa, a zrobić to może tylko ten, kto pamięta obie dyskusje. Ta praca nie jest widoczna w planie, nie wchodzi do niczyjego szacowania i zjada dni. Nie leczy tego dyscyplina, tylko powiązania między dokumentami — o tym, jak nie zgubić wymagania po drodze, jest osobna analiza: macierz śledzenia wymagań.

Dokument napisano, bo tak trzeba. Nie ma czytelnika: proces wymaga — dokument się pojawił, a decyzje nadal zapadają w korespondencji. Po miesiącu opisuje system, którego już nie ma.

Dokument bez czytelnika nie jest bezużyteczny — jest szkodliwy. Bezużyteczny po prostu leży. Ten wygląda jak odpowiedź: powołują się na niego, liczą po nim terminy, na jego podstawie wdrażają się nowi ludzie.

Stąd zasada, którą warto mieć w głowie przy każdym sporze o skład dokumentacji: dla każdego dokumentu trzeba nazwać czytelnika i decyzję, którą zamyka. Nie ma ani jednego, ani drugiego — dokument nie jest potrzebny. To normalna odpowiedź, a nie partactwo, i na rozmowie kwalifikacyjnej brzmi znacznie mocniej niż wyliczanie wszystkich artefaktów po kolei.

Który z nich jest potrzebny w twojej sytuacji

Wybieraj nie po etapie projektu, ale po pytaniu, na które teraz nikt nie potrafi odpowiedzieć.

Nie wiadomo, po co to robimy i jak poznamy, że się udało — potrzebny jest BRD, nawet jeśli zmieści się na stronie. Wiadomo po co, ale każdy wyobraża sobie zakres po swojemu — potrzebny jest FRD. Zakres jest jasny, a tester i deweloper przychodzą do ciebie z tymi samymi pytaniami — potrzebny jest SRS. Wszystkie trzy pytania są zamknięte, a nie ma żadnego dokumentu — być może nie jest potrzebny: zespół czterech osób, który rozmawia codziennie, nie ma obowiązku pisać trzech specyfikacji.

Tak ta odpowiedź brzmi przekonująco na rozmowie kwalifikacyjnej: nie „należy prowadzić trzy dokumenty”, ale „oto pytanie, które nie było zamknięte, dlatego powstał ten dokument”.

Jak to brzmi na rozmowie kwalifikacyjnej

W naszym banku pytań z prawdziwych rozmów temat tych trzech dokumentów pojawia się sześć razy, a cztery z tych pytań są oznaczone jako junior. Warto to przeczytać dosłownie: o dokumenty pyta się na wejściu do zawodu. Nie „kiedy dorobisz się Seniora”, ale na pierwszej rozmowie, na której pytają cię o artefakty.

Słaba odpowiedź to wyliczenie rozwinięć skrótów. Jest formalnie poprawna i kończy się niczym: rozmówca kiwa głową i idzie dalej po liście.

Mocna odpowiedź jest krótsza, niż się wydaje. Trzy dokumenty — trzech czytelników — trzy momenty. Dalej jedno zdanie o tym, że w twojej firmie nazywało się to inaczej, i jak dokładnie. I, jeśli zapytają głębiej, szczerze: w standardzie z tych trzech jest tylko SRS, reszta to praktyka.

To ostatnie odróżnia kogoś z praktyką od kogoś, kto streścił artykuł, mocniej niż jakikolwiek szczegół o strukturze rozdziałów.