Die einen schwören darauf, die anderen stellen sie infrage — Scrum-Projekte habe auf jeden Fall eigene Regeln. Requirements Engineering steht dabei nicht nur nicht an vorderster Stelle, die Frage ist auch, inwieweit agile Teams überhaupt eine Anforderungsanalyse durchführen.

Agile Verfahren wie Scrum beinhalten kaum Requirements Engineering. Scrum verwendet eine einfache priorisierte Feature-Liste (Product Backlog genannt), und die wesentliche RE-Techniken sind Benutzergeschichten sowie die kontinuierliche direkte Kommunikation der Anforderungsbeteiligten. Viel mehr braucht Scrum nicht, damit Projekte erfolgreich laufen. Dies als Rrequirements Engineering (RE) zu bezeichnen wäre etwas übertrieben. Gibt es also überhaupt ein agiles RE? Und falls ja, was ist das?

Requirements Engineering an sich kostet nur. Jedes RE muss daher einen Nutzen bringen, der seine Kosten deutlich übersteigt. Darum gibt es in jedem Fall den Bedarf, dass sich die Beschreibung von Anforderungen in Menge, Form und Zeitpunkt an ihren jeweiligen konkreten Empfängern orientieren.

Diese Erwartungen an das Requirements Engineering sind soweit normal und haben mit agilem Vorgehen noch gar nichts zu tun. Wer RE über diese klare Kosten-Nutzen-Abwägung hinaus als Selbstzweck betreibt, ist bereits mit klassischem Requirements Engineering unproduktiv.

Iterativ allein genügt nicht.

Interessant ist, dass agile Produktentwicklungsverfahren wie Scrum weitgehend ohne RE auskommen. Sie funktionieren dank stetiger direkter Kommunikation zwischen den Beteiligten und der regelmäßigen kurzfristigen Evaluierung lauffähiger Inkremente trotzdem sehr gurt und meistens sogar besser als nicht agile Projekte. Sehen Mitarbeiter in nicht agilen Projekten Anforderungsänderungen gewöhnlich als Störungen an, betrachten die, die agile Verfahren einsetzen, dasselbe als Zeichen von Reifung, also als Fortschritt.

Insofern kann aus agiler Sicht die Frage gestellt werden: Braucht man überhaupt irgendein fortgeschrittenes RE? Als Erstes ist ein Missverständins zu klären: Iteratives Vorgehen alleine macht noch kein agiles RE. Der Übergang vom Wasserfall zum Iterativen  sorgt dafür, dass nicht alle Anforderungen vorab fertiggestellt, sondern über den gesamten Projektzeitraum prioritätsgesteuert verteilt werden. Das ist aber nur der erste Schritt zu einem agilen RE. Wer diesen Schritt heute immer noch nicht gegangen ist, hat entweder verdammt gute Gründe oder arbeitet hoffnungslos rückständig.

Die entscheidenden Unterschiede von klassischem und agilem, Scrum basierten Requirements Engineering liegen aber ebenso wenig in der Auswahl spezieller RE-Techniken. In Scrum ist die Arbeit mit Benutzergeschichten, Epen und Themen üblich. Aber letztendlich macht Scrum keine Vorgabe und lässt auch alle anderen RE-Techniken zu. Insofert ist beispielsweise die Frage nachrangig, worin sich Benutzergeschichten und Anwendungsfälle unterscheiden.

Agiles RE ist unvollkommenes RE

Klassisches RE ist auf Perfektion konditioniert: Man soll Anforderungen möglichst weitgehend verstehen und präzise beschreiben. Scrum zeigt, dass es auch mit minimalem RE geht. Andererseits hat die Disziplin des RE in den letzten Jahrzehnten so viele teilweise einfache und mächtige Techniken hervorgebracht, beispielsweise um Widerspräche, Lücken und Abhängigkeiten in Anforderungen zu erkennen und erfolgreich zu handhaben. Linguistische Verfahren, formale Analysemethoden, Modellierungs- und Diagrammtechniken und vieles mehr.

Diese Errungenschaften völlig außer Acht zu lassen, wäre nicht nur ignorant, sonder vor allem ein großer Verlust. Das minimalistische RE in Scrum funktioniert — aber es ist nicht optimal, es kann durch fortgeschrittenere Techniken effizienter und effektiver laufen. Scrum-Protagonisten habe aber berechtigte Berührungsängste, neigen doch die klassischen REle dazu, die Anforderungen statt den Anfoderungsprozess zu perfektionieren.

