Czy wymagania muszą być idealne?
Czy wymagania muszą być idealne? Czy zawsze, w każdej sytuacji powinniśmy dążyć, do pełnego zrealizowania wszystkich charakterystyk jakości wymagań? To pytanie wydaje się dość przewrotne i zapewne pierwsza nasuwająca się odpowiedź brzmi: oczywiście, tak! Czy na pewno? Ciekawa interpretacja tego zagadnienia została przedstawiona w artykule profesora Martina Glinza z Uniwersytu w Zurychu.
Charakterystyki jakości wymagań
W literaturze znaleźć można różne zestawienia cech i charakterystyk, które powinny być spełnione przez dokumentację wymagań, aby można było uznać, że wymagania opisane zostały na wysokim poziomie jakości. Jednym z popularnych źródeł w tej kwestii z całą pewnością jest norma ISO 29148. Podaje ona charakterystyki jakości zarówno dla wymagań indywidualnych jak i dla zbiorów wymagań.
Charakterystyki jakości indywidualnych wymagań
- Niezbędne (ang. Necessary)
Wymaganie definiuje istotną funkcjonalność, jakość lub ograniczenie. Pominięcie wymagania spowoduje deficyt, którego nie da się uzupełnić poprzez realizację innych wymagań opisanych w specyfikacji. Ponadto wymaganie jest cały czas aktualne.
- Właściwe (ang. Appropriate)
Wymaganie jest opisane na odpowiednim poziomie abstrakcji stosownie do celu w jakim zostało udokumentowane. Wymaganie zawiera zakres informacji, który jest niezbędny i właściwy, bez narzucania zbędnych ograniczeń lub konkretnych sposobów rozwiązania.
- Jednoznaczne (ang. Unambiguous)
Wymaganie pozostawia minimalne (idealnie żadne) pole do interpretacji. Można je zinterpretować tylko w jeden, konkretny sposób.
- Kompletne (ang. Complete)
Wymaganie zawiera niezbędny zakres informacji, umożliwiający jego zrozumienie i zrealizowanie. Nie jest konieczne odniesienie w tym celu do informacji zawartych gdzie indziej.
- Pojedyncze (ang. Singular)
Wymaganie określa pojedynczą funkcjonalność, cechę jakościową lub ograniczenie. Dotyczy jednego aspektu.
- Wykonalne (ang. Feasible)
Wymaganie jest możliwe do zrealizowania w ramach zdefiniowanych ograniczeń (budżetowych, technologicznych etc.). Ryzyko jego niezrealizowania jest akceptowalne.
- Weryfikowalne (ang. Verifiable)
Wymaganie jest sformułowane w sposób umożliwiający udowodnienie (przetestowanie) jego realizacji. Weryfikowalności wymagania sprzyja jego mierzalność.
- Poprawne (ang. Correct)
Wymaganie przedstawia rzeczywistą, poprawnie zrozumianą, potrzebę biznesową.
- Zgodne ze standardem (ang. Conforming)
Wymaganie jest zgodne z przyjętym standardem lub szablonem dokumentowania wymagań. Oczywiście, jeśli taki szablon lub standard został zdefiniowany.
Charakterystyki jakości zbiorów wymagań
- Kompletne (ang. Complete)
Zbiór wymagań zawiera wszystkie niezbędne funkcjonalności, cechy jakościowe i ograniczenia niezbędne do zaspokojenia potrzeby biznesowej.
- Spójne (ang. Consistent)
Zbiór wymagań zawiera unikatowe wymagania, nie zawiera wymagań sprzecznych wymagań lub redundantnych (pokrywających się swoim zakresem). Ponadto terminologia użyta w opisach wymagań również jest spójna i ustandaryzowana.
- Wykonalne (ang. Feasible)
Zbiór wymagań jest możliwy do zrealizowania w ramach zdefiniowanych ograniczeń (budżetowych, technologicznych etc.). Ryzyko jego niezrealizowania jest akceptowalne. Jest to analogiczne do charakterystyki zdefiniowanej dla pojedynczego wymagania.
- Zrozumiałe (ang. Comprehensible)
Zbiór wymagań jest sformułowany w sposób umożliwiający jego jasne i poprawne zrozumienie.
- Możliwe do zwalidowania (ang. Able to be validated)
Istnieje możliwość zaspokojenia zdefiniowanej potrzeby biznesowej poprzez zrealizowanie zbioru wymagań.
Idealne wymagania
Sprawą oczywistą jest, iż warto dążyć do pełnego wypełniania wszystkich powyższych charakterystyk. Im większy jest stopień ich spełnienia tym wymaganie przynosi więcej korzyści. Są one zwykle rozumiane jako zwiększenie szansy na powstanie systemu zaspokajającego (w optymalny sposób) zdefiniowaną potrzebę biznesową oraz zmniejszenie ryzyka kosztownych zmian w trakcie realizowania systemu i późniejszych awarii w trakcie jego funkcjonowania.
Czy jednak idealna dokumentacja wymagań istnieje? Czy możliwe jest pełne wypełnienie wszystkich charakterystyk jakości? Ciekawa opinia na ten temat znajduje się we wspomnianych wcześniej artykule profesora Glinza. Jako przykład rozpatruje on takie charakterystyki jak jednoznaczność i kompletność.
Profesor Glinz wskazuje, że w pełni jednoznaczna specyfikacja wymagań wymaga formalnego języka specyfikowania. Wskazuje równocześnie na umiarkowany sukces stosowania tego rodzaju narzędzi w realnej inżynierii oprogramowania. Zakładając jednak, że mimo wszystko stosowalibyśmy tego typu narzędzie i tak wymaga to mapowania pomiędzy obiektami i zjawiskami świata rzeczywistego i elementami tego właśnie, formalnego języka. Zdaniem profesora Glina tego jest to modelowanie, które ze swojej natury nie jest możliwe do pełnego sformalizowania. Oznacza to, że finalnie możemy otrzymać jednoznaczną finalną formę opisu, jednakże sam sam proces jego tworzenia nie jest w pełni jednoznaczny. W konsekwencji oznacza to, że opracowanie w pełni jednoznacznych wymagań nie jest możliwe.
Podobnie rzecz się ma z kompletnością. Opracowanie w pełni kompletnej specyfikacji wymagań oznacza konieczność zdefiniowania wszystkich możliwych danych wejściowych, wyjściowych oraz relacji pomiędzy nimi. Jakkolwiek jest to możliwe dla zagadnień teoretycznych, tak według profesora Glinza nie jest to realne w przypadku systemów odzwierciedlających realny świat.
Wartość wymagań
Z powyższych rozważań wynika, że całościowe wypełnienie wszystkich charakterystyk jakości zdefiniowanych dla wymagań nie jest możliwe. Oznacza to, że idealna specyfikacja wymagań nie istnieje. Co w takiej sytuacji? Na ile poprawne powinny być wymagania? Odpowiedź jest prosta, ale nie w pełni jednoznaczna i brzmi ona: Na tyle na ile jest to niezbędne i uzasadnione.
Wraz ze wzrostem jakości wymagań zwiększa się również koszt ich opracowania i utrzymywania. Jest to zrozumiałe ze względu na to, że zwykle oznacza to większy wysiłek związany z ich pozyskaniem, dokumentowaniem i walidowaniem. Mamy zatem wspomniane wyżej korzyści wynikające w wysokiej jakości wymagań oraz koszty z nimi związane. Warto się zatem kierować wartością wymagań, czyli stosunkiem korzyści do kosztów. Takie właśnie rozumowanie zostało opisane w Sylabusie IREB 3.0, w pewnym zakresie bazującym również na wspominanym artykule profesora Glinza.
Jeśli na przykład zespół wytwarzający dany produkt bazuje w większości na interakcji i krótkich pętlach informacji zwrotnej i rzadko odwołuje się do formalnych zapisów specyfikacji, być może nie warto szczególnie dużo w nią inwestować. Na pewno nie warto za wszelką cenę i nie zważając na koszty dążyć do spełnienia w 100% wszystkich charakterystyk jakości wymagań.
Moje rekomendacje
- Zapoznaj się z charakterystykami jakości wymagań – bywają pomocne przy ich dokumentowaniu
- Pamiętaj, że nie jest możliwe spełnienie wszystkich zdefiniowanych charakterystyk jakości wymagań w 100%
- Rozważając stosowny i niezbędny stopień spełnienia poszczególnych charakterystyk wymagań, kieruj sie kryterium wartości, czyli stosunkiem korzyści wynikających z wymagań i kosztu ich udokumentowania u utrzymywania
Polecane szkolenia IREB CPRE
Źródła
- Martin Glinz: How Much Requirements Engineering Do We Need? Softwaretechnik-Trends 2016
- ISO/IEC/IEEE 29148: Systems and Software Engineering – Life Cycle Processes – Requirements Engineering, International Organization for Standardization, 2018
- Certyfikowany specjalista inżynierii wymagań IREB, Sylabus, wersja 3.1.0, 2022.
