Agiles Requirements Engineering

Klassisches Requirements Engineering und agile Entwicklungsprozesse kombinieren

30.09.2010 | Autor / Redakteur: Tim Weilkiens* / Hendrik Härter

Mit dem agilen Requirement Engineering soll das oft als bürokratisch und unproduktiv geltende RE aufgebrochen werden
Mit dem agilen Requirement Engineering soll das oft als bürokratisch und unproduktiv geltende RE aufgebrochen werden

Die Kosten des Requirement Engineerings

Bild 2: Hier fehlt es an einer schnellen Reaktionszeit. Viele klassische Projekte nehmen Anforderungen auf, analysieren sie und modellieren sie gegebenenfalls.
Bild 2: Hier fehlt es an einer schnellen Reaktionszeit. Viele klassische Projekte nehmen Anforderungen auf, analysieren sie und modellieren sie gegebenenfalls.

ARE bettet das Requirements Engineering in den gerade skizzierten iterativ-inkrementellen Prozess ein. Die Frage „Wie viel RE brauche ich eigentlich?“ kann so viel differenzierter beantwortet werden. RE an sich kostet nur und erfährt seine Rechtfertigung erst dadurch, dass es mehr Nutzen als Kosten im Entwicklungsprozess verursacht.

Viele Projekte laufen immer noch so ab, dass sie erst alle Anforderungen aufnehmen, analysieren und ggf. modellieren und diese dann als Ganzes an Designer oder Entwickler weitergeben, wodurch keine schnelle Reaktionsfähigkeit und keine besondere Flexibilität hergestellt werden kann (Bild 2). Und das Anforderungen sich stetig ändern, ist bekanntermaßen das einzige Stabile.

Das Agile Requirement Engineering

Bild 3: ARE beschreibt keine neuen Werkzeuge zur Anforderungserhebung, sondern kombiniert die klassische mit der agilen Welt
Bild 3: ARE beschreibt keine neuen Werkzeuge zur Anforderungserhebung, sondern kombiniert die klassische mit der agilen Welt

Im ARE werden Anforderungen zunächst nur soweit detailliert wie für die weitere Priorisierung, Einschätzung oder Bestimmung von Kosten, Risiken, Aufwänden oder Nutzen gerade eben notwendig ist. Nicht jede Anforderung wird in gleicher Weise detailliert und analysiert, sondern es wird für jede einzelne Anforderungen entschieden, welches Maß von RE nützlich ist und auch in welcher Weise und mit welchen RE-Techniken. Das stellt hohe Anforderungen an die Rolle des Requirements Engineers. Er muss ein großes Repertoire an Techniken beherrschen und wissen, sie angemessen einzusetzen.

Hinter ARE steckt also vor allem ein anderer RE-Prozess (Bild 3), der besonderen Werten und Prinzipien folgt. ARE beschreibt keine neuen Werkzeuge zur Anforderungserhebung, sondern kombiniert die Anforderungswerkzeuge der agilen Welt mit den Anforderungswerkzeugen der klassischen Welt.

Agilität und Requirements Engineering

In der agilen Welt gibt es beispielsweise die User Stories, die in wenigen Sätzen eine Anforderung aus Sicht des Anwenders beschreiben. Sie helfen Anforderungen zu benennen, können sie aber nur schlecht weiter detaillieren. Hier können dann klassische Werkzeuge wie Anwendungsfälle eingesetzt werden, die beispielsweise mit Ablaufdiagrammen oder Zustandsautomaten ergänzt die geforderte Systemfunktion sehr detailliert beschreiben können. In welchem Umfang welches Werkzeug eingesetzt wird, wird für jede Anforderung entschieden unter Berücksichtigung der Priorität und anderer Rahmenbedingungen.

Die Kommunikation

ARE ist auch eine andere Form der Kommunikation im Projekt. Sie ist einerseits inhaltlich intensiver, fokussierter und andererseits zeitlich besser über die Entwicklungszeit verteilt. Der Kunde kann und muss mehr Rückmeldungen geben, wird mehr in die Pflicht genommen, gewinnt aber auch früher Erkenntnisse, sieht viel konkreter Ergebnisse, so dass nicht nur einfacher korrigierend wirken kann, sondern sich auch eine viel höhere Qualität im Anforderungsdiskurs einstellt.

Die obige Schwarz-Weiß-Darstellung agiles Vorgehen vs. klassisches RE ist natürlich eine Vereinfachung zur Erklärung von ARE. Die Realität ist grau. Agile Vorgehen enthalten auch RE und das klassische RE ist richtig angewendet, deutlich agiler als so mancher denkt.

Das Neue von ARE ist nicht eine einzelne Technik, sondern die Kombination bestehender Ansätze. ARE stärkt Ihre Achillesverse RE und schafft so eine gesunde Basis, dass Ihr Projekt erfolgreich ins Ziel läuft.

*Tim Weilkiens ist Geschäftsführer der oose Innovative Informatik GmbH in Hamburg und Autor zahlreicher Buch- und Zeitschriftenpublikationen, darunter das Buch „Systems-Engineering mit SysML/UML“. Seine Schwerpunkte liegen im Systems Engineering, der Modellierung und bei Vorgehensmodellen. Er ist Co-Autor der SysML-Spezifikation und Entwickler der OMG-Zertifizierungsprogramme.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 359631 / Embedded Software Requirements Engineering )