Category Archives zarządzanie wymaganiami

Dokumenty wymagań zawierają dużą ilość różnych informacji. Aby umożliwić sprawne posługiwanie się tym dokumentem powinien on spełniać pewne standardy dotyczące jego układu oraz treści. W trakcie tworzenia dokumentu wymagań inżynierowie powinni określić i stosować określoną strukturę dokumentu. Struktura ta powinna być dopasowana do właściwości danego projektu i przestrzegać ograniczeń na niego nałożonych. Inżynierowie wymagań podczas tworzenia specyfikacji wymagań mogą skorzystać ze standaryzowanych struktur dokumentów lub zdefiniować własną strukturę, która będzie dopasowana do specyficznych wymagań projektu i interesariuszy.

Pozyskane wymagania należy opisać w dokumencie wymagań. Niniejszy post rozpoczyna cykl wpisów dotyczących dokumentacji wymagań. 

Definicja: Dokument wymagań / Specyfikacja wymagań
Specyfikacja wymagań jest usystematyzowaną reprezentacją zbioru wymagań dotyczących systemu lub jego komponentu, który spełnia określone kryteria.

Wymagania mają znaczenie kontraktowe. Wszystkie informacje zebrane i uzgodnione podczas podejmowanych czynności w ramach inżynierii wymagań muszą zostać udokumentowane. Każdy typ wymagania wpływa pośrednio lub bezpośrednio na wszystkie fazy życia oprogramowania. Jakość dokumentu wymagań, jak i samych wymagań, ma kluczowe znaczenie na przebieg realizowanego projektu i decyduje o jego sukcesie.

Określenie wymagań, które będą podnosiły satysfakcję interesariuszy z tworzonego systemu jest kluczowe dla procesu akwizycji wymagań. Zaimplementowanie zbyt dużej liczby funkcjonalności oraz „wodotrysków” spowoduje, że aplikacja stanie się mało intuicyjna i trudniejsza w użytkowaniu.

W trakcie procesu akwizycji wymagań należy wybrać te wymagania, które będą kluczowe dla osiągnięcia satysfakcji interesariuszy. Do określenia jaki wpływ na zadowolenie interesariuszy będzie miało zaimplementowanie danej funkcjonalności warto jest zastosować model Kano.

Zgodnie z założeniami modelu Kano wymagania mogą zostać podzielone na trzy kategorie decydujące o satysfakcji klienta:

  • Wymagania podstawowe
  • Wymagania pożądane
  • Wymagania powodujące ekscytację

Zastosowanie szablonów wymagań zapewnia proste i zrozumiałe podejście do dokumentowania wymagań w języku naturalny redukując niepożądane skutki jego użycia.  Szablony wymagań wspierają interesariuszy w pozyskiwaniu wymagań wysokiej jakości i syntetycznie jednoznacznych w optymalnym czasie i przy niskim nakładzie kosztów.

Definicja: Szablon wymagań

Szablon wymagań jest wzorcem dla struktury składniowej indywidualnych wymagań.

Wykorzystanie języka naturalnego jest najbardziej popularnym sposobem dokumentowania wymagań. Jego największą zaletą jest brak potrzeby poświęcenia czasu przez interesariuszy na poznanie nowych notacji wykorzystywanych w przypadku modelów konceptualnych (np. UML) oraz możliwość opisu rzeczywistości, która może być trudna do przedstawienia za pomocą innych notacji.

Stosowanie języka naturalnego ma niestety także wiele wad. Wymagania są definiowane i analizowane przez ludzi, którzy posiadają zróżnicowany poziom wiedzy, różne uwarunkowania społecznościowe oraz doświadczenie. Te czynniki wpływają na częste niezrozumienie lub różną interpretację wymagań tworzonych przy użyciu języka naturalnego.

Różna percepcja oraz reprezentacja informacji przez ludzi zaangażowanych w projekt wynika z tak zwanego „efektu transformacji”.

