Anforderungsmanagement

Die Aufgaben im Anforderungsmanagement

Die Aufgaben im Anforderungsmanagement variieren je nach Perspektive etwas. Grundsätzlich geht es darum, Anforderungen als Beschreibung eines gewünschten Funktionsumfangs zu verstehen. Ziel sollte es sein, korrekte, vollständige, eindeutige, widerspruchsfreie, nach Wichtigkeit und/oder Stabilität bewertete, prüfbare und verfolgbare Anforderungen zu ermitteln.

Das International Requirements Engineering Board (IREB) nennt bspw. vier zentrale Aufgaben:

• Die Ermittlung von Anforderungen inklusive Detaillierung und Verfeinerung.
• Die Dokumentation als adäquate Beschreibung von Anforderungen.
• Die Prüfung und Abstimmung von Anforderungen mit dem Ziel, die Qualität sicherzustellen.
• Die Verwaltung – auch als Requirements Management (also Anforderungsmanagement?) bezeichnet – von Anforderungen.

Die IEEE 24765:2017 spricht bspw. von

• Anforderungserhebung (Requirements Elicitation),
• Anforderungsanalyse (Requirements Analysis),
• Anforderungsspezifikation (Requirements Specification) und
• Anforderungsbewertung (Requirements Validation).

Unabhängig von den feinen Unterschieden der jeweiligen Perspektiven ist ein Punkt sehr wichtig: Anforderungen ändern sich. Neue Anforderungen kommen hinzu, bestehende Anforderungen verlieren ihre Bedeutung. Warum? Weil Stakeholder ihre Meinungen oder Ziele ändern, weil neue Zusammenhänge bei der Realisierung eines Produkts oder der Umsetzung eines Projekts klarer werden oder weil es neue Gesetze und Normen gibt. Daraus ergibt sich, dass Anforderungsmanagement – und damit die Erhebung, Analyse, Spezifikation und Bewertung von Anforderungen – keine einmalige Sache zu Beginn eines Projekts oder eine Entwicklung ist. Im Gegenteil: es handelt sich um eine kontinuierliche Aufgabe.

Herausforderungen beim Anforderungsmanagement

Der CHAOS Report der Standish Group führt regelmäßig unklare Anforderungen als einen wesentlichen Faktor für gescheitere Projekte und Entwicklungen an. Wie kommt es zu unklaren Anforderungen? Entweder wurden sie nicht eindeutig, korrekt, widerspruchsfrei etc. formuliert. Oder es gab Abweichungen zwischen den Wünschen der Stakeholder und der Implementierung der Entwickler. Oder implizite Wünsche von Auftraggebern wurden nicht explizit formuliert und konnten somit von den Auftragnehmern aus Unkenntnis nicht realisiert werden. Offensichtlich gibt es Herausforderungen beim Anforderungsmanagement. Hier finden Sie einige weitere Beispiele:

• Anforderungsmanagement ist eine vollständige Disziplin, die klare Regeln und eine gute Kommunikation zwischen den Beteiligten erfordert. So gilt es bspw. zu klären, wer wann was und wie macht, welche Rollen mit welchen Verantwortlichkeiten, Rechten und Pflichten involviert sind, welche Tools zur Anwendungen kommen, wie Lessons Learned aus früheren Vorhaben oder Good Practices aus bekannten Methoden genutzt werden.
• Wer sind die Stakeholder, welche Wünsche haben sie, welche Stakeholder sind wichtiger als andere, wie erfolgt die Kommunikation im Regelfall und insbesondere bei Schwierigkeiten etc.? Antworten auf diese Fragen sollte das Stakeholdermanagement liefern.¹
• Wie erfolgt die Priorisierung von Anforderungen? Erfolgt die Gewichtung bspw. mit der MoSCoW-Methode oder mit dem Kano-Modell, mit absoluten Werten – eine Anforderung mit dem Wert 984 ist wichtiger als eine mit dem Wert 983 – oder mit Abstufungen wie wichtig, sehr wichtig, unglaublich wichtig?
• Wie lässt sich sicherstellen, dass die wesentlichen Anforderungen rechtzeitig ermittelt, dokumentiert, geprüft und abgestimmt sind, so dass sich bspw. valide Architekturentscheidungen treffen lassen?
• Wie lässt sich der HIPPO-Effekt vermeiden, der eine kognitive Verzerrung beschreibt, wonach die Meinung der bestbezahlten Person – bspw. bei der Definition, Priorisierung und Realisierung von Anforderungen – mehr Beachtung findet?
• Es gibt immer wieder User, die ein System – beabsichtigt oder unbeabsichtigt – entgegen seiner Bestimmung verwenden. Hier können Ansätze wie Misuse Cases oder Chaos Engineering nützliche Perspektiven liefern.
• Wie werden Änderungswünsche dokumentiert? Wer darf überhaupt Änderungswünsche äußern und was geschieht ggf. mit Aufwänden, die für die Realisierung von Anforderungen angefallen sind, wenn diese später aufgrund eines Änderungswunsches nicht im finalen Produkt landen?
• …

