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

  • Statusy i priorytety wymagań Często otrzymuję pytanie jak opisuję wymagania. Otóż wielu projektach określam statusy i wymagania w następujący sposób:Status• Proponowane - wymaganie w fazie negocjacji pomiędzy klientem […]
  • Rejestracja problemów zidentyfikowanych podczas analizy Otrzymałem mailem ciekawe pytanie: Czy wg Pana wiedzy istnieje w EA obiekt, który najbardziej nadawałby się do rejestracji problemów zidentyfikowanych podczas analizy (AS-IS) biznesowej […]
  • Niezależny konsultant–nowy blog Nic mnie tak nie cieszy jak odkrycie, że na polskiej blogosferze pojawia się nowy blog o inżynierii oprogramowania. Tym razem takim odkryciem jest blog, który pani Ewa Wardzała. Pod dość […]
  • Cechy perfekcyjnych wymagań na system Jakość opisu wymagań jest bardzo ważna i tego nie muszę nikomu tłumaczyć. Standard  ANSI/IEEE 830  formułuje  szereg  zaleceń,  jakie  powinna  spełniać dobrze napisana specyfikacja […]
  • Kartezjusz a projektowanie systemów Ostatnio natknąłem się na prace Kartezjusza* “Rozprawa  metodzie”. Czytając to dzieło w rozdziale w części drugiej przeczytałem opis metody, którą niemalże bez zmian stosuje się dziś […]
Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Przewiń do góry