Jak zebrać wymagania do wyboru oprogramowania w firmie

Od celu wdrożenia do zakresu projektu

Zbieranie wymagań zaczyna się od pytania, po co firmie nowy system. Piotr Rawski uznaje zdefiniowanie konkretnego celu wdrożenia za pierwszy i najważniejszy etap projektu. Odpowiedź mówi, dla kogo ma pracować system (główna grupa beneficjentów) i jakiej klasy narzędzia potrzeba.

Rawski wymienia ERP do kompleksowego zarządzania firmą, HR do kapitału ludzkiego i ECM do obiegu dokumentów.

Cel działa jak sito przy selekcji wymagań. Te zbieżne z celem wdrożenia są najistotniejsze, co porządkuje długą listę oczekiwań jeszcze przed kontaktem z dostawcami.

Drugi element to zakres. Jarosław Żeliński zauważa, że nie powstają już projekty jednorazowej informatyzacji całej organizacji, więc zakres trzeba określić jawnie — nie obejmuje całej firmy.

Kluczowe jest przejście od modelu działania organizacji (procesy biznesowe i ich produkty) do modelu mechanizmu działania oprogramowania. Analiza przedwdrożeniowa i definicja celów otwierają mapę drogową wdrożenia systemu IT.

Kto współtworzy wymagania: decydenci i użytkownicy końcowi

Rawski rozdziela dwie role. Decyzje należą do kierownictwa: ma budżet i lepiej zna strategię firmy. Paradoksalnie sukces wdrożenia zależy od użytkowników końcowych.

Obie grupy wchodzą w innych rolach: kierownictwo zatwierdza kierunek i finansowanie, użytkownicy opisują rzeczywistą pracę.

Zaangażowanie zespołu lub jego przedstawicieli w decyzje daje lepsze rozpoznanie oczekiwań wobec nowego oprogramowania. Drugi efekt jest psychologiczny — kadra jest bardziej zadowolona z rozwiązania, które sama wybrała.

Wywiad z pracownikami można zrobić jako warsztat, np. burzę mózgów. Sesja niezależnie od formy ma dać kompletną listę funkcji i cech systemu oczekiwanych przez przyszłych użytkowników.

R. Wojtachnik opisuje, że wymagania zbiera się zazwyczaj podczas serii warsztatów, przechodząc przez kolejne funkcjonalności wpisane w analizowany proces.

Poza użytkownikami końcowymi informacji dostarczają sponsorzy projektu i eksperci dziedzinowi w bezpośrednich rozmowach (Ardura).

Etap domyka akceptacja: dokument wymagań zatwierdzony przez wszystkie strony analizy staje się podstawą prac nad szczegółowymi funkcjonalnościami.

Wymagania biznesowe, użytkownika i systemowe — trzy warstwy, nie jedna lista

Literatura przedmiotu podaje kolejność dość jednoznacznie. Najpierw wymagania biznesowe, potem wymagania użytkowników — najczęściej przez przypadki użycia (use case). Na końcu szczegółowa lista wymagań funkcjonalnych i jakościowych, czyli niefunkcjonalnych.

Wymagania biznesowe razem z systemowymi tworzą kompleksowe wymagania końcowego produktu. Całość zamyka dokument SRS (Software Requirements Specification).

Warstwy odpowiadają podziałowi z modelu MDA, na który powołuje się Żeliński: CIM (model działania organizacji — procesy biznesowe i ich produkty), PIM (udokumentowany mechanizm działania oprogramowania, jego logika) i PSM (model implementacji, w praktyce Koncepcja Wdrożenia opracowywana przez wykonawcę).

W PIM nie rozstrzyga się jeszcze o technologii. Jej wybór zależy od ograniczeń i wymagań poza-funkcjonalnych, a decyzja o narzędziu zapada po wskazaniu wykonawcy.

Historie użytkownika nie zastępują tych warstw. Żeliński przywołuje Ronalda Rossa: historie użytkownika pomagają tworzyć rozwiązania biznesowe, ale po opracowaniu zestawu historyjek praca nad wymaganiami i inżynierią rozwiązania nie jest nawet blisko końca.

W metodykach zwinnych modele CIM i PIM się pomija. Typowym narzędziem „zbierania wymagań” stają się historyjki użytkownika — jak podkreśla autor, z reguły niespójne i niekompletne jako wymagania, co stanowi kluczowe ryzyko projektów.

Warsztaty, wywiady, obserwacja i prototypowanie — dobierz technikę do projektu

Katalog technik analizy wymagań pochodzi z Business Analysis Body of Knowledge opracowanego przez International Institute of Business Analysis.

