Analiza – Proces zbierania i analizy wymagań

Analiza wymagań

Na rynku nie brakuje książek poświęconych tematyce zbierania wymagań skierowanych do analityków systemów IT. W tym artykule chciałabym podzielić się swoimi spostrzeżeniami związanymi ze stosowaniem wiedzy akademickiej i książkowej z zakresu zbierania wymagań w codziennej pracy praktykującego analityka systemów IT. Niniejszy artykuł jest konfrontacją wiedzy merytorycznej ze stosowanymi praktykami.

Nadrzędnym celem tworzonych rozwiązań informatycznych jest realizacja wymagań klienta. W przeciwnym razie nasz klient nie będzie zainteresowany ich odbiorem. Jeśli mamy 3 zespoły wytwórcze, do których trafiły takie same wymagania pod kątem rozwiązania IT, to w praktyce powstaną 3 różne systemy. Każdy z zespołów może stworzyć autorskie rozwiązanie. Każde z rozwiązań może być atrakcyjne, jednak każde powinno w pełni realizować otrzymane wymagania. Najważniejszą rzeczą jest więc dbałość o realizację wszystkich wymagań klienta i taką rolę ma analityk systemu IT. Widać zatem, że kluczową rolę w  tworzeniu rozwiązania IT ma proces zbierania i analizy wymagań klienta. Stanowi on podstawę do dalszych prac nad danym projektem. Moim zdaniem od niego właśnie zależy sukces całego projektu.

Zacznijmy więc od początku…

Wymaganie jest potrzebą klienta, która wpływa na powstanie nowego rozwiązania lub zmienia rozwiązanie już istniejące. Ze względu na poziom szczegółowości wymagania mogą być biznesowe lub systemowe.

Wymaganie biznesowe realizowane jest poprzez jedno lub zbiór wymagań systemowych. Przykładem może być Import plików z umowami. Wymaganie to można zrealizować poprzez dwa wymagania systemowe: import plików i obsługa zaimportowanych plików.

Import plików – schemat wymagań

Wymagania systemowe dotyczą bezpośrednich funkcjonalności systemu. Złożone wymagania systemowe można przedstawić za pomocą bardziej szczegółowych, np. Import plików obejmuje wykonanie sprawdzeń i walidacji na zaimportowanych danych oraz proces zapisu umów z pliku importu w systemie.

W przykładzie podanym dla wymagania biznesowego Import plików z umowami wymaganiami funkcjonalnymi są np.:

  • WMF_002 Import plików
  • WMF_003 Obsługa zaimportowanych plików

(wszystkie wymagania oznaczone kolorem różowym), natomiast wymagania niefunkcjonalne to:

  • WNF_001 Import poprzez Enterprise Service Bus
  • WNF_002 Max. czas importu dla jednego pliku

(oznaczone kolorem fioletowym).

UWAGA: W podanym przykładzie WNF_002 Max. czas importu dla jednego pliku ujęte jest jako wymaganie niefunkcjonalne, jednak można je również zakwalifikować do grupy wymagań efektywnościowych zawierających się w wymaganiach funkcjonalnych.

Pisząc o wymaganiach, trudno nie wspomnieć o formie, w jakiej najczęściej są one przekazywane analitykowi. Można je podzielić na trzy grupy:

  • przekazane jako załącznik do zapytania ofertowego;
  • przedstawione w formie opisu celu biznesowego, jaki klient chce osiągnąć;
  • przedstawione w formie opisu konkretnej modyfikacji systemu.

Taki podział wymagań wpływa na dalsze prace analityczne, które powinny doprowadzić do opracowania dokumentu specyfikacji wymagań. Więcej pracy analitycznej będzie wymagało zebranie wymagań przedstawionych w formie opisu celu do osiągnięcia niż w formie opisu konkretnej zmiany. Najlepiej jest oczywiście otrzymać wymagania wyspecyfikowane w zapytaniu ofertowym, gdyż zazwyczaj są one konkretne, spójne i osiągalne.

Definicja wymagania

Poprawnie zdefiniowane wymaganie powinno zawierać:

  • dane wejściowe;
  • dane wyjściowe, czyli zakres otrzymanych danych w wyniku wykonania danej funkcjonalności;
  • zbiór wymagań funkcjonalnych, czyli usług wykonywanych w ramach danej funkcjonalności;
    Wymagania funkcjonalne – określają, co system ma robić oraz czego robić nie powinien. Dotyczą rezultatów oczekiwanych przez użytkownika. Zawierają: przewidziane tryby pracy systemu, funkcje wykonywane przez system, oraz postać interfejsów.
    (Źródło: Inżynieria oprogramowania w projekcie informatycznym pod red. Janusza Górskiego, wyd. Mikom)
  • zbiór wymagań niefunkcjonalnych, czyli cech, jakie musi posiadać dane rozwiązanie.
    Wymagania niefunkcjonalne – związane są z określeniem ram jakościowych oraz wydajnościowych danego rozwiązania. Przykładami takich wymagań są przydatność, dostępność, niezawodność, podatność na testowanie, możliwości utrzymania, rozszerzalność, kompatybilność, integracja z innymi systemami.

