Wymagania to niewyczerpany temat dyskusji, blogów i sporów w projektach. Ich śladowanie już rzadziej jest takim tematem, bo mało kto to robi, a to właśnie między innymi brak śladowania prowadzi do problemów w projekcie. Typowy problem to utrata panowania nad zakresem projektu, utrata panowania nad złożonością dokumentacji i ilości “wymagań” (cudzysłów celowo, później o powodach). W konsekwencji jakość całego projektu upada, zadowolenie sponsorów także (polecam krótki wpis: Why is requirements traceability important on a project?). Dlaczego? Bo skoro wymagania mają być FURPS i SMART, to jak to osiągnąć i jak skontrolować? Jak skontrolować w mierzalny sposób np. kompletność?

O wymaganiach pisałem nie raz, dzisiaj z perspektywy ich śladowania i  celu tego procederu. Bardzo często spotyka się w dokumentach projektowych wymagania  funkcjonalne i pozafunkcjonalne, ale mało który z tych dokumentów zawiera definicje tych pojęć, a wymagań tych są setki a nie raz tysiące. Są – te “wymagania” – “zbierane” najczęściej podczas wywiadów, sesji burz mózgów, sesji “warsztatów wymagań”. Ilość wymagań jest najczęściej proporcjonalna do czasu trwania tych sesji a “analiza wymagań” jest przerywana gdy wymagań jest “wystarczająco dużo” (widywałem dokumenty z ponad czterema tysiącami wymagań!).

W języku polskim słowo wymaganie ma bardzo ścisłą i bardzo przydatna definicję:

wymaganie ?warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać?

Popatrzmy co na to BABOK

Jest to definicja bardzo bliska tej słownikowej: “warunek lub możliwość  produktu lub usługi, spełniający oczekiwania” (dość wolne tłumaczenie ;)).

A jak są klasyfikowane wymagania? Tu jest “bytów” jest więcej:

Tu moim zdaniem zaczyna się mała masakra, bo konia z rzędem temu, kto jednoznacznie podzieli długą listę cech produktu na powyższe sześć “kuwetek”. Przypomnę, że poprawny słownik pojęć to pojęcia wzajemnie się wykluczające, czyli jeżeli coś jest np. wymaganiem, przejściowym to nie jest żadnym innym. Dlatego ten (taki) podział jest moim zdaniem przyczyną wielu problemow w projektach.

Wymagania biznesowe

Rzadko spotykane a wręcz konieczne do poprawnej kontroli projektu i zarządzania jego zakresem. Inna definicja, moim zdaniem lepsza niż ta z BABOK’a:

Business Requirements

The purpose of business requirements is to define a project?s business need, as well as the criteria of its success. Business requirements describe why a project is needed, whom it will benefit, when and where it will take place, and what standards will be used to evaluate it. Business requirement generally do not define how a project is to be implemented; the requirements of the business need do not encompass a project?s implementation details. (Business Requirements – Requirements.com).

To rzadziej spotykana definicja wymagań biznesowych. W skrócie: wymagania biznesowe definicją biznesowy cel projektu, kryteria sukcesu (pomysłu); wymagania biznesowe opisują po co projekt jest uruchamiany; wymagania biznesowe nie mówią nic o ich implementacji. I to jest prosta i bardzo skuteczna w użyciu definicja.

Schody zaczynają się przy innych wymaganiach, kolejna wersja:

Functional requirements are a type of solution requirements. According to BABOK, these “describe the behavior and information that the solution will manage.” Continuing with our farming illustration, an example of a functional requirement would be: “This system will deliver produce from farms in our cooperative and deliver it to participating customers.” (Requirements – Requirements.com).

Wymagania funkcjonalne. Najczęściej podaje się jako “wymagania wobec rozwiązania” (i słusznie), jednak niestety, definiowane są poprzez przykład, np. stwierdzenie, że funkcjonalność to “zachowanie systemu i informacje, którymi system zarządza” jest bardzo niefortunne bo niezwykle pojemne, prowadzi wielu analityków to wniosku, że skoro wystawienie faktury wymaga “nastu kliknięć i  wprowadzenie nastu informacji” to wymagań funkcjonalnych jest też “naście”. Pojęcie “funkcjonalny” jest tak szerokie, że w zasadzie każda cecha produktu do czegoś służy i jest jakąś funkcjonalnością. Przeciętny samochód m ich setki a tak na prawdę służy do przemieszczania się.

Poszukajmy porządku i sposobu śladowania.

Wymagania biznesowe to cele uruchamiania projektu, to są cele organizacji (jej kadr kierowniczych). A reszta? Bardzo nieprecyzyjne definicje wymagań prowadzą do setek ich interpretacji. Sam fakt, że te same wymagania (jako nazwa i opis) są, przez różne osoby tego samego zespołu projektowego, różnie klasyfikowane, świadczy o tym, że jest problem.

Z pomocą przychodzi śladowanie, wymusza doprecyzowanie definicji. Dlaczego? Bo śladowanie, by było możliwe do przeprowadzenia, wymaga przechodzenia “od jednego do drugiego” w całości (jeden do jednego lub jeden do wielu ale w całości), nie można przejść od jednego wymagania np. biznesowego do dwóch i pół wymagań funkcjonalnych. To muszą być całkowite i jednoznaczne liczby wymagań.

