Klasyfikacja wymagań – teoria i praktyka

W literaturze często spotkać można propozycje klasyfikacji wymagań według różnych kryteriów. Zazwyczaj dotyczą ona szczegółowości, perspektywy, czy trwałości wymagań. BABOK wymienia podział na wymagania biznesowe (ang. Business requirements), wymagania interesariuszy (ang. Stakeholder requirements), wymagania dotyczące rozwiązania (ang. Solution requirements). Te z kolej dzielą się na wymagania funkcjonalne (ang. Functional requirements) i niefunkcjonalne (ang. Non-functional requirements). BABOK wyróżnia również wymagania przejściowe (ang. Transition requirements).

Podobna klasyfikacja wymagań proponowana jest przez IREB w opublikowanym przez tę instytucję Sylabusie. Zawiera ona podział na: wymagania interesariuszy (biznesowe), wymagania systemowe oraz wymagania dla oprogramowania. Dodatkowo istnieje tam podział na wymagania funkcjonalne, wymagania jakości oraz ograniczenia.

To tylko teoria?

Czy jest to tylko teoretyczny, akademicki i niemający praktycznego zastosowania podział? Czy oprócz przygotowań do egzaminów i rozmów kwalifikacyjnych do niczego nam się nie przyda? Bynajmniej.

Hierarchia wymagań

Podstawą zbierania i opisywania wymagań jest dogłębne zrozumienie stojącej za nimi potrzeby. To właśnie potrzeba (ang. Need) jest nadrzędnym elementem wobec wszystkich wymagań. Tylko w przypadku gdy ją dokładnie zrozumiemy, możemy zrozumieć poszczególne wymagania oraz ich pochodzenie i uzasadnienie.

Wymagania tworzą hierarchię i poprawna ich architektura powinna tę hierarchie uwzględniać. Wymagania znajdujące się wyżej w hierarchii, uzasadniają istnienie tych znajdujących się niżej. Na szczycie hierarchii jest zawsze potrzeba. Wyraża ona cel, który ma być osiągnięty i uzasadnia podjęcie działania. Zwykle utożsamiana jest z szansą, którą chcemy wykorzystać, lub problemem, którego chcemy uniknąć.

Mając dobrze zdefiniowaną potrzebę, wyrażającą cel naszego działania możemy przejść do zbierania i opisywania wymagań. Zaczynamy oczywiście od wymagań najwyższego poziomu, czyli wymagań biznesowych. Są one zazwyczaj dosyć ogólne i wyrażają perspektywę całej organizacji lub istotnej jej części. Dekomponują potrzebę na dokładniej zdefiniowane i konkretne wymagania. Definiują, co musi zostać spełnione, aby potrzeba była zaspokojona.

Kolejne w hierarchii są wymagania interesariuszy, które wyrażają perspektywę konkretnych grup. Opisują to co musi być dostarczone interesariuszom w celu spełnienia wymagań biznesowych.

Kolejne w hierarchi są wymagania dla rozwiązania. Definiują one konkretne możliwości i cechy rozwiązania. Mówią o tym co musi być dostarczone interesariuszom w celu spełnienia ich wymagań. Wymagania te podzielić możemy na wymagania funkcjonalne (skupiające się na konkretnych możliwościach rozwiązania) i wymagania niefunkcjonalne (dotyczące cech jakościowych).

Wyróżniane bywaja również wymagania przejściowe. W swojej naturze są one tymczasowe i mają zastosowanie jedynie w czasie, gdy rozwiązanie jest wprowadzane i organizacja przechodzi ze stanu obecnego, do stanu przyszłego (docelowego).

Kolejność definiowania wymagań

Skoro wymagania tworzą swoistą hierarchię, to również powinno się je definiować w określonej kolejności. Podstawą jest oczywiście dogłębne poznanie i zrozumienie potrzeby, która jest źródłem wszelkich wymagań. Rozumiejąc ją, możemy efektywnie zdefiniować wymagania biznesowe, a następnie patrząc z różnych perspektyw, wymagania interesariuszy. Te z kolei mogą by zdekomponowane do wymagań dla rozwiązania, zarówno funkcjonalnych jak i niefunkcjonalnych.

Nie oznacza to w żadnym wypadku konieczności ścisłego podążania za hierarchią tylko w jednym kierunku i najpierw definiowania wymagań wyższego rzędu, a po stworzeniu „kompletnej” listy ich dekomponowania bez możliwości powrotu do pozyskiwania i opisywania wymagań „nadrzędnych”. Byłoby to zaprzeczeniem „zwinności” i samej istoty Analizy Biznesowej, która zakłada, że nowe wymagania, niezależnie od ich sklasyfikowania, mogą się pojawić w dowolnym momencie projektu.

