Einführung Requirements Engineering und Projektmanagement
Das Management von Anforderungen bzw. Requirements Engineerings sollte immer integraler Bestandteil von (agilem) Projektmanagement sein. Denn es schützt Projekte davor, plötzlich in Schieflage zu geraten. Etwa indem sich bestimmte Vorgaben des Kunden später als nicht realisierbar erweisen. Daher muss jede einzelne Anforderung zuvor auf Herz und Nieren geprüft werden. Dies hilft, Risiken zu minimieren, Kosten zu senken und den Zeitplan einzuhalten.
In diesem Artikel behandelte Themen
- Was ist Requirements Engineering und warum ist es im Projektmanagement so wichtig?
- Worin bestehen die Ziele von Requirements Engineering?
- Warum ist Requirements Engineering wichtig?
- Was versteht man unter einer Anforderung?
- Erhebung, Analyse, Dokumentation und Management
- Aufgaben eines Requirements Engineers
- Anforderungen auf dem Prüfstand: Qualitätskriterien
- Arten der Anforderung: Funktional vs. nicht-funktional
- Anforderung richtig formulieren: Lösung nicht vorwegnehmen
- Fazit: Besser auf Anforderungsmanagement setzen!
Ziel des Beitrags: Projektverantwortliche erfahren, was Requirements Engineering ist und wie sie Anforderungen richtig einordnen, Streitigkeiten im Projekt vermeiden und Risiken minimieren.
Was ist Requirements Engineering und warum ist es im Projektmanagement so wichtig?
Sicherlich haben Sie es schon bemerkt: Sowohl in der deutschen als auch in der englischen Übersetzung geht es um Anforderungen (Requirements). Dass diese in komplexen Projekten irgendwie “gemanagt” werden müssen, ist noch unmittelbar einleuchtend. Aber “Engineering”?
Tatsächlich ist das Anforderungsmanagement ein wichtiger Bestandteil bei der Entwicklung und Konstruktion von Maschinen, Software und anderen Produkten. Nicht selten werden im Maschinenbau deshalb auch Ingenieure für das Requirements Engineering eingesetzt. Und in der Software- oder Web-Entwicklung greifen wir entsprechend auf Experten zurück – hier ist es Bestandteil von Software Engineering. Es geht also um deutlich mehr als nur um Projektmanagement: Fachliche Expertise ist unabdingbar!
Grob gesprochen umfasst Requirements Engineering alle Methoden und Maßnahmen, um Problemen im Projekt vorzubeugen. Während Testing die eine, nachgelagerte Seite der Medaille ist, zeigt das Anforderungsmanagement die andere, vorgelagerte Seite.
In diesem Zusammenhang vielleicht ebenfalls interessant für Sie: “Wie bereite ich ein digitales Projekt perfekt vor?”
Worin bestehen die Ziele von Requirements Engineering?
Häufig werden Vorgaben durch den Auftraggeber kommuniziert und einfach umgesetzt. Geprüft wird vielfach nur, ob sie richtig verstanden wurden und was ihre Realisierung kostet. Unberücksichtigt bleibt oft, inwieweit sie sinnvoll sind, ob es einfacher und vielleicht kostengünstiger geht. Denn der Kunde ist schließlich König! So beginnen oftmals Projekte, die ohne Anforderungsmanagement auskommen (müssen).
Wer sich stattdessen frühzeitig um das Erheben und Managen seiner Anforderungen kümmert, verfolgt die folgenden Ziele:
- Kosten während der Realisierung senken
Gerade das frühzeitige Kümmern um Anforderungen ist also wichtig, um die genannten Ziele zu erreichen. Wie groß die Vorteile durch Requirements Engineering sind, lässt sich gut an der sogenannten “Rule of Ten” veranschaulichen.
Warum ist Requirements Engineering wichtig?
Die “Rule of Ten” besagt, dass Fehler möglichst früh erkannt und behoben werden sollten: Denn bei jeder Produktionsstufe verzehnfachen sich die Folgekosten, um einen Fehler zu beheben. Fehler, die also bereits vor der Entwicklung des Projekts oder einzelner Komponenten erkannt werden, reduzieren die Kosten während der gesamten Projektlaufzeit (s. Projektlebenszyklus) drastisch. Und gerade das Vorbeugen von Fehlern ist die Domäne von Requirements Engineering!
Beispiele für Rule of Ten
- Rückrufaktion von Produkten
- Hohe Abbruchrate im Online-Shop
- Ausnutzung einer Schwachstelle in einer Software (Hacker-Angriff)
- Höhere Projekteffizienz
- Weniger Change Requests im Projektverlauf
- Verlagerung von Fehlern in das Vorprodukt
- Frühes Erkennen von Problemen
- Geringere Projektkosten, da Folgekosten aus Fehlern vermieden werden
- Projektabschluss „in time and budget”
- Höhere Kundenzufriedenheit
- Weniger Imageschäden
- Zielorienter Abschluss
Hat man einen Fehler also einmal “verbaut”, kann es äußerst schwierig sein, ihn zu reparieren. Ein mangelhaftes Requirements Engineering kann so äußerst unangenehm werden. Doch manchmal sind die Ergebnisse auch zum Schmunzeln:
Das sogenannte UX Designer Paradox hingegen zeigt, dass mangelhaftes Anforderungsmanagement auch dazu führen kann, dass ein vermeintlich innovatives Produkt leider überhaupt nicht zu den formulierten “Musts” des Endkunden passt. Bevor Sie also teure Features in Ihr Produkt einbauen, lohnt sich ein genauer Blick auf die Anforderungen Ihrer Zielgruppe. Auftraggeber, Designer und auch Entwickler realisieren zu oft Funktionen, die ihren eigenen Wünschen und Vorlieben entsprechen. Requirements Engineering hilft Ihnen dabei, diese Fehlentwicklungen zu vermeiden.
Kurzum: Offensichtlich gibt es also Anforderungen, die eher nicht so gut sind! Und das, obwohl die Projektbeteiligten von ihnen überzeugt waren. Persönliche Vorlieben sind anscheinend völlig ungeeignet, um eine Anforderung bewerten zu können.
Was versteht man unter einer Anforderung?
Schon dem Wort nach ist eine Anforderung etwas, das “angefordert” wird. Sie ist somit üblicherweise ausdrücklich verlangt, erbeten und muss daher in jedem Fall kommuniziert werden. Da sie wortwörtlich “gefordert” wird, handelt es sich um eine benötigte Eigenschaft. Entsprechende Vorgaben können unter anderem von Auftraggebern, Behörden, dem Gesetzgeber, Mitarbeitern oder Endkunden gestellt werden:
- Dritte: Was muss das System aus formaler, rechtlicher oder vertraglicher Sicht erfüllen (z. B. Gesetze, Normen, Spezifikationen)?
Wer aber bestimmt, was gefordert wird, was für Ihr Projekt wichtig ist? Und wie entscheiden Sie, wenn unterschiedliche Auffassungen darüber, was wichtig ist, zu Streitigkeiten führen? Gerade hier setzt Anforderungsmanagement an.
Erhebung, Analyse, Dokumentation und Management
Kunden sind keine IT-Experten. Gewisse Zusammenhänge können diese verständlicherweise weder kennen noch verstehen. Also formulieren Kunden ihre Anforderungen oft unvollständig, unstrukturiert, fehlerhaft, nicht immer verständlich und teilweise sogar widersprüchlich. Gleichzeitig erwarten sie, dass der IT-Dienstleister alles verstanden hat, jeden Punkt genau prüft, Risiken abwägt und das gewünschte Software-Produkt gemäß den Vorgaben realisiert.
Hier kommt das Requirements Engineering ins Spiel, das im Grunde wie folgt abläuft:
- Anforderungen erheben: Was muss das Produkt aus Sicht des Auftraggebers, des Endkunden etc. erfüllen oder leisten?
Anforderungsmanagement besteht im Grunde also darin, implizite Anforderungen explizit zu formulieren. Ein Anforderungsmanager stellt somit sicher, dass diese unter anderem vollständig, korrekt, verständlich und realisierbar sind. Dazu kümmert er sich um deren Erhebung, Analyse, Dokumentation und Management.
Agiles Projektmanagement und Requirements Engineering (ARE)
In agilen Projekten findet Anforderungsmanagement im Grunde die ganze Zeit über statt. Anforderungen werden für jedes Feature ermittelt, etwa in “User Stories” (so nennt man im Projektmanagement allgemeine Beschreibungen beispielsweise von Software-Features).
Auch hier geht es darum, eine Anforderung zu erheben (hier des Website-Besuchers), ohne etwa eine konkrete technische Lösung vorwegzunehmen (vgl. unten) – und zwar in der Sprache des Kunden.
Die wohl wichtigste Frage- oder Problemstellung im Requirements Engineering lautet damit: Wie ermitteln wir jede einzelne relevante Anforderung für das Projekt, falls/wenn der Auftraggeber nicht in der Lage dazu ist, sie zu kommunizieren?
Aufgaben eines Requirements Engineers
Im Grunde enthält jedes durchdachte Projektmanagement bereits ein Anforderungsmanagement. In agilen Projekten findet etwa eine Priorisierung durch den sogenannten Product Owner statt. Das ist die Person, die die Aufgabenliste verwaltet und die Priorisierung vornimmt.
Was kann ich tun, wenn mich die Masse an Anforderungen erschlägt?
- Priorisieren: Wichtige Aufgaben werden nach oben priorisiert, weniger wichtige nach unten. So werden alle notwendigen Punkte zuerst abgearbeitet, weniger wichtigere nach hinten verschoben.
- Sprints: Um den Überblick nicht zu verlieren, wird nicht alles auf einmal abgearbeitet. Das Projekt wird in kleinere Pakete aufgeteilt, die nach und nach in sogenannten Sprints realisiert werden.
- Eliminieren: Vielfach werden in Projekten Dinge realisiert, die – wenn man mal ehrlich ist – niemand braucht. In einer bereits priorisierten Liste aller Anforderungen sollten jene mit geringer Priorität auf den Prüfstand gestellt werden.
- Verfallsdatum: Wenn manches davon auch nach Monaten oder gar Jahren nicht umgesetzt wurde, das Projekt vielleicht sogar längst online gegangen ist, lohnt es sich, über ein Verfallsdatum nachzudenken. Ist etwas zum Beispiel älter 12 Monate, wandert es ins Archiv.
- Qualitätskriterien: Legen Sie Kriterien für Anforderungen fest! Dann wird Ihre Anforderungsliste stets aufgeräumt(er) sein. Die Priorisierung fällt Ihnen leichter, bestimmte Dinge können ohne Streit eliminiert werden. Welche Qualitätskriterien sinnvoll sind, diskutieren wir weiter unten.
Je mehr eine solche Person zum fachlichen Gehirn im Erstellen, Verwalten und Analysieren von Vorgaben wird, unter anderem die Dokumentation vornimmt und Beziehungen zwischen Anforderungen herstellt, desto mehr wird er zum Requirements Engineer. Weg vom reinen Projektmanagement, hin zum fachlich versierten, dokumenten- oder datenbankbasierten Anforderungsmanagement: So lässt sich eine Abgrenzung zu Projektmanagern vornehmen, wobei die Grenze durchaus fließend ist.
Anforderungen auf dem Prüfstand: Qualitätskriterien
Jedes komplexere Projekt kennt sie: Diskussionen darüber, inwieweit eine bestimmte Anforderung Sinn ergibt, überzogen, zu teuer oder schlicht nicht realisierbar ist. Oft prallen ganz unterschiedliche Meinungen und Sichtweisen aufeinander, und ausgetauscht werden dann mal mehr, mal weniger gute Begründungen. Am Ende setzt sich nicht selten derjenige durch, der den längeren Atem, das Budget oder eben “das Sagen” hat – oft mit fatalen Konsequenzen für den Projekterfolg!
Anforderungen, die bei Einhaltung von Qualitätskriterien so keine Chance auf eine Berücksichtigung im Projekt hätten, führen dazu, dass beispielsweise ein Webprojekt
- zu teuer wird,
Hinzu kommt, dass so manche Anforderung nicht wirklich objektiv ist. Was zu Problemen führen kann!
Qualitätskriterien helfen dabei, sich gegen sinnlose oder überzogene Forderungen durchzusetzen
Qualitätskriterien helfen dabei, endlose Diskussionen und Auseinandersetzungen zu vermeiden. Formulieren Sie mit allen Beteiligten klare Kriterien, die für jede Anforderung erfüllt sein müssen. Welche Qualitätskriterien Sie tatsächlich brauchen, kann stark von Ihrem Projekt abhängen.
Ausführlich beschrieben und erklärt wird all dies (und vieles mehr) in dem aktuellen Fachbuch “Basiswissen Requirements Engineering” von Klaus Pohl und Chris Rupp.
Häufig spielen die folgenden Kriterien eine wichtige Rolle:
- Realisierbar: Anforderungen müssen in dem gesetzten zeitlichen Rahmen und mit den vorhandenen Ressourcen technisch und finanziell machbar sein.
Bevor Sie Ihre Anforderungen anhand von Qualitätskriterien erheben und schließlich formulieren, sollten Sie zwischen funktionalen und nicht-funktionalen unterscheiden. Dies hilft Ihnen beispielsweise dabei, nicht etwa Funktion und Design zu vermengen, sondern daraus unterschiedliche Anforderungen zu generieren.
Arten der Anforderung: funktional vs. nicht-funktional
Gemeinhin beschreiben Auftraggeber, WAS eine Software tun soll. Zumindest liegt der Schwerpunkt oft auf diesen funktionalen Aspekten. Weil das häufig aber nicht ausreicht, um jede Anforderung zu berücksichtigen, braucht es auch nicht-funktionale Anforderungen. Mit diesen wird darüber hinaus gefordert, WIE oder WIE GUT das System eine Aufgabe erfüllen soll (etwa Zeitverhalten, Zuverlässigkeit, Wartbarkeit, Sicherheit, Aussehen, Usability, Leistung und Effizienz) – also Qualitätsanforderungen.
- Beispiel für eine funktionale Anforderung: Das Shop-System soll den Checkout in einem Schritt durchführen (sog. One-Page-Checkout).
Nicht-funktional sind neben den Qualitätsanforderungen in der Regel auch die Randbedingungen (Constraints). Eine Randbedingung könnte zum Beispiel darin bestehen, dass ein Projekt mit dem Content-Management-System TYPO3, einem PHP-Framework wie Laravel oder nach einem bestimmten Standard realisiert werden soll. Neben solchen technischen bzw. normativen Constraints können etwa auch kulturelle oder spezifische Vorgaben des Auftraggebers einschränkend wirken.
Die Anforderung richtig formulieren: Lösung nicht vorwegnehmen!
Anforderungen beschreiben nicht, wie etwas realisiert werden soll (auf welche Art und Weise, mit welcher Technologie o. ä.). Demgegenüber sollen Entwickler entscheiden können, mit welcher Lösung sie die Anforderung erfüllen. Dabei nehmen sie die Nutzerperspektive ein, in der agilen Entwicklung etwa in Form von User Stories. Damit sollen praktikable, aber auch neue, innovative Lösungen gefördert werden. Die Anforderung soll nicht die Lösung vorwegnehmen, da so meist nur althergebrachte Ergebnisse gefördert werden.
Fazit: Besser auf Anforderungsmanagement setzen!
Requirements Engineering im Projektmanagement bedeutet, sich mit Anforderungen systematisch zu beschäftigen – und das möglichst frühzeitig, da sonst die Kosten in späteren Projektphasen überproportional steigen können (s. “Rule of Ten”). In sehr komplexen oder besonders komplizierten Projekten gleichen die Anforderungen einem Bau- oder Konstruktionsplan, da Abhängigkeiten zwischen diesen erstellt, verfeinert und durch Änderungen aktualisiert werden. Dann kann es auch sinnvoll sein, ein datenbankbasiertes Requirements Engineering zu nutzen, um Aktualisierungen automatisch an der einen Stelle vornehmen zu können, wenn sich an einer anderen Stelle eine Anforderung ändert.
Qualitätskriterien sind besonders wichtig, weil eine Anforderung nicht durch subjektives Empfinden bewertet werden sollte, sondern durch objektive, unter allen Beteiligten geteilte Maßstäbe. Und es ist wichtig, sie richtig einzuordnen: Betrifft eine Anforderung eine Funktion oder geht es eher um einen reinen Design-Aspekt?
Obwohl sich der Requirements Engineer viel mit Dokumentation und Analyse beschäftigt, sollte er kommunikationsstark sein. Denn er muss die Wünsche aller Stakeholder unter einen Hut bringen und dem Entwicklungsteam kommunizieren. Er behält das Ziel im Blick, ein Produkt zu entwickeln, das die gesetzten Anforderungen erfüllt, unter Minimierung von Kosten und Risiken.
Bei blindwerk setzen wir konsequent auf professionelles Anforderungsmanagement und führen die digitalen Projekte unserer Kunden so zum Erfolg. Vereinbaren Sie gerne ein unverbindliches Erstgespräch mit uns, um mehr über unsere Arbeitsweise zu erfahren!
Fragen? Gerne direkt an die Geschäftsleitung:
Unsere Markenerfahrung