Wymagania biznesowe a wymagania systemowe

Wiele się mówi o potrzebie identyfikacji celów projektowych, celów organizacji a także o potrzebie identyfikacji wymagań biznesowych oraz systemowych. Wszystko po to by lepiej zrozumieć oczekiwania biznesu (interesariuszy) w kontekście tego co ma być zrobione, na czym ma polegać zmiana, co ma być wynikiem realizacji projektu. 

Wymienione powyżej elementy mają finalnie być uszczegółowione wymaganiami na system. Czasem po drodze, pojawiają się procesy biznesowe. 
Finalnie mamy mix elementów zarówno z obszaru motywacji, analizy biznesowej i systemowej. Co więcej mamy świat architektury korporacyjnej i świat analizy biznesowej. O analizie systemowej przez grzeczność nie wspominam :-), gdyż niezależnie od przyjętego podejścia czy to klasycznego czy też zwinnego problem także występuje.

Zacznijmy od tego, że cele i wymagania możemy opisywać w dwojaki sposób. Możemy sięgnąć do konceptów bazujących na BABOK® ( Business Analysis Body of Knowledge®) lub architekturze korporacyjnej czyli upraszczając w notacji ArchiMate. 

W BABOK mamy zdefiniowane cele oraz szereg typów wymagań. Z punktu widzenia omawianego zagadnienia istotne są:

• wymagania biznesowe (business requirements) – definiują oczekiwania i rezultaty, jakie powinny być zrealizowane by osiągnąć cel. Mogą dotyczyć całości organizacji, obszaru biznesowego lub określonej inicjatywy. Wymagania biznesowe są na poziomie organizacji i nie określają wymagań, które są specyficzne dla konkretnej grupy interesariuszy.
• wymagania interesariuszy ( stakeholder requirements) – opisują potrzeby interesariuszy, które muszą zostać spełnione, aby spełnić wymagania biznesowe. Mogą służyć jako most pomiędzy wymaganiami biznesowymi a rozwiązaniami.  
• wymagania definiujące rozwiązanie ( solution requirements) – definiują cechy rozwiązania, które spełnia wymagania interesariuszy. Wymagania definiujące rozwiązanie dzielą się na wymagania funkcjonalne i wymagania niefunkcjonalne. 

W kontekście zbierania wymagań ujęciu oferowanym przez BABOK mamy jeszcze do czynienia z potrzebami.

Potrzeba to problem lub szansa, którą należy zaadresować.

Potrzeby mogą powodować zmiany poprzez motywowanie interesariuszy do działania. Zmiany mogą również powodować potrzeby poprzez osłabienie lub wzmocnienie wartości dostarczonej przez istniejące rozwiązania. Potrzeba określa, na wysokim poziomie abstrakcji wymagania związane z realizacją celu biznesowego.

Wykorzystując model BABOK z Enterprise Architect

Otrzymuję taki obrazek:

W praktyce organizacje są na różnym poziomie dojrzałości. Nie zawsze są gotowe do złożonej analizy wymagań. W związku z tym, agreguję wymagania biznesowe z wymaganiami interesariuszy.

Posługuję się wtedy następującą definicją wymagań biznesowych.  

Wymaganie biznesowe określa obiekt, czynność lub usługę, która wspiera realizację celu biznesowego projektu lub organizacji. Wymaganie biznesowe jest uszczegółowione przez wymagania funkcjonalne i niefunkcjonalne.

Wynikiem jest następujący model:

Zwróć uwagę, że wymagania funkcjonalne z wymaganiami biznesowymi połączyłem relacją trace. To intencjonalne działanie. Wszędzie tam gdzie działam w obrębie danej warstwy stosuję relację realizacji (np.: mapowanie przypadków użycia na wymagania). Tam gdzie przechodzę pomiędzy warstwami, a tu przechodzę pomiędzy warstwą definicji problemu a warstwą rozwiązania, stosuję relację trace.

To podejście bazuje na idei translacji czyli opisie, w jaki sposób wymagania, które należą do różnych warstw są tłumaczone w wymaganiach innej warstwy. Parę lat temu znalazłem ten mechanizm u  G. Plataniotis, S. d. Kinderen, and H. A. Proper, “Relating decisions in enterprise architecture using decision design graphs,” in Proceedings of the 17th IEEE International Enterprise Distributed Object Computing Conference (EDOC), 2013.

Podobny mechanizm wykorzystania relacji trace opisałem w tekście: Mapowania wychodzące poza architekturę korporacyjną. Oczywiście zastosowanie relacji realizacji, w moim odczuciu, byłoby też prawidłowe.

W świecie architektury korporacyjnej sytuacja jest dość podobna. Mamy cele i wymagania definiowane w notacji ArchiMate (opis: Elementy motywacji). Wymaganie jest zdefiniowane jako deklaracja potrzeby, która ma zostać zrealizowana przez architekturę (a tym samym i przez organizację). Wymagania wskazują na właściwości tych elementów, które są potrzebne do osiągnięcia celów biznesowych. Cele te są realizowane przez wprowadzenie zmian w aktualnych systemach informatycznych lub przez tworzenie nowych lub zmianę istniejących procesów biznesowych. Mamy tu więc wskazane oczekiwań wobec  biznesu i systemu. Te wymagania także są na poziomie organizacji i nie określają wymagań, które są specyficzne dla konkretnej grupy interesariuszy.

Korzystając z modeli ArchiMate zdefiniowanych w Enterprise Archietect:

Otrzymuję (bazuję na tym samym przykładzie co powyżej) następujący model:

Wymagania są zmapowane na cele relacją realizacji. Wymagania funkcjonalne mapuję relacją trace, co podobnie jak w podejściu opartym o BABOK uwypukla przejście pomiędzy warstwami. 

Na koniec zostaje pytanie czy możemy zmiksować podejście, czyli użyć wymagań z ArchiMate i wymagań biznesowych z BABOK? Generalnie tak.  Sugerowałbym tylko określenie definicji elementów i zasad ich mapowania. Wtedy wymagania z ArchiMate mogą specyfikować bardziej potrzeby biznesowe a wymagania z BABOK będą bliżej wymagań interesariuszy. 

Reasumując. Specyfikacja szeroko rozumianych wymagań biznesowych może się odbyć zarówno za pomocą podejścia oferowanego przez BABOK jak i architekturę korporacyjną z perspektywą motywacji na czele. W moim odczuciu rozbijanie wymagań na biznesowe i interesariuszy nie przynosi wymiernych korzyści. Warto jest jednak identyfikować cele, wymagania biznesowe i uszczegóławiać je wymaganiami na system.  Osobiście staram się trzymać najprostszego podejścia, bo siła nie jest w posiadaniu wielu typów elementów a w specyfikacji
adekwatnej do budowanego rozwiązania oraz zrozumiałej dla interesariuszy.