Es gibt viele kleine und große Herausforderungen im Anforderungsmanagement. Auch aus diesem Grund lässt sich beobachten, dass viele Unternehmen in die Ausbildung von Mitarbeitenden und in Personenzertifikate wie bspw. den Certified Professional for Requirements Engineering (CPRE) investieren.

Artefakte im Anforderungsmanagement

Es gibt verschiedene Artefakte, in denen Anforderungen erfasst werden. Die Wahl des Artefakts hängt vom spezifischen Kontext ab. Hier finden Sie eine Auswahl:

Lastenheft, Pflichtenheft und SRS

Ein Lastenheft ist ein Dokument eines Auftraggebers, das Anforderungen an ein System und erwartete Leistungen eines Auftragnehmers beschreibt. Die DIN 69901-5 definiert ein Lastenheft entsprechend als „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“. Es handelt sich also um ein Dokument des Auftraggebers mit den Ergebnissen der Anforderungsanalyse und damit um einen Wunschzettel, den ein Auftragnehmer realisieren soll.

Ein Pflichtenheft beschreibt, wie der Auftragnehmer den Wunschzettel des Auftraggebers zu erfüllen gedenkt. Laut DIN 69901-5 umfasst das Pflichtenheft die „vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts“.

Das IEEE (Institute of Electrical and Electronic Engineers) definiert einen Standard zur Spezifikation von Software und Systemen: die sogenannte Systems and Software Requirements Specification (SRS). Die vollständige Bezeichnung lautet: IEEE 29148-2018 – ISO/IEC/IEEE International Standard – Systems and Software Engineering – Life Cycle Processes – Requirements Engineering.

Häufig wird die SRS als Begriff synonym oder als englische Übersetzung für Lastenheft verwendet. Die SRS ist jedoch nicht gleichbedeutend mit einem Lastenheft, denn sie definiert neben den customer requirements – auch C-Requirements genannt – zusätzlich development requirements – entsprechend D-Requirements genannt. In anderen Worten: eine SRS umfasst sowohl Lastenheft als auch Pflichtenheft.

Backlog

In der Software- und Produktentwicklung oder im agilen Projektmanagement ist ein Backlog eine dynamische Sammlung von offenen Aufgaben oder zu realisierenden Anforderungen. Wortwörtlich übersetzt steht der Begriff für Rückstand, Rückstau, Arbeitsrückstand, Nachholbedarf oder Auftragsüberhang. Und to backlog something bedeutet im Deutschen etwas auf Halde legen oder zu späterem Gebrauch beiseitelegen.

Die Struktur von Backlogs ist in Unternehmen unterschiedlich organisiert. Häufig wird zwischen drei Arten unterschieden:

• Product Backlog,
• Release Backlog und
• Sprint Backlog.

Sind im Rahmen einer Entwicklung verschiedene Teams involviert, bietet es sich an, mit Team Backlogs zu arbeiten und die Items entsprechend auf die jeweiligen Teams zu verteilen. Ist nur ein Team involviert, dann sind Release und Team Backlog identisch. Entwickler bzw. Mitarbeiter können auch individuelle, persönliche Listen pflegen.

Der aktuelle Scrum Guide 2020 kennt übrigens nur die beiden Begriffe Product und Sprint Backlog.

User Story

