Rodzaje wymagań według IIBA BABOK Guide 3.0

Jednym z etapów pracy analityka jest opisywanie wymagań. Mogą one przybierać różne formy: od wymagań opisywanych tradycyjnie po wymagania opisywane w formie historyjek użytkownika (ang. user stories). Warto jednak zaznaczyć, że mając do czynienia z wymaganiami, trzeba pamiętać o ich rodzajach/klasyfikacjach.

Jedną z takich klasyfikacji jest podział zaproponowany przez International Institute of Business Analysis (dalej IIBA), a opisany w Business Analysis Body of Knowledge Guide 3.0 (dalej BABOK Guide 3.0), który jest uznawany za „biblię” analizy biznesowej.

W artykule opisane zostaną poziomy wymagań zaproponowane przez IIBA w BABOK Guide 3.0 wraz z ich definicją oraz praktycznymi przykładami. Dodatkowo opisane zostaną zależności między typami wymagań, o których warto pamiętać.

Definicja wymagania

Zanim przejdziemy do klasyfikacji wymagań, warto zdefiniować wymaganie (ang. requirement). To, zgodnie z definicją IIBA BABOK 3.0, jest „użyteczną” reprezentacją potrzeby oraz skupia się na wartości, jaką można dostarczyć, gdy wymaganie zostanie spełnione¹. Warto zaznaczyć, że termin wymagania jest jednym z podstawowych pojęć (ang. key terms), które definiuje BABOK Guide 3.0.

A requirement is a usable representation of a need. Requirements focus on understanding what kind of value could be delivered if a requirement is fulfilled (…).

Wiedząc, czym jest wymaganie, zgodnie z IIBA BABOK 3.0 można przedstawić klasyfikację wymagań. Przewodnik analizy biznesowej definiuje cztery, niżej opisane typy:

• Wymagania biznesowe (ang. business requirements),
• Wymagania interesariuszy (ang. stakeholder requirements),
• Wymagania rozwiązania (ang. solution requirements),
• Wymagania przejścia (ang. transition requirements).

Wymagania biznesowe

Biorąc pod uwagę określanie wymagań oraz działając zgodnie z IIBA BABOK Guide 3.0, pierwszym i najwyższym poziomem wymagań są wymagania biznesowe². Ten typ wymagań jest bezpośrednią reprezentacją potrzeb Klienta. Odpowiada na pytanie, jakie cele biznesowe Klient chce osiągnąć poprzez rozwiązanie.

Business requirements: statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative.

Ten typ wymagań będzie odpowiadał na pytanie, dlaczego dana zmiana jest wprowadzana w przedsiębiorstwie.

Przykład wymagań biznesowych

Przedsiębiorstwo dochodząc przyczyn źródłowych swoich niepowodzeń w obszarze obsługi klienta, doszło do wniosku, że proces obsługi zajmuje za dużo czasu, przez co Klienci odchodzą do konkurencji. Podjęto decyzję, żeby przyspieszyć realizację procesu obsługi o 20% do końca przyszłego roku (wymaganie biznesowe). Jej celem było zminimalizowanie zidentyfikowanego ryzyka jakim jest potencjalny odpływ klientów (potrzeba ←→ ryzyko). Należy zauważyć, że tak określony cel, a tym samym stan przyszły jest SMART:

• Specific,
• Measurable, 
• Achievable, 
• Relevant,
• Time-bounded.

Wymagania interesariuszy

Kolejną kategorią wymagań są wymagania interesariuszy³. Zgodnie z definicją podaną przez BABOK Guide 3.0 są kategorią, która stanowi pomost pomiędzy wcześniej opisanymi wymaganiami biznesowymi a wymaganiami rozwiązania. Dodatkowo, wymagania te pokazują potrzeby interesariuszy, które muszą zostać zaspokojone, by osiągnąć wymaganie biznesowe. Poniżej, tak jak w przypadku wymagań biznesowych, została przytoczona definicja wymagań interesariuszy:

Stakeholder requirements: describe the needs of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business and solution requirements.

