Der beste Prozess im Anforderungsmanagement

Es gibt viele Faktoren, die über den Erfolg oder Misserfolg von Projekten entscheiden: der Projektstart, die Projektplanung und -durchführung, die Verfügbarkeit von Mitarbeitern, das Commitment des Managements und: das Anforderungsmanagement. Es ist eine Schlüsseldisziplin bei der Entwicklung von Software und Systemen. Dabei geht es jedoch nicht um eine effiziente Art der Verwaltung von Anforderungen, sondern um die bestmögliche Vorgehensweise zur Ermittlung von Anforderungen – häufig auch als Requirements Engineering bezeichnet. Wie funktioniert dieses Requirements Engineering oder anders gefragt: Was ist der beste Prozess im Anforderungsmanagement?

Die Definition des Systemkontexts

Mit dem Systemkontext definieren Sie die Bereiche eines Systems, für die Sie Anforderungen erheben. Wird der Systemkontext nicht vollständig definiert, werden auch die Anforderungen unvollständig bleiben. Für ein zu entwickelndes System ist die Betrachtung des Systemkontexts wichtig, denn mit der Definition von System und Systemgrenze, sowie relevanter und irrelevanter Systemumgebung legen Sie fest, welche Aspekte im Rahmen einer Entwicklung zu beachten sind. Auch Gesetze, Normen, Richtlinien sind bei der Beurteilung der Kontextgrenzen zu berücksichtigen. Nicht immer stehen jedoch zu Projektbeginn alle Informationen zur Verfügung oder das Management tut sich schwer mit Entscheidungen über den Scope der Entwicklung. So entstehen Grauzonen, die Sie so früh wie möglich beseitigen sollten, um im Laufe des Projekts Probleme, Aufwände und Kosten zu vermeiden.

Das Stakeholdermanagement

Identifizieren, analysieren und kommunizieren – das sind die drei wesentlichen Tätigkeiten im Stakeholdermanagement. Stakeholder sind Personen, Gruppen und Organisationen, die von Aktivitäten eines Unternehmens direkt oder indirekt betroffen sind oder ein konkretes Interesse an diesen Aktivitäten haben. Die Stakeholderidentifikation ist der erste Schritt im Stakeholdermanagement. Sie verfolgt das Ziel, alle Organisationen und Personen zu bestimmen, die von der Software- oder Systementwicklung direkt oder indirekt betroffen sind oder ein konkretes Interesse an den Ergebnissen der Entwicklung haben. Das Ergebnis sollte eine Liste aller Stakeholder sein. Basierend auf dieser Liste ermittelt die Stakeholderanalyse die wichtigsten Stakeholder, deren Ziele, Motive und Einstellungen.

Warum ist das wichtig? Anforderungen konkretisieren Ziele bzw. aus den Zielen der Stakeholder lassen sich Anforderungen ableiten und gegebenenfalls auch Grauzonen im Systemkontext beseitigen. Damit ist jedoch das Stakeholdermanagement noch nicht abgeschlossen, denn die regelmäßige Kommunikation mit den Stakeholdern ist ebenfalls sehr wichtig. Stakeholder ändern ihre Meinungen, Ziele verschieben sich und daraus ergeben sich neue Prioritäten und oft auch neue Anforderungen. Durch die Stakeholderkommunikation erhalten sie strukturiert und frühzeitig Feedback und Meinungen, die Sie nutzen können, um Konflikte zu vermeiden.

Die Verwendung von Szenarien

Ein Szenario ist die Beschreibung einer möglichen Abfolge von Ereignissen. Szenarien lassen sich nach Inhalt und Kontext klassifizieren. So gibt es fünf verschiedene inhaltliche Kategorien:

• Operational Scenario
• Failure Scenario
• Performance Scenario
• Refinement Scenario
• Learning Scenario

Und bei der Kontext-Klassifikation gibt es drei Kategorien:

• Systeminternes Szenario
• Interaktionsszenario
• Organisatorisches Szenario

Die Kontext-Klassifikation grenzt Szenarien inhaltlich deutlich von Anwendungsfällen ab. Ein systeminternes Szenario beschreibt bspw. die Interaktion von verschiedenen Komponenten innerhalb eines Systems, ohne dabei den Kontext zu beachten, in den das System eingebettet ist. Die inhaltlichen Kategorien hingegen fokussieren nicht den Kontext, sondern legen das Augenmerk auf unterschiedliche Perspektiven der Beschreibungen, die über die Nennung von Ereignissen hinausgehen. So kann ein Szenario auch mehreren Kategorien zugeordnet werden, also bspw. ein funktionales und ein erläuterndes Szenario darstellen. Warum sind Szenarien interessant für das Anforderungsmanagement? Der Vorteil liegt in den unterschiedlichen Blickwinkeln, die durch Szenarien gewonnen werden. Sie helfen bei der Entwicklung von Zielen, bei der Identifikation von Stakeholdern und auch bei der Definition der Systemgrenzen. Anforderungen können durch Szenarien beschrieben werden und aus Szenarien lassen sich Anforderungen und Ziele ableiten. Insgesamt ist das Arbeiten mit Szenarien, Stakeholdern, Zielen und Anforderungen sehr verzahnt und iterativ.

Die Ermittlung von Anforderungen

