Analiza wymagań – sztuka czy rzemiosło?

Każdą zmianę w systemach IT zaczynamy od analizy wymagań. Może być ona na bardzo wysokim poziomie ogólności lub szczegółowa. Może być wykonana przez zespół wewnętrzny albo przez kogoś z zewnątrz. Bez względu na to, pewnym jest, że bez określenia co jest oczekiwane, nie jest możliwe zaplanowanie żadnych prac, zabudżetowanie, zaalokować zespołu, nie mówiąc już o stworzeniu systemu informatycznego.

Wysoka jakość analizy wymagań staje się zatem kluczem do sukcesu kolejnych etapów projektu informatycznego, a w konsekwencji całego przedsięwzięcia. Jak osiągnąć taką jakość? Czy zależy to wyłącznie od indywidualnych umiejętności konkretnej osoby wykonującej tę pracę czy są narzędzia i metody, które pomagają osiągnąć ten cel? Na te pytania postaram się odpowiedzieć.

Sztuka analityczna

Wiele osób zastanawiało się nad tym, jak wygląda dobra analiza wymagań i dobre wymaganie. Na przykład Business Analysts Body Of Knowledge (BABOK) definiuje wymaganie dość ogólnie, jako użyteczną reprezentację potrzeby. Z drugiej strony, norma 29148-2011 ISO/IEC/IEEE International Standard, wskazuje, aby wymaganie było weryfikowalne, realizowało cel interesariusza, było określone przez mierzalne warunki lub ograniczenia i definiowało zachowanie systemu. Z kolei standard: 830-1998 IEEE Recommended Practice for Software Requirements Specifications wymagał jednoznaczności wymagania, spójności, czytelności, poprawności, kompletności, weryfikowalności oraz łatwej modyfikowalności i śledzenia zmian.

Bez wątpienia najważniejsze jest, aby wymaganie odpowiadało rzeczywistej potrzebie. Jest to o tyle trudne, że często jest ona ukryta i nie jest tak łatwo do niej dotrzeć. Przykładowo użytkownik zgłasza potrzebę wyszukiwania osób. Potrzeba wydaje się racjonalna i uzasadniona. Moglibyśmy tylko na tej podstawie zaplanować i zrealizować funkcjonalność wyszukiwania osób. Jakie byłoby jednak nasze zdziwienie, gdyby użytkownik na testach akceptacyjnych chwaląc nas za dobrze działające wyszukiwanie, zapytał jednocześnie gdzie jest zapis wyników do Excela, ponieważ tak naprawdę potrzebuje raportu osób ubezpieczonych…

Rzemiosło analityczne

Jak zatem „wydobyć” od użytkownika biznesowego faktyczną potrzebę? Jak upewnić się, że wydobyta potrzeba jest tą prawdziwą? Z mojej praktyki najskuteczniejszą metodą jest wykorzystanie przykładów. W pełni zgadzam się z Gojko Adzic, autorem książki Specification by Example, który używając przykładów w swojej praktyce inżynierii oprogramowania zbudował własną metodę specyfikacji i realizacji systemów IT.  Jako analityk, dzięki przykładom, mogę lepiej zrozumieć pojęcia, którymi operuje mój rozmówca – użytkownik biznesowy. Pytania na temat działania biznesu, które zadaję na konkretnym przykładzie, są lepiej zrozumiane niż pytania abstrakcyjne nie wykorzystujące takich informacji.

Przykłady warto także wykorzystać do weryfikacji przygotowanej koncepcji realizacji danego wymagania. Ta weryfikacja jest fundamentalnym momentem analizy wymagań. Jeśli osoba definiująca dane wymaganie widzi, że przygotowana koncepcja rozwiązania realizuje to wymaganie, mamy pewność, że zbudujemy właściwe rozwiązanie.  Użytkownikowi biznesowemu, nieznającemu języka IT, najłatwiej będzie zrozumieć koncepcję rozwiązania właśnie przez przykłady. Mogą nimi być makiety, wyniki obliczeń, raporty, dokumenty, opisy stanu obiektów widocznych dla użytkownika.

Przykłady, przykłady, przykłady

Przykłady, będące częścią dokumentacji wymagań i projektu rozwiązania, są naturalnym źródłem dobrych danych testowych, pochodzących bezpośrednio od użytkowników biznesowych. Dobrze sprawdzają się także do rozstrzygania późniejszych problemów „czy to błąd czy poprawne działanie”.

Zalety wykorzystywania przykładów w mojej opinii zdecydowanie przeważają nad pracą, którą należy poświęcić, aby zarządzać przykładami – identyfikować kluczowe, dodawać brakujące a eliminować zbędne i utrzymywać ich aktualność w miarę pojawiających się zmian.

Mam wiele pozytywnych doświadczeń z zastosowania przykładów w wielu projektach z różnych branż – zarówno w przypadku systemu do zarządzania i planowania czasu pracy pracowników, jak i systemu do sprzedaży i obsługi ubezpieczeń – gdzie przykłady były gwarancją wzajemnego zrozumienia, a przez to dobrej dokumentacji analitycznej.

Autor: Artur Kret, Dyrektor Działu Konsultingu Altkom Software & Consulting