Unvollständige, inkonsistente oder unzureichend abgestimmte Anforderungen sind mitverantwortlich für das Scheitern vieler Projekte. Obwohl diese Erkenntnis nicht neu ist, wird dem Requirements Engineering in der Praxis oft zu wenig Aufmerksamkeit geschenkt. In diesem Beitrag gehe ich näher auf die Herausforderungen beim Requirements Engineering ein. Der Fokus liegt dabei auf der ersten Hauptaufgabe: der Anforderungsermittlung.
Requirements Engineering (RE) sollte heutzutage fester Bestandteil eines jeden Projekts sein. Fehlendes oder unzureichendes RE führt zu stillschweigenden Annahmen, zu unvollständigen, inkonsistenten oder unzureichend abgestimmten Anforderungen. Daraus resultieren oft hohe Fehlerquoten und enorme Mehrkosten. Obwohl diese Erkenntnis nicht neu ist, wird dem Requirements Engineering in vielen Projekten zu wenig Aufmerksamkeit geschenkt. Gründe für mangelhaftes RE sind das Streben nach einer schnellen Umsetzung und der Versuch Geld zu sparen. Auch wird irrtümlich angenommen, dass die Ziele ohnehin klar sind. Gutes Requirements Engineering spart viel Zeit, Geld und nicht zuletzt Nerven.
Um das Thema RE bei unseren Projekten zu intensivieren, haben viele solvistas Mitarbeiterinnen und Mitarbeiter Schulungen besucht und wurden vom International Requirements Engineering Board (kurz IREB) zertifiziert.
Doch was macht „gutes Requirements Engineering“ eigentlich aus? Um diese Frage beantworten zu können, betrachten wir zunächst die verschiedenen Aufgaben eines Requirements Engineers. Nach IREB besteht Requirements Engineering aus den folgenden vier Haupttätigkeiten:
- Anforderungsermittlung
- Anforderungsdokumentation
- Anforderungsprüfung und -abstimmung
- Anforderungsverwaltung
Im Laufe eines Projekts werden diese Tätigkeiten iterativ durchgeführt. Jede einzelne dieser Tätigkeiten ist dabei wichtig und nicht zu vernachlässigen. Um den Rahmen dieses Beitrags nicht zu sprengen, wird im folgenden ausschließlich auf die Ermittlung der Anforderungen näher eingegangen.
Anforderungsquellen
Vor Ermittlung der Anforderungen müssen sämtliche für das Projekt relevanten Anforderungsquellen identifiziert werden. Mögliche Quellen für Anforderungen sind:
- Stakeholder: Personen oder Organisationen, die (direkt oder indirekt) Einfluss auf die Anforderungen haben. Beispiele für Stakeholder sind Nutzer, Betreiber, Entwickler, Architekten, Auftraggeber und Tester.
- Dokumente: Dokumentationen und Anforderungsdokumente von Altsystemen, branchenspezifische Literatur, sowie Normen/Standards oder Gesetzestexte enthalten oft wichtige Informationen um Anforderungen zu gewinnen.
- Systeme in Betrieb: Alt- bzw. Vorgängersysteme, aber auch Konkurrenzprodukte sind oft Quellen für Änderungs- und Erweiterungswünsche.
Anforderungskategorisierung nach dem Kano-Modell
Sobald alle relevanten Anforderungsquellen identifiziert sind, steht der Ermittlung der Anforderungen nichts mehr im Weg. Es ist hilfreich, bereits bei der Erhebung ein Bewusstsein für den Einfluss der Anforderungen auf die Zufriedenheit der Stakeholder zu schaffen. Die Anforderungen sind nach dem sogenannten Kano-Modell in folgende Kategorien einzuteilen:
- Basisfaktoren: Als selbstverständlich vorausgesetzte Systemmerkmale (unterbewusste Anforderungen), welche das System auf jeden Fall vollständig erfüllen muss. Nicht erfüllte Basisfaktoren führen zu starker Unzufriedenheit bei den Stakeholdern.
- Leistungsfaktoren: Merkmale, welche die Stakeholder bewusst und explizit fordern (bewusste Anforderungen). Der Grad der Erfüllung der Leistungsfaktoren ist direkt proportional zur Zufriedenheit der Stakeholder.
- Begeisterungsfaktoren: Unbewusste, nicht einmal erträumte Anforderungen, deren Erfüllung die Zufriedenheit der Stakeholder überproportional steigern.
Da sich die Benutzer des Systems an dessen Merkmale gewöhnen, werden im Laufe der Zeit aus Begeisterungsfaktoren Leistungsfaktoren und letztendlich Basisfaktoren. Es ist wichtig, beim Requirements Engineering alle drei Kategorien zu berücksichtigen.
Ermittlungstechniken
Viele Methoden und Techniken können bei der Erhebung von Anforderungen unterstützen. Eine universell einsetzbare Vorgehensweise gibt es allerdings nicht. Da gerade zu Beginn eines Projektes vermehrt Kommunikationsprobleme auftreten können und Kunden, Fachexperten und Entwickler zunächst von einander lernen müssen „die gleiche Sprache zu sprechen“, bieten sich zu Beginn insbesondere die folgenden Techniken an:
- Interviews: Bei einem Interview werden einem oder mehreren Stakeholdern Fragen gestellt und die Antworten protokolliert.
- Workshops: Im Zuge von Anforderungsworkshops werden die Anforderungen in Zusammenarbeit mit den Stakeholdern erarbeitet. Diese dauern ein paar Stunden bis hin zu einigen Tagen.
- Feldbeobachtungen: Bei einer sogenannten Feldbeobachtung ist der Requirements Engineer vor Ort bei den Spezialisten bzw. Anwendern des Systems. Er beobachtet und dokumentiert die Prozesse, Handgriffe und Arbeitsabläufe.
Dadurch lernt der Requirements Engineer rasch die Fachbegriffe kennen. Dabei wird ein Glossar erstellt und laufend erweitert. Nach Erfassen der Begrifflichkeiten und der ersten Anforderungen werden weitere Methoden eingesetzt:
- Use-Case-Modellierung: Ein Use-Case bündelt alle möglichen Szenarien, die eintreten können, wenn ein Akteur versucht, mit Hilfe des betrachteten Systems ein bestimmtes fachliches Ziel zu erreichen. Ziel der Use-Case-Modellierung ist es, möglichst alle relevanten Use-Cases zu erfassen.
- Prototyping: Prototypen eignen sich besonders, um erarbeitete Anforderungen, von denen die Stakeholder nur eine vage Vorstellung haben, zu hinterfragen und zu ermitteln.
Die bisher erwähnten Methoden bieten sich besonders gut für die Ermittlung von Basis- und Leistungsfaktoren an. Um Begeisterungsfaktoren ermitteln zu können, empfiehlt sich der Einsatz von Kreativitätstechniken:
- Brainstorming: Beim Brainstorming werden zwei Phasen durchgeführt. In der ersten Phase werden (spontane) Ideen gesammelt. In der zweiten Phase wird gruppiert und bewertet.
- Brainstorming paradox: Bei dieser Variante des Brainstormings werden Ereignisse und Merkmale gesammelt, die nicht eintreten sollen. Anschließend werden Maßnahmen erstellt, die das Eintreten dieser verhindern.
- Perspektivenwechsel: Beim Perspektivenwechsel ändern die TeilnehmerInnen ihren Blick auf das zu entwickelnde System und betrachten es aus einer völlig neuen Perspektive. Diese liefert Anregungen, die man sonst nicht oder nur nach langer Suche gefunden hätte.
Fazit
Requirements Engineering ist ein wichtiger Tätigkeitsbereich eines jeden Projektes. Wird diesem Bereich die nötige Aufmerksamkeit und Zeit geschenkt, können letztendlich viel Zeit, Geld und Nerven gespart werden. Unsere spezialisierten Requirements Engineers bilden dabei die Schnittstelle zwischen dem Fachbereich und der IT der jeweiligen Abteilung. Wie Sie in agilen Projekten mit hoher Anforderungsinstabilität den Überblick bewahren, wird in einem Folgebeitrag genauer erläutert.
Autor: Wolfgang CARL