Specyfikacja wymagań systemu: jak przygotować dobry brief

Dobra specyfikacja wymagań systemu odpowiada na pytania „po co”, „dla kogo” i „w jakich warunkach”, a sposób budowy zostawia wykonawcy. Zawiera cele biznesowe, opis procesów, role użytkowników, integracje, dane i wymagania niefunkcjonalne, takie jak bezpieczeństwo czy dostępność. Poniżej opisuję, jak przygotować taki brief dla software house’u krok po kroku, co w nim musi być, a czego lepiej nie pisać, bo zamiast pomagać, zawęża wycenę i rozwiązanie.

Po co firmie specyfikacja wymagań systemu?

Specyfikacja wymagań systemu jest po to, żeby wszyscy wykonawcy wyceniali ten sam projekt, a po wdrożeniu było wiadomo, co miało zostać dostarczone. Bez niej każda oferta opiera się na innych domysłach, więc ceny różnią się nie dlatego, że firmy liczą inaczej, tylko dlatego, że wyobrażają sobie inny system.

Brief przydaje się na trzech etapach. Przy zapytaniu ofertowym daje porównywalne wyceny. Na starcie projektu skraca analizę, bo wykonawca nie zaczyna od zera. Przy odbiorze jest punktem odniesienia, gdy pojawia się spór, czy coś było w zakresie. O tym, jak zakres przekłada się na cenę, piszę we wpisie o tym, ile kosztuje system dedykowany.

Brief nie musi być długi. Kilka do kilkunastu stron konkretów jest lepsze niż sto stron, których nikt po Twojej stronie nie przeczytał w całości.

Cele biznesowe: od czego zacząć brief

Zacznij od problemu, który system ma rozwiązać, i od tego, jak poznasz, że go rozwiązał. Cel w rodzaju „nowoczesny system do obsługi zamówień” niczego nie mówi. Cel w rodzaju „handlowcy przestają przepisywać zamówienia z maili do ERP, a klient widzi status zamówienia bez dzwonienia” mówi bardzo dużo.

W tej części zapisz:

• jaki problem dziś istnieje i kogo dotyczy,
• co ma się zmienić po wdrożeniu, opisane mierzalnie tam, gdzie się da,
• jakie są ograniczenia: budżet, termin, przepisy, systemy, których nie wolno ruszać,
• kto po Twojej stronie podejmuje decyzje i akceptuje kolejne etapy.

Ostatni punkt bywa pomijany, a to od niego zależy tempo projektu. Wykonawca, który czeka tydzień na odpowiedź, bo nikt nie wie, kto decyduje, wystawi Ci rachunek za ten tydzień w takiej czy innej formie.

Procesy zamiast listy funkcji

Opisuj procesy krok po kroku, a nie listę funkcji. Lista typu „logowanie, koszyk, eksport do PDF, powiadomienia” nie mówi, jak te elementy mają ze sobą współpracować ani co dzieje się w sytuacjach wyjątkowych.

Weźmy jako przykład firmę dystrybucyjną, która chce przyjmować zamówienia od klientów hurtowych online. Opis procesu mógłby wyglądać tak: klient loguje się, widzi swój cennik, składa zamówienie, system sprawdza limit kredytowy, zamówienie trafia do ERP, magazyn kompletuje towar, klient dostaje fakturę i numer przesyłki. Do tego wyjątki: brak towaru, przekroczony limit, zmiana zamówienia po złożeniu, zwrot.

Dla każdego procesu warto zapisać:

• kto go zaczyna i co jest na wejściu,
• kolejne kroki i decyzje, z informacją, kto je podejmuje,
• co jest wynikiem procesu i gdzie trafia,
• wyjątki i to, jak dziś się je obsługuje,
• jak często proces się powtarza, w przybliżeniu.

Opis obecnego procesu jest tak samo ważny jak opis docelowego. Wykonawca zobaczy w nim, gdzie są ręczne obejścia, które system musi zastąpić, i czego nie wolno zepsuć.

Użytkownicy i role

Wypisz grupy użytkowników, ich zadania i uprawnienia. Inaczej projektuje się system dla trzech osób w biurze, a inaczej dla klientów zewnętrznych, przedstawicieli handlowych w terenie i magazynu pracującego na skanerach.

Przy każdej roli odpowiedz krótko: co ta osoba robi w systemie, czego nie może zobaczyć ani zmienić, na jakim urządzeniu pracuje i jak dobrze zna podobne narzędzia. Ta ostatnia informacja wpływa na projekt interfejsu bardziej, niż się wydaje.

Integracje i dane

Integracje to najczęstsze źródło niedoszacowania, więc opisz je szczególnie starannie. Dla każdego systemu, z którym nowe oprogramowanie ma się łączyć, podaj nazwę, wersję i firmę, która go utrzymuje. Dopisz, jakie dane mają płynąć i w którą stronę oraz czy system ma udokumentowane API.

Równie ważne jest źródło prawdy, czyli odpowiedź na pytanie, który system decyduje o danej informacji. Jeśli stany magazynowe są w ERP, a ceny w arkuszu działu handlowego, to brief musi to powiedzieć wprost. Przykład takiego układu dla sklepu internetowego opisuję w tekście o tym, jak przeprowadzić integrację ERP ze sklepem internetowym.

