Dokumentacja wymagań

Pozyskane wymagania należy opisać w dokumencie wymagań. Niniejszy post rozpoczyna cykl wpisów dotyczących dokumentacji wymagań. 

Definicja: Dokument wymagań / Specyfikacja wymagań
Specyfikacja wymagań jest usystematyzowaną reprezentacją zbioru wymagań dotyczących systemu lub jego komponentu, który spełnia określone kryteria.

Wymagania mają znaczenie kontraktowe. Wszystkie informacje zebrane i uzgodnione podczas podejmowanych czynności w ramach inżynierii wymagań muszą zostać udokumentowane. Każdy typ wymagania wpływa pośrednio lub bezpośrednio na wszystkie fazy życia oprogramowania. Jakość dokumentu wymagań, jak i samych wymagań, ma kluczowe znaczenie na przebieg realizowanego projektu i decyduje o jego sukcesie.

Wymagania są podstawą dla tworzonego systemu. Z tego też powodu dokument wymagań reprezentuje umowę pomiędzy klientem a zleceniobiorcą. Klient ma prawo wymagać realizacji uzgodnionych wymagań. W przypadku braku porozumienia podczas odbioru stworzonego systemu dokument wymagań stanowi podstawę do rozstrzygania sporów.

Dokumentacja wymagań jest złożona. Systemy, które posiadają tysiące wymagań, które z kolei mają wiele powiązań pomiędzy sobą, są często spotykane w praktyce. Bez odpowiedniej dokumentacji zarządzanie wymaganiami byłoby bardzo trudne.

Wymagania muszą być dostępne dla wszystkich zainteresowanych stron. Jeżeli wymagania są stale dostępne to zainteresowane strony mogą na bieżąco wyjaśniać swoje niejasności związane z wymaganiami, a nowi pracownicy, którzy dołączyli do projektu mogą się w szybki sposób się z nimi zapoznać.

Dokumentacja wymagań może być rozpatrywana z trzech różnych perspektyw:

  • Perspektywy danych
  • Perspektywy funkcjonalności
  • Perspektywy zachowania

Do opisu każdej z wyżej wymienionej perspektywy inżynier wymagań może wykorzystać język naturalny oraz modele konceptualne.

Perspektywa danych

W przypadku pespektywy danych wymagania są przedstawiane ze strukturalnego punktu widzenia. W perspektywie tej przedstawiane są np. struktury danych wejściowych i wyjściowych dla tworzonego systemu, a także relacje pomiędzy tymi danymi.

Perspektywa funkcjonalności

Perspektywa funkcjonalności dokumentuje jakie informacje są odbierane, przetwarzane i zwracane przez system lub jego funkcje oraz kolejność wywoływanych funkcji przetwarzających te informacje.

Perspektywa zachowania

Perspektywa zachowania systemu koncentruje się na dokumentowaniu reakcji systemu na zdarzenia występujące w jego kontekście, warunków, które powodują zmianę stanu systemu lub jego elementów oraz wyników, jakie system powinien zapewnić do jego otoczenia.

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
Jesienny The Rational Edge ezine

Właśnie ukazał się jesienny The Rational Edge ezine (http://ibm.com/developerworks/ecma/campaign/er.jsp?id=376126&imid=68950291&end). Dla fanów RSA jest bardzo ciekawy artykuł, w którym Steve Arnold więcej

Podstawowe dobre praktyki inżynierii wymagań

Poniżej opisane wskazówki to podstawowe dobre praktyki opracowane przez Ian Sommerville i Pete Sawyer. Więcej na ten temat możesz przeczytać więcej

Średniozaawansowane dobre praktyki inżynierii wymagań

Poniżej opisane wskazówki to średniozaawansowane dobre praktyki opracowane przez Ian Sommerville i Pete Sawyer. Więcej na ten temat możesz przeczytać więcej

Zaawansowane dobre praktyki inżynierii wymagań

Poniżej opisane wskazówki to zaawansowane dobre praktyki opracowane przez Ian Sommerville i Pete Sawyer. Więcej na ten temat możesz przeczytać więcej

Reklama
MODESTO - licencje Enterprise Architect
Scroll to Top