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

  • 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 jest […]
  • 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 […]
  • 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 z celem zamiany czy […]
  • 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ż w jawny sposób opisuje szereg ważnych […]
  • Wymagania – Zarządzanie wersjami Zmiany w wymaganiach wymaga ich wersjonowania.Wersje wymagań pomagają uzyskać dostęp do określonego stanu wymagania w trakcie życia oprogramowania. Najczęściej wersje wymagań określane są […]
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