Specyfikacja wymagań opisuje, co budujesz, dla kogo, po czym poznać, że działa, i czego projekt nie obejmuje. Dobra specyfikacja ma dwie funkcje. Pozwala rzetelnie wycenić projekt i daje kryteria, według których klient odbierze wynik.
Piszesz ją w ośmiu krokach, opisanych niżej. Przy umowie o dzieło to specyfikacja oznacza dzieło, do którego wykonania się zobowiązujesz (art. 627 Kodeksu cywilnego). Bez niej spór o to, czy projekt jest skończony, trudno rozstrzygnąć.
Co musi zawierać specyfikacja wymagań?
Minimum, które pozwala wycenić projekt i go odebrać:
| Sekcja | Po co |
|---|---|
| Cel projektu | Kryterium, do którego wracasz przy każdym sporze o priorytety |
| Role i scenariusze | Podstawa wyceny i testów akceptacyjnych |
| Funkcje z kryteriami odbioru | Lista tego, co klient sprawdzi przy odbiorze |
| Integracje i dane | Najczęstsze źródło przekroczeń budżetu |
| Wymagania niefunkcjonalne | Wydajność, bezpieczeństwo, dostępność, hosting |
| Zakres wyłączony | Ochrona przed „to przecież oczywiste” |
| Zmiany i odbiór | Procedura change requestu i protokół odbioru |
Długość nie jest miarą jakości. Specyfikacja na dwadzieścia stron z jasnymi kryteriami odbioru jest lepsza niż sto stron opisów ekranów.
Jak napisać specyfikację wymagań krok po kroku?
- Zapisz cel projektu. Dwa, trzy zdania: jaki problem rozwiązuje system i po czym klient pozna sukces. Na przykład: „recepcja obsługuje rezerwacje bez telefonu, pacjent umawia wizytę w aplikacji w mniej niż minutę”.
- Opisz role i scenariusze. Każda rola i jej najważniejsze scenariusze: kto, co robi, jaki dostaje wynik.
- Wypisz funkcje z kryteriami odbioru. Przy każdej funkcji sprawdzalne kryterium.
- Opisz integracje i dane. Systemy zewnętrzne, API, kto daje dostępy, migracja danych.
- Zapisz wymagania niefunkcjonalne. Liczby tam, gdzie się da.
- Wypisz, czego projekt nie obejmuje. Osobna sekcja.
- Opisz procedurę zmian i odbioru. Kto zgłasza, kto wycenia, kto podpisuje i w jakim terminie.
- Podpisz specyfikację jako załącznik do umowy. Bez tego jest tylko notatką ze spotkań.
Jak opisać wymagania niefunkcjonalne?
To sekcja, którą klient zwykle pomija, a która najbardziej wpływa na koszt. Opisz ją liczbami:
- Wydajność. Liczba jednoczesnych użytkowników, czas odpowiedzi dla kluczowych operacji.
- Dostępność. Dopuszczalne okna serwisowe, czas przywrócenia po awarii.
- Bezpieczeństwo. Uwierzytelnianie, szyfrowanie, logowanie zdarzeń, testy penetracyjne.
- Dane osobowe. Gdzie są przechowywane, kto ma dostęp, jak długo. Jeśli software house będzie miał dostęp do danych na produkcji, potrzebna jest umowa powierzenia (art. 28 ust. 3 RODO).
- Środowisko. Przeglądarki, wersje systemów mobilnych, hosting klienta czy twój.
Jeśli klient działa w sektorze finansowym, wymagania niefunkcjonalne dopisze za ciebie jego dział ryzyka. Szczegóły na stronie DORA dla software house’u.
Jak powiązać specyfikację z umową i odbiorem?
Specyfikacja działa tylko jako część umowy. Kilka przepisów Kodeksu cywilnego, które warto znać przy umowie o dzieło:
- Odbiór. Zamawiający musi odebrać dzieło wydane zgodnie z umową (art. 643 KC). Kryteria odbioru ze specyfikacji mówią, co znaczy „zgodnie z umową”.
- Współdziałanie. Jeśli do wykonania dzieła potrzebne jest współdziałanie zamawiającego, a klient go nie zapewnia, możesz wyznaczyć termin z zagrożeniem odstąpienia od umowy (art. 640 KC). Zapisz w specyfikacji, co dostarcza klient i kiedy.
- Ryczałt. Przy wynagrodzeniu ryczałtowym nie podniesiesz ceny, nawet jeśli zakresu nie dało się przewidzieć (art. 632 § 1 KC). Sekcja „czego projekt nie obejmuje” to twoja ochrona.
Kto płaci za napisanie specyfikacji?
Najlepiej klient, jako osobny etap analizy. Specyfikacja to kilka tygodni pracy kilku osób:
- analityka, który prowadzi warsztaty i spisuje scenariusze,
- architekta, który opisuje integracje i wymagania niefunkcjonalne,
- projektanta UX, który przygotowuje makiety kluczowych ekranów.
Jeśli robisz ją za darmo w presalesie, finansujesz klientowi dokument, z którym może pójść do tańszej konkurencji.
Płatna analiza daje ci też lepszą wycenę projektu IT. Szacujesz na podstawie opisanych scenariuszy, integracji i wymagań, z mniejszym buforem na niewiadome.
Co zapisać w specyfikacji o prawach do kodu?
Specyfikacja to dobre miejsce, żeby oznaczyć pochodzenie każdego modułu. Ta lista przyda się przy umowie:
| Moduł | Skąd | Co dostaje klient |
|---|---|---|
| Pisany od zera dla klienta | Projekt | Przeniesienie praw |
| Twój gotowy komponent | Biblioteka firmy | Licencja niewyłączna |
| Biblioteka open source | Zewnętrzna | Licencja open source tej biblioteki |
Tak zostawiasz sobie kod, który obniża koszt kolejnych projektów i który możesz licencjonować innym. Jak to zapisać, opisujemy na stronie przeniesienie autorskich praw majątkowych. Ile może być wart taki zasób, sprawdzisz na stronie ile jest wart kod źródłowy.