Pięć procesów transformacyjnych, które są najbardziej istotne dla inżynierii wymagań:

  • Nominalizacja
  • Rzeczowniki bez indeksu referencyjnego
  • Uniwersalne kwantyfikatory
  • Niekompletnie określone warunki
  • Niekompletnie określone czasowniki

W poprzednim poście pisałem o technikach akwizycji wymagań. Dziś cześć druga – kontynuacja poprzedniego wpisu.

Techniki zmiany perspektywy polegają na sprowokowaniu uczestników warsztatów do spojrzenia na problem z innej perspektywy. Najpopularniejszą techniką wykorzystującą zmianę perspektywy jest technika zwana Sześć Myślowych Kapeluszy.

Technika Sześć Myślowych Kapeluszy polega na przyjmowaniu przez uczestników kolejnych punktów widzenia problemu reprezentowanych przez poszczególne kapelusze. Zaletą stosowania tej techniki jest możliwość przekonania do jakiegoś rozwiązania osób, które były uparcie przekonane do proponowanej przez siebie idei. Jednak technika ta będzie bardzo pracochłonna w przypadku akwizycji wymagań na wysokim poziomie szczegółowości.

Techniki akwizycji wymagań mają na celu wspieranie inżynierów wymagań w procesie akwizycji, aby mogli dostarczyć jak najbardziej kompletne i zrozumiałe wymagania. Wybór odpowiedniej techniki zależy od wielu czynników, które muszą zostać uwzględnione przez inżyniera wymagań podczas procesu akwizycji.

W praktyce w trakcie akwizycji wymagań stosuje się różne techniki, aby ograniczyć ryzyko pominięcia lub złego zinterpretowania wymagań. Każda z technik ma swoje słabe i mocne strony. Słabe strony jednej techniki mogą być zrównoważone przez inną technikę.

Czynniki wpływające na wybór technik akwizycji wymagań:

  • Rodzaj pozyskiwanych wymagań (podstawowe, pożądane, powodujące ekscytację)
  • Ograniczenia czasowe i budżetowe, a także ograniczenia dostępności interesariuszy
  • Doświadczenie inżyniera wymagań dotyczących wykorzystania określonej techniki
  • Szanse i zagrożenia dla projektu

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…

Do głównych zadań inżynierii wymagań należy m.in. akwizycja i dokumentacja wymagań na system. Aby tego dokonać należy zidentyfikować te części świata rzeczywistego, które będą miały wpływ na wymagania dotyczące systemu.

Ta część rzeczywistości, która ma wpływ na definiowanie wymagań systemu nazywa się kontekstem systemu.

Nieprawidłowe lub niepełne określenie kontekstu systemu podczas inżynierii wymagań prowadzi do niekompletnych lub błędnie zdefiniowanych wymagań.

W poprzednim wpisie określiłem kilka definicji, którymi będę się posługiwał w cyklu tekstów o inżynierii wymagań. Czas podział wymagań.

Wymagania dzielę na wymagania funkcjonalne i wymagania niefunkcjonalne (zwane także wymaganiami jakościowymi). Ponadto identyfikuję ograniczenia.

Wymagania funkcjonalne określają funkcjonalność tworzonego oprogramowania.

Wymagania funkcjonalne mogą być podzielone na wymagania funkcjonalne, wymagania dotyczące zachowania systemu oraz wymagania dotyczące danych.

Wymagania niefunkcjonalne określają pożądane cechy tworzonego systemu i często mają bardziej znaczący wpływ na wybór architektury dla tworzonego systemu niż wymagania funkcjonalne. Wymagania jakościowe dotyczą min. wydajności, dostępności, niezawodności, skalowalności i przenośności.

Ograniczenia dotyczą bezpośrednio tworzonego systemu (np. System musi być zaimplementowany jako usługa WEB) lub procesu produkcyjnego (np. System musi być dostarczony do końca roku 2013).

Ograniczenia w przeciwieństwie do wymagań funkcjonalnych i jakościowych nie są implementowane w systemie, a dotyczą przestrzegania limitów rozwiązań i zasobów w procesie produkcyjnym oprogramowania.

Close