Czym się różni dobra specyfikacja wymagań od słabej? Przede wszystkim formą i stylem. Jak ocenić czy Ty, Twój pracownik czy wykonawca tworzy przyzwoity dokument? Przekaż ją osobom, dla których jest tworzona – klientowi lub programistom. Czy np. programiści po lekturze wiedzą, co mają robić? Ile mają pytań i wątpliwości? Jak ocenić formę i styl? Czytaj dalej.
Pierwsza i najważniejsza zmiana w podejściu do tematu polega na zauważeniu, że specyfikacja wymagań to nie literatura piękna. Niby oczywiste, a jednak różne ciekawe (i mniej ciekawe) formy literackie są bardzo często spotykane w projektach. Trzymają w napięciu, mają zwroty akcji, intrygujące niedopowiedzenia. A specyfikacja to nie lektura na wieczór. Do dokument techniczny, który czemuś ma służyć.
Klient uzupełnia w pop-upie parametry i potwierdza złożenie zamówienia. W kolejnym kroku uzupełnia dane identyfikacyjne oraz dokonuje potwierdzenia zakupu. Przesłany kod umieszczany jest w formularzu potwierdzającym wykonanie transakcji. System zakupowy powinien komunikować się efektywnie za pomocą webservice z innymi systemami.
Pamiętaj
Hierarchia i struktura – to nadrzędne zasady. Pisz zwięźle, stosuj wypunktowania, tabele, diagramy, gdzie się tylko da (i ma to sens). Używaj zdefiniowanych pojęć (najlepiej od razu z dziedziny problemu np. „wartość brutto” zamiast „kwota”). Zwróć uwagę na wartości graniczne – „Użytkownik nie może zapłacić kartą, jeśli towar kosztuje mniej niż 1zł”, „Użytkownik może wykonać płatność, jeśli towar kosztuje więcej niż 1zł”, a co, jeśli towar kosztuje dokładnie 1zł?
Unikaj
Zapomnij o synonimach (lub je zdefiniuj!) – nie ma być interesująco, ma być jednoznacznie. Unikaj też zaimków (on, jego, itd.) i przysłówków – „Zapisywanie wykonuje się szybko” czy „Podsumowanie tworzone jest odpowiednio dla każdego” wiele Ci nie pomoże. I człowieku! Nie pisz w stronie biernej! „Podsumowanie tworzone jest…” przez kogo – system czy użytkownika? Bądź stanowczy. Nie „powinien obliczać” czy „może obliczać”, ale „oblicza”. Nie nadużywaj zaprzeczeń (lepiej niż „użytkownik nie może dodawać niepodpisanych komentarzy, jeśli nie jest zalogowany” brzmi „Niezalogowany użytkownik musi podpisywać swoje komentarze.”). Przeczesz specyfikację w poszukiwaniu niepotrzebnie narzucanych rozwiązań w interfejsie czy technologii.
Wypleniaj niejednoznaczność – zastanów się 3 razy czy czasem nie burzysz jasności przekazu zanim użyjesz takich słów jak:
- Optymalizować, minimalizować, usprawniać
- Przyjazny dla użytkownika, szybki, prosty, łatwy, intuicyjny, efektywny, elastyczny
- Wystarczający, adekwatny
- W razie potrzeby, gdy konieczne, opcjonalnie
- Kilka, dużo, niektóre
- Np., zawierające, i/lub
- oraz konstrukcji A/B (np . „wysyłanie SMS/maila” to znaczy „SMS i maila”, „SMS lub maila”, „SMS pod pewnym warunkiem – jakim? – a pod innym warunkiem – jakim”?)
Sprawdź
Warto upewnić się czy nie pominąłeś czegoś, np. „Użytkownik może oznaczać wykonanie płatności” -> „Użytkownik może zaznaczać i odznaczać wykonanie płatności”. Jeśli Twoje wymagania wydają Ci się za długie, pomyśl czy da się je przetestować (przeprowadzić testy). Jeśli byłoby to trudne, może masz kombinację 2 czy kilku wymagań?
A tak może wyglądać opisane wymaganie – wzór z książki „Requirements” Karla Wiegersa (podgląd dostępny na stronie: http://amzn.to/WrRrgF) – jednego z najbardziej zasłużonych na tym polu. Polecam!
Źródło:
- Wiegers K., Elements of requirements style, ModernAnalyst.com, webinar, 13.03.2012 r.