Jak widać wymagania biznesowe to cele, cele lokalne (działy, piony), więc będzie ich kilkanaście, kilkadziesiąt przy dużych projektach, obejmujących cała organizację. Jeden cel biznesowy to jedna lub kilka (rzadko więcej) usług jakich oczekujemy od nowego rozwiązania. Tak więc należałoby się spodziewać kilkudziesięciu usług rozwiązania a nie kilku tysięcy “wymagań”. Pomijając długie dywagacje o definicjach (były już na tym blogu) poniższy schemat (model pojęciowy) pokazuje związki pomiędzy spotykanymi w literaturze, wymaganiami i ich reprezentacjami (tu przypadki użycia w UML).

Na diagramie zaznaczyłem z pomocą tak zwanego “dziedziczenia” (strzałka z niewypełnionym grotem wskazuje uogólnione pojęcie, jej drugi zaś koniec pojęcie szczegółowe). Zwykła linia to powiązanie pomiędzy pojęciami (fakt łączący różne pojęcia). Tak więc wymagania wobec rozwiązania to pewien podzbiór wymagań biznesowych (nie wszystkie cele biznesowe muszą wiązać się z konkretnym rozwiązaniem). Wymagania wobec rozwiązania to właśnie sporne, niejednoznaczne, pojęcia spotykane w literaturze. To co można potwierdzić, to podział “wszystkich wymagań” wobec rozwiązania na funkcjonalne i niefunkcjonalne. Mimo braku ich ścisłych definicji (czym jest możliwość łatwego dodawania danych kontrahenta z listy??) wiemy, że są tylko te dwa. Wymagania niefunkcjonalne dzieli się (między innymi) na jakościowe i dziedzinowe, te drugie to logika biznesowa i algorytmy. Mamy jednak precyzyjną definicję pojęcia przypadek użycia (mam na myśli definicję w specyfikacji notacji UML), jest to usługa systemu, świadczona aktorowi (na jego żądanie, a wiec inicjowana przez aktora), której produkt ma wartość dla aktora bo jest celem korzystania z systemu przez tego aktora. Tak więc przypadkiem użycia jest to, że “system pozwala na wytworzenie faktury VAT” a nie to, że “pozwala wybrać kontrahenta z listy po kliknięciu myszą”. Każda usługa systemu, jego przypadek użycia, związany jest ze konkretną logiką jego zrealizowania (wykonania) czyli wymaganiem dziedzinowym.

Śladowanie. Jak pomaga?

Mając listę celów projektu, określamy, które planujemy zrealizować z pomocą nowego  oprogramowania – to wymagania wobec rozwiązania. Wymagania wobec rozwiązania opisujemy skończoną liczbą wymaganych usług systemu, do których jednoznacznie przyporządkowujemy wymagania jakościowe (np. dostępność) i dziedzinowe (np. wzór na wartość podatku).  Całość modelujemy jako przypadki użycia i model dziedziny (przypadki użycia – usługi systemu – są realizowane elementami modelu dziedziny, klasami lub komponentami realizującymi określoną logikę). Skąd brać przypadki użycia? Z warsztatów? Sesji burzy mózgów? Kiepski pomysł, co napisałem na początku. Jeżeli już jednak to robimy to śladowanie pozwala panować nad zakresem projektu i złożonością całej dokumentacji wymagań: po zatwierdzeniu wymagań biznesowych,  odrzucamy wszystkie zgłaszane wymagania funkcjonalne i niefunkcjonalne, które nie wspierają (nie dają się zaadresować – śladować) wymagań biznesowych. Skąd brać przypadku użycia? Najlepiej z modeli procesów, bo te są zweryfikowanym (tu śladowanie aktywność – przypadek użycia) modelem działania organizacji. Śladowanie wymaga jednak ścisłych – jednoznacznych, definicji. Skoro nie da się jednoznacznie zdefiniować “funkcjonalności systemu”, nie stosujmy tego pojęcia. Pojęcie usługa systemu jest dobrze zdefiniowane, w UML jest to przypadek użycia, w SOA i architekturze korporacyjnej, usługa aplikacyjna kojarzona jest (mapowana, śladowana) z elementarnymi (atomowymi) procesami biznesowymi (aktywnościami). 

Tak więc wymagań biznesowych może być kilkadziesiąt. Wymaganych usług systemu (przypadków użycia) w dużym projekcie także może być kilkadziesiąt. Ale setki, czy tysiące “wymagań” to wyraz utraty panowania nad zakresem projektu… Tu zwrócę uwagę, że wymaganiem (usługa systemu) może być np. wytworzona faktura VAT zgodna z przepisami. Cechy tej faktury (lista pól)  to nie osobne wymagania, to cechy (parametry, atrybuty) jednego wymagania. Żadna cecha faktury VAT nie ma sama w pojedynkę żadnej wartości, nie może więc być oddzielnym przypadkiem użycia, tak samo jak wymaganiem naszym może być samochód, ale jego kolor czy automatyczna skrzynia biegów, to cechy samochodu, nie ma sensu wymagać “czerwonego koloru” nie oczekując samochodu (i jak uzasadnić, to że ten kolor wspiera cel biznesowy). Przypadkiem użycia samochodu jest podróż a nie włożenie kluczyka do stacyjki, bo to jest tylko jeden z elementów scenariusza rozpoczęcia podróży samochodem.

Czemu tak  często jednak powstają nieweryfikowalne specyfikacje na setki pozycji? Najczęściej słyszę – z ust analityka –  głupie tłumaczenie: bo tak mi pokazano na szkoleniu (tak czytałem w jednej książce, tak było napisane na blogu XXX, tak robi się u mnie w firmie itp…).  Warto sobie samemu udowodnić poprawność wytworzenia efektów swojej pracy, a dobra dokumentacja analityczna jest sama dla siebie dowodem poprawności. Tak, mój blog także należy weryfikować.