Po wakacyjnej przerwie wznawiam cykl artykułów dotyczących inżynierii wymagań. Tak jak przed wakacjami teksty będą pojawiać się co środę.
Walidacja i negocjacja wymagań służą przede wszystkim do poprawy ich jakości. Negocjacja i walidacja wymagań powinna być przeprowadzana podczas całego procesu inżynierii wymagań. Aby zapewnić możliwość systematycznej walidacji wymagań muszą zostać określone kryteria jakościowe pozwalające na określenie jakości tych wymagań.
Walidacja wymagań
Podczas walidacji wymagań należy określić, czy zdefiniowane wymagania posiadają wymagany poziom jakości oraz czy wymagania te mogą zostać zatwierdzone do dalszego wykorzystania w kolejnych fazach cyklu życia oprogramowania (np. projektowania, implementacji, czy testowania). Celem walidacji wymagań jest wykrycie potencjalnych błędów w dokumentacji wymagań. Do błędów tych mogą należeć niejednoznaczność, niekompletność lub sprzeczność z innymi wymaganiami.
Jeżeli błędy dotyczące wymagań nie zostaną wykryte na tym etapie, to jest duże prawdopodobieństwo, że zostaną wykryte dopiero podczas użytkowania tworzonego systemu, co znacząco podniesie koszty usunięcia tych błędów.
Negocjacja wymagań
Celem negocjacji wymagań jest osiągnięcie wspólnego i uzgodnionego porozumienia dotyczącego zdefiniowanych wymagań, które zostanie opracowane przez wszystkich interesariuszy. Brak opracowanego porozumienia dotyczącego zdefiniowanych wymagań może spowodować niemożliwość zaimplementowania wszystkich wymagań (np. wymagań sprzecznych z wymaganiami określonej grupy interesariuszy), co może spowodować brak akceptacji tworzonego systemu przez klienta. Podczas rozwiązywania konfliktów pomiędzy wymaganiami różnych grup interesariuszy istnieje możliwość odkrycia nowych rozwiązań dla tworzonego systemu, które będzie satysfakcjonujące dla wszystkich stron konfliktu, a dodatkowo może doprowadzić do odkrycia wymagań, które w znacznym stopniu podniosą satysfakcję klienta w tworzonego systemu.
Jakość wymagań
W zależności od podejmowanych działań (akwizycji, dokumentacji, walidacji i negocjacji) w procesie inżynierii wymagań, można wyróżnić trzy aspekty jakościowe wymagań, które korespondują z tymi działaniami dotyczącymi:
- Zawartości, który określa czy wszystkie wymagania zostały zidentyfikowane i udokumentowane
- Dokumentacji, który określa czy wszystkie dokumenty wymagań przestrzegają ustalonych wytycznych dotyczących dokumentacji i specyfikacji
- Porozumienia, który określa czy wszyscy interesariusze zgadzają się z udokumentowanymi wymaganiami oraz czy wszystkie konflikty pomiędzy wymaganiami interesariuszy zostały rozwiązane
Aspekty jakościowe wymagań dotyczące zawartości odnoszą się do walidacji wymagań w odniesieniu do błędów w ich treści. Błędy wymagań dotyczące zawartości występują, jeżeli poszczególne kryteria jakościowe dla wymagań lub dokumentów wymagań nie zostały spełnione.
Walidacja wymagań dotycząca zawartości może zostać określona jako zrealizowana pozytywie, jeżeli w jej trakcie nie wykryto żadnych istotnych błędów dotyczących:
- Kompletności (w rozumieniu zbioru wymagań): Wszystkie istotne wymagania dotyczące tworzonego systemu zostały udokumentowane.
- Kompletności (w odniesieniu do poszczególnych wymagań): Każde wymaganie posiada wszystkie potrzebne informacje.
Aspekty jakościowe wymagań: Zawartość
Aspekty jakościowe wymagań w zakresie zawartości dotyczą:
- Identyfikalności: Wszystkie istotne powiązania zostały określone.
- Poprawności/adekwatności: Wszystkie wymagania są adekwatne do życzeń i potrzeb interesariuszy.
- Spójności: Istnieje możliwość implementacji wszystkich wymagań w systemie – brak wymagań sprzecznych.
- Braku przedwczesnych decyzji projektowych: Czy istnieją decyzje projektowe wynikające z aktualnych wymagań, które nie są określone przez ograniczenia?
- Weryfikowalności: Czy istnieje możliwość zdefiniowania testów akceptacyjnych na podstawie zebranych wymagań?
- Potrzebności: Czy każde wymaganie przyczynia się do realizacji celów interesariuszy?
Aspekty jakościowe wymagań: Dokumentacja
Walidacja wymagań w odniesieniu do aspektów jakościowych dokumentacji może być określona jako zrealizowana pozytywnie, jeżeli w jej trakcie nie wykryto żadnych istotnych błędów dotyczących:
- Zgodności formatu dokumentacji: Wszystkie dokumenty wymagań mają wcześniej określony format, np. wykorzystano określone szablony dla wymagań i przypadków użycia, wykorzystano wcześniej ustalony język do modelowania wymagań.
- Zgodności struktury dokumentów: Wszystkie dokumenty wymagań posiadają wcześniej określoną strukturę, wszystkie wymagania zostały w nich ujęte oraz znajdują się w odpowiednim miejscu w dokumentacji.
- Zrozumiałości: Czy wszystkie wymagania są należycie zrozumiane w danym kontekście? Czy na przykład wszystkie użyte w dokumencie definicje zostały uwzględnione w słowniku?
- Jednoznaczności: Czy wszystkie dokumenty wymagań pozwalają tylko na jedną ich interpretację, czy nie ma możliwości różnej interpretacji zawartych w nich wymagań?
- Zgodności z regułami dokumentacji: Czy zostały spełnione wszystkie wcześniej określone reguły i wytyczne dotyczące dokumentacji? Czy na przykład prawidłowo został użyty język modelowania?
Zignorowanie wytycznych dotyczących tworzenia dokumentacji może m.in. doprowadzić do:
- Nieprzydatności dokumentów wymagań dla kolejnych etapów tworzenia oprogramowania
- Niezrozumienia wymagań
- Niekompletności wymagań
- Przeoczenia wymagań, które zostały zdefiniowane w miejscu innym niż przewidywała struktura dokumentu
Reasumując dbanie o jakość wymagań opłaca się wszystkim interesariuszom. W kolejnych postach napiszę o zasadach i technikach walidacji wymagań.
Tekst zainspirowany książką: Klaus Pohl, Chris Rupp „Requirements engineering fundamentals : a study guide for the Certified Professional for Requirements Engineering exam : foundation level”, IREB compliant Wydawnictwo: Rocky Nook Inc, 2011
