Wymaganie biznesowe a reguła biznesowa

Wymaganie biznesowe czy jeszcze reguła biznesowa? Czy podczas rozmowy z Klientem zastanawiałeś się jaka jest różnica? Czy kiedykolwiek miałeś sytuację, kiedy Klient był zdziwiony, że nie wszystkie wymagania zostały poprawnie zidentyfikowane, albo nie do końca chciał osiągnąć w systemie to co właśnie otrzymał? Jeśli byłeś świadkiem takie sytuacji prawdopodobnie zinterpretowano reguły biznesowe jako reguły systemowe. W artykule odpowiadam na najczęściej pojawiające się pytania: Czym jest reguła biznesowa? Jak rozpoznać czy to co mówi Klient jest regułą, czy jego wymaganiem wobec rozwiązania IT? Czy istnieje klasyfikacja reguł biznesowych? Kto odpowiada za definiowanie reguł biznesowych w projekcie? Jakie pytania zadać Klientowi, aby odkryć reguły biznesowe?

Pytanie 1: Czym jest reguła biznesowa?

Reguła biznesowa to stwierdzenie, które definiuje lub ogranicza pewien aspekt biznesu. Ma wpływ na zachowanie organizacji w procesie biznesowym.

Zgodnie z definicją opracowaną przez Business Rules Grup z 2012 roku:
z perspektywy biznesu: “Reguła biznesowa informuje, że istnieją określone wymogi dotyczące postępowania, działań i praktyk albo procedur realizowanych w ramach danej działalności, bądź dziedziny.
z perspektywy IT: “Reguła biznesowa jest deklaracją określającą albo ograniczającą niektóre aspekty biznesu. Jej celem jest zdefiniowanie struktury biznesowej, bądź kontrolowanie lub wywieranie wpływu na zachowania biznesowe.”

Możemy zatem uznać, że reguła biznesowa informuje, że istnieją określone wymogi dotyczące postępowania, działań i praktyk albo procedur realizowanych w ramach danej aktywności użytkownika.

Zatem reguła biznesowa na pewno nie jest:

1. Wymaganiem – reguły biznesowe bardzo często są mylone z wymaganiami biznesowymi. Klient stwierdzając pewne fakty, bądź zasady, które chce zaimplementować tak naprawdę mówi nam o regułach biznesowych, które błędnie interpretujemy jako “wymagania”. Rolą analityka biznesowego, bądź inżyniera wymagań (analityka biznesowo-systemowego) jest zadawanie pytań doprecyzowujących, aby dzięki odpowiedziom Klienta móc zdefiniować jego faktyczne wymaganie biznesowe.
2. Procesem– reguły biznesowe są również mylone z procesem biznesowym, bądź krokami procesu biznesowego, jakie wykonuje użytkownik biznesowy w swojej aktywności. Reguły biznesowe niewątpliwie wpływają na to, w jaki sposób proces biznesowy jest “regulowany”. Podobnie jak w przypadku wymagań poprzez odpowiednie zadawanie pytań, wychodząc od tego co powiedział nam Klient, możemy doprecyzować proces biznesowy uzupełniając go o “luki”, które w finale prowadzą do pojawienia się tzw. ‘oczywistych wymagań” z punktu widzenia Klienta.

Pytanie 2: Jak rozpoznać czy to co mówi Klient jest regułą, czy jego wymaganiem wobec rozwiązania IT?

W związku z tym, że reguły biznesowe są często mylone z wymaganiami biznesowymi wobec rozwiązania IT nietrudno wyobrazić sobie sytuację, że każda wypowiedź Klienta jest przekładana na rozwiązanie IT, a dokładniej na reguły systemowe.
Kryteria odróżniania reguł biznesowych od systemowych nie są skomplikowane. W celu stwierdzenia czy dana reguła, wypowiedź Klienta jest faktycznie regułą biznesową musi ona spełniać wszystkie 3 poniższe kryteria:

Kryterium 1. Reguła biznesowa musi być wykonalna.
Kryterium 2. Reguła biznesowa musi dotyczyć biznesu a nie rozwiązań systemowych, czy rejestracji danych, które wspierają biznes.
Kryterium 3. Reguła musi być wyrażona w języku biznesu, a nie w języku IT.

Jeśli kryteria nie są dla Ciebie zrozumiałe możesz próbować odpowiedzieć sobie na pytanie:
“Czy jeśli wyrzucę “system”/ “rozwiązanie systemowe” ze stwierdzenia to czy zasada jest nadal istotna z punktu widzenia biznesu, prowadzenia firmy? Jeśli odpowiedź jest twierdząca, prawdopodobnie masz do czynienia z regułą biznesową.

