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

Dodawanie w Enterprise Architect diagramu z elementami wymagań – BABOK

Otrzymuję taki obrazek:

Wymagania biznesowe a wymagania systemowe – BABOK

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.

Wymagania biznesowe – uproszczenie

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:


Mapowanie wymagań funkcjonalnych na wymagania bizesowe

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:


Dodawanie w Enterprise Architect diagramu z elementami wymagań – ArchiMate

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


Wymagania biznesowe a wymagania systemowe – ArchiMate

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.

Podobne wpisy

  • Wymagania są najważniejsze Podczas mojej pracy zauważyłem, że spory problem stanowią wymagania. Trudnością nie jest ich spisanie. Trudnością jest ich wyartykułowanie. Pomijam turbulencje związane z celem zamiany czy […]
  • International Institute of Business Analysis Pracując z klientami zawsze staram się działać zgodnie z dobrymi praktykami oferowanymi przez nurt Agile Modeling i/lub RUP. Dotyczy to także modelowania procesów biznesowych, w których […]
  • Inżynieria wymagań – certyfikat Inżynieria wymagań jest pierwszym etapem projektów informatycznych i ma decydujące znaczenie dla ich powodzenia. Inżynieria wymagań określa wszystkich interesariuszy projektu i jego […]
  • Prototyp a przypadek użycia Specyfikacja wymagań na system to trudny moment przede wszystkim dla osób, które muszą je wyspecyfikować. Nie zawsze wiadomo w jaki sposób narzędzia informatyki będą mogły pomóc. Często […]
  • Wymagania na system – kontekst i granica systemu Do głównych zadań inżynierii wymagań należy m.in. akwizycja i dokumentacja wymagań na system. Aby tego dokonać należy zidentyfikować te części świata rzeczywistego, które będą miały wpływ […]

1 komentarz dla “Wymagania biznesowe a wymagania systemowe”

  1. Fajny wpis, niemniej znamienne jest ostatnie zdanie. LessIsMore’yzm stosowany.
    To częsta pułapka – mnożenie bytów i stereotypów w architekturze informacji. Z mojej perspektywy opisanie domeny biznesowej z użyciem BMM i przejście na model projektowy (analityczny) w relacji Requirement(ArchiMate) trace Requirement (UML Functiona/nonfunctional) załatwia kwestię dekompozycji funkcjonalnej i pozwala uchwycić cel projektu jak i obserwować poprawności realizacji onego. 🙂
    Pomocne w tym przypadku bywa również podejście MVP – ale to już osobny watek bliższy realizacji niż budowaniu samej koncepcji.
    Fajnie, że poruszyłeś ten wątek – mam nadzieję, że wywoła szerszą dyskusję.
    Pozdrawiam
    JW

Zostaw komentarz

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