Suchen

Klassisch, agil, und dann? – Teil 2

Agile Ansätze im Requirements Engineering

Seite: 5/9

Was ist Agiles Requirements Engineering ARE?

Agile Vorgehensweisen sind beliebter als konventionelle, da diese oft als bürokratisch und unproduktiv gelten. Das agile Requirements Engineering (ARE) ist keine neue Erfindung, sondern basiert auf einem sinnvollen und projektbezogenen Mischen von agilen und klassischen Techniken (Weilkins und Härter, 2010).

Das Vorgehen ist hierbei iterativ-inkrementell. Das Projekt wird in feste Zeitabschnitte unterteilt (iterativ), jeweils zum Ende dieser wurde ein neues Inkrement (inkrementell) entwickelt. Hiermit wird ein Rückkopplungsmechanismus unterstützt, in dem Vertreter der Kundenseite ein belastbares Feedback über das wachsende Produkt und seine Wirkung bzw. seinen Nutzen für den Kunden geben können. Die Iteration ist ein stets gleich langer Rhythmus und seine Dauer liegt meist zwischen zwei und vier Wochen.

Bildergalerie

In diesen interativ-inkrementellen Prozess bettet sich ARE ein. In erster Instanz wird z.B. durch User Stories ein Gesamtüberblick geschaffen. Dieser wird priorisiert. Alle hochprioren Anforderungen werden sofort detailliert und anschließend realisiert.

Weilkins (Weilkins und Härter, 2010) nennt für das agile Requirements Engineering folgende fünf Regeln:

1) Wähle für jede einzelne Anforderung die passende RE-Technik, um sie zu beschreiben.
2) Wähle für jede einzelne Anforderung die angemessene Beschreibungstiefe.
3) Im Umkehrschluss zu 1 und 2: Verwende kein einheitliches Beschreibungsverfahren für alle Anforderungen.
4) Erstelle ausschließlich nur Anforderungsartefakte, die unmittelbar verwendet werden. Alles andere ist zu diesem Zeitpunkt überflüssig, kostet Verwaltungsaufwand und wird in Zukunft vielleicht nie benötigt.
5) Priorisiere die Anforderungen nach ihrem Geschäftswert. Die hochpriorisierten Anforderungen werden zuerst umgesetzt. Die Priorität hat keinen Einfluss auf die einzusetzende RE-Technik und Beschreibungstiefe.

Zahlreiche Projekte laufen aktuell noch ziemlich statisch ab, d.h. nach der Anforderungsaufnahme folgt die Analyse, bis hin zur kompletten Weitergabe an den Entwickler. Hierdurch wird eine schnelle Reaktionszeit unterbunden und eine flexible Änderung auf Anforderungen ist nicht mehr möglich, siehe Abbildung 5.

Abb. 5: typischer statischer Ablauf eines Softwareentwicklungsprojekts. Eine flexible Änderung auf Anforderungen während der Entwicklung ist in diesem Vorgehensmodell schwierig.
Abb. 5: typischer statischer Ablauf eines Softwareentwicklungsprojekts. Eine flexible Änderung auf Anforderungen während der Entwicklung ist in diesem Vorgehensmodell schwierig.
(Quelle: Weilkins und Härter, 2010)

Der dargestellte Kreislauf wird in einer vorgeschriebenen Reihenfolge durchlaufen, erst wenn die beschriebenen Anforderungen den Wünschen des Kunden entsprechend, gelangt man in die Entwicklung.

Abb. 6: dynamischer Ablauf. Die Entwicklung ist in den Kreislauf eingebunden, darüber hinaus sind auch direkte Sprünge möglich.
Abb. 6: dynamischer Ablauf. Die Entwicklung ist in den Kreislauf eingebunden, darüber hinaus sind auch direkte Sprünge möglich.
(Quelle: Weilkins und Härter, 2010)

Wie bereits erwähnt werden in ARE Anforderungen nur soweit priorisiert, wie dies für die weitere Einschätzung von Nöten ist. Nicht für jede Anforderung wird hierbei gleich detailliert analysiert. ARE beschreibt keine neuen Werkzeuge zur Anforderungserhebung sondern kombiniert diese lediglich. In Abbildung 6 ist ein deutlicher Unterschied zu erkennen. Die Entwicklung hier ist in den Kreislauf eingebunden, darüber hinaus sind auch direkte Sprünge möglich.

Artikelfiles und Artikellinks

(ID:42704398)