Fortgeschrittene RE-Techniken erlauben es, Anforderungessachverhalte bereits vor ihrer Umsetzung viel besser zu begreifen. Scrum vertieft das Verständnis erst bei der Realisierung und mit den Rückmeldungen zu fertigen Teillösungen nachher. Eine hohe Verständnistiefe, die zeitnah (etwa durch iteratives Vorgehen) vor der Implementierung erzielt wird, könnte die anschließende Umsetzung vereinfachen. Aber ist das wirklich notwendig?

Kriterien für die Verständnistiefe

  • Wie vertraut sind der Product Owner, die Fachabteilung, der Anforderungsanalytiker und das Entwicklungsteam mit der Fachlichen Domäne?
  • Wie homogen praktizieren sowohl die Mitarbeiter der Fachabteilung als auch die Systembenutzer die geschäftlichen Abläufe?
  • Wie viel fachliche Varianten uns Ausnahmen sind zu berücksichtigen beziehungsweise werden erwartet?
  • Wie viele verschiedene Personen sind als Anforderungsgeber oder -beeinflusser zu berücksichtigen?
  • Wie viele Erkenntnisse über noch zu berücksichtigende Details, Varianten, Anforderungen lassen sich mit RE-Techniken genauso teuer oder günstiger vor der Realisierung erkennen und antizipieren als hinterher?
  • Wie hoch ist das Risiko, durch zu wenig RE wichtige Abhängigkeiten oder Details zu vergessen, die später Mehrkosten oder Verzögerungen verursachen?
  • Wie gravierend sind die Folgen, wenn das Projektteam wichtige fachliche Varianten oder Details vergisst?
  • Sind (in größeren Projekten) die Entwicklungsteams stark oder oft voneinander abhängig?

Agiles RE basiert auf der These, dass nicht die maximierung oder Normierung der Verständnistiefe der beste Weg ist, sondern die kontextspezifisch richtige. Für bestimmte Anforderungen ist ein teifergehendes Durchdringen der Materie hilfreich, für andere reicht ein oberflächliches Verständnis.

Viele Projekte oder Unternehmen — auch Scrum-Projekte — entscheiden sich irgendwann für bestimmte RE-Rechniken als Standard. Beispielsweise: „Wir arbeiten mti Benutezrgeschichten, Akzeptanzkriterien und testfällen“ oder:  „Wir arbeiten mit Anwendungsfällen, die wir jeweils mit Aktivitätsdiagrammen und Testfällen detaillieren“ oder: „Wir beginnen mit einem Systemkontextmodell, beschreiben dann Produkt-Features, verfeinern diese mit Anwenungsfällen und gruppieren sie anschließend zu Iterations-Features.“

Die richtige Methode wählen

Diese Form unternehmens- oder projektspezifischer Standardisierung (auch wenn sie durch Retrospektiven kontinuierlich verbessert wird) ist zwar einfach und gut verständlich, aber letztendlich zu einfach. RE-Techniken werden hier blindlings mit der Gießkanne verteilt. Dabei mag es für einen einzelnen Sachverhalt oder einen bestimmten Anforderungsempfänger sinnvoller sein, andere Verfahren anzuwenden und unterschiedlich tief in die Anforderung einzusteigen.

Manchmal reicht ein kurzer syntaktisch standardisierter Satz auf einer  Karteikarte aus (Benutzergeschichte), um ein Ergebnis umzusetzen, das gut genug ist. Ein andermal ist es besser, die Ablaufvarianten zu visualisieren, also ein Bild zu zeichnen (Aktivitätsdiagramm) und von den Ablaufpfaden Ausbaustufen und Pfadüberdeckungstests abzuleiten.

Wie tief ein Team in jedem Einzelfall Anforderungen vor der Realisierung verstehen sollte, hängt von der Kompliziertheit und Komplexität der Anforderung selbst ab, ebenso aber von der Ausgangssituation bei den Anforderungsgebern und Systembenutzern sowie den Bedürfnissen und Notwendigkeiten auf Seiten der Realisierer.

Die Frage nach der richtigen Verständnistiefe ist aber nur einer von zwei zentralen Aspekten. Der andere betrifft die Auswahl der richtigen Methode:

  • Benutzergeschichten (inkl. Epen und Themen)
  • Anwendungsfälle (inkl. Geschäts- und Systemanwenungsfällen, essentiellen Ablaufbeschreibungen und Testfällen)
  • Geschätsprozesse (inkl. Kern- und unterstützenden Geschäftsprozessen)
  • Story Maps
  • Produktkartons
  • Features (Produkt-, Release-, Iterations- und minimale Markt-Features und andere)
  • Systemkontext-Modelle
  • Stakeholder-Diagramme und -Profile
  • linguistische Techniken (W-Fragen, Universalquantorenanalyse et cetera), natürliche Phrasen und syntaktische Muster
  • formale Sprachen und Diagramme (UML, DSL, BPMN, ERM et cetera)
  • Geschäftsmotivationsmodelle (inkl. strategischen und operativen Zielen, Strategien, Visionen, Missionnen et cetera)
  • Glossare und Begriffsmodelle
  • Abhängigkeitsgraphen, Ursache-Wirkungs-Graphen, Entscheidungstabellen, -bäume et cetera
  • Ablaufdiagramme (auch informelle Ablaufvisualisierungen)
  • Prototypen, Dialogskizzen, Muster, Beispile et cetera
  • RE-nahe Softskills wie Interview-, Workshop-, Kommunikations- und Verhandlungstechniken