Można zauważyć, że definicja tej kategorii wymagań nie jest jednoznaczna i może być wyzwaniem podczas interpretacji, przez co zaciemnia jej zrozumienie. W związku z powyższym poprosiliśmy IIBA o wyjaśnienia. Poniżej przytoczono tekst odpowiedzi:

When it comes to stakeholder requirements, people describe them in different ways. Below is described one possible way how to think of them.

Let’s say that the goal of an organization is to increase revenue by 10%. That’s your business requirement.

There are different ways to achieve this business requirement, and different stakeholders will prefer different ways to meet that goal.

Example: Chief of Marketing may say we need to increase marketing for our products.

Example: Head of Product Development thinks we should add more features to our best-selling product and it will result in more sales.

Example: Head of Sales insists we create better promotional materials for the sales team.

Each of these are important stakeholders.

An important part of business analysis professionals’ work is to develop a shared understanding and common goals. It is particularly important to ensure support from all key stakeholders so the team is focused on producing the desired outcomes and delivering value that helps achieve the business requirement. Working with key stakeholders to identify stakeholder requirements will define which direction will be undertaken.

Having set a direction with stakeholder requirements, we can now better define solution requirements for this new feature – what functional or non-functional requirements this new feature must have.

If we jump straight from business to solution requirements, we might define a solution that does not satisfy the needs of stakeholders.

By aligning the business, stakeholder, and solution requirements, we ensure alignment across the organization to achieve the desired goal.

Interpretacja wymagań interesariuszy

Jak, w związku z powyższym, można rozumieć ten rodzaj wymagań? Wymagania interesariuszy można zdefiniować jako grupę wymagań, która pokazuje akcje niezbędne z perspektywy interesariuszy do zrealizowania potrzeby biznesowej (wymagania biznesowego). Co więcej, akcje te na późniejszym etapie prac nad wymaganiami będą grupowały wymagania rozwiązania, w związku z czym można je rozumieć jako hasła na wysokim poziomie abstrakcji, które określają to, co powinno zostać dostarczone, aby zaspokoić potrzebę.

Skąd je bierzemy? W momencie, gdy określone zostały wymagania biznesowe (reprezentacje potrzeb – szans/zagrożeń), główni interesariusze (key stakeholders) muszą zostać zaangażowani w celu wydobycia tychże wymagań. W wyniku rozmów otrzymujemy grupy wymagań, nad którymi możemy pracować. Dodatkowo, jak pokazuje praktyka, źródłem wymagań interesariuszy mogą być zamodelowane, docelowe procesy biznesowe (proces biznesowy to-be).

Ważnym jest, by zaznaczyć, że na etapie wymagań rozwiązania, ale też na etapie wymagań biznesowych, należy abstrahować od rozwiązania/implementacji. Przykładowo: jeden z kluczowych interesariuszy powie, że chciałby mieć feature w postaci „Spinacza takiego jak w Wordzie”. Trzeba dowiedzieć się, „dlaczego” taka funkcjonalność jest potrzebna. Wówczas można otrzymać informację, że np. oczekiwaniem Klienta jest bycie poinformowanym o możliwych akcjach. Czy też w momencie, gdy Klient stwierdzi, że chciałby, aby jego system był zintegrowany z systemem PESEL, możemy dowiedzieć się, że potrzebą interesariusza jest zapewnienie aktualności danych.

Charakterystyki wymagań interesariuszy

Podsumowując, wymagania interesariuszy mogą przybrać następujące charakterystyki:

• Pochodzą od głównych interesariuszy lub można opisywać je w oparciu o procesy biznesowe to-be (dobra praktyka).
• Są wysokopoziomowymi grupami wymagań, przy czym grupa ma wskazywać na akcję, którą należy wykonać, ażeby osiągnąć cel biznesowy → wiodący jest cel. Innymi słowy wymagania interesariuszy pokazują „hasła” grupujące to, co w szczegółach będzie opisywane w wymaganiach rozwiązania, tj. wymagania interesariuszy są źródłem/abstrakcją wymagań rozwiązania.
• Wydobywając wymagania interesariusza, należy dociekać „jaką” i „dlaczego taką” interesariusz widzi potrzebę wykonania danej akcji.