Eine User Story ist eine kurze Beschreibung einer Funktionalität eines Systems aus Sicht eines Anwenders. Sie beschreibt, wer was mit welcher Intention von einem System möchte. Der Begriff User Story stammt aus dem Englischen. Das Wort user bedeutet Anwender oder Benutzer, story bedeutet Geschichte. Im wörtlichen Sinne beschreibt eine User Story also eine Geschichte eines Anwenders. Im agilen Projektmanagement und der Softwareentwicklung ist eine User Story ein Werkzeug, um gewünschte Funktionalitäten eines Systems aus Sicht des Anwenders zu beschreiben.

Als Konzept geht die User Story auf Extreme Programming (XP) – und nicht wie häufig angenommen auf den Scrum Guide – zurück.

Use Case

Use Cases bzw. Anwendungsfälle beschreiben das Verhalten eines Systems, insbesondere die Interaktion zwischen dem System und seinen Anwendern. Der Anwender ist eine Person, eine Rolle, eine Organisation oder ein anderes System. Er tritt als Akteur mit dem System in Interaktion, um ein bestimmtes Ziel in einer definierten Folge von Aktionen zu erreichen. Aus dem Ziel (bspw. „Fahrzeuggeschwindigkeit regeln“ oder „Geld abheben“) ergibt sich normalerweise der Name des Use Cases, so dass auf einen Blick zu erkennen ist, welches Systemverhalten beschrieben wird.

Use Cases werden bereits seit Anfang 1990 in der Softwareentwicklung, bei der Systemerstellung und auch in der Produktentwicklung genutzt. Auch heutzutage sind sie sehr beliebt, denn sie dokumentieren die Funktionalität eines vorhandenen oder geplanten Systems mit einfachen Modellen.

Fragen im Kontext von Anforderungsmanagement

Es gibt eine Liste an Fragen im Kontext von Anforderungsmanagement. Auf einige der Fragen finden Sie Antworten in unserem Blog:

• Was ist ein guter Prozess im Anforderungsmanagement?
• Welche Tipps gibt es zur Durchführung von Anforderungsworkshops?
• Was tun, wenn der Berg an Anforderungen zu groß wird?
• Wie lassen sich Anforderungen binnen 14 Tagen spezifizieren?
• Wie funktioniert die Anforderungsanalyse remote?
• Macht es Sinn, Anforderungen mit MS Excel zu managen?
• Wie lässt sich die Vollständigkeit von Spezifikationen nachweisen?

Sicherlich fallen Ihnen noch weitere Fragen ein. Melden Sie sich gerne bei uns und wir versuchen Ihre Fragen zu beantworten oder entsprechende Beiträge zu publizieren.

Tools für Anforderungsmanagement

Es gibt verschiedene Tools im Anforderungsmanagement bzw. Requirements Engineering. Hier finden Sie eine kleine Liste mit Tools ohne Anspruch auf Vollständigkeit und ohne Bewertung:

• Polarion Requirements von Siemens
• DOORS Next von IBM
• Helix ALM von Perforce
• Visure Requirements
• TraceCloud
• SpiraTest von Inflecta
• Jira von Atlassian

Sicherlich lässt sich die Liste leicht ergänzen, zumal es zahlreiche Produkte gibt, die in Organisationen für die Arbeit mit Anforderungen genutzt werden (bspw. MS Excel oder MS Word), originär aber einen anderen Vermarktungsschwerpunkt haben.

Impuls zum Diskutieren:

Wie lassen sich Aussagen zu Terminen und Kosten treffen, wenn lediglich ein Teil der Anforderungen zu Projekt- oder Entwicklungsbeginn bekannt sind?

Hinweise:

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!

[1] Nicht immer es einfach, mit Stakeholdern Kontakt aufzunehmen oder sie zur aktiven Beteiligung zu animieren. Manche Organisationen wählen daher bewusst das sogenannte Crowdsourcing als kontextuelle, punktuelle, temporäre und zielgerichtete Interaktion einer großen Menge von unternehmensexternen Menschen (Crowd) zur Beschaffung von Wissen (Sourcing).

Hier finden Sie das kostenlose Requirements Engineering Whitepaper zum Downloaden.

Und hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt:

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