Chat with us, powered by LiveChat
zurück zum blog

Requirements Engineering - Wofür und für wen?


Last updated: 25.03.22
Requirements Engineering - Wofür und für wen?

Liebe Jenny! 

Gelegentlich nutzen wir unseren Blog, um einen Einblick in unsere Schulungen zu geben. Was ist das, wer braucht das und wofür kann ich das ganz genau im Alltag nutzen? Danke, dass Du uns für ein kurzes Interview zur Verfügung stehst!

 

Zuerst die Frage: Was verstehe ich unter Requirements Engineering? 

Das Requirements Engineering ist ein Prozess, der definiert und gemanagt sein sollte. Die IREB-Schulung befasst sich ausführlich mit der Konfiguration eines maßgeschneiderten RE-Prozesses, unter Berücksichtigung von Einflussfaktoren aus der Projektumgebung und Facetten von Prozessen (Ziel, Zweck (präskriptiv/explorativ) und Zeit). 

Im Anschluss daran wird das Requirements Management erläutert, das den gesamten Lebenslauf von Anforderungen impliziert. Hier sprechen wir im Kurs über Versionierung, Konfigurationen, Basislinien und Priorisierung oder zum Beispiel Verfolgbarkeit (in allen denkbaren Richtungen: rückwärts, vorwärts und horizontal)).
 

Das klingt ganz schön theoretisch. Was bringt mir die Schulung in der Praxis?

Ich erhalte einen Fahrplan und einen Überblick, was zu tun ist. Wünsche und Bedürfnisse der Stakeholder werden verstanden und die richtigen Personen in den entsprechenden Stakeholder-Rollen werden identifiziert. Denn erst, wenn man diese richtig einbezieht und eine Zusammenarbeit schafft, kann RE wirklich erfolgreich sein.

Außerdem geben wir den Kursteilnehmern neun Prinzipien an die Hand, in denen alle Aufgaben, Aktivitäten und Praktiken zusammengefasst werden. Das hilft schon sehr, um sich ein Gerüst zurechtzulegen, an dem entlang in der Praxis vorgegangen werden kann.

Die Techniken und Überlegungen zu Anforderungsermittlung, -dokumentation und -review sind von Praktikern identifiziert und beschrieben worden, damit sie in jeder Praxis, wenn auch in angepasster Form, einsetzbar sind.

Und, ganz praktisch gedacht: Der IREB behandelt auch Prototypen! Explorative (wie z.B. Wireframes, Mock-Ups), aber auch experimentelle und evolutionäre. 
 

Verstanden. Aber trotzdem bleibt RE in unserem Verständnis ja in erster Linie sehr viel Dokumentation! Du kennst sicher den Einwand, dass das zu aufwändig ist für den ein oder anderen, insbesondere agilen, Projektalltag?

Die Essenz beim RE ist das gemeinsame Verständnis (auch eines der Prinzipien), da gilt es die Dokumentation als Unterstützung dieses zentralen Prinzips zu sehen. Eine vollständige Beschreibung ist in unserer komplexen Welt unmöglich.

Der IREB gibt allerdings konkrete Unterstützung, auf welcher Abstraktionsebene welche Arbeitsprodukte sinnvoll sind und welchen Detaillierungsgrad sie haben sollten. Deren Umfang ist abhängig von ihrer Lebensdauer und dem Entwicklungsmodell. Im Kurs versuche ich genau das zu vermitteln: Wie kann man die Dokumentation an den Projektkontext anpassen und so Lean oder Agil (minimale Dokumentation) halten. 

Der Umgang mit der Dokumentation ist auf Struktur ausgelegt, damit der Übersicht da ist und die Dokumentation somit auch minimal bleiben kann. In allen Belangen steht hier eines der Prinzipien „Wertorientierung“ an erster Stelle.

 

Liegen die Anforderungen als Fließtext vor oder gibt es hier ebenfalls sowas wie eine Kurzschrift?

