Im ersten Beitrag unserer 8-teiligen Blogserie habe ich Ihnen einen kurzen Überblick über die Requirements Engineering & Requirements Management Software objectiF RM gegeben. Heute erfahren Sie in Teil 2, was objectiF RM Ihnen für die Abgrenzung des Kontextes der zu entwickelnden Lösung und die Stakeholder-Analyse anbietet.
Systemkontext definieren – darum geht es hier
Was steckt hinter diesen Aktivitäten des Requirements Engineering?
Als Requirements Engineer werden Sie in jedem Projekt mit einer Vielzahl an – oft ungeordneten – fachlichen Anforderungen, Wünschen und Ideen konfrontiert. Dabei müssen Sie immer wieder entscheiden: Was davon betrifft das geplante System? Was ist wirklich relevant? Richtige Entscheidungen können Sie nur treffen, wenn klar ist,
- welche Aspekte das geplante System abdecken soll und welche nicht,
- was in der Systemumgebung für die Entwicklung des Systems von Bedeutung ist und was nicht.
Anders ausgedrückt: Sie müssen die Grenzen des geplanten Systems und des Systemkontextes abstecken.
Dafür brauchen Sie Informationen von den Stakeholdern, also von denjenigen Personen, Gruppen oder Organisationseinheiten, die ein – wie auch immer geartetes – Interesse an dem geplanten System haben. Aber wer sind die Stakeholder? Sie müssen also zunächst einmal die Stakeholder ermitteln und sie dann – zum Beispiel in Hinsicht auf ihren Einfluss – einordnen und bewerten.
Sehen wir uns einmal an, wie Ihnen objectiF RM bei diesen beiden, eng miteinander verbundenen Schritten helfen kann.
Was ist drin? Was ist draußen? – System- und Kontextgrenzen festlegen
Um Klarheit über die System- und Kontextgrenzen zu gewinnen, muss man in der Regel intensiv mit den Stakeholdern kommunizieren. Für die Stakeholder-Kommunikation finden Sie in objectiF RM einen speziellen Diagrammtyp: das Systemkontextdiagramm.
Welche Schnittstellen müssen beachtet werden, welche nicht? Welche gesetzlichen Vorgaben müssen berücksichtigt werden? Wer benutzt eigentlich das System? Mit dem Systemkontextdiagramm klären Sie diese Fragen.
Ein Systemkontextdiagramm besteht im Wesentlichen nur aus Kästchen und Pfeilen. Mit diesen einfachen Mitteln bilden Sie Geräte, Fremdsysteme oder auch Bediener ab, die mit dem geplanten System zusammenarbeiten. Beschriftete Pfeile stellen Informationsflüsse zwischen dem System und diesen Kontextelementen dar. Die Richtung der Pfeile zeigt, ob es sich um eingehende oder ausgehende Informationen handelt. Zu abstrakt für Ihre Stakeholder? Da lässt sich noch etwas machen! Fügen Sie einfach in die Systemkontextelemente Fotos oder Icons Ihrer Wahl ein. Die Darstellung des Systemkontextes wird damit so bildhaft und anschaulich, dass Sie die Diagramme in der Diskussion mit den Stakeholdern direkt verwenden können.
In vielen Bereichen – nehmen wir z.B. Automotive oder Medizintechnik – müssen Systeme gesetzliche Vorschriften oder Normen erfüllen. Auch diese wichtigen Rahmenbedingungen oder „Regeln“, die Sie berücksichtigen müssen, können Sie als spezielle Elemente in ein Systemkontextdiagramm einfügen, um sie gemeinsam mit den Stakeholdern auf Korrektheit und Vollständigkeit zu prüfen.
Übrigens: Für die Beschreibung des Systemkontextes können Sie in objectiF RM auch Blockdiagramme der SysML oder Use-Case-Diagramme der UML verwenden. Auf beide Diagrammtypen werde ich in einem späteren Beitrag eingehen. Warum dann zusätzlich Systemkontextdiagramme? Weil wir in den vergangenen Jahren immer wieder mit Kunden über die Frage diskutiert haben, ob Use-Case-Diagramme für Gespräche mit Fachabteilungen geeignet sind. Das Ergebnis: Manche Kunden antworten darauf klar mit Nein. Sie haben die Erfahrung gemacht, dass Use-Case-Diagramme zu abstrakt für die Stakeholder-Kommunikation sind. Deshalb haben wir speziell für die Abgrenzung des Systems und des Systemkontextes, also für den ersten entscheidenden Schritt in einem Projekt, der ohne Stakeholder-Beteiligung nicht geht, eine anschauliche Alternative geschaffen.
Wer hat Einfluss? Wer weiß Bescheid? – Stakeholder analysieren
Stakeholder sind nicht nur die wichtigsten Ansprechpartner, wenn es um die Systemgrenzen geht. Sie sind auch die wichtigste Quelle für Anforderungen. Werden nicht alle relevanten Stakeholder erkannt und in das Projekt einbezogen, dann kann es passieren, dass wichtige Anforderungen erst als Change Request im laufenden Betrieb auf den Tisch kommen. Und Sie wissen: Das kann teuer werden.
Informationen über Stakeholder sollten deshalb mit einer Bewertung ihrer Bedeutung für das geplante System festgehalten werden. objectiF RM bietet Ihnen die Möglichkeit, Informationen über Stakeholder schnell und systematisch nach einheitlichen Kriterien per Formular zu erfassen. Und das geht so:
Eine Bewertung des Einflusses eines Stakeholders als „gering“ oder „sehr hoch“ ist nur ein erster Schritt. Was wirklich für den erfolgreichen Start in die Anforderungsermittlung zählt, ist Klarheit über die Intentionen der Stakeholder. Welche Ziele sollen aus Sicht eines Stakeholders mit dem geplanten System erreicht werden? Welches Gewicht haben diese Ziele im Vergleich zu anderen? Tun sich möglicherweise zwischen Stakeholdern Zielkonflikte auf? Diese Fragen müssen geklärt, die Antworten dokumentiert und erkannte Zusammenhänge nachvollziehbar festgehalten werden. Was Ihnen objectiF RM dafür anbietet, erfahren Sie in Teil 3: Ziele als Basis für die Ermittlung von Anforderungen.
Oder Sie probieren objectiF RM selbst einmal aus mit Ihrer kostenlosen Trialversion.