Alle diese Vorgehensweisen können für eine spezielle Anforderung, einen bestimmten Anforderungsempfänger oder zu einem bestimmten Zeitpunkt sinnvoll und effizient eingesetzt werden oder aber zum falschen Zeitpunkt, für die falsche Anforderung oder den falschen Empfänger einfach nur überflüssig sein.

Wenn der Weg vom Wasserfall zum iterativen RE der erste Schritt ist, dann ist die gezielte Steuerung der Verständnistiefe, also der Unvollkommenheit der Anforderungen, der nächste Schritt. Hier teilen sich jetzt aber die Wege:

Verständnistife gezielt steuern

  • Klassische REler sollten die gezielte Unvollkommenheit als notwendigen Optimierungschritt akzeptieren lernen.
  • Die erfahrenen Agilisten sollten anspruchsvollere RE-Techniken beherrschen lernen, weil eine Standardisierung auf der Basis einfachster RE-Mittel nicth optimal ist.

Definition des agilen RE

Requirements Engineering (RE) ist der Erwerbt und die Anwendung von struktur- und sozialwissenschaftlichem Wissen, um die Kollaboration (Zusammenarbeit) von Menschen im Kontext von Anforderungen für die konsistente Entwicklung von Systemen zu unterstützen.

Agiles RE (ARE) ist RE mit der speziellen Strategie

  • genau die Menge an Anforderungen in der angemessenen Beschaffenheit zum passenden Zeitpunkt den relevanten Beteiligten verfügb ar zu machen.
  • in einer kontinuierlichen Begleitung immer die insgesamt effektivsten und effizientesten Kommunikationsmöglichkeiten zwischen den Beteiligten und den dafür notwendigen wissenschaftlichen Techniken einzusetzen und
  • Anforderungsänderungen als Ausdruck reifenden Verständnisses und reifender Entscheidungen wert zu schätzen.

Die Kunst des agilen RE besteht darin, die genannten Eigenschaften (angemessen, passend, relevant und so weit) zu erfüllen.

Zu den für diese Definition herangezogenen Strukturwissenschaften zählen insbesondere die Mathematik, Informatik, Systemtheorie, Linguistik und Synergetik, zu den einfließenden Sozialwissenschaften vor allem Wirtschafts-, Kommunikations-, Rechtswissenschaft, Soziologie und Psychologie. Die folgenden Ausführungen erläutern kurz einige wesentliche Aspekte des agilen RE.

Iteration ist wichtiger als Spezifikation. — Die Aufgabe des Teams beschränkt sich nicht auf die Erhebung, Analyse, Spezifikation und Dokumentation von Requirements, sonder die Inhalte und Bedeutungen von Anforderungen sind zwischen den Beteiligten (vor allem zwischen fachlichen Vertretern und Entwicklern) proaktiv zu vermitteln und zu klären.

Evolution ist wichtiger als Determination (Abgrenzung). — Dei Aufgabe des RE findet keinen eigenen Abschluss, sonder ist eine die gesamte Entwicklungszeit begleitende Tätigkeit. Agiles Requirements Engineering (ARE) versteht Spezifikationen, Definitionen und andere Abgrenzungen als Artefakte, die sowohl volatil als auch jederzeit zu hinterfragen und weiter zu entwickeln sind. Darüber hinaus sind sie Struktur bildend und vereinfachen die Kollaboration und Prozesse.

Agiles Vorgehen ist „lean“. — Den genannten ARE-Prinzipien untergeordnet ist es zusätzlich, Wartezeiten im Entwicklungsprozess, (Informations-)Bestände und Produktnachbesserungen zu minimieren. (Unter einem Bestand versteht man etwas, dass aktuell keine Verwendung findet.)

RE ist eine Querschnittsfunktion. — Requirements Engineering ist eine vor allem indirekt wertschöpfende, querschnittsbildende und dienstleistende Disziplin. Sie unterstützt vor allem verschiedene andere Disziplinen, beispielsweise Entwicklung, Organisations- und Projektmanagement, Architektur, Betriebswirtschaft und die jeweiligen fachlichen Domänen.

Quellen:

  • iX Magazin für profesionelle Informationstechnik 8/2010, S.93ff