Przykład 1: “Jeśli użytkownik 3 – krotnie wprowadzi nieprawidłowe dane logowania, jego konto powinno zostać zablokowane”.

To stwierdzenie spełnia kryterium: 1 oraz 3, natomiast sugeruje już oczekiwane rozwiązanie systemowe, zatem nie możemy mówić tutaj o regule biznesowej.
Jest to przykład reguły systemowej, która nie zawsze musi wynikać z reguły biznesowej, lecz jest niezbędna do poprawnego funkcjonowania systemu.
Dla tego przykładu regułą biznesową (a dokładniej ograniczeniem wynikającym z polityki firmy) byłoby np. “Polityka firmy związana z bezpieczeństwem danych wymusza określenie praw dostępu do systemu przez poszczególnych jej użytkowników’.

Przykład 2: “Klient może wnioskować w ramach jednego wniosku o 3 przedmioty.”
To stwierdzenie spełnia wszystkie 3 kryteria. Reguła biznesowa jest źródłem dla wymagań, ponieważ określają one właściwości, które powinien mieć system, aby być zgodny z regułami.
Kolejnym krokiem jest zastanowienie się jak ta reguła przekłada się na wymaganie wobec systemu.

W związku z tym możemy zadać pytania o przypadki użycia, np.:
“Jak wygląda proces składania wniosku w przypadku, gdy Klient wnioskuje o:

• 2 przedmioty – ile wniosków musi złożyć?
• 4 przedmioty – ile wniosków musi złożyć?
• Czy proces składania wniosku różni się w zależności od liczby przedmiotów?
• Czy w ramach wniosku można wnioskować o różne przedmioty?

Pytanie 3: Czy istnieje klasyfikacja reguł biznesowych?

Prosta systematyka reguł biznesowych zawierająca 6 reguł biznesowych sprawdzi się w większości przypadków:

1. Fakty

Proste stwierdzenia, które zgodnie z prawdą opisują stan biznesu w danym momencie. Określają związki pomiędzy ważnymi elementami biznesu.

O czym pamiętać?

1. Skup się na faktach, które są bezpośrednio związane z zakresem projektu, zamiast zbierać całą wiedzę biznesową, która spowolni analizę.
2. Staraj się łączyć fakty z danymi wejściowymi i wyjściowymi, aby sprawdzić kontekst występowania stwierdzenia, o którym wspomina Klient.

Przykład: “Do faktury VAT za sprzedawany towar zawsze doliczany jest podatek VAT”.

2. Ograniczenia

Twierdzenia, które “limitują” działania, które może wykonać użytkownik. Charakterystyczne słowa, po których możesz rozpoznać ograniczenia: “musi”, “może”, “powinno być wykonane”.

W zależności od źródła możemy rozróżnić kilka rodzajów ograniczeń:

• Polityka organizacyjna

 Przykład: Osoba ubiegająca się o kredyt przed 18 rokiem życia musi mieć poręczyciela w postaci jednego z rodziców albo opiekuna prawnego.

• Przepisy prawa

 Przykład: Każda aplikacja musi być zgodna z przepisami regulującymi korzystanie z oprogramowania przez osoby niedowidzące.

• Standardy branżowe

Przykład: Osoby ubiegające się o kredyt mieszkaniowy muszą spełniać standardy kwalifikacyjne Krajowej Komisji Hipotecznej.

3. Terminy

To definicje słów, zwrotów, skrótów, które są istotne dla biznesu. Mówiąc inaczej, jest to słownik pojęć.

 O czym pamiętać?

1. Nie rezygnuj z tworzenia słownika pojęć tylko dlatego, że z “klientem pracujesz dłuższy czas i przecież znamy pojęcia, którymi się posługujemy”
2. Przygotuj jeden zbiorczy słownik pojęć ogólnodostępny w firmie, bądź tylko dla samego siebie. Dzięki temu utrzymasz spójność między projektami.
3. W słowniku pojęć umieszczaj pojęcia w kolejności alfabetycznej od A do Z, ułatwisz Twojemu czytelnikowi odnalezienie właściwego pojęcia.
4. W słowniku pojęć umieszczaj pojęcia, które są ważne dla biznesu, ale również dla zespołu deweloperskiego. Jeśli dla klienta nie jest znane pojęcie XSD, XML i chciałby je umieścić w słowniku- nie zastanawiaj się

4. Wnioski

Definiują nowe informacje na podstawie informacji już znanych. Najczęściej wykorzystywana jest konstrukcja: “Jeśli…..to…”

 Przykład: “Jeśli płatność za fakturę VAT nie zostanie zarejestrowana w ciągu 30 dni od terminu płatności, to należy wystawić notę odsetkową”.