Najpopularniejsze to burze mózgów, analiza aktualnej dokumentacji lub procesów biznesowych, wywiady, obserwacja, prototypowanie i warsztaty. Wybór lub łączenie technik zależy od projektu, stopnia skomplikowania i dostępnego czasu.

Każda technika daje inny typ informacji, więc zestawiaj je świadomie. Analiza dokumentacji i procedur pokazuje stan zapisany w firmie. Obserwacja ujawnia rzeczywisty przebieg pracy, często odbiegający od procedury. Wywiady pozwalają dopytać o wyjątki i przypadki brzegowe, których nie ma w opisach.

Prototypowanie daje użytkownikom konkretny obiekt do oceny i pozwala wykryć braki w opisie przed specyfikacją. Warsztat służy uzgodnieniu stanowisk między działami, które inaczej zgłaszałyby sprzeczne oczekiwania.

Zbieranie wymagań odbywa się zazwyczaj przez serie warsztatów, na których przechodzi się przez kolejne funkcjonalności wpisane w analizowany proces (Wojtachnik).

Uzupełnia je sesja z pracownikami w formie burzy mózgów, której wynikiem ma być kompletna lista funkcji i cech oczekiwanych przez przyszłych użytkowników (Rawski).

Jeden wywiad lub spotkanie nie zastąpi takiego cyklu — ryzykiem jest pominięcie całych obszarów procesu i wyjątków branżowych.

Wymagania funkcjonalne: co system ma robić i jak to sprawdzisz

Wymagania funkcjonalne mówią, co system ma robić: jakie zachowania, funkcje i akcje dostarcza. Odpowiadają na pytania „co” — jakie dane przetwarza, jakie akcje może wykonać użytkownik, jakie dane wyjściowe generuje. Można je ująć jako relację między danymi wejściowymi, stanem systemu i oczekiwanymi danymi wyjściowymi.

Od ogólnej wizji produktu odróżnia je weryfikowalność: system albo realizuje funkcję poprawnie, albo nie.

Standardowe formaty to historie użytkownika („Jako [rola], chcę [funkcja] żeby [korzyść]”), przypadki użycia ze szczegółowym przepływem interakcji, zdania wymagań w stylu IEEE 830 („system musi” / „system powinien”) oraz scenariusze BDD w konwencji Given-When-Then.

Przykłady: „Użytkownik może zresetować hasło przez e-mail”, „System nalicza VAT 23% dla transakcji w PL”, „Administrator może eksportować dane do CSV”.

Przy formułowaniu wymagań funkcjonalnych obowiązują cztery zasady: weryfikowalność i testowalność, brak szczegółów implementacyjnych (opisywać „co”, nie „jak”), spójna terminologia w całym dokumencie oraz powiązanie każdego wymagania z kryteriami akceptacji.

Ardura powołuje się na dane Standish Group: zła inżynieria wymagań to przyczyna numer jeden niepowodzeń projektów IT. Inwestycja w analizę wymagań zwraca się około pięciokrotnie w redukcji przeróbek.

Wymagania niefunkcjonalne: bezpieczeństwo, wydajność, dostępność i niezawodność

Podział łatwo zapamiętać: wymagania funkcjonalne mówią „co”, a niefunkcjonalne (NFR) „jak” — dotyczą wydajności, bezpieczeństwa i niezawodności.

W polskim piśmiennictwie nazywa się je też wymaganiami jakościowymi; obejmują m.in. bezpieczeństwo, bezawaryjność i dostępność systemu. Do tego dochodzą wymagania prawne, o których obok niefunkcjonalnych przypomina Rawski.

NFR nie są dodatkiem na koniec — przesądzają o wyborze technologii i wykonawcy. Żeliński podkreśla, że technologia zależy od wielu poza-funkcjonalnych ograniczeń i wymagań, a wykonawca dopiero opracowuje model implementacji; jego wskazanie poprzedza ustalenie technologii.

Zestaw NFR zawęża listę potencjalnych dostawców, zanim porównamy ceny.

Visure Solutions w przewodnikach po zarządzaniu wymaganiami radzi ustalać realistyczne i osiągalne cele dla NFR.

Zbyt wyśrubowany parametr bez uzasadnienia biznesowego podnosi koszt oferty i utrudnia porównanie dostawców. Zbyt ogólny zapis („system ma być szybki”, „system ma być bezpieczny”) nie daje się zweryfikować na etapie testów odbiorczych.

Priorytetyzacja: MoSCoW i przypadki użycia

Najczęstsze skale priorytetów to opisowa (Wysoki, Średni, Niski), liczbowa (np. od 1 do 5) i MoSCoW ze zbiorami Must (musi być), Should (powinien być), Could (może być) oraz Would/Won't (może być lub nie musi być).

