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 ein Dilemma. 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. Und wer nachfragt, ist feige – oder?

Als Architekten und Entwickler sollten Sie eine der beiden Alternativen aus Abbildung 1 wählen: Entweder Sie klären 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)

Für die Personen, die eigentlich zuständig für gute Anforderungen wären, gibt es unterschiedliche Berufsbezeichnungen. Wir verwenden im Folgenden den Scrum-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 oder schlichtweg fehlen.

Modernes Requirements Engineering …

… ist ein kooperativer, iterativer und inkrementeller Prozess. Alle am Produkt Beteiligten arbeiten eng und vertrauensvoll zusammen. Sie sorgen dafür, dass in einer Folge von Releases das Produkt immer besser wird. Die Zeiten, in denen wir über Monate und Jahre dicke Pflichten- und Lastenhefte geschrieben haben, sind – zum Glück – für die meisten von uns vorbei. Unser Ziel ist es heute, zunächst einen groben Überblick über alles zu bekommen, was das Produkt leisten soll. Anschließend wollen wir sehr schnell diejenigen Teile genauer spezifizieren und implementieren, die frühen Geschäftswert (oder Risikoreduzierung) versprechen. Das gibt uns Zeit, die weniger wichtigen Themen erst dann zu präzisieren, wenn sie aktuell werden.

Das geordnete Backlog

Agile Methoden wie Scrum ersetzen die klassischen Requirements-Dokumente durch ein ständig gepflegtes und nach Prioritäten geordnetes Product Backlog. Das Wichtige und Dringende steht weiter oben und ist hoffentlich bis ins Detail verstanden und präzisiert. Das weniger Wichtige steht weiter unten und darf durchaus noch vage und unscharf formuliert sein. Job des Product Owners ist es, immer genügend Details zu haben, die das Entwicklungsteam für die nächsten Iterationen oder Releases benötigt (Abb. 2).

Das Product Backlog ist ein Arbeitsinstrument, um mit funktionalen Anforderungen auf unterschiedlichem Präzisionsgrad arbeiten zu können. Für uns als Architekten sind jedoch oft auch die geforderten Qualitäten extrem wichtig. Aber Anforderungen wie „Das System soll maximal zweimal pro Jahr ausfallen und im Falle eines Ausfalls nach zehn Minuten wieder voll funktionsfähig sein“ bzw. „Das Produkt soll alle Bestimmungen der DSGVO einhalten“ sind querschnittlicher Natur. Sie lassen sich nicht einfach irgendwo in so einem Backlog einordnen. Wir werden Ihnen im Rahmen der Kolumne noch viele Hinweise geben, wie Sie solche Aspekte erarbeiten können.

Viele spannende Themen

In den kommenden Folgen dieser Kolumne greifen wir jeweils einen anderen Aspekt für gutes Requirements Engineering auf und geben Ihnen praktische und pragmatische Tipps, wie Sie zu „just enough“ Requirements kommen.

In der nächsten Folge adressieren wir den Clean Start: die Tatsache, dass auch hochgradig agile Projekte wenigstens ihre Ziele explizit kennen und wissen sollten, wer wozu etwas zu sagen hat.

Dann betrachten wir unterschiedliche Möglichkeiten, funktionale Anforderungen auf den Punkt zu bringen. Gutes Verständnis Ihrer Businessprozesse und Ihrer Domänenobjekte, sowie der Trend zu Specification by Example stehen im Mittelpunkt.

In mehreren Folgen widmen wir uns dem Kernthema „Qualitätsanforderungen“. Sie wissen ja, dass diese die Architektur stärker und nachhaltiger beeinflussen können als die funktionalen Anforderungen. Wir zeigen, wie man auch im agilen Umfeld vernünftig damit umgehen kann und widmen uns zusätzlich auch insbesondere dem Thema Benutzbarkeit (UI/UX).

In einer weiteren Folge stellen wir dann das engere Zusammenspiel und die stärkere Verzahnung zwischen Business und IT vor. Wir sprechen Methoden wie Design-Thinking oder Design-Sprints und „Discover to Deliver“ [3] an.

Schließlich bliebt auch die leidige Frage des Toolings: Mit welchen Werkzeugen erfassen und kommunizieren wir Anforderungen? Wir geben Ihnen später einen kleinen Marktüberblick, angefangen von Kärtchen an der Wand über spezialisierte Requirements-Tools bis hin zu Simulations- und Animationswerkzeugen.

Die gute Nachricht lautet: es gibt ausreichend Möglichkeiten, modernes Requirements-Engineering zu erlernen. Unter anderem hat das International Requirements Engineering Board (www.ireb.org) ein Advanced-Modul „RE@Agile“ freigegeben, das gutes Requirements Engineering in einer agilen Welt behandelt. Parallel zur Kolumne bauen wir unter www.req42.de eine Reihe von Onlinegoodies auf. Darunter finden sich beispielsweise ein Glossar zu den wichtigsten Req4Arc-Begriffen, eine kommentierte Literaturliste sowie ausführlichere Beispiele zu den einzelnen Themen.

Bleiben Sie dran

Innerhalb der nächsten Folgen vermitteln wir Ihnen als Architekten und Entwickler das passende Requirements-Know-how. Mit dessen Hilfe können Sie so trotz oftmals schlechtem (Requirements-)Input Ihre Produkte zielsicher entwickeln. Nebenbei erfahren Sie, wie Sie Ihre Product Owner oder Requirements-Verantwortlichen durch gezieltere Nachfragen zu besseren Vorgaben bewegen können, damit Sie sich noch mehr auf Ihre Kernaufgabe konzentrieren und spannende Produkte bauen können, die am Ende exakt die Bedürfnisse des Marktes treffen.