Proces zbierania wymagań
Otrzymanie wymagań od klienta to dopiero początek ich analizy. Nie można oprzeć się wprost na otrzymanym wymaganiu, gdyż często nie stanowi ono zbioru potrzeb wszystkich użytkowników, a tylko jednej osoby i jako takie jest mało precyzyjne, niekompletne, niespójne. Należy doprecyzować zakres zmian objętych danym wymaganiem. W zależności od formy, w jakiej dane wymagania zostały przekazane, wymagany jest od analityka większy lub mniejszy nakład pracy z wymaganiami. Należy przy tym pamiętać, że niezależnie od formy otrzymanych wymagań ich wstępna analiza powinna zakończyć się dokumentem na takim samym poziomie szczegółowości. Proces zbierania wymagań lub doprecyzowanie otrzymanych wymagań opiera się na różnorodnych technikach: spotkania z klientem na których prezentowane są procesy wymagające systemowego wsparcia, wywiady z użytkownikami systemu oraz analizy systemów, które mają zostać rozwinięte.

Pozyskiwanie wymagań można podzielić na 3 etapy:

  • otrzymanie lub „wydobycie” wymagań;
  • wstępna prezentacja wymagań – wypowiedzenie i udokumentowanie wymagań z punktu widzenia analityka; metody reprezentacji najczęściej stosowane w praktyce to opis słowny oraz graficzna prezentacja wymagań;
  • wstępna analiza wymagań – ma na celu potwierdzenie przez klienta, że opisane przez analityka wymagania zostały wiarygodnie odzwierciedlone w stosunku do jego oczekiwań.

Proces pozyskiwania wymagań powinien być kontynuowany do momentu, gdy będziemy pewni, że zebrane wymagania są kompletne i poprawnie sformułowane. Należy przewidzieć kilka iteracji dla tego procesu. Podczas każdej z nich analityk powinien ustalić, czy opis wymagania odpowiada oczekiwaniom i potrzebom klienta oraz czy jego interpretacja jest poprawna.

Cykl pracy z wymaganiami

 

W praktyce mamy do czynienia z następującym cyklem pracy z wymaganiami:

  1. powstanie nowego wymagania;
  2. przegląd, omówienie nowego wymagania;
  3. akceptacja potwierdzonego wymagania;
  4. modyfikacje wymagania na etapie omawiania.

Dokument specyfikacji wymagań użytkownika
Zgodnie z teorią specyfikacja powinna zawierać przede wszystkim wymagania zaprezentowane z punktu widzenia klienta i w terminach dla niego zrozumiałych. Powinna stwierdzać, co ma zostać zrealizowane, a nie jak należy to zrobić. Specyfikacja nie może być więc próbą projektowania systemu.

A co na taką definicję odpowiada praktyka? Otóż trudno się z nią nie zgodzić. Kluczowym celem analizy wymagań jest dokładne określenie, nazwanie i opisanie potrzeb klienta. Na tym etapie opisujemy, co powinno być wykonane, abstrahując od tego, jak to powinno zostać wykonane. Dokument analizy wymagań użytkownika pełni rolę umowy między klientem a docelowym wykonawcą rozwiązania. Analiza wymagań użytkownika powinna stanowić element analizy szczegółowej, która z kolei nie powinna się rozpoczynać, jeśli nie mamy potwierdzonej specyfikacji wymagań.

Analiza wymagań powinna obejmować następujące etapy:

  1. Identyfikacja wymagania biznesowego – nazwanie wymagania. Ponieważ wymagania mogą być przekazane w różnej formie, zadaniem analityka jest wyspecyfikowanie konkretnych wymagań. Każde powinno otrzymać unikalny symbol oraz krótką znaczącą nazwę, opis wymagania, zestaw atrybutów (cech) danego wymagania.
  2. Potwierdzenie wymagania z klientem – etap bardzo istotny ze względu na zakres całego projektu. Etap potwierdzenia to ustalenie, czy opisane wymagania w pełni realizują procesy, których dotyczyły.
  3. Grupowanie i segregowanie zebranych wymagań – etap porządkowania, grupowania wg funkcji, kategorii. Celem tego etapu jest znalezienie duplikatów, sprzeczności, powiązań między wymaganiami oraz potwierdzenie kompletności rozwiązania.
  4. Ustalenie priorytetów – nadanie stopnia ważności danego wymagania dla klienta.
  5. Przemapowanie wymagania biznesowego na wymagania systemowe. Etap dekompozycji wymagania biznesowego na bardziej szczegółowe wymagania systemowe.
  6. Zatwierdzenie dokumentu analizy wymagań przez klienta.
