WYMAGANIA FUNKCJONALNE

WPROWADZENIE

W większości organizacji wyspecyfikowane docelowe procesy biznesowe wymagać będą wsparcia systemów informatycznych o określonych funkcjonalnościach, które pozwolą optymalnie realizować działania wykonywane przez poszczególnych pracowników uczestniczących w procesie. 

W metodyce OMNIS, oczekiwane przez specjalistów dziedzinowych funkcjonalności systemów IT są identyfikowane oraz specyfikowane na bazie opisanych procesów biznesowych. Analiza potrzeb odbywa się na poziomie wyspecyfikowanych, niepodzielnych kroków w przebiegu procesów biznesowych, tym samym, nadając wymaganiom bardzo wąski kontekst biznesowy. Uzyskanie oczekiwanej jednolitości tworzonych wymagań, charakteryzującej się zbliżonym poziomem szczegółowości opisu, jednoznacznie określonymi cechami oraz jednoznacznie określonymi zasadami śladowania jest wypadkową stosowanego języka opisu wymagań, dostępnego modelu pojęciowego oraz przyjętej metodyki prac.

Do specyfikowania wymagań spełniających powyższe założenia, Metodyka OMNIS rekomenduje stosowanie diagramu wymagań języka Systems Modeling Language (SysML) albo jego odpowiednika. Motywacja stojąca za tym wyborem jest efektem: 

• chęci opierania się w jak największym stopniu na powszechnie dostępnych standardach przemysłowych, 
• dostępności narzędzi typu CASE umożliwiających stosowanie diagramu wymagań języka SysML (albo jego odpowiednika) integrującego wymagania ze wszystkimi artefaktami architektury biznesowej oraz modeli rozwiązań informatycznych.

Od procesu do wymagań

Punktem wyjściowym dla określania wymagań funkcjonalnych jest przebieg procesu biznesowego. Poniej został przedstawiony jeden krok diagramu przebiegu procesu, który będzie w dalszej części poddany przykładowej analizie pod kątem specyfikacji wymagań funkcjonalnych na poziomie Computation Independent Model (CIM), według nomenklatury MDA.

Rozważając możliwość wsparcia kroku Rejestracja dyspozycji rozwiązaniem informatycznym, można wyobrazić sobie następujące oczekiwania wobec funkcjonalności rozwiązania: Umożliwienie zarejestrowania dyspozycji Western Union oraz Umożliwienie dołączenia skanu dyspozycji. Zgodny z metodyką OMNIS sposób prezentacji wymagań funkcjonalnych oraz ich powiązania z czynnością zdefiniowaną w procesie biznesowym przedstawiony został na poniższym diagramie. Umieszczając wymaganie w kontekście niedużego działania w procesie ułatwiamy wykazywanie, iż realizacja wymagań pozytywnie wpłynie na sposób wykonywania kroku procesu biznesowego.  W szczególnych przypadkach może się okazać, iż wykorzystanie technologii informatycznych nie tylko polepszy parametry poszczególnych kroków procesu, ale także zmieni kształt przebiegu procesu (na przykład automatyzując działania do tej pory realizowane poza systemem). Jeżeli wymaganie nie posiada uzasadnienia biznesowego lub wraz z przemodelowaniem procesu je utraciło, należy takie wymaganie wyeliminować, gdyż jego implementacja nie przniesie pozytywnej wartości w modelowanym procesie.

Nieocenioną zaletą korzystania do opisu wymagań z diagramu wymagań języka SysML jest możliwość tworzenia różnego rodzaju związków i zależności pomiędzy wymaganiami. Związek kompozycji pozwala na dekomponowanie bardziej ogólnych wymagań, na wymagania o większym stopniu szczegółowości. Co jest szczególnie przydatne, gdy ogólne wymaganie będzie dostarczane w sposób przyrostowy, albo poszczególne aspekty wymagania ogólnego będą miały różne priorytety. Innym sposobem wzajemnego powiązania wymagań jest wskazanie wymagań wyprowadzonych z innego wymagania. W omawianym przykładzie, wymaganie „Umożliwienie definiowania szablonu wniosku ubezpieczeniowego” jest wyprowadzone z bardziej ogólnego wymagania „Umożliwienie definiowania szablonu dokumentu”. Jest to szczególnie użyteczne, gdy chcemy zaznaczyć, że niektóre funkcjonalności nie zostały explicite wyrazóne przez biznes, ale powstały w skutek krytycznej analizy wymagań i potrzeb bizesu. Często takie wymgania stanowią ograniczenia wynikające z polityki firmy lub przepisów prawa.
Analogicznie, warto rozpatrzyć model pod kątem zastosowania pozostałych rodzajów zależności, zdefiniowanych dla tej klasy problemu, co może się przyczynić do poprawy jego jakości. Z punktu widzenia metodyki OMNIS, warto zauważyć, iż wymagania funkcjonalne definiowane na poziomie modelu architektury biznesowej powinny być opisywane z punktu widzenia potrzeb biznesu, pozostawiając decyzję co do sposobu ich realizacji na późniejsze etapy projektu.

Rola techniki w metodyce OMNIS

Wszelakie artefakty architektury biznesowej definiują biznesowy kontekst dla systemu wspierającego opisywaną organizację. Osadzone w tym kontekście wymagania są oczekiwaniami organizacji wobec systemu informatycznego, definiowane z perspektywy uczestników procesów biznesowych, które system ma wspierać, stanowiąc ramy przedsięwzięcia jakim jest wytworzenie tego systemu. Określenie zakresu pozwala przystąpić do realizacji kolejnych prac procesu wytwórczego, których celem jest opracowanie propozycji rozwiązania informatycznego realizującego wymagania, które powstanie na dalszych etapach prac analitycznych. 

Wykorzystywane języki i narzędzia

Wykorzystywanym w OMNIS środkiem wyrazu, umożliwiającym zapis architektury procesów biznesowych, jest BPMN oraz UML.

UŻYTECZNE TECHNIKI