Pokazują poziom między celem (wymagania biznesowe) a konkretem rozwiązania (wymagania rozwiązania).

Przykład wymagań interesariuszy

W momencie, gdy zidentyfikowano wymaganie biznesowego, jakim jest przyspieszenie realizacji procesu obsługi klienta o 20% do końca przyszłego roku, główni – z perspektywy zmiany –interesariusze zostali zaangażowani do rozmów. W efekcie stwierdzono, że należy zapewnić m.in.:

• Możliwość przyjmowania zapytań od Klientów firmy.
• Aktualizację danych klientów.
• W przypadku, gdy niemożliwa jest obsługa zapytania Klienta bez udziału pracownika Biura Obsługi Klienta, wspomniany pracownik BOK ma dostęp do zapytań od Klientów i obsługuje ich zapytania.

Na tym etapie wymagań można przyjąć dalsze dekompozycje w ramach poszczególnych grup.

Wymagania rozwiązania

Trzecią kategorią wymagań zaproponowanych przez BABOK Guide 3.0, są wymagania rozwiązania⁴. Kategoria ta pokazuje szczegóły rozwiązania. Stanowią one podstawę prac implementacyjnych dla zespołu deweloperskiego. Ważnym jest, by podkreślić, że kategoria ta jest kategorią abstrakcyjną. Zapisując wymagania, ten typ nie jest odrębnym typem wymagań. Kategoria ta dzieli się na znane wszystkim z klasycznej inżynierii wymagań wymagania funkcjonalne i niefunkcjonalne.

Solution requirements: describe the capabilities and qualities of a solution that meets the stakeholder requirements. They provide the appropriate level of detail to allow for the development and implementation of the solution. Solution requirements can be divided into two sub-categories:

• functional requirements: describe the capabilities that a solution must have in terms of the behaviour and information that the solution will manage, and

• non-functional requirements or quality of service requirements: do not relate directly to the behaviour of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have.

Wymagania te na ogół powinny być wymaganiami atomowymi, w związku z czym nie będziemy dokonywać dekompozycji.

Przykład wymagań rozwiązania

W ramach określonych wymagań interesariuszy zidentyfikowano następujące wymaganie:

• Możliwość przyjmowania zapytań od Klientów firmy.

Dla takiego wymagania interesariusza można zidentyfikować następujące wymagania rozwiązania:

Wymagania funkcjonalne

• Klient może złożyć zapytanie reklamacyjne do swojego zamówienia.
• Klient jest informowany o statusie zapytania.
• Klient otrzymuje informację o otrzymaniu odpowiedzi zgodnie z preferowanym kanałem kontaktu (SMS, wiadomość e-mail).
• Klient tworząc zapytanie, załącza załączniki: paragon lub faktura VAT oraz opis reklamacji.
• Pracownik BOK jest informowany nowych zapytaniach.
• Pracownik BOK przypisuje do siebie zapytanie.
• Pracownik BOK jest informowany o treści zapytania reklamacyjnego.
• Pracownik BOK po zapoznaniu się z treścią zapytania odrzuca bądź akceptuje zapytanie reklamacyjne.

Wymagania niefunkcjonalne

• Panel Klienta ładuje się maksymalnie 2 sekundy.
• Proces reklamacji kończy się maksymalnie w ciągu 7 dni roboczych od daty złożenia zapytania reklamacyjnego.
• Aplikacja stosuje szyfrowanie XXX.
• System jest dostępny na przeglądarkach XXX z wersją od YYY.
• System może obsłużyć ZZZ zapytań w ciągu sekundy.

Wymagania przejścia

Ostatnią kategorią wymagań są wymagania przejścia⁵ (ang. transition requirements). Kategoria ta określa, jakie czynności należy przedsięwziąć, aby zmiana była możliwa, gdzie wymagania „żyją” do momentu ich wdrożenia. Innymi słowy – można określić je wymaganiami jednorazowymi.

