Specyfikacja wymagań – po co tracić czas?

Dla wielu uczestników projektu ograniczających fazę analizy jasne jest, że szczegółowe opisywanie wymagań (tworzenie  SW – specyfikacji wymagań, czy SWS – specyfikacji wymagań systemowych) zabiera cenny czas. Niewielu jednak łączy tę kwestię z licznie i powszechnie występującymi zjawiskami marnowania czasu w kolejnych etapach projektu. Czy i Twój zespół napotyka takie trudności?
Warto zwrócić uwagę, w jak wielu sytuacjach w czasie trwania projektu powraca się do zapisu wymagań: planowania, projektowania, realizacji, delegowania, zmian, testowania, odbioru. W kontekście tej listy raz jeszcze odpowiedzmy sobie na pytanie – czy dokładne spisywanie wymagań jest w moim projekcie stratą czasu? A jeśli można odzyskać go później z nawiązką i dodatkiem jakim jest dobra jakość?

Jak często wygląda opis wymagań? Jest to zdanie lub kilka zdań, które przyszły do głowy klientowi, zapisane w formie, w jakiej zostały wypowiedziane. Jakie są tego skutki? Wymaganie jest nieprecyzyjne i niejednoznaczne. Nierzadko na podstawie tego zdania (czy kilku) trudno przygotować projekt. Gratuluję tym, którzy mimo wszystko tworzą systemy w oparciu o takie wymagania. Nie bez znaczenia jednak pozostaje tutaj ich inwencja i kreatywność. Niestety nie zawsze może ona spotkać się z aprobatą oraz spełnieniem potrzeb i celów klienta, dla którego to przecież powstaje zamawiane oprogramowanie.
Innymi często spotykanymi formami „wymagań” są propozycje rozwiązań (opis technologii czy jej komponentów) czy też opisy komponentów interfejsu na stronie.
Jak można zatem dobrze opisać wymagania? Przede wszystkim należy odpowiedzieć sobie na pytanie – do czego będą one potrzebne? W praktyce często spotka się podejście związane z tworzeniem specyfikacji wymagań (SWS – Specyfikacja Wymagań Systemowych) polegające na pisaniu jej z racji wymogów umowy. Klient chce, więc dostanie. Efekt? W specyfikacji przejdzie wszystko, cokolwiek klient jest skłonny zaakceptować, i choć dla dobra projektu powinno mieć to miejsce – nie każdy będzie z zaangażowaniem i skupieniem przedzierać się przez dziesiątki stron dokumentacji. Po co więc w ogóle pisać specyfikację? Poza uzgodnieniem z klientem, jakie są jego oczekiwania i warunki przyjęcia systemu, zapominamy, że wymagania przydadzą się NAM – i to nie raz i nie dwa 😉
W jakich sytuacjach powraca się do wymagań w czasie trwania projektu? Na pewno będą to:

• planowanie,
• projektowanie,
• realizacja,
• delegowanie,
• zmiany,
• testowanie,
• odbiór.

Lista dość długa jak na produkt, na którego wykonanie często żałuje się czasu. Sami odpowiedzcie sobie na pytanie jak częste i znaczące w Waszych projektach są poszczególne czynności i ile członkowie zespołu doświadczają w nich czynników straty czasu i utraty jakości. A może ich zapytacie? 🙂
Co warto, by znalazło się w opisie wymagania [1]?

• identyfikator – pomaga przy wyszukiwaniu wymagania w czasie realizacji, delegowania zadań wykonawcom, zgłaszania zmian, testowania i odbioru, np. WF.Z.001 – wymaganie funkcjonalne z grupy „Zamówienia”, numer porządkowy 001
• priorytet – pomaga przy ustalaniu planu projektu i jego realizacji, np. najpierw planujemy spełnić najważniejsze dla klienta wymagania, w przypadku problemów z terminami, możemy odsunąć na dalszy plan te o mniejszym znaczeniu
• status – pomaga przy orientowaniu się w stanie zaawansowania procesu zatwierdzania specyfikacji i poszczególnych wymagań, np. proponowane, zatwierdzone, zaimplementowane
• tytuł – nazwa wymagania pomocna w szybkim określaniu się w jego treści
• opis – precyzyjne, jednoznaczne określenie wymagania pomaga w jego zrozumieniu, wspomagając planowanie, projektowanie, realizację, delegowanie, zmiany, testowanie, odbiór
• kryterium – pomaga przy testowaniu i odbiorze w jednoznacznym określeniu czy wymaganie zostało spełnione
• źródło – pomaga w doprecyzowywaniu wymagań, realizacji, zmianach, odbiorze dzięki określeniu osoby (grupy) czy innych źródeł informacji (np. dokumentów, przepisów)
• powiązania – pomaga w planowaniu, realizacji, zmianach i testowaniu dzięki określaniu zależności między wymaganiami oraz ich związków z przypadkami użycia, itp.

Po takim określeniu wymagań, warto pamiętać także o ich analizie – sprawdzeniu spójności, kompletności. Jest to temat na kolejny wpis. Obok innych metod temu służących znajdują się także, będące nie do przecenienia, narzędzia CASE. Wadą zaniechania ich pomocy i polegania jedynie na dokumentach jest znany fakt, że „papier przyjmie wszystko”.
Źródła:
1. Górski J. (2010), Inżynieria wymagań, niepublikowane materiały, Politechnika Gdańska.