Das Gelbe vom Ei im Requirements Engineering
Ich bin nun schon seit über einem Jahr Certified Professional for Requirements Engineering (FL). In nur drei Tagen habe ich die Basics des Anforderungsmanagements erlernt. Und an was erinnere ich mich am meisten? An das Spiegelei, das uns am ersten Tag serviert wurde.
System und Systemkontext
Das Spiegelei eignet sich perfekt dazu, die wichtige Abgrenzung von System und Systemkontext darzustellen.
Warum ist diese Abgrenzung so wichtig und weshalb sollte man Sie schon am Anfang des Requirements Engineering Prozesses vornehmen?
Ganz einfach, um sich klar zu machen, was eigentlich alles zum System gehören soll, was das System beeinflusst bzw. womit es interagieren wird und natürlich auch, was gar nicht berücksichtigt werden muss. Nur wenn man das geklärt hat, kann man richtig anfangen, Stakeholder zu befragen und Anforderungen zu ermitteln. Man könnte auch sagen, man bestimmt damit den Scope der Entwicklung. Manche Grenzen können zwar erst nach der Befragung von Stakeholdern gezogen werden, aber grundsätzlich sollte sich der Requirements Engineer schon zu Beginn eines neuen Projekts ein solches Spiegelei skizzieren. Denn aus Rührei lässt sich bekanntlich kein Spiegelei mehr herstellen. Oft ist gerade die Festlegung der Systemgrenze ein Hauptaspekt bei der Anforderungserhebung. Im Lehrbuch[1] zum CPRE (FL) ist die Systemgrenze so definiert:
Die Systemgrenze separiert das geplante System von seiner Umgebung. Sie grenzt den im Rahmen des Entwicklungsprozesses gestaltbaren und veränderbaren Teil der Realität von Aspekten in der Umgebung ab, die durch den Entwicklungsprozess nicht verändert werden können.
Die genaue Analyse des Systemkontexts soll helfen, fatale Fehler zu vermeiden. Wenn beispielsweise gesetzliche Vorschriften im Systemkontext vergessen werden, die erst nach Inbetriebnahme des Systems auffallen, kann das im schlimmsten Fall eine Entwicklung wieder zurück auf null setzen.
Der Requirements Engineer hat deshalb die Aufgabe, sämtliche Aspekte im Systemkontext zu entdecken. Dazu gehören:
- Personen (Stakeholder oder Stakeholdergruppen)
- Systeme im Betrieb (andere technische Systeme oder Hardware)
- Prozesse (technisch oder physikalisch, Geschäftsprozesse)
- Ereignisse (technisch oder physikalisch)
- Dokumente (z.B. Gesetze, Standards, Systemdokumentationen)
Die Bestimmung der System- und der Kontextgrenze ist nicht immer final. Änderungen können im Verlauf der Entwicklung auch eine Verschiebung dieser Grenzen verursachen. Für die Auswirkungen, die das haben kann, ist dann wieder der Requirements Engineer zuständig.
Systemkontextdiagramm
Gut, wenn man diese Zusammenhänge solide dokumentiert hat. Dazu kann man Use Cases oder Datenflussdiagramme nutzen oder ein Systemkontextdiagramm in objectiF RM. Hier sehen Sie ein Beispiel für ein mobiles Patienteninformationssystem, das von Personen bedient wird, Normen einhalten muss und mit anderen Endgeräten Daten austauschen soll. 
Die Beziehungen und Abhängigkeiten der Kontextelemente sind hier übersichtlich erfasst. So lassen sich Änderungen und deren Auswirkungen viel leichter logisch durchdenken.
Gebrauchte Kommandos von nicht gebrauchten trennen
Mit objectiF RM haben wir eine Software geschaffen, die Requirements Engineers beim Ermitteln, Dokumentieren, Modellieren, Strukturieren, Nachvollziehen und Prüfen von Anforderungen perfekt unterstützen kann. Die Vielzahl der Werkzeuge, die das Tool bietet, hat dazu geführt, dass einige Kontextmenüs ganz schön in die Länge gewachsen sind. Nicht jeder Anwender braucht all diese Commands. Wie bei der Kontextabgrenzung im RE ist es hier auch angebracht, Ihnen eine Abgrenzung zu ermöglichen. Deshalb haben wir die Anpassbarkeit an dieser Stelle verbessert. Sie können sich einfach mit ein paar Klicks die Kontextmenüs von Abfragen (z.B. Stakeholderlisten, Anforderungen, Use Cases, Risiken, Bugs etc.) passend konfigurieren.
Bei Rechtsklick auf ein Listenelement der Abfrage Anforderungsliste klappt ein Kontextmenü aus, von dem Sie einige Optionen vielleicht nicht für Ihre tägliche Arbeit brauchen.
Per Rechtsklick auf die Liste in der Themenleiste können Sie diese bearbeiten.
Gehen Sie im Formular Abfrage bearbeiten auf das Symbol Kontextmenü bearbeiten 
, dann öffnet sich eine Übersicht aller verfügbaren Befehle mit Checkboxen. Die aufgelisteten Befehle sind per default im Kontextmenü der Abfrage vorhanden. Haken Sie nun die an, die Sie brauchen, bestätigen Sie mit OK und schon haben Sie Ihr Kontextmenü verschlankt.
Nachher sehen Sie bei Rechtsklick auf einen Listeneintrag der Abfrage im Kontextmenü nur noch das, was Sie explizit ausgewählt haben:
So können Sie die Kontextmenüs rollen- oder gruppenbasiert anpassen und die Usability und Übersicht für die Nutzer individuell erhöhen. Denn nicht jeder braucht jede Funktion jederzeit. Manchmal braucht man nur das Gelbe vom Ei. Dann ist es gut, wenn man das Relevante vom Nicht-Relevanten leicht trennen kann.
[1] Rupp, C. und Pohl, K.: Basiswissen Requirements Engineering, dpunkt.verlag 2015, 4. Auflage
Ich habe das Gefühl, dass hier zwei Spiegeleier durcheinander geraten sind. Zumindest nach meinem Kochverstand. Es ist eine Ungenauigkeit zu behaupten, dass Stakeholder zum Systemkontext gehören, in meiner Küche gehören sie in den Projektkontext. Dort sitzt im Spiegelei das Projekt und rundum sind die Stakeholder, die einen Einfluss nehmen müssen / wollen / dürfen auf das Ergebnis des Projekts – mit denen muss das Projektteam kommunizieren, nicht das System. Rundum Spiegelei mit dem System darin stehen alle Akteure – Benutzergruppen und Systeme – die mit unserem System kommunizieren. Wichtig ist, dass wir dafür sorgen, dass alle Akteure vertreten sind in der Stakeholder-Mannschaft. Das Beispiel Systemkontextdiagramm offenbart genau diese Ungenauigkeit. Die Normen haben einen Einfluss auf das Ergebnis und wir benötigen jemanden, der sich mit den Normen auskennt und als Stakeholder fungieren kann, aber die Normen werden nie mit unserem System selbst interagieren. In den Projektkontextdiagramm gehören neben den Normenexperten auch Personen, welche die Anwender repräsentieren als auch welche, die sich mit den Umsystemen auskennen, welche mit unserem System interagieren (werden). Mit denen kann das Projektteam reden, mit den Umsystemen nicht. Zusammengefasst: Im Projektkontext habe ich Stakeholder, lebendige Personen, mit denen das Projektteam sich über ihre Bedürfnisse austauschen kann. Im Systemkontext habe ich Akteure, Personengruppen und Systeme, mit denen das System, welche wir spezifizieren, interagiert. Die beiden Informationen in die gleiche Pfanne zu hauen ist nicht dienlich. Das Kochen mit zwei Pfannen lohnt sich hier.
Vielen Dank für Ihren Kommentar, Herr Frühauf. Wir haben in diesem Beitrag das Eigelb als System verstanden, so wie es das Buch von Rupp & Pohl “Basiswissen Requirements Engineering” vorsieht. Darin steht, dass Stakeholder oder Standards dem Systemkontext zugerechnet werden. Ich finde Ihre Interpretation, das Spiegelei als das Projekt zu verstehen, auch plausibel. Und sicherlich haben Sie in der Praxis schon jede Menge Erfahrungen gemacht, die diese Sichtweise bestätigen. Insofern lohnt es sich bestimmt, das Projekt in eine eigene Pfanne zu hauen.