W grudniu 2011 roku napisałem na zakończenie pewnego artykułu o wymaganiach:
Większość projektów takich jak np. wdrażanie nowych metod kontrolingu, zrównoważonej karty wyników, nowych systemów IT itp. cierpi głównie z powodu posiadania nadmiaru informacji z jednej strony i kompletnego jej niezrozumienia z drugiej. Sławne już w badaniach ?złe i niekompletne wymagania? czy ?zmiany zakresu projektu w trakcie jego trwania? to klasyczne skutki złej (a często pomijania!) analizy biznesowej. Koszty tych porażek wielokrotnie przewyższają koszt takich analiz. (Analiza biznesowa ? skuteczne modelowanie a ryzyko projektu).
Specyfikowanie wymagań, zarządzanie wymaganiami, inżynieria wymagań, to jak widać bardzo trudny etap projektu. Trudność bierze się stad, że dostępne zalecenia określają, że wymagania maja być np. spójne i kompletne ale zupełnie nie opisują jak to osiągnąć (a nawet jak to sprawdzić).
Często można się spotkać z pojęciem “inżynieria wymagań”. Budzi ono mój opór z dwóch powodów: znaczenie słowa inżynieria w j.polskim i nieadekwatność tego słowa do dziedziny jaką jest specyfikowanie wymagań, które są po protu listą warunków.
Zajrzyjmy do słownika języka polskiego:
inżynieria ?projektowanie i konstruowanie obiektów oraz urządzeń technicznych?
wymaganie ?warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać?
Więc jak rozumieć złożenie “inżynieria wymagań”? Ja nie wiem, chyba, że ktoś uważa, że wymagania się “konstruuje”, i że są to zagadnienia techniczne. Za to ma sens “inżynierii systemów”. Mamy def. pojęcia system:
system ?układ elementów mający określoną strukturę i stanowiący logicznie uporządkowaną całość?
Gdyby definicje słowa “inżynieria” okroić z “technicznych” albo uznać, że systemy są także nie techniczne (bo są np. społeczne) to mamy wdzięczna definicję:
inżynieria systemów ?projektowanie i konstruowanie układów elementów mających określoną strukturę i stanowiący logicznie uporządkowaną całość?
Jeden z moich ulubionych autorów akademickich, Ian Sommeville (lubię go także za to, że książki pisze w pubach popijając piwo ;)) definiuje inżynierię wymagań tak:
Requirements engineering (RE) refers to the process of formulating, documenting and maintaining software requirements (źr. Kotonya G. and Sommerville, I. Requirements Engineering: Processes and Techniques. Chichester, UK: John Wiley & Sons)
(pojęcie inżynierii wymagań odnosi do procesu formułowania, dokumentowania i zarządzania wymaganiami)
Tak więc uznając, że wymagania na systemy to element inżynierii tych systemów, niniejszym godzę się używać pojęcia “inżynieria wymagań” w znaczeniu jakim opisał to Sommerville :).
Po co tyle ględzenia o słowach i ich znaczeniach? Poza “szukaniem” alibi dla istnienia pojęcia “inżyniera wymagań” chcę pokazać, że słowa mają znaczenie, zaniedbywanie tego prowadzi do wielu nieporozumień (niejednoznaczność) a po drugie zwracam uwagę, że analiza pojęciowa to jeden z kluczowych elementów analizy w ogóle (i często zaniedbywana).
Skoro wymagania to warunki, to aż prosi się by te warunki sprawdzać. Patrzmy do słownika:
sprawdzać ?skontrolować, zbadać, czy coś jest zgodne z prawdą, czy coś zostało zrobione prawidłowo?
Tak więc wniosek jest prosty: wymaganie (każde!) powinno być sprawdzalne! Bez tego nie jesteśmy w stanie określić czy “coś” spełnia te wymagania, czyli czy zdanie: “dostarczony produkt jest zgodny z wymaganiami” jest prawdziwe czy nie (a nie chcemy oddać rozstrzygania tego prawnikom ;)).
Inżynieria wymagań
Skoro więc ugiąłem się i uznałem pojęcie inżynierii wymagań, popatrzmy na to systemowo. Jak zawsze proste jest piękne więc co analizujemy w inżynierii systemowej i inżynierii wymagań:
Pojęcie “system” to także supersystem (system nadrzędny) i podsystem (system podrzędny, część systemu). To troszkę jak znane wam, być może, matrioszki 🙂 (figurki jedna w drugiej…).
Jest to, nazewnictwo, bardzo ważne, bo w jednym projekcie (dokumentacji) należy zachować bezwzględną dyscyplinę pojęciową, czyli słowo System powinno się odnosić wyłącznie do konkretnego poziomu opisu, reszta to elementy systemu nadrzędnego lub podrzędnego.
Mianem system określa się zwyczajowo specyfikowane oprogramowanie, jednak problem pojawi się natychmiast, gdy dotkniemy takich pojęć jak wymagania funkcjonalne na oprogramowanie i wymagania biznesowe. To ostatnie niesie pewną niejasność. Bo nie wiem czy chodzi o wymagania wobec (w stosunku do) biznesu (np. poprawa jakości obsługi klienta o 5% w najbliższym badaniu jakości ISO) czy wymagania biznesu wobec (w stosunku do) oprogramowania (np. minimalizacja do zera otrzymanych i zagubionych zapytań ofertowych).
Popatrzmy na powyższy diagram. Mamy tu dwa Systemy:
- Organizacja jest podsystemem, jest elementem systemu, którym tu jest rynek na jakim ta organizacja funkcjonuje.
- Organizacja jest analizowanym systemem, oprogramowanie jest jednym z zasobów tej organizacji (oprogramowanie jest tu podsystemem).
Wymagania możemy tu odnosić w stosunku do Organizacji i w stosunku do Oprogramowania. To dlatego jasno wyodrębniamy analizę biznesową (produktem są modele biznesowe i wymagania biznesowe) od analizy wymagań na oprogramowanie (modele i wymagania na oprogramowanie). Jak widać wymagania na oprogramowanie to wymagania, których źródłem jest biznes, który ma konkretne cele do osiągnięcia. Nie powinny być one pobożnymi życzeniami użytkowników, aż do momentu gdy sponsor projektu nie powie np.: moim celem jest wygoda pracy moich pracowników. Oczywiście, ta wygoda jest zawsze wymagana ale nie musi ona być celem samym w sobie i nie musi mieć najwyższego priorytetu.
Wymagania interesariuszy. Moja definicja interesariusza (jedna z wielu): osoba (podmiot) zainteresowana zaistnieniem produktu, na którą pojawienie się produktu ma wpływ. Nie raz jestem pytany czy interesariusz ma prawo zgłaszania wymagań. Jeżeli ma coś do powiedzenia podczas odbioru produktu to znaczy, że ma wymagania. One mogą być jednak niejawne czyli taki interesariusz nie zgłasza wymagań ale ma wpływ na odbiór produktu, należy go koniecznie zidentyfikować. Jeżeli zaś ktoś nie ma nic do gadania przy odbiorze produktu nie jest interesariuszem (ang. stakeholder, kluczem jest tu ‘holder’ czyli dysponent mający coś do powiedzenia, mający wpływ). Tak wiec interesariusz to ktoś kto, na swoim poziomie ogólności, także musi umieć określić, kiedy uzna, że produkt spełnia jego wymagania. Jak nie potrafi, ktoś musi mu pomóc…analityk :)).
I tu rola analityka. Interesariusz spisuje co mu przyjdzie do głowy swoim językiem, analityk upewnia się, że zrozumiał, doprowadza je do postaci testowalnej i klasyfikuje “wymagania” jako “źródło: konkretny interesariusz” (bo każde wymaganie musi mieć właściciela). Proszę zwrócić uwagę, że interesariuszem jest także użytkownik jeżeli tylko ma coś go powiedzenia w projekcie :).
Popatrzmy na wymaganie:
Wymaganie jest jedno (warunek jaki coś musi spełnić) ale może ono mieć wiele atrybutów i tu widzę “złożoność” wymagań (ich [[taksonomia]]). Zarówno “wystawianie faktur VAT” jak i “dostępność 99,99% czasu” to równoprawne wymagania bo oprogramowanie np. wspomagające sprzedaż jest bezwartościowe zarówno gdy nie pozwala wystawiać faktur jak wtedy, gdy często się psuje. Owszem, jedno jest funkcjonalne drugie jest poza-funkcjonalne ale jedno i drugie to “równoprawny warunek przydatności” czyli Wymaganie wobec oprogramowania.
Jak wspomniałem, wymagania są (warto tak robić) klasyfikowane za pomocą atrybutów. Najczęściej spotykane to: rodzaj (Kind), źródło wymagania (Source), polecam także priorytet, metodę weryfikacji (np. test, audyt zgodności z opisem w dokumentacji), status (planowane, zaakcpetowane, odrzucone, …) i inne, zależnie od wymagań i typu projektu.
Ważna uwaga i zalecenie IIBA: zarządzanie wymaganiami “zabrania” ich usuwania (albo renumeracji po usunięciu). usuwanie powoduje to niespójność wersjonowanej dokumentacji, która także ma swój cykl życia. Ja od dłuższego czasu stosuję dodatkowy status “odrzucone”, co daje mi ciągłość dokumentacji a także pozwala na “odwieszenie” wcześniej zdefiniowanego wymagania, gdy ktoś jednak uzna, że coś co było zbędne nagle znowu staje się konieczne :).
Liczba pytań i sugestii (także na kilku forach dyskusyjna) skłoniła mnie do podjęcia próby zbudowania taksonomii wymagań. Jak już wspomniałem wyżej, zalecenia takie jak FURPS to niestety tylko płaska lista “cech” (i nie wszystkich). Wydaje mi się, że struktura wymagań, ich taksonomia wzajemne zależności oraz relacje do udziałowców projektu (interesariusze) i przyszłych użytkowników rozwiązania, wymagają bardziej formalnego podejścia. Celem jest uzyskanie możliwości sprawdzania czy wymagania – jako przedmiot inżynierii wymagań – spełniają jakieś, trzeba je stworzyć, wymagania.
Powyżej próba usystematyzowania “wymagań” na bazie wyżej cytowanych definicji tego pojęcia.
Na koniec jeszcze kolejna ważna rzecz. Warto wskazywać, które elementy logiki biznesowej (Model) odpowiadają (są powiązane) z danym wymaganiem bo np. szczegółowo opisują wymagany sposób realizacji danego wymagania (np. system upustów albo konkretny przypadek użycia, także Model). Warto także, jeżeli opis wymagania nie jest testem, zaprojektować test (przypadek testowy), który potwierdzi spełnienie wymagania np. “oprogramowanie ma pozwalać na wyliczanie pierwiastków drugiego i trzeciego stopnia”. Tu warto podać kilka konkretnych danych wejściowych wraz z prawidłowymi wynikami (może to dotyczyć nap. tabeli upustów, systemu skoringu klientów itp.).
Tego typu metody maja nazwę deklaratywnych:
Programowanie deklaratywne ? rodzina paradygmatów programowania, które nie są z natury imperatywne. W przeciwieństwie do programów napisanych imperatywnie, programista opisuje warunki, jakie musi spełniać końcowe rozwiązanie (co chcemy osiągnąć), a nie szczegółową sekwencję kroków, które do niego prowadzą (jak to zrobić). Programowanie deklaratywne często traktuje programy jako pewne hipotezy wyrażone w logice formalnej, a wykonywanie obliczeń jako ich dowodzenie. Programowanie deklaratywne jest szczególnym przedmiotem zainteresowania naukowców, gdyż dzięki minimalizacji lub eliminacji skutków ubocznych może znacząco uprościć tworzenie programów współbieżnych. Paradygmat programowania deklaratywnego obejmuje szeroką gamę języków programowania i bardziej szczegółowych paradygmatów podrzędnych. (Programowanie deklaratywne ? Wikipedia, wolna encyklopedia).
