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:
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]?
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.
Jako strategiczny analityk biznesowy na pograniczu zarządzania i IT zapewniam, że projekty i działania w organizacji przynoszą wartość biznesową. Dostarczam kompetencji analitycznych managerom i zarządom z Polski, Niemiec i Szwajcarii przy tworzeniu strategii oraz wdrażaniu jej w kilkuset osobowej międzynarodowej organizacji.
Maria Kaczmarczyk
Hey, słuchajcie ostatnio zaczęłam rozglądać się o pracę w branży IT, i natknęłam się na SMT. Nie żałuję podjętej zmiany, a firmę gorąco polecam, świetna atmosfera, super socjal i duża perspektywa rozwoju, bardzo polecam!