Ustalenie powiązań między wymaganiami jest bardzo istotnym elementem, gdyż bezpośrednio przekłada się na proces zarządzania zmianą. Wymagania mogą być powiązane związkiem agregacji (aggregate) lub zależności (dependency).

 
Poprawność dokumentu specyfikacji wymagań
Analityk powinien zadbać o wysoką jakość specyfikowanych wymagań. Literatura z zakresu inżynierii oprogramowania (Inżynieria oprogramowania w projekcie informatycznym pod red. Janusza Górskiego, Wydawnictwo MIKOM) mówi o następujących atrybutach poprawnej specyfikacji:

  1. poprawna – przeanalizowana i potwierdzona przez klienta;
  2. kompletna – zawiera pełen zbiór wymagań i każde z nich jest kompletnie opisane;
  3. jednoznaczna – zawiera wymagania podlegające tylko jednej semantycznej interpretacji;
  4. spójna – nie zawiera wymagań wzajemnie sprzecznych;
  5. weryfikowalna – zawiera procedury sprawdzające, czy wymaganie zostało zrealizowane;
  6. modyfikowalna – pozwala w łatwy sposób dokonać zmian w wymaganiach, przy zachowaniu kompatybilności i spójności między nimi.
  7. sprawdzalna – pozwala na śledzenie wpływu wszelkich zmian na dane wymaganie poprzez rejestrację źródła każdego z wymagań.

W praktyce największą uwagę poświęca się pierwszym pięciu atrybutom. Szczególnie dba się o to, aby wymagania zawarte w specyfikacji były:

  • poprawne;
  • kompletne, czyli w pełni opisane;
  • jednoznaczne, czyli podlegające jednej i tylko jednej interpretacji;
  • spójne, czyli zgodne z pozostałymi wymaganiami;
  • weryfikowalne, czyli możliwe do sprawdzenia, przetestowania.

Takie praktyki pokrywają się wprost z definicją jakości wymagań ujętą w książce (D. Leffingwell, D. Widrig, Zarządzanie wymaganiami, WNT 2003)

Dokument specyfikacji wymagań jest punktem wyjścia do tworzenia analizy szczegółowej. Każde wymaganie opisane w specyfikacji powinno być źródłem do szczegółowej analizy systemu.

Podsumowując, muszę przyznać, że wiedza „książkowa” z zakresu inżynierii oprogramowania, modelowania z użyciem języka UML, czy metodyk stosowanych w procesach wytwórczych (RUP, Agile – Scrum) stanowi idealną podstawę dla codziennej pracy analityka systemów IT. W zakresie zbierania i analizy wymagań wiedza ta w pełni pokrywa się z praktyką.


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

2 komentarzy do “Analiza – Proces zbierania i analizy wymagań

  • Mariusz

    Realizacja wymagań czy zarządzanie wymaganiami

    Przeczytałem, ciekawy opis definicji wymagań. Szczególnie podoba mi się ocena, że od wymagań powinien zacząć się proces analizy. Analiza powinna być poprzedzona opracowaniem wymagań. Powinna się też zakończyć podsumowaniem w jakim stopniu spełnia wymagania.
    Jedno mnie zaniepokoiło. Napisałaś we wstępie, że musimy zrealizować wszystkie wymagania klienta. Uważam, że nie musimy. Zwłaszcza jeśli to jest lista wymagań jeszcze nie opracowanych a tylko zgłoszonych. Tak jak dalej piszesz, jest proces pozyskiwania i opracowywania wymagań, sprawdzania czy są spójne, jednoznaczne. W trakcie tego opracowania może wyjść, że niektóre wymagania są sprzeczne i trzeba je odrzucić. Być może też wyjdzie, że niektóre niosą małą wartość biznesową a wysoki koszt realizacji i też ich nie będziemy realizować w systemie. Dlatego bardziej do mnie trafia to co napisałaś, że celem jest zbieranie i analiza wymagań, czyli zarządzanie wymaganiami.

    • Magdalena Fostacz Autor wpisu

      Słuszna uwaga do stwierdzenia, że wszystkie wymagania klienta musimy zrealizować. Stwierdzenie powinno zawierać raczej opinię, że analiza wymagań jest podstawą do podjęcia decyzji, co do słuszności realizacji wszystkich zebranych wymagań. Dziękuję za trafne spostrzeżenia.