Von der Stakeholder-Anforderung zur Systemarchitektur

Vor ein paar Tagen bin ich in einem Blog auf einen kurzen Post mit dem Titel „Wer liefert eigentlich Anforderungen an das System?“ gestoßen. Die Antwort erhielt ich gleich im ersten Satz: die Stakeholder. Die Stakeholder spielen eine Schlüsselrolle bei der Anforderungsermittlung. Welche Aspekte sollte man pro Stakeholder festhalten? Und wie kann man diese Informationen kontinuierlich pflegen? Mit diesen Fragen sind Requirements Engineers konfrontiert.

Ich möchte im Beitrag folgende Frage beantworten: Wenn man die Stakeholder kennt, was dann? Wie kommt man zu den Anforderungen und zur Systemspezifikation?

Es gibt drei vom „Gelände“ abhängige Wege. Heute starte ich mit dem günstigsten Fall – sozusagen …

Über die Autobahn von der Stakeholder-Anforderung zur Systemarchitektur

Über die Schnellstraße können Sie gehen, wenn die Stakeholder ihre eigenen Anforderungen gut kennen und benennen können. Der Requirements Engineer muss im Anschluss an die Befragung der Stakeholder die Anforderungen dann „nur noch“ ausformulieren, detaillieren, verfeinern und vervollständigen, „zu Papier“ bringen, gewichten und abstimmen. Parallel dazu kann er in einem iterativen Prozess daran gehen, Systemkomponenten zu entwerfen, welche später die Anforderungen erfüllen sollen. Wenn die Stakeholder-Anforderungen schon klar auf dem Tisch liegen, worin besteht dann noch die Herausforderung für den Requirements Engineer?

Das könnte sein:

• bei zunehmender Komplexität den Überblick zu behalten und
• den Weg von den Stakeholder-Anforderungen zum Systementwurf und umgekehrt nachvollziehbar zu machen, damit die Auswirkungen von veränderten Anforderungen schnell erkannt werden können.

Wo immer es darum geht, Komplexität beherrschbar zu machen und Nachvollziehbarkeit herzustellen, sind Diagramme das Mittel der Wahl. Im Requirements Engineering sind es speziell die der Modellierungssprachen UML/SysML und ganz besonders das – leider noch viel zu wenig bekannte – Anforderungsdiagramm.

Wie die Fahrt über die Autobahn durch das Requirements Engineering – unterstützt durch die Requirements Engineering und Management Software objectiF RM – aussieht, zeigt Ihnen dieses Video:

Im nächsten Beitrag gehen wir gemeinsam über die Landstraße: Die Stakeholder wissen, wo sie hin wollen. Sie kennen ihre fachlichen und wirtschaftlichen Ziele genau, aber es gelingt ihnen nicht so recht, daraus konkrete Anforderungen abzuleiten. Wie kommt der Requirements Engineer in diesem Fall zu Anforderungen und Systemmodellen?

Und zum Schluss dieser kleinen Blog-Serie bewegen wir uns in Teil 3 off-road: Die Stakeholder haben keine konkreten Anforderungen, allerdings Zielvorstellungen. Aber diese sind so unscharf, vielleicht sogar missverständlich, dass sie sich dem Requirements Engineer nicht so leicht erschließen. Auch für dieses Szenario finden wir mit objectiF RM Lösungen. Bleiben Sie dran.