Zasady walidacji wymagań

Walidacja wymagań wymaga kilku czynników. Dziś przedstawię kilka zasad.

Zaangażowanie odpowiednich interesariuszy

Podczas wyboru interesariuszy do walidacji wymagań należy mieć na uwadze, aby wymagania nie były walidowane jedynie przez ich autorów. Można także rozważyć zatrudnienia do walidacji wymagań zewnętrznych audytorów, przy czym należy mieć na uwadze, że zatrudnienie zewnętrznych audytorów znacząco może podnieść koszty inżynierii wymagań. W związku z tym należy rozważać tą opcję w przypadku wymagań krytycznych i wymagają wysokiego poziomu jakości.

Oddzielenie identyfikacji i korekty błędów

Podczas walidacji wymagań należy oddzielić proces identyfikacji błędów oraz ich naprawiania. Każda zidentyfikowana nieprawidłowość przed przekazaniem do naprawy powinna zostać dwukrotnie sprawdzona, pod kątem czy na pewno dotyczy błędu. W ten sposób można zidentyfikować nieprawidłowości które nie wymagają naprawy, a która to naprawa mogłaby spowodować pow stanie nowych błędów.

Walidacja z różnych perspektyw

Praktyka ta wymaga aby walidacja wymagań była przeprowadzana przez ludzi reprezentujących różne grupy interesariuszy (np. kierownictwo, przyszłych użytkowników, testerów).

Odpowiednia zmiana typu dokumentacji

Podczas czytania dokumentów wymagań należy analizować różne typy dokumentacji. Np. analiza opisu wymagania w formie modelu koncepcyjnego pozwala na zidentyfikowanie niejednoznaczności spowodowanej opisem w języki naturalnym.

Konstruowanie artefaktów

Konstruowanie artefaktów późniejszych faz cyklu życia oprogramowania pozwala na określenie przydatności wymagań w tych fazach. Np. audytor podczas walidacji wymagań tworzy na podstawie tych wymagań przypadki testowe, co pozwala mu na identyfikację błędów, np. dotyczących niejednoznaczności.

Powtórna walidacja

Walidacja wymagań odbywa się w określonym czasie w trakcie życia projektu i polega na wiedzy interesariuszy jaką posiadają w tym czasie. W trakcie życia projektu wiedza interesariuszy na temat tworzonego systemu wzrasta. Wymagania, które zostały zaakceptowane przez interesariuszy w określonym punkcie życia projektu mogą nie być przez nich akceptowane, kiedy ich wiedza na temat tworzonego systemu wzrośnie. Aby zapewnić aktualność walidacji wymagań należy ją przeprowadzać kilka razy w trakcie życia projektu.

W kolejnym poście napiszę o techniki 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

Podobne wpisy
Zarządzanie relacjami pomiędzy wymaganiami

Zarządzanie wymaganiami to ważny element procesu wytwórczego oprogramowania. Jednym z jego elementów budowanie i zarządzanie relacjami pomiędzy wymaganiami. Najczęściej spotykanym więcej

Architektura procesów biznesowych a modelowanie procesów biznesowych – poziomy modelowania

W poprzednim wpisie Modelowanie procesów biznesowych w procesie wytwórczym oprogramowania opisałem znaczenie modelowania procesów biznesowych. W moim odczuciu, modelowanie procesów biznesowych więcej

Wymagania są najważniejsze

Podczas mojej pracy zauważyłem, że spory problem stanowią wymagania. Trudnością nie jest ich spisanie. Trudnością jest ich wyartykułowanie. Pomijam turbulencje związane więcej

Plan zarządzania wymaganiami

Plan zarządzania wymaganiami to dokument, który opisuje zasady postępowania z wymaganiami. W moim odczuciu to jeden z najważniejszych dokumentów, gdyż więcej

Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *

Przewiń do góry