Grając zgodnie z zasadami
"Grając zgodnie z zasadami" - tak nazywa się jeden z rozdziałów w książce Karla Wiegers "Software Requirements"
Każda organizacja działa zgodnie z pewnym zestawem ustalonym wewnętrznie lub narzuconych z zewnątrz zasad, przepisów i standardów, np. organizacje bankowe muszą działać w ramach obowiązujących przepisów prawa bankowego. Gdy tworzymy oprogramowanie dla naszego klienta, to warto zastanowić się jakimi regułami kieruje się biznes klienta, tak aby nasze oprogramowanie było z nimi zgodne.
Typy reguł biznesowych
- fakty - proste stwierdzenia, które są zawsze prawdziwe dla biznesu. Często opisują one relacje między istotnymi obiektami biznesowymi. Inne reguły mogą odwoływać się w swoich definicjach do faktów. Same fakty rzadko przekładają się bezpośrednio na wymagania funkcjonalne, są natomiast często częścią modelu danych.
Przykłady:
Każdy kontener z materiałami chemicznymi ma indywidualny identyfikator.
Każde zamówienie musi mieć określoną cenę. - ograniczenia - jak sama nazwa wskazuje ograniczają akcje , które system lub użytkownik może wykonywać.
Przykłady:
Pożyczkobiorca, który ma mniej niż 18 lat musi mieć pisemną zgodę rodzica lub opiekuna prawnego.
Stały czytelnik może mieć maksymalnie 10 książek wypożyczonych.
Użytkownik ma dostęp do dokumentów pounych jedynie jeśli uzyskał certyfikat poufności w ciągu ostatnich 12 miesięcy.
Pracownicy załóg linii lotniczych muszą mieć zagwarantowany 14-godziny odpoczynek po każdym locie. - wyzwalacze - reguły, które pod wpływem określonych zdarzeń lub w określonych warunkach wywołują specyficzne akcje.
Przykłady:
Jeśli produkt straci ważność w ciągu najbliższych 30 dni powiadom osobę przypisaną do tego produktu.
Jeśli klient zamawia książki autora, który napisał kilka książek to zaproponuj pozostałe książki tego autora przez zakończeniem składania zamówienia przez klienta. - obliczenia - określają sposób w jaki wykonywane są określone operacje matematyczne lub algorytmy.
Przykłady:
Cena produktów jest obniżana o 10% jeśli zamówienie zawiera od 6 do 10 sztuk, o 20% gdy zamówienie zawiera od 11 do 20 sztuk, o 35% dla zamówienia z ponad 20-ma sztukami.
Droga między dwoma punktami ma być wyznaczana zgodnie z algorytmem Bellmana-Forda. - wnioski - określają nową wiedzę lub zmianę stanu obiektów biznesowych ma podstawie określonych warunków.
Przykłady:
Jeśli opłata nie zostanie wniesiona w ciągu 30 dni od określonej daty zapłaty to konto klienta staje się unieważnione.
Jeśli sprzedano więcej niż sto tysięcy płyt to ma ona status platynowej.
Jak zapisywać reguły biznesowe?
Co jest dla Ciebie najważniejsze?
Co zrobić najpierw?
W życiu każdego z nas przychodzi taki moment, w którym musimy określić, co jest dla nas najważniejsze? I podobnie jest w projektach,w których bierzemy udział, nie jesteśmy w stanie zabrać się za realizację wszystkiego, musimy wybrać wymagania najbardziej istotne lub te najbardziej pilne.
Podejście iteracyjne
Dodatkowo w ostatnim czasie coraz większą popularność zdobywa iteracyjne podejście do budowy oprogramowania.Nie ma się czemu dziwić, skoro iteracje niosą za sobą wiele plusów:
- klient szybko dostaje chociaż częściowo działającą aplikację i może ją zacząć wykorzystywać (nawet jeśli będziemy mieli opóźnienia w realizacji projektu, to klient będzie mógł korzystać z części funkcjonalności),
- możemy liczyć na ocenę klienta po każdej iteracji i wprowadzać konieczne zmiany,
- jeśli w jakiejś iteracji podejmiemy złe decyzje, to możemy niskim kosztem się z nich wycofać w kolejnej iteracji,
- mamy możliwość bezpiecznego wprowadzenia zmian po każdej iteracji, szczególnie jeśli klient zmieni swoje zdanie,
- na podstawie małych przyrostów możemy lepiej szacować wydajność naszego zespołu,
Jak ustalać priorytety?
Powstaje jednak pytanie, od których wymagań powinniśmy zacząć nasze prace? którymi wymaganiami powinniśmy zająć się w pierwszej iteracji? którymi w drugiej? a które możemy zostawić na koniec? Jeśli spytamy się o to klienta, to możemy spodziewać się odpowiedzi, że dla niego najważniejsze są przecież wszystkie wymagania! W takim momencie dobrze jest wytłumaczyć klientowi sens nadawania priorytetów i zaangażować go w proces oceny istotności wymagań. Warto również pamiętać o uwzględnieniu zdania managera projektu, który będzie później planował projekt oraz architekta, który będzie służył swoją wiedzą i będzie w stanie stwierdzić, czy ustalone przez nas priorytety mają sens z punktu widzenia architektury systemu.
Karl E. Wiegers w swojej książce "Software Requirements" proponuje system nadawania priorytetów oparty na zasadach podanych przez Stephena Covey'a w książce "Siedem nawyków skutecznego działania". Poniższa tabela prezentuje proponowany system priorytetów:
Jak widać tabela wprowadza podział wymagań według kryteriów: ważności oraz pilności. I tak:
- priorytet wysoki nadajemy wymaganiom, które są dla nas ważne oraz które są pilne (np. z punku widzenia klienta, lub architektury);
- priorytet średni nadajemy wymaganiom, które są dla nas ważne, ale nie są pilne i mogą poczekać;
- priorytet niski nadajemy wymaganiom, które są mniej ważne i które nie są pilne, można je zaimplementować na samym końcu.
A co z kategorią "nie rób tego"? Otóż jeśli wymaganie nie jest istotne, ale pilne to albo albo zaimplementujemy je poświęcając w ten sposób wymagania ważne, albo pozostawimy to wymaganie na później, ale skoro jest pilne, to za jakiś czas może już nie być sensu go implementować. Jak widać, w przypadku takich wymagań najlepiej jest zastanowić się, czy jest sens w ich implementacji, albo czy nie zostawić ich na później nadając im niski priorytet.
Oczywiście każdy może oceniać wymagania według swoich własnych kryteriów, istotne jednak jest, aby za przydzielaniem priorytetów stały jakieś racjonalne powody, łatwiej jest wtedy przekonać inne osoby to przestrzegania naszych ustaleń.