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