Rawski opisuje tę samą ideę węższym zestawem MUST, SHOULD i COULD. Dodaje drugie kryterium: dopasowanie wymagania do celu wdrożenia.

Zanim wymagania trafią na skalę, pogrupuj je w przypadki użycia. Grupowanie funkcji daje lepszy obraz docelowego kształtu systemu niż płaska lista — pokazuje, kto wykonuje jaką czynność i w jakim kontekście procesowym. Przypadki użycia są zresztą jedną z najczęstszych metod zbierania wymagań od użytkowników.

Priorytety to podstawa rozmowy z dostawcami: MUST wyznacza warunki brzegowe, bez których oferta nie spełnia potrzeb, a SHOULD i COULD dają przestrzeń do ustalania zakresu pierwszego etapu i kolejności wdrożenia.

Bez takiego podziału każda pozycja wygląda równie ważnie, co uniemożliwia porównanie wariantów.

Dokument wymagań: spójny, kompletny, niesprzeczny

Specyfikacja wymagań ma być spójna, kompletna i niesprzeczna. Wymagania muszą kompletnie, spójnie i jednoznacznie opisywać, co chcemy osiągnąć. Informacje z analizy mają jednoznacznie opisywać wymagania i oczekiwania wobec wykonawcy.

Przy spisywaniu wymagań biznesowych warto korzystać z map myśli (mind maps), diagramów przypadków użycia (use case) i narzędzi do modelowania procesów biznesowych.

Efekt końcowy to dokument wymagań wobec oprogramowania, czyli SRS (Software Requirements Specification), zawierający wymagania funkcjonalne i niefunkcjonalne.

Wymagania funkcjonalne zapisuje się m.in. jako zdania „system musi” / „system powinien” albo jako historie użytkownika i scenariusze Given-When-Then.

Dokument jest gotowy do dalszych prac dopiero po akceptacji przez wszystkie strony uczestniczące w analizie. To formalny moment przejścia od zbierania potrzeb do szczegółowych funkcjonalności, a później do oceny ofert.

Najczęstsze pułapki: niejednoznaczność, niekompletność i sama historia użytkownika

Pierwsza pułapka: uznanie zestawu historyjek użytkownika za kompletne wymagania. Żeliński, powołując się na Ronalda Rossa, pisze wprost, że historyjki są pomocne, ale po ich opracowaniu praca nad wymaganiami i inżynierią rozwiązania nie jest nawet blisko zakończenia.

W praktyce bywają niespójne i niekompletne jako wymagania, co czyni je kluczowym ryzykiem projektu.

Druga pułapka: pominięcie modelu działania firmy. W metodykach zwinnych modele CIM i PIM są pomijane, a skoro zakresem projektu nie jest już cała organizacja, trzeba go określić świadomie.

Bez modelu procesów i ich produktów nie ma punktu odniesienia, by sprawdzić, czy wymagania pokrywają cały analizowany obszar pracy.

Trzecia pułapka: niejednoznaczność. W większości przypadków wymagania są niejednoznaczne, a możliwości interpretacji duże.

Lekarstwem jest konsekwentne stosowanie tych samych reguł: kompletności, spójności i jednoznacznego opisu celu, a także powiązania każdego wymagania z kryterium akceptacji i spójnej terminologii w całym dokumencie.

Od zatwierdzonych wymagań do wyboru oprogramowania

Zaakceptowana specyfikacja staje się narzędziem oceny ofert. Każde wymaganie funkcjonalne to scenariusz do sprawdzenia na demonstracji lub w testach — przypisane kryterium akceptacji mówi wprost, kiedy jest spełnione. Każde wymaganie niefunkcjonalne zamienia się w pytanie do dostawcy o sposób pomiaru i potwierdzenia parametru.

Priorytety porządkują rozmowę: MUST wyznaczają warunki brzegowe oferty, a SHOULD i COULD dają pole do ustalania zakresu pierwszego etapu i kolejności prac.

Wymagania niefunkcjonalne dodatkowo zawężają listę wykonawców, bo od nich zależy wybór technologii. Żeliński wskazuje, że technologia ma wynikać z wyboru wykonawcy, nie odwrotnie.

Na koniec kryterium najłatwiejsze do zapomnienia: cel wdrożenia. Rawski ostrzega, że sukcesu nowego systemu nie zapewni najdroższy czy najbardziej renomowany produkt — może być zupełnie niedopasowany do potrzeb przedsiębiorstwa.

Wybór wynikający z zatwierdzonych wymagań i ich priorytetów chroni przed niepotrzebnymi wydatkami, marnowaniem czasu i nieporozumieniami.