Requirements Engineering

Die Qualität der im Requirements Engineering erfassten Anforderungen ist entscheidend für den Erfolg eines Entwicklungsprojektes. Dies trifft unabhängig der gewählten Entwicklungsmethode zu. Entgegen der weitverbreiteten Meinung können die Techniken und Methoden der Requirements Engineering-Disziplin in klassischen (Wasserfall-Modell) oder agilen (Scrum) Methodologien angewandt werden.

Auch unsere Erfahrung aus Kundenprojekten zeigt es: Auf dem Weg das Anforderungsmanagement mit der Agilität zu verbinden, sind einige Stolpersteine versteckt. Wir haben diese für Sie identifiziert und aus dem Weg geräumt!

Lesen Sie in der folgenden Aufzählung, welche Missverständnisse auftreten können und wie Sie diese umgehen, um Ihren Projekterfolg sicherzustellen:

 

  • Stolperstein 1: RE wird lediglich als vorab erstellte Analyse betrachtet, anstatt als iterativer Prozess

Requirements Engineering wird oft als eine mögliche Vorabaktivität in Entwicklungsprojekten betrachtet. In der Realität können jedoch die Requirements Engineering Aktivitäten im Rahmen einer agilen Methode wie andere Tätigkeiten (Programmieren, Testen, etc.) durchgeführt und in jede Iteration integriert werden. Die Agilität sollte nicht dahingehend missinterpretiert werden, dass Überlegungen im Vorfeld immer negativ zu verstehen sind. Der Projektkontext bestimmt, wie und in welchem Umfang eine Voranalyse sinnvoll ist. Schaffen Sie ein gemeinsames Verständnis bezüglich Requirements Engineering und Agilität, um diesem Stolperstein auszuweichen!

 

  • Stolperstein 2: RE wird mit Dokumentation gleichgestellt, greift jedoch in der Realität viel weiter

Von «Aussenstehenden» wird das Requirements Engineering mit den in diesem Zusammenhang erstellten Dokumenten in Verbindung gebracht. Dies greift jedoch zu wenig weit. Dokumente und Artefakte sind nur ein mögliches Ergebnis aus Aktivitäten, welche Wissen erzeugen. Ein guter RE-Spezialist ist sich jederzeit im Klaren darüber, dass ein Dokument nie vollumfänglich abgeschlossen ist. Es dient lediglich dem Zwecke Informationen zu bewahren, die Kommunikation zu vereinfachen und gedankliche Vorgänge zu unterstützen. Ein Wert des agilen Manifests besagt, dass funktionierende Software über die Dokumentation gestellt werden soll. Dennoch sind wir überzeugt, dass genauso wie die Design-, Test- oder Betriebsdokumentation auch die Anforderungsdokumentation ein gültiges und notwendiges Artefakt ist, welches in jedem nachhaltigen Entwicklungsprozess von Softwareprodukten oder Systemen entsteht.

 

  • Stolperstein 3: Der Zusammenhang wird aus den Augen verloren, wenn nicht regelmässig eine übergreifende und langfristige Sicht eingenommen wird

Die agile Methodik wird oft fälschlicherweise mit kurzfristigem Denken und Vorgehen gleichgesetzt. Dabei wird davon ausgegangen, dass der Schwerpunkt jederzeit auf den unmittelbar anstehenden Tasks liegt. Dies mag für Entwickler auch sinnvoll sein, um die Leistung und Energie auf die aktuelle Arbeit zu konzentrieren. Es braucht aber immer auch jemanden der zuständig ist, dass die einzelnen Aktivitäten zielgerichtet und auf die lange Perspektive ausgerichtet bleiben. Entgegen vielen Annahmen ist in nachhaltigen agilen Methoden durchaus auch die mittlere und längere Frist verankert. So sind beispielsweise eigens dafür Sitzungen, wie Road-Mapping-Meetings oder Workshops zur Produktvision, vorgesehen. Weichen Sie dem Stolperstein aus, in dem Sie immer wieder einen Abgleich zwischen den Perspektiven herstellen und kommunizieren!

 

  • Stolperstein 4: Die Stakeholder werden mit Informationen überladen, anstatt sinnvoll miteinbezogen

Agile Teams erarbeiten schnell Requirements Engineering Artefakte mit sehr hoher Informationsdichte. Ein kontinuierlicher dokumentbasierter und textueller Review kann für die Stakeholder komplex und zeitintensiv sein. Nutzen Sie bewusst und gezielt andere Möglichkeiten zur Prüfung der Anforderungen, wie beispielsweise Mock-Ups oder Prototypen! Dies macht Anforderungen greif- sowie sichtbar und vermindert damit die Komplexität. Die Stakeholder werden somit nicht überfordert und sind optimal informiert und einbezogen.

 

  • Stolperstein 5: Eine inkrementelle und iterative Ausarbeitung aller Themen wird angestrebt, anstatt das Vorgehen auf den Komplexitätsgrad abzustimmen

Eine inkrementelle Entwicklung eignet sich durchaus bei durchschnittlich komplexen Themen. Dabei kann man sich Prozesse vorstellen, welche in unabhängige Elemente unterteilt werden können, wie beispielsweise der Einkaufsprozess in einem Onlineshop. Hierbei hilft das iterative Vorgehen die Komplexität zu reduzieren, in dem Schritt für Schritt bearbeitet wird. Jedoch ist bei hochkomplexen Themen das gleiche Vorgehen wenig erfolgsversprechend. Denn jede neue Erkenntnis kann bei unübersichtlichen und verflochtenen Themenstellungen zu einem völlig neuen Verständnis der bereits bekannten Informationen führen. Verschaffen Sie sich freie Bahn, in dem Sie zu Beginn des Projektes die Komplexität der Themenstellung bestimmen!

 

  • Stolperstein 6: Agile und kulturelle Veränderungen sind unvereinbar, ausser es geschieht eine enge Abstimmung

Die Agilität verändert die Art und Weise, wie Unternehmen arbeiten und fördert die kollektive Verantwortung. Dabei wird eine kontinuierliche, reflektierende Sicht in Form einer Retrospektive eingenommen, um das Verhalten und die Arbeitsweise der agilen Teams zu optimieren. In der heutigen, schnelllebigen Welt sind Teams und gesamte Unternehmen immer wieder dem Wandel unterlegen. Um nicht zu stolpern, ist wichtig, dass die organisatorischen und kulturellen mit den agilen Veränderungen abgestimmt sind.

 

Wollen auch Sie von unseren Erfahrungen profitieren und professionelles Requirements Engineering betreiben? Unsere RE-Spezialisten unterstützen Sie gerne über Hürden hinweg zum Projekterfolg!

Falls Sie gerne mehr zum Thema Requirements Engineering im agilen Umfeld erfahren möchten, können wir Ihnen unseren Blogbeitrag zum Thema «Agiles Requirements Engineering: Unsere Erfolgsrezepte» empfehlen.

Um bestimmt keinen weiteren Beitrag mehr zu verpassen, folgen Sie uns auf Linkedin!

Stefanie Schütz

Stefanie Schütz

Senior Consultant

 stefanie.schuetz@valion.ch

Roland Maurer

Roland Maurer

Senior Technical Consultant

 roland.maurer@valion.ch

Jean-Marc Riser

Jean-Marc Riser

Senior Technical Consultant

 jean-marc.riser@valion.ch

David Meier

David Meier

Technical Consultant

 david.meier@valion.ch

Stefan Loretan

Stefan Loretan

Manager

 stefan.loretan@valion.ch

Stefano Marcone

Stefano Marcone

Technical Consultant

 stefano.marcone@valion.ch

Share This