5. Wyzwalacze działań

Wyzwalacze działań (aktywatory) pozwalają na rozpoczęcie pewnej czynności po spełnieniu określonych warunków.

 O czym pamiętać?

Jeśli warunki są bardziej złożone nie staraj się ich opisywać, lecz je rozrysuj. Dzięki temu szybciej zauważysz wykluczenia, albo brakujące reguły.

 Przykład: Jeśli na magazynie będzie stan niski materiałów, magazynier musi uzupełnić zapas.

6. Obliczenia

Przekształcanie danych za pomocą wzorów matematycznych, bądź algorytmów.

Przykład: Wartość zamówienia jest sumą cen zamówionych towarów pomniejszoną o przyznane rabaty i powiększona o cenę dostawy oraz ewentualne koszty ubezpieczenia.

O czym pamiętać?

1. Zwracaj uwagę na warunki brzegowe,
2. Dodaj do wzoru kilka przykładów, dzięki temu masz szansę zweryfikować poprawność wzoru z klientem,
3. Zwróć uwagę na którym etapie działania będziesz (i czy w ogóle) zaokrąglać liczby po przecinku, do którego miejsca.

Dla przykładu:

Wartość= 20,566+45,216 = 65,782

Gdy zaokrąglamy sam wynik do 2 miejsca po przecinku w górę otrzymamy wartość równą: 65,78

Gdy zaokrąglamy czynniki składowe do 2 miejsca po przecinku w górę ostatecznie nasza wartość wyniesie: 65,79

Pytanie 4: Kto odpowiada za definiowanie reguł biznesowych w projekcie?

Każdy użytkownik procesu biznesowego zna reguły biznesowe, jakimi ma się kierować, aby proces biznesowy, w którym uczestniczy działał.

Pierwszym krokiem w projekcie IT jest poprawne zidentyfikowanie wymagań biznesowych Klienta, czyli poszukiwanie odpowiedzi na pytanie: “Co chce osiągnąć organizacja?”, albo w przypadku wymagań biznesowych użytkownika: “Co chcesz dzięki temu działaniu osiągnąć?”.

To co słyszymy od Klienta najczęściej interpretujemy jako jego wymaganie względem rozwiązania IT, natomiast w 90% przypadkach Klient nawet nie będąc tego świadomym przekazuje nam reguły biznesowe.

Za poprawną identyfikację reguł biznesowych odpowiedzialny jest analityk biznesowy w projekcie. W praktyce najczęściej jednak robi to analityk biznesowo-systemowy (inżynier wymagań), ponieważ w trakcie rozmowy z Klientem od razu przechodzi do pytań doprecyzowujących nie tylko regułę biznesową, ale definiujemy wymagania biznesowe względem rozwiązania, które wynikają z reguły biznesowej. Wówczas w dokumentacji nie mamy oddzielnej sekcji: “Reguły biznesowe” a później “Wymagania biznesowe”, lecz tylko: “Wymagania biznesowe”.

W przypadku, gdy pracujesz jako analityk biznesowy po stronie biznesu, i musisz przygotować dokument zawierający spis reguł, możesz skorzystać z prostego formatu zaproponowanego przez Kulak i Guiney w 2004 roku, gdzie w kolejnych kolumnach opisujesz:

1. Identyfikator reguły biznesowej
2. Definicja reguły biznesowej – jej treść
3. Typ reguły – tutaj możesz skorzystać z systematyki reguł biznesowych
4. Statyczna czy dynamiczna – określasz, czy dana reguła może zmienić się w czasie (dynamiczna). Jest to bardzo istotne z punktu widzenia prac deweloperskich pod kątem projektowania architektury rozwiązania. Przykładem takiej reguły będzie np. stawka VAT, która może zmieniać się w czasie, czy opłaty, daty dostarczenia dokumentów itp.
5. Źródło– tutaj wpisujesz źródło reguły, np. polityka cenowa firmy, standardy branżowe, polityka marketingowa, Ekspert ds. X. Dzięki takiemu zapisowi łatwiej będzie Tobie odnaleźć ‘właściciela” celem ich dalszego doprecyzowania.

 Pytanie 5: Jakie pytania zadać Klientowi, aby odkryć reguły biznesowe?

1. W jaki sposób obliczana jest dana wartość?
2. Jaki związek mają ze sobą te czynności?
3. Co w dalszej kolejności robi użytkownik? Co musi się stać? Czy aktywatorem działania użytkownika jest: warunek, decyzja, bądź czas?
4. Czy są jakieś regulacje prawne związane z taką obsługą?
5. Dlaczego zmienia się stan tego <obiektu>?