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ń.
Definicja: Kontekst systemu
Kontekst systemu jest częścią środowiska systemu, która jest istotna ze względu na definiowanie i zrozumienie wymagań dla tworzonego systemu.
Wybrane aspekty rzeczywistości, które mogą wpływać na określenie kontekstu systemu to przykładowo:
- Ludzie (interesariusze i grupy interesariuszy)
- Systemy współpracujące (inne oprogramowanie lub sprzęt)
- Procesy (procesy technologiczne lub biznesowe)
- Zdarzenia (techniczne lub fizyczne)
- Dokumenty (np. normy prawne, standardy, dokumentacja systemowa)
Prawidłowe określenie kontekstu systemu wymaga odseparowania kontekstu systemu od samego systemu oraz części rzeczywistości, która jest nieistotna dla tworzonego systemu. Definiowanie granic systemu polega na podjęciu decyzji, które aspekty będą implementowane w systemie, a które należą tylko do jego kontekstu.
Definiowanie granic kontekstu systemu polega na podjęciu decyzji, które aspekty dotyczą kontekstu tworzonego systemu (np. mają wpływ na tworzone oprogramowanie), a które są częścią środowiska nieistotnego dla tworzonego oprogramowania.
Definicja: Granica systemu
Granica systemu odseparowuje tworzony system od jego środowiska, np. odseparowuje część rzeczywistości, która może być modyfikowana w trakcie procesu wytwórczego od aspektów środowiska, które nie mogą być zmieniane w tym procesie. Zazwyczaj granica systemu nie jest jednoznacznie określona, aż do zakończenia procesu inżynierii wymagań. Ze względu na to, że na początku procesu inżynierii wymagań nie do końca są określone funkcje tworzonego systemu, granica ta może ulegać zmianie w czasie.
Na przykład na początku procesu inżynierii wymagań może nie być określone czy dana funkcjonalność zostanie zaimplementowana w systemie, czy np. będzie wykorzystywała inne zewnętrzne oprogramowanie. Podczas definiowania granicy systemu należy rozważyć przez jakie interfejsy tworzony system będzie się komunikował z jego otoczeniem.
Należy rozważyć kto (co) będzie dostarczał informacji do systemu oraz kto (co) będzie odbierał informacje z systemu.
Potencjalnymi dostawcami i odbiorcami informacji do/z systemu będą:
- Interesariusze (lub grupy interesariuszy)
- Istniejące systemy
Poprzez interfejsy system będzie dostarczał funkcjonalność do jego otoczenia, monitorował środowisko, w którym pracuje, wpływał na parametry tego środowiska oraz kontrolował operacje wykonywane w tym środowisku.
Definicja: Granica kontekstu systemu
Granica kontekstu systemu odseparowuje istotne części otoczenia tworzonego systemu od części nieistotnych, np. części, które nie będą miały wpływu na tworzony system i w związku z tym nie muszą być brane pod uwagę podczas procesu inżynierii wymagań.
Zazwyczaj granica kontekstu systemu (podobnie jak granica systemu) nie jest jednoznacznie określona na początku procesu inżynierii wymagań i ulega zmianie w trakcie tego procesu.
Podczas dokumentowania kontekstu systemu (w szczególności granic systemu i jego otoczenia) można skorzystać z:
- Diagramów przypadków użycia
- Diagramów przepływu danych
- Diagramów klas
Po zdefiniowaniu kontekstu i granic systemu przychodzi kolej na omówienie sposobu pozyskania wymagań. Opiszę to w kolejnym tekście.
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