O co zatem chodzi?

Chodzi o to by nie chodzić na skróty, choć zawsze jest to kuszące. Często Analitycy Biznesowi mają tendencję do pomijania dokładnego definiowania potrzeby i celu, a co za tym idzie nie rozumieją go i nie potrafią go wytłumaczyć interesariuszom. Skutkuje to tym, iż cel się „rozmywa”. Przestajemy wiedzieć co właściwie robimy, po co i dlaczego. Ciężko jest osiągnąć cel, który nie jest zdefiniowany, a zatem ciężko zakończyć taki projekt sukcesem.

Inną powszechną pokusą jest pomijanie definiowania ogólnych wymagań biznesowych i przechodzenie od razu do „konkretów” dotyczących rozwiązania. Skutkuje to zbyt wczesnym narzuceniem sobie pewnych założeń i niepotrzebnym ograniczeniem sobie puli potencjalnych rozwiązań. Zazwyczaj kończymy wtedy na implementacji rozwiązania dalekiego od optymalnego, za to dobrze znanego, standardowego, lub tego, które przyszło nam do głowy jako pierwsze.

Definiując zbyt wcześnie, zbyt szczegółowe wymagania (w skrajności gotowe rozwiązania) niszczymy kreatywność zespołu, z którym współpracujemy. Potencjalnie zespół kreatywnych ludzi (programistów, testerów, specjalistów od UX etc.) mógłby zaproponować coś lepszego, ale będąc zbyt wcześnie ukierunkowany lub mając ograniczoną zbyt wcześnie swobodę za pomocą nadmiernie szczegółowych wymagań, podąża utartą, narzuconą ścieżką, tworząc rozwiązania nieoptymalne.

Antyprzykłady

Spotkałem się kiedyś z sytuacją, gdy współpracujący ze mną Analityk Biznesowy zaprezentował rozwiązanie, opisane szczegółowo na makietach ekranu, ze zwróceniem szczególnej uwagi na kontrolki, ich rodzaj, rozmieszczenie itp. Zapytany o proces biznesowy, który za tym stoi, realizowaną potrzebę i inne potencjalne opcje rozwiązania, miał problemy z odpowiedzią. Jest to przykład skutków, do których prowadzi zbyt wczesne skupienie się na rozwiązaniu, bez dokładnego rozważenia poszczególnych wymagań i stojącej za nimi potrzeby.

Innym przykładem zbyt wczesnego skupienia się na szczegółach rozwiązania bez dokładnej analizy wymagań, była sytuacja mająca miejsce gdy pracowałem w pewnej dużej instytucji. Pracujący w niej zespół zgłosił „wymaganie” mówiące o dodaniu nowego formularza. Oczywiście istniała możliwość bezrefleksyjnego przyjęcia tego wymagania i dodania dodatkowego formularza do używanego przez nich systemu. Zapewne byliby w miarę zadowoleni, bo przecież ich żądanie zostałoby spełnione. Czy jednak rzeczywistą ich potrzebą czy choćby wymaganiem interesariusza był nowy formularz? Oczywiście, że nie. Potrzebowali w systemie określonych danych, niezbędnych do wykonania pewnych operacji, a formularz miał być tylko narzędziem do ich wprowadzania. Dane te mogły być importowane w automatyczny sposób z innego systemu, o czym zespół zgłaszający „wymaganie” nie wiedział. Finalnie udało się stworzyć funkcjonalność importu i zautomatyzować cały proces. Bez wyjścia poza ramy narzucanego rozwiązania i odkrycia stojącej za nim potrzeby, dostarczone rozwiązanie byłoby dalekie od optymalnego.

Hierarchia a śladowanie wymagań

Dobre zrozumienie klasyfikacji i wynikającej z niej hierarchii wymagań, pozwala na efektywne śladowanie wymagań, czyli tworzenie między nimi stosownych powiązań. Jest to niezwykle przydatne i użyteczne. Zalety śladowania wymagań i dobre praktyki z tym związane to dość obszerny temat, nadający się na osobny artykuł.

Moje rekomendacje

  • Zawsze staraj się dogłębnie zrozumieć potrzebę stojącą za danym projektem lub działaniem
  • Twórz wymagania hierarchicznie, dekomponując ogólne na bardziej szczegółowe
  • Zbierając i opisując wymagania interesariuszy, staraj się spojrzeć na problem z ich perspektywy
  • Nie skupiaj się zbyt wcześnie na rozwiązaniu i nie zawężaj tym samym potencjalnego zbioru dostępnych opcji

Źródła

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide). Version 3. 2015.
Certyfikowany specjalista inżynierii wymagań IREB, Sylabus, wersja 2.3, 2015.