Połącz oczekiwanie z proponowaną odpowiedzią
Specyfikacja potrzeb może mówić, że klient ma mieć możliwość zmiany rezerwacji. Specyfikacja realizacji wyjaśnia, które rezerwacje można zmienić, kto może to zrobić i co stanie się z dostępnością oraz wiadomością potwierdzającą. Wypełnia więc przestrzeń między potrzebą biznesową a decyzjami, na podstawie których można rzeczywiście przygotować i uruchomić rozwiązanie.
Zamawiający powinien rozumieć proponowane działanie, a zespół wykonawczy potrzebuje spójnej podstawy do pracy. Te grupy wymagają innej szczegółowości. Oddziel czytelne scenariusze od głębszych opisów technicznych. Dokument złożony z nazw wewnętrznych komponentów może pomóc programistom, lecz utrudnić osobie zatwierdzającej projekt rozpoznanie błędu dotyczącego samego procesu lub potrzeb przyszłych użytkowników.
Najpierw opisz zachowanie
Zacznij od uczestników, warunków początkowych, działania i rezultatu. Co widzi użytkownik? Co zapisuje system? Która reguła pozwala przejść dalej, a która zatrzymuje zadanie? Potem opisz wyjątki: brak informacji, ponowne wysłanie, anulowanie i niedostępne połączenie. Widoki ekranów pomagają w rozmowie, ale same nie wyjaśniają wszystkich decyzji podejmowanych w tle.
Przy istotnej decyzji wskaż wymaganie, na które ona odpowiada. Łatwiej zauważysz wtedy zbędną funkcję lub potrzebę bez zaplanowanej odpowiedzi. Takie powiązanie pomaga też przy zmianach. Jeżeli zmieni się pierwotna potrzeba, zespół może odnaleźć konkretne zasady do poprawy, zamiast przeszukiwać długi tekst i zgadywać, które podobne zdania dotyczą tej samej sprawy.
Przykład firmy cateringowej
Wyobraź sobie fikcyjną firmę cateringową tworzącą formularz zapytań o obsługę wydarzeń. Wymaganie mówi, że zainteresowana osoba może przesłać zapytanie i otrzymać wiadomość o jego przyjęciu. Specyfikacja realizacji odróżnia takie potwierdzenie od zatwierdzenia zamówienia. Pracownik nadal musi sprawdzić dostępność zespołu i uzgodnić szczegóły, zanim firma przyjmie pracę do wykonania.
Dokument wyjaśnia, jakie informacje o wydarzeniu zbiera formularz, co dzieje się bez podanej daty i gdzie pojawia się zgłoszenie. Opisuje również sposób rozpoznania możliwego duplikatu. Bez takich decyzji estetyczny ekran z napisem „potwierdzone” mógłby stworzyć oczekiwanie, którego firma jeszcze nie jest gotowa spełnić. To przykład poglądowy, a nie opis rzeczywistego klienta.
Doprecyzuj przejścia między systemami
Jeśli zapytanie trafia do CRM, wskaż przesyłane dane, ich znaczenie oraz miejsce przechowywania obowiązującego zapisu. Opisz, jak późniejsze uzupełnienie zostaje połączone z istniejącym zgłoszeniem. Uwzględnij też awarię: co widzi użytkownik, kto dowiaduje się o problemie i jak zespół zapobiega utracie zgłoszenia albo jego podwójnej obsłudze po przywróceniu działania połączenia.
Nie oznacza to konieczności ustalania każdej instrukcji programu. Jednak zapis „systemy są połączone” pozostawia zbyt wiele pytań. Połączenie może istnieć technicznie, a mimo to pomijać ważne pole lub ukrywać błąd przed pracownikami. Dobra specyfikacja opisuje oczekiwany skutek dla pracy firmy na tyle jasno, aby dało się go omówić, wykonać i sprawdzić.
Zbuduj scenariusze odbioru
Scenariusz zawiera stan początkowy, określone działanie i oczekiwany wynik. W przykładzie cateringu wysyłasz kompletne zapytanie i sprawdzasz, czy klient otrzymuje informację o wpływie, a pracownik widzi zgłoszenie czekające na ocenę. Potem rozpatrujesz brak danych i przerwę w działaniu. Dla każdego przypadku zapisujesz, co ma się wydarzyć po stronie obu uczestników.
Prototyp może wcześniej pomóc wyjaśnić sposób obsługi. Wnioski z obserwacji wykorzystaj przy dopracowaniu dokumentu. Nie traktuj jednak modelu jako dowodu, że cała usługa będzie niezawodna. Klikalny ekran nie potwierdza poprawnego dostarczania wiadomości, działania uprawnień ani bezpiecznego wznowienia wymiany danych po błędzie. Każda z tych kwestii wymaga właściwego sprawdzenia na odpowiednim etapie.
Dobierz zakres szczegółów
Opisuj decyzje, które inna osoba musiałaby odgadnąć: reguły, stany, prawa dostępu, przepływ informacji, obowiązki operacyjne i oczekiwania przy odbiorze. W razie potrzeby odsyłaj do dokładniejszych projektów. Unikaj powielania tej samej zasady w kilku rozdziałach. Po zmianie łatwo wtedy pozostawić sprzeczne wersje, z których każda wygląda jak aktualne i wiążące ustalenie.
W małym projekcie potrzeby i propozycja realizacji mogą znaleźć się w jednym dokumencie. Osobne sekcje lub wyraźnie nazwane pola zachowają różnicę między nimi. Wartość daje zrozumiała decyzja i zgoda uczestników. Dwa formalne pliki powtarzające tę samą treść zwiększają pracę przy aktualizacji, ale nie wyjaśniają lepiej, co wykonawca naprawdę zamierza dostarczyć.
Połącz uzgodnienia z obsługą zmian
Specyfikacja utrwala wspólny stan decyzji. Nie oznacza, że później nikt nie może dowiedzieć się czegoś nowego. Nadaj jej wersję i właściciela. Osobno zapisuj nierozstrzygnięte kwestie oraz ich wpływ na dalszą pracę. Przed uznaniem szkicu za uzgodniony sprawdź, czy właściwe osoby biznesowe i techniczne rzeczywiście przejrzały dotyczące ich fragmenty opisu.
Gdy pojawi się zmiana, prześledź jej skutki dla zasad, danych, testów i instrukcji. Nowy termin dopuszczalnej zmiany rezerwacji może dotknąć wiadomości, pracy zespołu oraz istniejących zapisów. Oceń te skutki przed nową obietnicą. Stopień formalności powinien pasować do projektu, ale jasność tego, na co strony się umawiają, pozostaje potrzebna w każdym przypadku.
Przejdź przez całe zadanie
Wybierz ważną czynność i przeanalizuj ją wyłącznie na podstawie dokumentu. Czy inna osoba potrafi wskazać dane wejściowe, kolejne decyzje, wynik i reakcję na przerwę? Poproś o zaznaczenie miejsc, w których autor zakłada wiedzę dostępną tylko sobie. To dobry sposób na odkrycie luk, których nie widać podczas zwykłego czytania własnego tekstu.
Następnie porównaj scenariusz z wymaganiem. Rozwiązanie może być kompletne i wewnętrznie spójne, a mimo to dotyczyć niewłaściwego problemu. Powrót do oczekiwanego rezultatu chroni przed taką sytuacją. Zakończ przegląd konkretnymi decyzjami lub nazwanymi pytaniami, zamiast ogólnej uwagi, że całość wygląda dobrze i można bez dalszego zastanowienia rozpocząć pracę.
Częste pytania
Czy to jest dokumentacja techniczna?
Może zawierać decyzje techniczne, ale przede wszystkim wyjaśnia uzgodnione rozwiązanie i jego zachowanie. Szczegółowy opis kodu służy innemu odbiorcy i rozwija się wraz z wdrożeniem. Warto łączyć oba poziomy odnośnikami tam, gdzie decyzja techniczna wpływa na oczekiwany wynik.
Czy taki dokument pasuje do pracy zwinnej?
Tak. Zespół może zapisywać decyzje stopniowo i doprecyzowywać je przed realizacją danego fragmentu. Nadal trzeba wiedzieć, co uzgodniono, co pozostaje otwarte i jak obsługiwać zmianę. Zwinna praca nie usuwa potrzeby jasnego opisu zachowania rozwiązania.