Transition requirements: describe the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete. They are differentiated from other requirements types because they are of a temporary nature. Transition requirements address topics such as data conversion, training, and business continuity.

W praktyce jednak często ten typ wymagań nie jest zapisywany bądź zapisywany wyłącznie po stronie Zleceniodawcy (Sponsora projektu).

Przykład wymagań przejścia

Na podstawie przytoczonej definicji oraz zdefiniowanych w poprzednich rozdziałach: wymagania biznesowego, interesariuszy oraz rozwiązania, można określić następujące wymagania przejścia:

• Dostarczenie serwera o konkretnych parametrach.
• Przeszkolenie pracowników BOK w zakresie obsługi nowego rozwiązania.
• Informowanie Klientów o nadchodzącej zmianie (kampania marketingowa).

Podsumowanie

IIBA BABOK Guide 3.0 dostarcza ustrukturyzowany schemat opisywania wymagań. To, co nie zostało jeszcze napisane, a co warto podkreślić – źródłem wymagań każdego poziomu są interesariusze, mimo że tylko jedna z kategorii na nich wskazuje. Może to wprowadzać pewne zamieszanie.

Na podstawie wyżej przytoczonych definicji oraz przykładów wymagania biznesowe są najwyżej w hierarchii wymagań. Są opisywane w oparciu o potrzeby klientów i pokazują nadrzędny cel. Po nich określane są wymagania interesariuszy, które ten cel realizują, a w końcu, by dostarczyć wymagania interesariuszy, a tym samym zaspokoić potrzeby Klienta, opisywane są wymagania rozwiązania, na podstawie których zespoły deweloperskie mogą przeprowadzić implementację.

Powiązania pomiędzy poszczególnymi poziomami wymagań a rozwiązaniem pokazuje powyższy diagram. Jak widać, zgodnie z zaproponowanym przez BABOK Guide 3.0, diagram nie przedstawia wymagań przejścia, a wyłącznie śladowanie od potrzeby biznesowej po wymagania rozwiązania i  projekt (ang. desing), kod i testy, które realizują, a w przypadku testów walidują, wymagania rozwiązania, celem sprawdzenia czy dostarczone rozwiązanie (ang. solution) spełnia wymaganie.

W przypadku powiązań pomiędzy wymaganiami a projektem rozwiązania, w praktyce można stosować znaną z notacji UML relację realizacji (ang. realise), gdzie grot relacji jest skierowany ku wymaganiu wyższego rzędu bądź ku wymaganiu rozwiązania w przypadku realizacji między np. wymaganiem rozwiązania a przypadkiem użycia.

Dlaczego warto stosować taki podział? Tak jak wspomniałem, wymagania biznesowe pokazują cel, do którego dążymy. Wymagania interesariuszy z kolei pokazują nam akcje, hasła na wysokim poziomie abstrakcji, grupujące akcje, jakie główni interesariusze wiedzą, że muszą zostać wykonane, aby zaspokoić potrzebę. Są, swego rodzaju, spojrzeniem danego interesariusza na rozwiązanie problemu bądź wykorzystaniem szansy.

Przechodząc bezpośrednio z wymagań biznesowych do wymagań rozwiązania, istnieje ryzyko utracenia wiedzy o potencjalnych, różnych obszarach, które należy rozważyć celem zaspokojenia wymagań biznesowych, stąd też zasadne jest stosowanie takiego podziału.

Źródła

Business Analysis Body Of Knowledge Guide 3.0, International Institute of Business Analysis, 2015

¹ IIBA BABOK Guide 3.0, roz. 2.2. Key Terms, strona 15

² IIBA BABOK Guide 3.0, roz. 2.3. Requirements Classification Schema, strona 16

³ IIBA BABOK Guide 3.0, roz. 2.3. Requirements Classification Schema, strona 16

⁴ IIBA BABOK Guide 3.0, roz. 2.3. Requirements Classification Schema, strona 16

⁵ IIBA BABOK Guide 3.0, roz. 2.3. Requirements Classification Schema, strona 16

⁶ IIBA BABOK Guide 3.0,  roz. 5.1. Trace Requirements, strona 80