Wprowadzenie do zarządzania wymaganiami–podstawowe definicje

Wpisy na temat inżynierii wymagań zacznę od podstawowych definicji.

Definicja: Wymaganie

1.Ograniczenie lub zdolność potrzebna użytkownikowi do rozwiązania problemu lub osiągnięcia określonego celu.

2.Ograniczenie lub zdolność, które musi być spełnione lub zrealizowane przez system lub składnik systemu w celu spełnienia warunków umowy, standardu, specyfikacji lub innych formalnych dokumentów.

3.Udokumentowana reprezentacja ograniczeń i zdolności określonych w punkcie 1 i 2.

Definicja: Interesariusz

Interesariusz systemu to osoba lub organizacja, która posiada (bezpośredni lub pośredni) wpływ na wymagania stawiane przed systemem.

Termin Interesariusz ma zasadnicze znaczenie dla inżynierii wymagań. Interesariusze są najważniejszym źródłem pozyskiwania wymagań.

Pominięcie jednego z interesariuszy jest zazwyczaj przyczyną niekompletnych wymagań.

Interesariuszami mogą być:

  • Osoby, które mają bezpośredni kontakt z systemem (np. użytkownicy, administratorzy)
  • Osoby, które są zainteresowane wykorzystaniem systemu, ale nie mają z nim bezpośredniego kontaktu (np. zarząd, haker, przed którym system ma być zabezpieczony)
  • Osoby prawne, instytucje itp., które mogą wpływać lub określać wymagania stawiane przed systemem (np. ustawodawca)

Definicja: Inżynieria wymagań

Inżynieria wymagań to systematyczne i zdyscyplinowane podejście do specyfikacji i zarządzania wymaganiami, które ma na celu:

1.Określenie odpowiednich wymagań, osiągnięcie konsensusu dotyczącego tych wymagań pomiędzy interesariuszami, udokumentowanie wymagań zgodnie z przyjętymi standardami oraz ich systematyczne zarządzanie

2.Zrozumienie i udokumentowanie wymagań i potrzeb interesariuszy oraz specyfikacja i zarządzanie wymaganiami aby zminimalizować ryzyko dostarczenia systemu, który nie będzie spełniał tych wymagań i potrzeb

Cztery podstawowe działania inżynierii wymagań to

Akwizycja: Podczas akwizycji wymagań stosowane są różne techniki służące do pozyskiwania wymagań od interesariuszy, a także innych źródeł oraz ich uszczegółowiania.  

Dokumentacja: Pozyskane wymagania muszą zostać w odpowiedni sposób udokumentowane. Podczas dokumentacji wymagań wykorzystywany jest język naturalny lub modele konceptualne.  

Walidacja i negocjacja: Aby zapewnić, że predefiniowane kryteria jakościowe zostaną spełnione, udokumentowane wymagania muszę być wynegocjowane i zatwierdzone.

Zarządzanie: Zarządzanie wymaganiami jest ortogonalne do poprzednich działań i obejmuje wszelkie środki potrzebne do:

  • strukturalizacji wymagań
  • przygotowania ich tak, aby mogły być wykorzystywane przez różne role w projekcie
  • zachowania ich spójności po zmianach
  • sprawdzenia ich implementacji w systemie

W kontekście definicji warto wprowadzić (obok analityka, projektanta, testera i programisty) rolę inżyniera wymagań. Inżynier wymagań powinien mieć takie cechy jak: 

  • Umiejętność analitycznego myślenia
  • Empatia
  • Umiejętności komunikacyjne
  • Umiejętności rozwiązywania problemów
  • Umiejętności moderatora
  • Pewność siebie
  • Umiejętność perswazji

Inżynier wymagań odpowiada za obszar inżynierii oprogramowania zwany: zarządzanie wymaganiami Uśmiech

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
Przypadki użycia są łatwiejsze do zrozumienia niż diagramy BPMN

Jakiś czas temu napotkałem ciekawe wyniki badań, które zostały opracowane w Polsce. Instytut Informatyki Politechniki Poznańskiej wykonał badania, w których  więcej

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

Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Scroll to Top