W części o danych dopisz, jakie dane trzeba przenieść ze starego systemu, w jakim są stanie i czy są wśród nich dane osobowe. Migracja danych to osobne zadanie z osobną wyceną, a nie czynność na ostatni dzień projektu.

Wymagania niefunkcjonalne, o których łatwo zapomnieć

Wymagania niefunkcjonalne opisują, jak system ma działać, a nie co ma robić. To one często decydują o architekturze i koszcie, a w briefach pojawiają się rzadko albo w formie „system ma być szybki i bezpieczny”.

• Wydajność i skala: ilu użytkowników jednocześnie, ile zamówień lub dokumentów w szczycie, jak szybko ma reagować kluczowy ekran.
• Dostępność działania: w jakich godzinach system musi działać i jak długa przerwa jest jeszcze akceptowalna.
• Bezpieczeństwo: logowanie, role, rejestr zdarzeń, wymagania Twojego działu IT lub klientów.
• Dane osobowe: jakie dane, gdzie mogą być przechowywane, kto ma do nich dostęp.
• Dostępność cyfrowa: czy system jest usługą dla konsumentów, która musi spełniać wymagania dostępności.
• Utrzymanie: kopie zapasowe, monitoring, czas reakcji na awarie, kto będzie rozwijał system po wdrożeniu.

Przy dostępności cyfrowej brief powinien wskazać, czy system podlega ustawie o zapewnianiu spełniania wymagań dostępności, która weszła w życie 28 czerwca 2025 r. i obejmuje między innymi usługi handlu elektronicznego. Ocenę, czy Twoja usługa jest objęta przepisami, zostaw prawnikowi, ale samą informację, że trzeba to sprawdzić, wpisz do briefu.

Czego nie pisać w briefie

Specyfikacja wymagań systemu nie powinna projektować rozwiązania za wykonawcę. Brief, który narzuca technologię, bazę danych i układ każdego ekranu, odbiera Ci najcenniejszą część oferty, czyli propozycję, jak rozwiązać problem lepiej lub taniej.

Z mojej perspektywy najwięcej szkody robią:

• gotowe rozwiązania techniczne bez uzasadnienia, na przykład konkretny framework, bo „ktoś słyszał, że jest dobry”,
• porównania typu „jak znany serwis X” bez wskazania, o którą jego cechę chodzi,
• długie listy funkcji bez priorytetów, w których drobiazg ma tę samą wagę co proces krytyczny,
• sformułowania nieweryfikowalne: intuicyjny, nowoczesny, elastyczny, bez opisu, co to znaczy w praktyce,
• wymagania „na zapas”, czyli funkcje, które mogą się kiedyś przydać.

Priorytety rozwiązują większość tych problemów. Podziel wymagania na trzy grupy: bez tego system nie ma sensu, ważne, ale może poczekać, oraz miłe dodatki. Ułatwia to wycenę wariantów i ustalenie pierwszej wersji, o czym piszę we wpisie o tym, jak zaplanować MVP.

Szablon briefu dla software house’u

Jeśli nie wiesz, jak ułożyć dokument, możesz skorzystać z poniższego układu. Sprawdza się zarówno przy małym systemie wewnętrznym, jak i przy platformie dla klientów, bo pierwsza wersja specyfikacji wymagań systemu nie musi być kompletna, tylko uporządkowana. Każdy punkt to od kilku zdań do kilku stron, zależnie od wielkości projektu.

1. Kontekst firmy i problem do rozwiązania.
2. Cele biznesowe i sposób sprawdzenia, czy zostały osiągnięte.
3. Ograniczenia: budżet lub jego przedział, termin, przepisy, decydenci.
4. Role użytkowników i ich zadania.
5. Procesy obecne i docelowe, z wyjątkami.
6. Integracje, źródło prawdy dla kluczowych danych, migracja.
7. Wymagania niefunkcjonalne.
8. Priorytety wymagań.
9. Załączniki: przykładowe dokumenty, zrzuty ekranów obecnych narzędzi, eksporty danych bez danych osobowych.
10. Lista otwartych pytań, na które sam nie znasz odpowiedzi.

Ostatni punkt jest zaskakująco ważny. Pokazuje wykonawcy, gdzie potrzebna jest analiza, i chroni przed tym, żeby niepewność została w wycenie ukryta jako pewnik.

Od briefu do specyfikacji uzgodnionej z wykonawcą

Brief to Twój dokument wejściowy, a nie ostateczna specyfikacja. Dobry wykonawca odpowie na niego pytaniami, a potem zaproponuje warsztat lub płatną analizę, po której powstaje szczegółowa specyfikacja uzgodniona przez obie strony.

Sposób, w jaki firma reaguje na brief, mówi dużo o tym, jak będzie prowadzić projekt. Wycena przysłana bez jednego pytania to sygnał ostrzegawczy, o którym piszę szerzej w tekście o tym, jak wybrać software house. Pytania o wyjątki, dane i role to dobry znak, nawet jeśli oznaczają więcej pracy po Twojej stronie.

Jeśli przygotowujesz specyfikację wymagań systemu, zacznij od celów i jednego procesu opisanego krok po kroku, a resztę dopisuj według szablonu powyżej. Gotowy szkic możesz przesłać przez stronę kontakt z Krzysztofem Balickim, a porozmawiamy o tym, czego w nim brakuje.