© GreenFlash/Shutterstock.com
Kolumne: Req4Arcs

Kolumne: Req4Arcs


Nachdem Sie von uns über die letzten Jahre in zahlreichen Ausgaben des „Knigge für Softwarearchitekten“ hoffentlich ein paar Ideen für gute Lösungsfindung bekommen haben [1], geht es in dieser neuen Kolumne um diverse Dilemmata. Das Dilemma diesmal: Softwarearchitekten und Entwickler leiden immer wieder unter schlechten beziehungsweise fehlenden Anforderungen für ihre Arbeit. Dabei finden Entwicklungsteams für praktisch jedes Problem eine vernünftige Lösung – sofern sie wissen, wo genau das Problem liegt [2].

Gutes Requirements Engineering respektive Businessanalyse zählen nach wie vor zu den wichtigen Erfolgsfaktoren für erfolgreiche Systeme und Produkte. In dieser Kolumne zeigen wir Ihnen praktische Wege auf, wie Sie Ihre Anforderungen in den Griff bekommen.

Entwicklungsteams benötigen adäquate Anforderungen

Unklare Anforderungen führen in der Entwicklung oftmals zu übermäßig flexiblen und komplexen Lösungen [3]. Und wer nachfragt, ist feige – oder?

Als Architekten und Entwickler sollten Sie eine der beiden Alternativen aus Abbildung 1 wählen: Entweder klären Sie die schlechten Anforderungen selbst (2), indem Sie das Gespräch mit den Stakeholdern suchen, die mit dem Produkt arbeiten wollen oder für die es geschäftlichen Wert bringen soll. Alternativ muss das Entwicklungsteam diejenigen Personen identifizieren, die eigentlich dafür zuständig wären, klare Anforderungen zu liefern – und diese dann motivieren, ihren Job ordentlich zu erledigen (1).

hruschka_starke_req4arcs_1.tif_fmt1.jpgAbb. 1: Zwei Möglichkeiten für bessere Anforderungen

Für die Personen, die eigentlich zuständig für gute Anforderungen wären, gibt es unterschiedliche Berufsbezeichnungen. Wir verwenden im Folgenden den Sc rum-Begriff „Product Owner“. Er drückt genau das aus, was wir wichtig finden: Jemand fühlt sich als „Eigner“ für ein Produkt oder ein System verantwortlich. Dieser Rolle obliegt es, das Produkt kurz- und langfristig erfolgreich zu machen. Sie subsummiert, was früher einerseits Projektleitung (Entscheider) und andererseits Requirements Engineers beziehungsweise Systemanalytiker oder Businessanalysten gemeinsam erledigen mussten: Sowohl gute Anforderungen auszuarbeiten und zu kommunizieren, aber auch Entscheidungen darüber zu treffen, was früher oder später implementiert werden sollte.

Unsere Präferenz in Abbildung 1 ist recht eindeutig Alternative 1. Erzieht eure Product Owner! Im rauen Praxisalltag allerdings finden Sie immer wieder die Notwendigkeit für Alternative 2, z. B. wenn Product Owner überfordert sind...

Exklusives Abo-Special

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang