Wprowadzenie

Ronald Ross, współautor standardu modelowania reguł biznesowych i biznesowego słownika pojęć napisał niedawno na swoim profilu LinkedIn:

“People love stories. Are user stories helpful in engineering business solutions? Absolutely. Are you done with requirements and solution engineering when you?ve worked through a set of user stories? No. Not even close!” [“Ludzie kochają historie. Czy historie użytkowników są pomocne w tworzeniu rozwiązań biznesowych? Zdecydowanie tak. Czy skończyłeś z wymaganiami i inżynierią rozwiązania, gdy już opracowałeś zestaw historyjek użytkownika? Nie. Nawet nie zbliżyłeś się do nich!”.]

(https://www.linkedin.com/posts/rossronald_people-love-stories-are-user-stories-helpful-activity-6935627008265633793-Bpzb/)

Świat od dekad boryka się z jakością i skutecznością specyfikowania wymagań na oprogramowanie. OMG.org opublikowało standard o nazwie MDA (ang. Model Driven Architecture ), który tak opisuje proces tworzenia oprogramowania:

CIM -> PIM -> PSM

Są to odpowiednio modele: Model Biznesowy (CIM: Computation Independent Model), Model Mechanizmu działania (PIM: Platform-Independent Model, jest to model dziedziny systemu wg. MVC) oraz Model Implementacji (PSM: Platform-Specific Model). Swego czasu szerzej opisałem zależności między tymi modelami (czytaj więcej o MDA).

CIM to model działania organizacji: procesy biznesowe i ich produkty. Z uwagi na to, że obecnie już nie rodzą się projekty jednorazowej informatyzacji całości organizacji, pojawia się potrzeba określenia zakresu projektu, bo nie jest już nim cała organizacja. Model PIM to udokumentowany mechanizm działania systemu (oprogramowania), logika jego działania. Nie ma tu mowy o tym w jakiej technologii powstanie, bo z zasady mamy ich wiele do wyboru, a wybór technologii zależy od wielu poza-funkcjonalnych ograniczeń i wymagań. Technologia jest (powinna być) konsekwencją wyboru wykonawcy i ten dopiero opracuje model PSM, który w praktyce jest tak zwaną Koncepcją Wdrożenia, można ją także udokumentować w notacji UML, ale na tym etapie powszechna praktyką jest jedynie zaprojektowanie środowiska, zestawienie go i praca od razu w kodzie.

Kluczowym problemem jest przejście z CIM na PIM, czyli jak udokumentować zakres projektu dostarczenia oprogramowania i przekształcić go na wymagania wobec tego oprogramowania?

CIM -> [zakres projektu] -> PIM -> PSM

W metodach zwanych zwinnymi, modele CIM i PIM są pomijane. Typowym zaś narzędziem “zbierania wymagań” są tak zwane historyjki użytkownika (user story). Problem w tym, że są one kluczowym ryzykiem projektów gdyż z reguły są niespójne i niekompletne jako wymagania. Specyfikacja wymagań powinna być: spójna, kompletna i niesprzeczna. Opisanie zakresu projektu historyjkami użytkownika, nie mając modelu procesów biznesowych całości (model CIM), jest pozbawieniem się narzędzia do weryfikacji kompletności, spójności i niesprzeczności takiej specyfikacji. Wszystkie wady (niekompletność, niespójność, sprzeczności) odkrywane są i usuwane (uzupełniane) dopiero na etapie wdrażania. Jest to proces “odkrywania wymagań w toku wdrożenia”.

Historyjki użytkownika jako lista potrzeb biznesowych? Owszem! Historyjki użytkownika jako wymagania dla developera? NIE! To tylko materiał dla projektanta, ponieważ bardzo często jedna i ta sama funkcja systemu realizuje wiele różnych historii użytkownika. Implementacja “per user story” prowadzi do bardzo kosztownych i nieefektywnych rozwiązań (Opisywałem to na blogu: wpis projekt Biblioteka, dwie historyjki użytkownika: chciałbym wypożyczyć książkę oraz chciałbym zwrócić książkę są realizowane jedną usługą aplikacji: Karta Wypożyczenia, która zawiera również pole Data zwrotu. Nadal spotykam programistów przekonujących, że powinny to być dwa osobne ekrany – dwa przypadki użycia, czytaj dwa razy więcej pracy kodera i dwa razy większy koszt).

Czy można sformalizować proces zbierania historyjek użytkownika?

User Story to jedno z najbardziej problematycznych narzędzi w metodach zwinnych. Najczęściej zalecana struktura tych “historyjek”, wraz z przykładami:

“Jako ?typ użytkownika? chcę osiągnąć ?cel?, aby ?jakiś powód?”.

Na przykład:

“Jako Administrator chcę otrzymywać wiadomość e-mail, gdy zostanie przesłany formularz kontaktowy, abym mógł na niego odpowiedzieć”

albo

”Jako użytkownik mam możliwość kliknięcia określonej lokalizacji na mapie”;

Tak spisywane wymagania stanowią ogromny problem z powodu nierównej gradacji, sprowadzanie ich do poziomu tak zwanych atomowych user story (drugi z powyższych przykładów) prowadzi do bardzo dużych liczb tych historyjek. Próba ich weryfikacji (walidacja user story) staje się co najmniej trudnym zadaniem. Jakakolwiek wycena oprogramowania na bazie takich historyjek to wróżenie z fusów (więc developerzy mocno zawyżają wyceny z uwagi na ryzyko utraty rentowności). Autorzy innego opracowania zauważają:

Rzeczywiście, przy około 800 US [User Story], hierarchia była raczej trudna do określenia, a obraz systemu podczas planowania był bardzo duży. Skalowalność jest więc zdecydowanie problemem w projektach zwinnych, w których US są słabymi artefaktami inżynierii wymagań. Zdecydował się on [autor] na wprowadzenie wzorca US: “Jako [Użytkownik], chcę [Zadanie], aby [Cel]”, aby zdefiniować hierarchię w postaci Celu, Zadania i Użytkownika, ale bez powiązania semantycznego.

Znam projekt, w którym liczba przypadków użycia, w pewnym średniej tylko wielkości projekcie, szybko sięgnęła czterystu. Wycena na ich podstawie pokazała, że planowany koszt wielokrotnie przekracza planowany budżet. Ten projekt zarzucono, jednak wiele tak wycenionych projektów jest realizowanych, co daje obraz skali strat jakie przynoszą (zawyżony koszt to strata). Powyżsi autorzy piszą na zakończenie:

Przyszłe prace obejmują identyfikację luk reprezentacyjnych, które napotykają praktycy w modelowaniu US, oraz przegląd sposobów, w jakie nasze ramy i [metoda] GORE w ogóle mogłyby rozwiązać te problemy. Równolegle oceniana będzie również zdolność praktyków do stosowania proponowanych ram zamiast zwykłych szablonów. Obecnie trwają prace nad narzędziem CASE (Computer Aided Software Engineering), które zostanie wykorzystane do wsparcia eksperymentów.

Nie znalazłem wyników dalszych prac, więc podzielę się wynikami swoich.

Gradacja User Story

Podstawowym problemem z user story jest, moim zdaniem, brak standardu pozwalającego na zdefiniowanie “atomowej historyjki użytkownika” czyli poziomu, poniżej którego nie dzielimy ich na mniejsze. Jako audytor wielu dokumentacji (często w roli biegłego) zauważyłem, że historyjki użytkownika są doprowadzane do poziomu pojedynczych kroków scenariuszy przypadków użycia. Często też historyjki użytkownika utożsamiane są z przypadkami użycia (UML) i tak modelowane, co jest poważnym błędem. Np. powyższe:

“Jako użytkownik mam możliwość kliknięcia określonej lokalizacji na mapie”

Mogło by to być częścią scenariusza usługi (przypadek użycia UML), której celem jest Pokazanie Określonego Miejsca:

1. AKTOR inicjuje usługę Cel podróży
2. SYSTEM wyświetla formularz Adres
3. AKTOR wprowadza dane i naciska OK
4. SYSTEM wyświetla mapę z naniesioną lokalizacją
5. AKTOR klika określony punkt na mapie
6. SYSTEM powiększa obraz pokazując detale lokalizacji

Powyższa historyjka to jedynie punkt 5. tego scenariusza. Nie trudno dojść do wniosku, że samo kliknięcie na mapie to pozbawiona kontekstu i celu, wyrwana prosta czynność, i jej samodzielne istnienie w specyfikacji jako osobny byt, pozbawione jest sensu. Z perspektywy oprogramowania powstającego w określonym celu, uznanie tej historyjki za samodzielne wymaganie nie ma uzasadnienia. Uznanie jednak, że aplikacja służy między innymi do zapoznawania się określonymi miejscami w przestrzeni, a usługą tej aplikacji jest Pokazanie Określonego Miejsca jak najbardziej ma sens. Idąc za sugestią by historyjka użytkownika miała strukturę:

“Jako [Użytkownik], chcę [Zadanie], aby [Cel]”

zmusza do zastanowienia się czy klikanie na mapie jest celem, czy może jednak tym celem jest Pokazanie Określonego Miejsca, a klikanie jest elementem scenariusza (procedury) realizacji tego celu (pamiętamy, że przypadki użycia mają scenariusze, a te złożone są z sekwencji kolejnych kroków!).

Formalizacja User Story

Pojęcia Użytkownik, Zadanie, Cel, jako spójny zestaw pojęć odpowiadają definicji atomowego (elementarnego) procesu w notacji BPMN (dodatek C, Słownik , ): Aktywność jest skojarzona z jej wykonawcą (pula, tor), tworzy produkt (data object). Biorąc pod uwagę fakt, że produkt ma tu określonego adresata i musi on stanowić sobą wartość dla tego adresata, mamy punkt wyznaczający granicę “dzielenia na części” tych historyjek. Nie będzie to “możliwość wstawienia z listy numeru NIP nabywcy” a “utworzenie faktury” (bo wartość ma dopiero poprawnie wystawiona faktura, a nie kliknięcie np. w pole NIP by wybrać kontrahenta).

Jak sformalizować historyjkę użytkownika? Podstawą formalizacji (i celem) jest opracowanie metody kontroli poprawności (walidacja). Popatrzmy jeszcze raz na szablon:

“Jako ?typ użytkownika? chcę osiągnąć ?cel?, aby ?jakiś powód?”.

Typ użytkownika to rola, celem jest produkt pracy, a powodem? Powodem jest zawsze to, że określona osoba oczekuje na efekt tej pracy (bez tego praca ta byłaby po prostu zbędna). Można więc wyobrazić sobie taki zapis:

Jako sprzedawca, chcę wystawić fakturę, klientowi.

Mamy tu:

1. rola: sprzedawca
2. cel: faktura
3. powód: oczekuje tego klient.

W tym miejscu widać pełną zgodność tej definicji z konstrukcją: aktywność, jej produkt, jego odbiorca. Innymi słowy analityczny model procesów biznesowych wykonany w notacji BPMN, to nic innego jak połączone w logiczne ciągi historyjki użytkownika.

Wyobraźmy sobie taką listę historyjek użytkownika, wykonaną wg. powyższego opisu:

Niektóre narzędzia CASE, pozwalające na ich profilowanie, pozwalają przedstawić to także na modelu wymagań (co później umożliwia śladowanie, czyli kontrolę kompletności, spójności i niesprzeczności):

Powyższe mogłoby być konsekwencją takiego modelu procesów:

Jak widać, model procesu daje pełny kontekst dla aktywności. Fakt, że proces to logiczny przepływ pracy, powoduje, że tworzenie modeli BPMN gwarantuje spójność, kompletność i niesprzeczność listy aktywności, ich produktów i ról.

Kilka słów o priorytetach

Często stosowane jest nadawanie wymaganiom priorytetów. Jeżeli mówimy o MBSE/MDD (odpowiednio: Model-Based System Engineering, Model-Driven Development), czyli podejściu w którym “model to wymaganie”, priorytety nie są stosowane, gdyż ma powstać to co zostało zaprojektowane (nikt nie nadaje priorytetów składnikom w recepturze na potrawę, nikt nie nadaje priorytetów na elementy składowe produkowanych przedmiotów).

Kiedy i jakim wymaganiom nadajemy priorytety? Ma to sens w przypadku wymagań biznesowych oraz w stosunku do przypadków użycia oprogramowania (przypominam, że Use Case w notacji UML to cecha systemu). Najczęściej spotykane systemu priorytetyzacji to trzystopniowa skala oraz tak zwana MoSCoW.

Trzystopniowa skala to:

1. niespełnienie tego wymagania pogorszy efektywność pracy
2. niespełnienie tego wymagania spowoduje ograniczenie funkcjonalności
3. niespełnienie tego wymagania uczyni system nieprzydatnym do celu w hakim powstaje.

Jak widać jedynka to najniższy priorytet. Z uwagi na zarządzanie projektem i wymaganiami, dodatkowo stosowane są, niezależnie od priorytetów, statusy wymagań: proponowane, zatwierdzone, odrzucone, odroczone, projektowane, wdrożone (mozna spotkań inne ale ich sens jest taki sam).

Skala MoSCoW to:

M – Must have – wymagania obligatoryjne, które system musi zapewniać.
S – Should have – wymagania, które powinny znaleźć się w systemie.
C – Could have – wymagania dodatkowe, które są pożądane, ale nie są niezbędne.
W – Won’t have – wymagania, które nie zostaną wdrożone (ale mogą być wdrożone w przyszłości).

Jak widać skale te różnią sie podejściem. Generalnie celem jest zarządzanie wymaganiami. Skala trzystopniowa to świadome zarzadzanie zakresem projektu. Definicje są precyzyjne: nie ma żadnego problemu z nadawaniem priorytetów. Skala MoSCoW ma charakter uznaniowy: definicje tych czterech grup nie są precyzyjne: nie wiadomo jak odróżnić to co “powinno być” od tego co “jest pożądane”?

Podsumowanie

Stosowanie typowych historyjek użytkownika ma dwie kluczowe wady: 1. nie ma jednej metody zarządzania ich gradacją i strukturą, wielu autorów przywołuje własne, nieco się różniące metody standaryzacji, 2. ich drobiazgowość oraz brak metody kontroli spójności, prowadzą do szybko rosnącej ich liczby, w konsekwencji chaosu, szczególnie w średnich i większych projektach.

Powyżej widać, że modelowanie procesów biznesowych na podstawie zebranych przykładowych dokumentów (produkty pracy ludzi: dokumenty) i opracowanie na ich podstawie diagramu przypadków użycia, daje znacznie lepsze wyniki niż zbierane na warsztatach historyjki użytkownika. Same wymagania wyrażone jako historyjki użytkownika, nie dają żadnej szansy (brak metody) na kontrolę ich spójności, kompletności i niesprzeczności. Wymagania, jako konsekwencja poprawnie wykonanych modeli procesów biznesowych, z zasady są spójne, kompletne i niesprzeczne.

W przytoczonym tu przykładzie widać, że dwie aktywności (rejestracja zamówienia i kontrola jego statusu) realizowane są jako dostęp do zapisanego w systemie Zamówienia. Daje to jasną przesłankę do tego, że dwie historyjki użytkownika (dwie aktywności na modelu procesów) to dwa różne konteksty użycia tej samej usługi aplikacji: Zamówienia (czyli dostęp do ich tworzenia, aktualizacji i podglądu, to typowy przypadek użycia typu CRUD). Prawa dostępu do tego dokumentu modeluje się zaś regułami biznesowymi (nie pokazano ich na diagramach), np. “Klient ma wgląd tylko w Zamówienia, które sam złożył”.

Można uznać, że małe projekty, o małym ryzyku chaosu wywołanego brakiem modeli procesów, można realizowac “na skróty” czyli historyjki użytkownika i od razu model PSM (implementacja) z pominięciem CIM i PIM, jednak jest to poważne ryzyko już przy średnich projektach. Dlatego proces MDA:

{CIM -> [zakres projektu] -> PIM} -> PSM

wydaje się być znacznie efektywniejszy co pokazuje praktyka (w nawiasach klamrowych {} zakres pracy analityka-projektanta).

Zakres projektu to albo całe procesy biznesowe albo świadomie wybrane ich określone aktywności. Nie jest to także żaden “wodospad” (waterfall), bo analityczny model procesów biznesowych powstanie szybciej i taniej niż lista setek historyjek z pomocą wielodniowych warsztatów angażujących całe zespoły ludzi. Wygenerowane z modelu procesów biznesowych przypadki użycia, są z zasady spójne i kompletne, więc ich iteracyjne (kolejne) specyfikowanie (każdy projektujemy jako samodzielny mikroserwis) pozwala bez ryzyka oddawać je kolejno do implementacji, i jednocześnie dokumentować (uszczegóławiać) kolejne.

To sprawdzona w praktyce metoda wspierana przez wiele narzędzi CASE (wszystkie diagramy i ich przekształcenia pokazane w tym artykule powstały z użyciem Visual-Paradigm). Diagram przypadków użycia UML jest tu automatycznie generowany z modeli BPMN, wg poniższych zasad:

Po tej operacji wystarczy sprawdzić konteksty dokumentow i skonsolidować w jeden ewentualne nadmiarowe przypadki użycia. I na koniec:

“Jeśli nie masz modeli pojęciowych, brakuje Ci ważnego elementu układanki w projektowaniu rozwiązań, który jest niezwykle pomocny w dostrzeganiu i przekazywaniu ogólnego obrazu tych historyjek.”

Ronald Ross (Business Rules)

Źródła

Pełna Specyfikacja

Poniżej przykładowy dokument wygenerowany bezpośrednio z Visual Paradigm, zawiera także śladowanie.

1. Procesy Business Process Diagram

2. User Story

Historyjki użytkownika jako wymagania biznesowe.

3. Diagram Przypadków Użycia

4. Specyfikacja

 4.1. Sprzedaż

ID: UC02

Usługa pozwala wystawiać faktury.

4.1.1. Główni aktorzy 

 Sprzedawca

4.1.2. Szczegóły

4.1.3. Wymagania 

 4.1.3.1. Sprzedaż

ID: REQ001

jako sprzedawca chcę wystawić fakturę klientowi

4.1.4. Relacje

4.1.5. Diagramy Podległe 

4.1.5.1. Faktura

4.1.6. Śladowanie 

 4.2. Magazyny

ID: UC03

Usługa dokumentuje wydawanie towaru na podstawie opłaconych faktur.

4.2.1. Główni aktorzy 

 Magazynier

4.2.2. Szczegóły

4.2.3. Wymagania 

 4.2.3.1. Wydanie towaru

ID: REQ002

jako magazynier chce wystawić Dokument WZ klientowi

4.2.4. Relacje

4.2.5. Diagramy Podległe 

4.2.5.1. Dokument WZ

4.2.6. Śladowanie 

 4.3. Zamówienia

ID: UC01

Rejestr zamówień pozwala rejestrować zamówienia, śledzić ich status.

4.3.1. Główni aktorzy 

 Klient,   Pracownik BOK

4.3.2. Szczegóły

4.3.3. Wymagania 

 4.3.3.1. Rejestracja Zamówień

ID: REQ003

jako pracownik BOK chce zarejestrować zamówienie zakupu dla Sprzedawcy

 4.3.3.2. Śledzenie Zamówień

ID: REQ004

Jako Klient chciał bym śledzić statusy moich Zamówień zakupu

4.3.4. Relacje

4.3.5. Diagramy Podległe 

4.3.5.1. Zamówienia Zakupu

4.3.6. Śladowanie