Inżynieria wymagań

Inżynieria wymagań ( RE ) to proces definiowania, dokumentowania i utrzymywania wymagań w procesie projektowania inżynierskiego . Jest to powszechna rola w inżynierii systemów i inżynierii oprogramowania .

Pierwsze użycie terminu inżynieria wymagań miało miejsce prawdopodobnie w 1964 roku w artykule konferencyjnym „Maintenance, Maintenanceability, and System Requirements Engineering”, ale wszedł on do powszechnego użytku dopiero pod koniec lat 90. XX wieku wraz z publikacją samouczka IEEE Computer Society w marcu 1997 i ustanowienie serii konferencji poświęconych inżynierii wymagań, która przekształciła się w Międzynarodową Konferencję Inżynierii Wymagań .

W modelu kaskadowym inżynieria wymagań jest przedstawiona jako pierwsza faza procesu rozwoju. Późniejsze metody rozwoju, w tym Rational Unified Process (RUP) dla oprogramowania, zakładają, że inżynieria wymagań trwa przez cały okres życia systemu.

Zarządzanie wymaganiami , które jest funkcją podrzędną praktyk inżynierii systemów, jest również indeksowane w podręcznikach Międzynarodowej Rady Inżynierii Systemów (INCOSE).

Zajęcia

Czynności związane z inżynierią wymagań różnią się znacznie w zależności od typu opracowywanego systemu i konkretnych praktyk organizacji. Mogą to być:

  1. Inicjowanie wymagań lub pozyskiwanie wymagań — spotykają się programiści i interesariusze; ci ostatni są pytani o ich potrzeby i pragnienia dotyczące oprogramowania.
  2. Analiza wymagań i negocjacje – Wymagania są identyfikowane (w tym nowe, jeśli rozwój jest iteracyjny) i rozwiązywane są konflikty z interesariuszami. Zarówno narzędzia pisane, jak i graficzne (te ostatnie są powszechnie stosowane w fazie projektowania, ale niektórzy uważają je za pomocne także na tym etapie) są z powodzeniem wykorzystywane jako pomoce. Przykłady pisemnych narzędzi analitycznych: przypadki użycia i historie użytkowników . Przykłady narzędzi graficznych: UML i LML .
  3. Modelowanie systemu — niektóre dziedziny inżynierii (lub określone sytuacje) wymagają całkowitego zaprojektowania i wymodelowania produktu przed rozpoczęciem jego budowy lub produkcji. Dlatego faza projektowania musi być wykonana z wyprzedzeniem. Na przykład plany budynku muszą zostać opracowane przed zatwierdzeniem i podpisaniem jakiejkolwiek umowy. Wiele pól może uzyskiwać modele systemu za pomocą języka modelowania cyklu życia , podczas gdy inne mogą używać języka UML . Uwaga: W wielu dziedzinach, takich jak inżynieria oprogramowania, większość działań związanych z modelowaniem jest klasyfikowana jako działania projektowe, a nie jako działania związane z inżynierią wymagań.
  4. Specyfikacja wymagań — wymagania są udokumentowane w formalnym artefaktie zwanym specyfikacją wymagań (RS), która stanie się oficjalna dopiero po walidacji. W razie potrzeby RS może zawierać zarówno informacje pisemne, jak i graficzne (modele). Przykład: Specyfikacja wymagań oprogramowania (SRS).
  5. Walidacja wymagań – Sprawdzenie, czy udokumentowane wymagania i modele są spójne i spełniają potrzeby interesariuszy. Tylko wtedy, gdy ostateczny projekt przejdzie proces walidacji, RS staje się oficjalny.
  6. Zarządzanie wymaganiami – Zarządzanie wszystkimi działaniami związanymi z wymaganiami od momentu powstania, nadzór nad rozwojem systemu, a nawet po oddaniu do użytku (np. zmiany, rozszerzenia itp.)

Są one czasami przedstawiane jako etapy chronologiczne, chociaż w praktyce te działania są w znacznym stopniu przeplatane.

Wykazano, że inżynieria wymagań wyraźnie przyczynia się do sukcesów projektów oprogramowania.

Problemy

W jednym ograniczonym badaniu przeprowadzonym w Niemczech przedstawiono możliwe problemy we wdrażaniu inżynierii wymagań i zapytano respondentów, czy zgadzają się, że są to rzeczywiste problemy. Wyniki nie zostały przedstawione jako dające się uogólnić, ale sugerowały, że głównymi dostrzeganymi problemami były niekompletne wymagania, przesuwające się cele i ograniczenia czasowe, przy czym mniejsze problemy to błędy w komunikacji, brak identyfikowalności, problemy terminologiczne i niejasne obowiązki.

Krytyka

Spekuluje się, że struktura problemu, kluczowy aspekt inżynierii wymagań, zmniejsza wydajność projektu. Niektóre badania sugerują, że jest możliwe, że w przypadku braków w procesie inżynierii wymagań skutkujących sytuacją, w której wymagania nie istnieją, wymagania oprogramowania mogą być tworzone niezależnie jako iluzja fałszywie przedstawiająca decyzje projektowe jako wymagania

Zobacz też

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Requirements_engineering&oldid=1140886096 ”