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