Akwizycja wymagań

Akwizycja wymagań może być określona jako rdzeń inżynierii wymagań.

Akwizycja wymagań polega na pozyskiwaniu wymagań z dostępnych źródeł (np. interesariuszy) za pomocą różnych technik (np. burza mózgów). Podstawą dla akwizycji wymagań jest wiedza zdobyta w trakcie definiowania kontekstu dla tworzonego systemu, który obejmuje źródła wymagań, które w procesie akwizycji wymagań będą dalej analizowane i badane.

Trzy podstawowe źródła wymagań:

  • Interesariusze – ludzie lub organizacje, które mają bezpośredni lub pośredni wpływ na wymagania stawiane przed systemem (np. użytkownicy systemu, deweloperzy, testerzy)
  • Dokumenty – normy prawne, standardy, dokumenty opisujące domenę problemu lub organizację, dokumentacja i raporty błędów dla istniejących systemów, itp., które mogą zapewnić ważne informacje na temat wymagań
  • Pracujące systemy – systemy istniejące lub wymienione, a także systemy konkurencyjne, których interesariusze używali i na podstawie swoich doświadczeń mogą wskazać braki tych systemów oraz propozycję ich zmiany oraz rozszerzenia

Interesariusze są głównym źródłem wymagań dla tworzonego systemu. Wymagania zidentyfikowane z innych źródeł (dostępnych dokumentów oraz działających systemów) muszą zostać uzgodnione z interesariuszami. Nieuwzględnienie wszystkich interesariuszy (lub grup interesariuszy) może doprowadzić do pominięcia ważnych z punktu widzenia projektu wymagań, które zostaną zidentyfikowane dopiero po wdrożeniu tworzonego systemu. Powodzenie procesu akwizycji wymagań w głównym stopniu zależy od prawidłowego zidentyfikowania interesariuszy oraz odpowiedniego ich zmotywowania do aktywnego udziału w tym procesie.

Przy dużych projektach lista interesariuszy może być bardzo duża. Ze względu na ograniczenia zasobów (czasu, liczby inżynierów wymagań) należy zwrócić szczególną uwagę na dobór właściwych interesariuszy. Dobrym rozwiązaniem jest udokumentowanie interesariuszy za pomocą tabeli, która będzie zawierała przynajmniej następujące informacje:

  • nazwę,
  • pełnioną funkcję lub rolę,
  • dodatkowe informacje personalne oraz kontaktowe,
  • czasowa oraz przestrzenna dostępność w trakcie realizacji projektu,
  • znaczenie interesariusza, obszar oraz poziom jego doświadczenia,
  • cele oraz zainteresowania dotyczące realizowanego projektu.

Częstym problemem inżynierii wymagań, jest pasywna postawa interesariuszy w trakcie realizacji projektu. Brak motywacji do współpracy może wynikać z obawy przed zmianami, złymi doświadczeniami z poprzednich projektów lub ich satysfakcją z już istniejących systemów.

Zadaniem inżyniera wymagań jest współpraca z menadżerem projektu w celu przekonania wszystkich interesariuszy do korzyści płynących z realizacji projektu. W tym celu należy określić zakres obowiązków i odpowiedzialności interesariuszy, a także ich indywidualne cele, ścieżki komunikacji oraz sposoby zgłaszania uwag.

Obowiązki inżyniera wymagań to:

  • Używanie języka zrozumiałego dla interesariuszy
  • Dokładne zapoznanie się z dziedziną problemu
  • Tworzenie dokumentacji wymagań
  • Opracowywanie wyników pracy (np. diagramy)
  • Utrzymywanie dobrych relacji z każdym z interesariuszy
  • Prezentowanie swoich idei oraz ich alternatyw, wraz ze sposobem ich realizacji
  • Umożliwienie interesariuszom określania właściwości tworzonego systemu, aby ten był przyjazny użytkownikowi
  • Zapewnienie spełnienia przez system wymagań funkcjonalnych i jakościowych określonych przez interesariuszy

Natomiast obowiązki interesariuszy to:

  • Zapoznanie inżynierów wymagań z dziedziną problemu
  • Dostarczenie wymagań inżynierowi wymagań
  • Wytrwałe(gorliwe) dokumentowanie wymagań
  • Podejmowanie terminowych decyzji
  • Respektowanie nałożonych na projekt ograniczeń
  • Priorytetyzacja wymagań
  • Nadzór nad dokumentowanymi przez inżyniera wymaganiami
  • Natychmiastowe komunikowanie zmian w wymaganiach
  • Przestrzeganie zdefiniowanego procesu zgłaszania zmian
  • Przestrzeganie założonego przebiegu procesu inżynierii wymagań

Realizacja powyższych obowiązków jest jednym z czynników pomocnych w akwizycji 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
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