Nachdem Sie den Systemkontext definiert und die Stakeholder analysiert haben, gilt es nun, die richtigen Anforderungen zu ermitteln. Hier helfen verschiedene Konzepte und Techniken. Die Durchführung von Anforderungsworkshops ist bspw. eine wirksame Möglichkeit zur Entwicklung von Anforderungen. Im Zuge der Workshops lassen sich Anforderungen aus Zielen und Szenarien ableiten, verfeinern und bewerten, und ein Konsens unter den Stakeholdern herstellen. Durch Kreativitätstechniken wie bspw. Brainstorming, Brainwriting und Braindumping können weitere Anforderungen ermittelt werden. Sind Stakeholder mit Anforderungsworkshops nicht vertraut oder können bzw. wollen keine Zeit dafür aufbringen, helfen Beobachtungstechniken wie Feldbeobachtung, Apprenticing und Contextual Inquiry, oder Befragungstechniken wie Fragebogen, Interview und Selbstaufschreibung.

Darüber hinaus gibt es noch viele weitere Optionen zur Ermittlung von Anforderungen wie bspw. das Arbeiten mit Personas und Use Cases, die Nutzung von Systemarchäologie und perspektivenbasiertem Lesen, oder die Verwendung von Prototypen. Tatsächlich ist es in der Realität nicht so einfach, die richtigen Anforderungen zu ermitteln. Und leider lässt sich die Frage nach den besten Konzepten und Techniken zur Ermittlung der relevanten Anforderungen nicht allgemeingültig beantworten. Vermutlich ist es keine gute Idee, mit unmotivierten Stakeholdern ein Brainstorming durchzuführen oder sie zu Anforderungsworkshops einzuladen. Hier könnte bspw. eine Feldbeobachtung deutlich bessere Erkenntnisse liefern.

Anforderungen und Architektur

Oft stehen Organisationen vor der Frage, wie sie bei der Entwicklung eines neuen Systems vorgehen sollen. Anforderungen und die Architektur eines Systems hängen stark voneinander ab – sollten also zuerst Anforderungen erfasst oder zuerst die Softwarearchitektur entworfen werden? Anforderungen ändern sich häufig, neue Technologien erscheinen und frühere Designentscheidungen müssen überdacht werden. Hier bietet das Twin Peaks Modell Unterstützung. Es empfiehlt zu Beginn, die wichtigsten Anforderungen an ein System rudimentär zu entwerfen, um darauf basierend einen Prototypen oder ein Minimum Viable Product (MVP) zu entwickeln. Erhalten Stakeholder nun die Möglichkeit, ihre Meinungen und Eindrücke zu einem Prototyp zu äußern, hilft das den Organisationen, Anforderungen besser zu verstehen. Die neuen Erkenntnisse können zur Überarbeitung des Prototyps genutzt werden – und so entsteht eine Verzahnung aus Anforderungen und Architektur mit einer parallelen, iterativen Entwicklung.

Anforderungen prüfen und dokumentieren

Die wichtigste Aufgabe im Anforderungsmanagement bzw. Requirements Engineering ist die Ermittlung von Anforderungen. Es gilt die Anforderungen zu erheben, die technisch, finanziell und auch personell realisierbar sind. Natürlich sollten die Anforderungen vollständig sein. Und widerspruchsfrei. Um dies alles zu gewährleisten muss die Qualität der Anforderungen geprüft werden. Je mehr Anforderungen es zu realisieren gilt, desto mehr Informationen müssen geprüft werden. Und dazu müssen die Anforderungen dokumentiert sein. Idealerweise werden Anforderungen mit einer festgelegten Struktur und Form verwaltet. So lässt sich gut überprüfen, ob immer alle notwendigen Informationen zu einer Anforderung vorliegen.

Die Dokumentation läuft häufig auf ein Lastenheft, ein Pflichtenheft oder ein Spezifikationsdokument hinaus. 15 % aller Softwarefehler werden ausgeliefert und ein Großteil dieser Fehler steckt bereits in der Spezifikation. Anforderungen von Kunden werden falsch verstanden, Anwendungsfälle unvollständig beschrieben und Begriffe unterschiedlich interpretiert. Diese Probleme wirken sich natürlich nicht nur auf Spezifikationen sondern auch auf Architekturentwürfe, Testfälle, sämtliche schriftlichen Zwischenergebnisse der Softwareentwicklung und den Quellcode aus. Es ist also wichtig, die Spezifikation – gerne auch mehrmals – zu überprüfen. Natürlich verursacht die Überprüfung einer Spezifikation Aufwand, doch der lohnt sich häufig im Vergleich zu den Aufwänden, die bei der Beseitigung von ausgelieferten Software- und Systemfehlern entstehen.

Fazit

Der Umgang mit Anforderungen ist ein wesentlicher Erfolgsfaktor in Projekten. Die Vorgehensweise mit der Definition des Systemkontexts, der Analyse von Stakeholdern und ihren Zielen, der Verwendung von Szenarien, der Ermittlung von Anforderungen mit unterschiedlichen Konzepten und Techniken, der Parallelisierung von Systementwurf und Anforderungserhebung, sowie der Prüfung und Dokumentation von Anforderungen, beschreibt den optimalen Prozess im Anforderungsmanagement.

Häufig stehen in der Realität nicht immer alle wichtigen Stakeholder für Rückfragen zur Verfügung, der Berg an Anforderungen ist zu groß (hier könnte die Eliminierung von Anforderungen helfen) oder die Aufwandsschätzung von User Storys mit Story Points macht Probleme. Mit Ausnahme des Systemkontexts, der – sofern möglich – nicht im Laufe eines Projektes verändert werden sollte, ist es empfehlenswert, alle Schritte kontinuierlich im Projekt durchzuführen. So lassen sich Änderungen möglichst frühzeitig erkennen, neue Prioritäten definieren, die Konsistenz und Widerspruchsfreiheit von Anforderungen dauerhaft sicherstellen.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Alles Wichtige über Requirements Engineering auf 37 Seiten jetzt als Download zum Mitnehmen.

Michael Schenkel hat im t2informatik Blog weitere Beiträge zum Umgang mit Anforderungen veröffentlicht, u. a.

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.