Autor: Iwona Kula
Zapraszamy do kolejnej części cyklu publikacji, mających na celu omówienie głównych punktów w programie certyfikacji IREB oraz wspierających przygotowanie do egzaminu certyfikacyjnego IREB CPRE. Przedmiotem tej części publikacji będzie dokumentacja – produkty pracy (artefakty) oraz praktyki dokumentowania wymagań.
Zacznijmy od wyjaśnienia pojęcia artefakt, inaczej produkt pracy.
Artefakt to zarejestrowany, pośredni lub końcowy, rezultat wytworzony w procesie pracy.
W inżynierii wymagań wykorzystujemy wiele różnych produktów pracy. Część z nich tworzymy sami, jako wyniki czynności inżynierii wymagań. Część jest wynikiem pracy innych osób zaangażowanych w projekt, a my wykorzystujemy tę dokumentację jako wsad do naszych czynności i rezultatów.
Najprostszym przykładem artefaktu w inżynierii wymagań jest samo udokumentowane w jakiejś formie wymaganie. Artefaktem może być historyjka użytkownika, może to być specyfikacja przypadku użycia, model funkcjonalny aplikacji, tradycyjna dokumentacja specyfikacji wymagań. Ale artefaktem jest też rysunek, szkic służący porozumieniu się, wytworzony ad hoc na spotkaniu z klientem. Swego rodzaju artefaktem jest notatka z warsztatu przekazana uczestnikom spotkania.
Podsumowując w inżynierii wymagań tworzymy i wykorzystujemy wiele różnych artefaktów. Każdy z nich cechuje się pewnymi właściwościami:
Przeznaczenie – niektóre produkty pracy są dedykowane do opisu pojedynczych wymagań. Przykładem jest historyjka użytkownika lub opis wymagania w postaci tak zwanej deklaracji wymagania (ang. Requirement statement). Inne produkty pracy zawierają wymagania – jak na przykład przypadek użycia czy scenariusz funkcjonalny, który może obejmować kilka pojedynczych wymagań funkcjonalnych. Istnieją też artefakty dotyczące tak zwanych struktur dokumentacji wymagań – czyli w uproszczeniu szablony czy inne mechanizmy, które pozwalają uporządkować wymagania w jakiejś formie, zwykle pozwalają też przedstawiać powiązania i zależności pomiędzy wymaganiami. Przykładem struktury dokumentacji wymagań jest tradycyjna specyfikacja wymagań systemowych, czy stosowany w środowiskach zwinnych backlog. Inne artefakty, niekoniecznie bezpośrednio związane z opisem wymagań, a stosowane w inżynierii wymagań, to przykładowo słowniki projektowe, makiety, rysunki, notatki na tablicy.
Forma – produkty pracy mogą być wyrażone za pomocą języka naturalnego, mogą być oparte na uzgodnionym szablonie lub wyrażone za pomocą modelu. Możemy wyróżnić też inne formy reprezentacji produktów pracy, jak na przykład formy wizualne, rysunki, szkice, prototypy. W projektach zwykle stosuje się pewną kombinację tych form. Przykładowo wymagania wyższego poziomu, na przykład wymagania interesariuszy, mogą być opisane przy pomocy prostego języka naturalnego. Wymagania na poziomie systemowym, funkcjonalne, mogą być wyrażone przy pomocy diagramu przypadków użycia w języku UML oraz tekstowej, zgodnej z ustalonym szablonem, specyfikacji przypadków użycia.
Przechowywanie – w dzisiejszych czasach dominuje forma elektroniczna. Wymagania, modele, całe specyfikacje, przechowujemy na dyskach współdzielonych, w narzędziach inżynierii wymagań, sporadycznie na lokalnym urządzeniu inżyniera wymagań (taka sytuacja może mieć miejsce gdy przykładowo analityk jest na etapie tworzenia specyfikacji wymagań).
Forma elektroniczna dominuje, ale nie jest jedyna. Niektóre artefakty spokojnie możemy przechowywać w formie papierowej czy na tablicy (rysunki).
Długość życia – produkty pracy mogą być tymczasowe, stworzone celem porozumienia się, omówienia jakiegoś tematu, podjęcie decyzji. Nazywają się tymczasowe, ponieważ nie stają się artefaktem rozwijanym, zazwyczaj po tym, jak spełniły swój cel są albo niszczone, albo po prostu trwają w swojej postaci, nie są w żaden sposób rozwijane. Przykładem może być rysunek na tablicy stworzony podczas warsztatów z klientem i służący porozumieniu się w temacie kolejności wykonywania zadań w ramach danego procesu biznesowego.
Innym rodzajem produktu pracy są artefakty rozwijane. Tu przykładem może być specyfikacja przypadku użycia, która jest iteracyjnie uszczegóławiana do momentu opracowania wersji finalnej. Rozwijane produkty pracy podlegają kontroli zmian – w tym celu musimy utrzymywać zestaw tak zwanych metadanych (np. data utworzenia, ostatniej edycji, autor zmian, wersja).
Trwałe produkty pracy to, te które zostały przekazane do kolejnego etapu wytwórczego, udostępnione interesariuszom po akceptacji, lub z innego powodu uznane za swego rodzaju punkt odniesienia (ang. baseline). Przykładem takiego artefaktu może być uzgodniona i zaakceptowana przez interesariuszy, przekazana zespołowi wytwórczemu, specyfikacja wymagań opisujących pewne wydanie systemu.
Warto zwrócić uwagę na to że długość życia jako atrybut artefaktu nie jest czymś stałym i ostatecznym. Tymczasowy produkt pracy może zostać przekształcony w produkt rozwijany. Produkt rozwijany może stać się trwałym.
Wymagania, jak i inne produkty pracy w inżynierii wymagań, mogą istnieć na różnych poziomach abstrakcji. Standardowa klasyfikacja została przedstawiona w rozdziale pierwszym syllabusa IREB i dzieli wymagania na poziomy: biznesowy, interesariuszy oraz systemowy. Analogicznie można podzielić inne produkty pracy. I tak dla przykładu możemy mówić o systemowym przypadku użycia opisującym funkcjonalność z punktu widzenia aktora (roli użytkownika w systemie) i reakcji systemu na działania aktora; ale możemy też mówić o biznesowym przypadku użycia funkcjonującym na poziomie operacji biznesowych.
W zależności od etapu projektowego, celu produktu pracy oraz odbiorców, należy dobrać odpowiedni poziom szczegółowości. Jeśli odbiorcami produktu pracy jest tak zwany biznes, z reguły zdecydujemy się na bardziej ogólny opis, bez szczegółów technicznych i sposobów realizacji, za to ze szczególnym naciskiem na reguły biznesowe. Jeśli naszym produktem pracy jest specyfikacja wymagania której odbiorcą jest deweloper, zawarte w wymaganiu informacji powinny wystarczyć do sprawnej implementacji wymagania, najprawdopodobniej takie wymaganie będzie więc o wiele bardziej szczegółowe.
Jakąkolwiek formę opisu i typ artefaktu dobierzemy, ważne jest jednak zachowanie pewnej spójności koncepcji i nie mieszanie różnych poziomów abstrakcji w ramach tego samego artefaktu. Dla przykładu historyjka użytkownika z definicji powinna opisywać potrzebę oraz jej uzasadnienie, ale nie wchodzić w szczegóły realizacji. Z tego też powodu opis historyjki “jako użytkownik Allegro chcę widzieć na stronie głównej ikonę Dodaj do ulubionych” nie jest prawidłowym opisem artefaktu tego typu, jako że potrzebą użytkownika nie jest posiadanie ikony a możliwość dodania produktu do listy ulubionych po to, żeby na przykład być informowanym o zmianie ceny tego produktu. Szczegóły w rodzaju czy funkcja dostępna jest poprzez ikonę, przycisk czy jeszcze inną formę realizacji, nie powinny być częścią tej historyjki, mogą natomiast stać się częścią jej kryteriów akceptacji. W szczególnym przypadku jeśli mamy do czynienia z dużym artefaktem, obszerną specyfikacją wymagań zawierającą zarówno wymagania interesariuszy, jak i wymagania systemowe czy nawet wymagania na poziomie oprogramowania, poszczególne poziomy wymagań powinny być opisane oddzielnie (na przykład w różnych sekcjach takiego dokumentu). Należy jednak zachować powiązań, pomiędzy wymaganiami na różnych poziomach (patrz koncepcja śledzenia powiązań).
W przypadku typowego kaskadowego projektu wytwórczego, dość często można wskazać następującą przykładową ścieżkę rozwoju artefaktu: wymagania biznesowe i wymagania interesariuszy są identyfikowane i specyfikowane na samym początku inicjatywy, zawierają one informacje na wysokim poziomie abstrakcji i służą jako podstawa opracowywania wymagań na niższych poziomach (wymagania systemowe).
W przypadku projektów zwinnych sytuacja może przedstawiać się nieco inaczej – wymagania na różnych poziomach mogą być pozyskiwane i opracowywane niemalże w tym samym czasie (jako że charakterystyką metod zwinnych jest otwartość na zmiany i umożliwienie dodawania nowych wymagań do zakresu w zasadzie w dowolnym momencie inicjatywy).
Określenie właściwego poziomu szczegółowości wymagań to nie lada wyzwanie. Nie ma tutaj prostej reguły, która mówiłaby, że w przypadku tego projektu wymagania powinny być bardzo szczegółowe, w przypadku innego projektu można sobie pozwolić na lekką dokumentację.
Dobór właściwego poziomu szczegółowości zależy od szeregu czynników. Wśród nich istotne jest zrozumienie charakterystyki problemu biznesowego i specyfiki produktu, które mogą determinować lub znacząco wpływać na podjęcie właściwej decyzji. Dla przykładu systemy obarczone wysokim ryzykiem (tak zwane systemy safety critical) z reguły mają wyśrubowane wymagania co do procesów wytwórczych. W przypadku tego rodzaju systemów możemy mieć do czynienia ze standardami i regulacjami narzucającymi nie tylko zawartość dokumentacji wymagań, ale i często regulującymi sam proces wytwarzania (na przykład Automotive Spice, stosowany w przypadku oprogramowania związanego z komponentami krytycznymi w branży samochodowej, poniekąd narzuca schemat klasyfikacji wymagań oraz szereg praktyk, które należy wykonywać w ramach inżynierii wymagań).
Kolejnym czynnikiem, który wpływa na szczegółowość opisu jest stopień porozumienia pomiędzy dostawcą a klientem – jeśli dostawca znakomicie rozumie biznes klienta, dodatkowo panują między innymi przyjazne i pokojowe nastroje, wystarczająca może okazać się lekka dokumentacja wymagań.
Takich czynników wpływających na poziom szczegółowości opisu jest więcej – ich szczególnym przykładem są ograniczenia projektowe jak koszt i harmonogramy oraz kompetencje personelu odpowiedzialnego za opracowywanie różnych produktów pracy.
Warto zwrócić uwagę na jedno. W teorii im bardziej szczegółowy, wręcz pedantyczny opis wymagań, tym mniejsze ryzyko nieporozumień i rozczarowania w stosunku do finalnego produktu. Produkty pracy jednak nie tworzą się same – ich opracowanie, walidacja i inne czynności to koszt. Należy więc odpowiednio wyważyć korzyści wynikające ze szczegółowego opisu względem kosztu poniesionego na osiągnięcie tego celu. Kłania się tutaj 1 zasada inżynierii wymagań „Orientacja na wartość” omawiana w poprzedniej części cyklu.
Pierwszy, a zarazem kluczowy aspekt, który należy uwzględnić myśląc o jakichkolwiek produktach pracy związanej z inżynierią wymagań to kontekst systemu. Jak wyjaśniono w 4 zasadzie inżynierii wymagań, kontekst systemu umożliwia prawidłowe zrozumienie istoty systemu, jego ograniczeń, możliwości oraz stanowi źródło dla pozyskiwania wymagań.
Dodatkowym aspektem, który należy uwzględnić, jest to, jaki rodzaj wymagań chcemy opisać. Inaczej dokumentuje się wymagania funkcjonalne, inaczej jakościowe, jeszcze inaczej możemy definiować ograniczenia.
Dobrym wsparciem dla specyfikacji wymagań różnego rodzaju, mogą okazać się modele jakości, w szczególności model SQuaRE, który z całym przekonaniem mogę polecić jako gotowy system klasyfikacji wymagań oraz znakomitą ściągawkę podczas dyskusji o wymaganiach z klientem i innymi interesariuszami.
Kolejnym wyróżnionym przez IREB aspektem do uwzględnienia, jest kwestia wymagań funkcjonalnych. Mogą one koncentrować się na danych przetwarzanych przez system, funkcjach i przepływie lub stanach i zachowaniu. Te trzy perspektywy wymagań funkcjonalnych zostaną szerzej opisane w module poświęconym technikom dokumentacji przy użyciu modelu.
Co wspólnego mają powyższe aspekty z praktycznym podejściem do dokumentacji wymagań? Po pierwsze warto mieć świadomość różnych powiązań – zmiana w kontekście może spowodować zmianę wymagań funkcjonalnych, które zostały przedstawione za pomocą aspektu funkcji przepływu. Innymi słowy zmiana w kontekście może być lawiną powodującą zmiany w wielu powiązanych artefaktach.
Kolejna praktyczna wskazówka dotyczy tego, który aspekt (inaczej perspektywa) jest przedstawiony w jakim artefakcie. I tak są artefakty, które opisują tylko i wyłącznie jeden aspekt – jak na przykład diagram sześć stanów skupia się na aspekcie stanu i zachowania, podczas gdy specyfikacja wymagań funkcjonalnych może obejmować kilka aspektów: wymagania funkcjonalne i związane z nimi ograniczenia, aspekt funkcji przepływu i do pewnego stopnia aspekt stanu i zachowania.
Ogólne wytyczne dotyczące dokumentacji
IREB określa kilka uniwersalnych wytycznych dotyczących tworzenia produktów pracy.
Osobiście dodałabym do tego zasadę atomowości, czy też rozwarstwiania informacji – czyli ustalenia takiego systemu produktów pracy, w których każdy rodzaj informacji ma swoje zdefiniowane miejsce. Dla przykładu:
Informacje w artefaktach nie duplikują się, a są odpowiednio powiązane. Tym sposobem łatwiej będzie dbać o spójność, łatwiej też będzie zarządzać potencjalnymi zmianami.
Typowy błąd popełniany przez początkujących inżynierów wymagań, to rozpoczęcie prac projektowych od „pisania” wymagań. Pomijam, ze wymagań się nie pisze.
Większym problemem jest to, że tworzenie jakiegokolwiek produktu pracy bez zastanowienia się, co właściwie chcę udokumentować, komu ma to służyć i jak być przedstawione (szczegółowo, ogólnie, w formie języka naturalnego, modelu czy pisma obrazkowego), w zasadzie mija się z celem.
Pomyśl o tym:
Sprawdza się tu prosta reguła – „ zanim coś zrobisz, pomyśl”.
Pomyśl również o szkoleniu, na które serdecznie zapraszamy. Szkolenie przygotowuje do egzaminu i uzyskania certyfikatu IREB® CPRE Foundation Level (poziom podstawowy).
Zachęcamy również do zapoznania się na naszym blogu z drugą częścią publikacji, dotyczącą przygotowania do egzaminu IREB.
Autor: Karolina Zmitrowicz
Ekspert z kilkunastoletnim doświadczeniem w branży IT i szeroką wiedzą w zakresie procesów IT, pełni wiodącą funkcję w strukturach międzynarodowej organizacji IREB (International Requirements Engineering Board) oraz wspiera inne stowarzyszenia i organizacje branżowe. Twórca programów szkoleniowych, autor wielu publikacji książkowych.