Der IREB gibt konkrete Anleitungen, schon im Vorfeld Strukturen bereitzustellen, die bei der Beschreibung der Anforderung unterstützen. Das geschieht durch Vorlagen, durch Formulierungshilfen und durch die Definition eines Glossars zur konsistenten Verwendung von Begriffen und einer einheitlichen Terminologie. Worauf zu achten ist, z.B.: kurze Sätze, nur eine einzige Anforderung in einem Satz, sinnvolle Struktur (Satzschablonen zur Unterstützung), und welche Formulierungen zu vermeiden sind (z.B. konkrete statt allgemeine Bezugnahme). Außerdem lehre ich fünf Qualitätskriterien für alle Arbeitsprodukte: Adäquat, notwendig, eindeutig, vollständig, verständlich und verifizierbar. Was man darunter versteht und wie man das umsetzt, kann man bei uns im Kurs lernen.

 

Trotzdem nochmal konkreter nachgefragt: Lassen sich aus den natürlichsprachigen Anforderungen grafische Darstellungen oder Modelle ableiten?

Man kann umfangreiche Anforderungen durch Kompression/Aggregation und durch Selektion reduzieren, um daraus abzuleiten, welches oder welche Modelle geeignet sind, um die Anforderungen zu visualisieren und dadurch für alle Stakeholder leichter verständlich zu machen. Einige Beispiele: 

  1. Ich möchte gerne darstellen, wie die Daten durch das System, durch den Geschäftsvorfall fließen. Nach der ursprünglichen Idee des IREB kann man den Fluss mit Hilfe eines Aktivitätendiagramms modellieren. 
  2. Die Interaktion mit dem betrachteten System möchte ich aus der Use Case Spezifikation ableiten und darstellen. Der IREB betrachtet die unterschiedlichen Perspektiven mit Hilfe der Use Case Diagramme (UML), diese müssen aber mit anderen Diagrammen ergänzt werden, damit eine vollständigere Perspektive auf das künftige System entstehen kann. 
  3. Ich möchte die Daten meines Systems modellieren. Der IREB stellt UML-Klassendiagramme vor. Eine Klasse beschreibt eine Menge von Objekten, ein Attribut beschreibt die Eigenschaft der Klasse. 

Im Training werden die grundlegenden Notationselemente und die verschiedene Diagramme (Aktivitätsdiagramm, Zustandsdiagramm, Zustandsdiagramm) an praktischen Beispielen und Übungen erklärt.

 

Und wo bekomme ich die Anforderungen her? Entstehen diese erst durch die Arbeit der Requirements Engineers?

Jein. Die meisten Anforderungen liegen tatsächlich vor, sie müssen nur als solche gesammelt, geordnet und explizit formuliert werden. Der IREB teilt die Anforderungsquellen in drei Hauptkategorien auf: Stakeholder (Zwiebelmodell nach Ian Alexander, Personas), Dokumente und andere Systeme. Darüber hinaus werden Ermittlungstechniken auf Basis des Kano-Modells ausgewählt, wie z.B. Erhebungstechniken (Befragung, Kollaboration, Beobachtung, artefaktbasiert) und Entwurfstechniken vertieft.

Der IREB befasst sich ebenfalls mit der Lösung von Anforderungskonflikten, die entstehen, wenn verschiedene Stakeholder verschiedene oder sogar widersprüchliche Ansichten zu bestimmten Anforderungen haben. Wege zur Identifizierung von Konflikten, zur Analyse, zur Lösung und zur Dokumentation der Konfliktlösung werden aufgezeigt.
 

Gibt es auch für das RE Tools, die die Arbeit erleichtern?

Die Werkzeuge, die im RE eine wichtige unterstützende Aufgabe haben, werden im IREB in einem eigenen Kapitel behandelt. Das sind zum einen Werkzeuge zum Verwalten von Anforderungen, zum anderen zur Unterstützung des RE-Prozesses. Auch wie RE-Werkzeuge in einer Organisation eingeführt werden sollten und welche Lebenszykluskosten damit verbunden sind, umreiße ich. Außerdem gebe ich Hilfestellung für die Bewertung eines Werkzeugs nach definierten Kriterien.

 

Hab vielen Dank Jenny für Deine Ausführungen! 


PS: Für alle, die bis zum Ende gelesen haben, und nach wie vor Interesse an dem Kurs haben, geht es hier zum trendig IREB-Schulungsangebot.


Please enable JavaScript to view the comments powered by Disqus.