UX & Design

Artikel merken

Requirements Engineering: Bedarfsanalysen für Webprojekte richtig durchführen

Ein gelungenes Projekt, glückliche Kunden und ein zufriedenes Team – das wünscht sich jeder Projektleiter. Doch nur zu oft schießen Software-Projekte über das Budget, die Zeit und den Umfang hinaus. Requirements Engineering hilft, unklare Anforderungen, Last-Minute-Korrekturen und somit Konflikte zu vermeiden.

9 Min. Lesezeit

(Foto: so&amp:#776:ralex / Photocase)

Immer wieder driften bei Webprojekten Anforderungen von Kunden und Lösungen von Agenturen auseinander. Der Grund: Zum einen denken viele Projekt-Manager viel zu schnell in vertrauten Lösungen, anstatt den Bedarf ihrer Kunden genau zu analysieren und nehmen die Anforderungen nur grob auf. Zum anderen sind Kunden keine IT-Experten. Außerdem sitzen oft nur die Entscheider mit am Tisch, die die Prozesse lediglich aus der Vogelperspektive kennen – die Know-how-Träger des Projekts sind nicht involviert.

Typischerweise kommen im Laufe des Projekts dann immer neue Anforderungen dazu, vor allem am Projektende. Weil die Zeit drängt und die neuen Anforderungen nicht sauber in die IT-Architektur passen, leidet die Qualität – Workarounds oder fehleranfällige Umsetzungen sind die Folge. Durch die mangelnde Bedarfsanalyse fehlt eine Grundlage für ein gemeinsames Verständnis des Projektumfangs – das kann ein Auftraggeber ausnutzen. Um Streitigkeiten mit Auftraggebern zu vermeiden, ufern Projekte meist zu Lasten der Agentur aus. Der Druck steigt und das Team ist unzufrieden, weil sie Teile der Lösung neu programmieren müssen und bisher geleistete Arbeit umsonst war. Bricht einer von beiden das Projekt schließlich gar ab, steht die Agentur auch noch in der Nachweispflicht, welche Arbeiten abrechnungsfähig sind.

Projektbeteiligte identifizieren

Requirements Engineering hilft, die Projektanforderungen schon zu Beginn zu analysieren, zu definieren und mit dem Auftraggeber abzustimmen. Erst dann sucht die Agentur nach einer Lösung, die sich jederzeit mit den Anforderungen abgleichen lässt. Um alle Anforderungen genau aufzunehmen, muss der Projektleiter zunächst einmal die verschiedenen Projektbeteiligten identifizieren:

  • Wer ist Entscheider?
  • Wer arbeitet mit der Lösung?
  • Wer ist Nutzer der Umsetzung?
  • Unter welchen Bedingungen kommt die Software zum Einsatz?

Nur wer sich mit den verschiedenen Projektbeteiligten befasst, kann die Vision, Workflows, Vorstellungen und Funktionalitäten sicher identifizieren. Nicht selten verstehen sogar die Entscheider auf Kundenseite selbst erst jetzt den gesamten Umfang des Projekts. Weil sie somit die Notwendigkeiten, Prozesse und Einsparpotenziale kennen, entwickeln Kunden auch oft Verständnis für ein erweitertes Budget.

So kann die Struktur eines Requirements-Engineering-Dokuments aussehen: Jeder einzelne Aspekt eines Webprojekts wird aufgeschrieben, um für alle Beteiligten klare Regeln zur Verfügung zu stellen, auf die sich alle berufen können. (Screenshot: DBook)

So kann die Struktur eines Requirements-Engineering-Dokuments aussehen: Jeder einzelne Aspekt eines Webprojekts wird aufgeschrieben, um für alle Beteiligten klare Regeln zur Verfügung zu stellen, auf die sich alle berufen können. (Screenshot: DBook)

Muss-, Soll- und Kann-Anforderungen

Anforderungen lassen sich grundsätzlich in drei Rubriken unterteilen: Die Muss-, Soll- und Kann-Anforderungen. Die Muss-Anforderungen sind aus Kunden- und Agentursicht das Minimum einer guten Umsetzung. Alle Soll-Anforderungen sorgen für eine sehr gute Umsetzung, treiben aber Zeit und Budget in die Höhe. Hierbei sollten sich Kunde und Agentur genau fragen, welche dieser Anforderungen gegebenenfalls nur für Poweruser wichtig sind.

Die Kann-Anforderungen machen ein Projekt zu einem Highlight. Solche Anforderungen erhöhen das Budget stark und haben viele Details, die in Abhängigkeiten zu anderen Anforderungen stehen. Wenn Agentur und Auftraggeber noch keine Erfahrungen mit dem Projektziel haben, machen solche Anforderungen spätere Umbauten auch oft sehr kostspielig. Sie lassen sich daher häufig in eine spätere Ausbaustufe verschieben, wenn es Erfahrungen mit der eigentlichen Umsetzung gibt.

Funktionale und nicht-funktionale Anforderungen

Neben diesen drei Rubriken unterscheidet das Requirements Engineering auch funktionale und nichtfunktionale Anforderungen. Während funktionale Anforderungen die Leistung einer Lösung definieren, legen die nichtfunktionalen Anforderungen fest, wie gut eine Umsetzung sein soll.

Nichtfunktionale Anforderungen können etwa Zuverlässigkeit, Usability, Wartbarkeit, Flexibilität, Unterstützung von Standards oder Skalierbarkeit sein. Nichtfunktionale Anforderungen sind hingegen oftmals für ein besseres Verständnis mit Beispielen oder Verlinkungen hinterlegt. Hilfreich sind hier zum Beispiel Screenshots bereits bestehender Lösungen. Jede funktionale Anforderung sollte die Agentur genau definieren:

  • Welches Protokoll und welche Schnittstelle nutzt die Lösung?
  • Auf welchem Server und welche URL wird zugegriffen?
  • Welche Maßnahmen sind für die Sicherheit von Daten und den Datenschutz wichtig?
  • Für welche Benutzerrolle stehen welche Funktionen zur Verfügung?
  • In welchem Intervall werden Funktionen oder Schnittstellen bedient?
  • Welche Datenmenge oder welche Anzahl muss die Umsetzung sicher handhaben können?
  • Wie kann man die Anforderung im fertigen Produkt testen?
  • Von wem kam die Anforderung?

Darüber hinaus sollte die Agentur die Anforderungen eingrenzen. Für kritische oder interpretierbare Punkte eines Projekts legen beide fest, welche Anforderungen der Auftraggeber oder ein Drittdienstleister erbringt.

Agile Management-Methoden

Auf den ersten Blick wirkt es ganz so, als wäre Requirements Engineering eher ein Mittel für das typische Wasserfall-Modell. Im ersten Schritt definiert die Agentur die Anforderungen und im zweiten Schritt entwickelt sie darauf basierend eine Konzeption, Mockups sowie ein Design – und setzt das Projekt schließlich entsprechend um. Dem ist aber nicht so. Requirements Engineering eignet sich auch für agiles Projekt-Management.

Im Gegensatz zum Wasserfall-Modell, bei dem sich das Requirements Engineering am Anfang des Projekts befindet, definieren Kunde und Agentur bei agilen Entwicklungsmethoden die Anforderungen am Anfang eines jeden Sprints. Das ist mitunter einfacher, weil für die Teilabschnitte nicht so viele Projektbeteiligte eingebunden sind. Die Herausforderung besteht jedoch darin, immer auch an die Abhängigkeiten späterer Sprints zu denken. Das Ziel ist dabei, zusätzliche Sprints für spätere Optimierungen zu minimieren.

Um funktionale Anforderungen strukturiert zu erfassen, empfehlen sich einheitliche Masken. Diese sollten es den Projektverantwortlichen ermöglichen, auch Abhängigkeiten und optional Testszenarien zu vermerken. (Screenshot: DBook)

Um funktionale Anforderungen strukturiert zu erfassen, empfehlen sich einheitliche Masken. Diese sollten es den Projektverantwortlichen ermöglichen, auch Abhängigkeiten und optional Testszenarien zu vermerken. (Screenshot: DBook)

Wasserfall-Projekte aufteilen

Sollte es bei einem Wasserfall-Projekt zu langwierig sein, alle Anforderungen auf einmal zu erfassen, kann man das Projekt auch in Teilprojekte gliedern. Dann muss man die Anforderungen in jeder Projektphase bestimmen. Ähnlich wie beim agilen Vorgehen sind dadurch nicht immer alle Projektbeteiligten nötig.

Dennoch ist der Kunde nicht ganz so stark gefordert wie bei einer agilen Entwicklung. Außerdem treten die Abhängigkeiten zwischen den Umsetzungsphasen gebündelter auf. Darüber hinaus, kann die Agentur die Anforderungen für die unterschiedlichen Phasen parallelisiert erfassen und spart dadurch Zeit.

Literatur zum Requirements Engineering
Das Literaturangebot ist sehr breit
gefächert. Wer sich intensiv mit dem Requirement Engineering auseinandersetzen will, dem seien folgende Bücher empfohlen:
  • Rational Unified Process: An Introduction (Philippe Kruchten)
  • Peopleware: Productive Projects and Teams (Tom DeMarco)
  • UML Distilled: A Brief Guide to the Standard Object Modeling Language (Martin Fowler)

Der Einstieg: Ein Beispielprozess

Wer mit Requirements Engineering anfängt, sollte sich klar machen: Auch hier macht die Übung den Meister. Der erste Versuch wird vieles an der Umsetzung des Projekts vereinfachen, aber auch Lücken offen lassen. Daraus kann man seine Lehren ziehen und beim nächsten Mal Durchführung und Ergebnis um einiges verbessern.

Der Prozess des Requirements Engineering ist branchenübergreifend und hat seine Wurzeln in der Industrie. Wie schon erwähnt, kann er sehr viel Zeit kosten. Der folgende Prozess lässt sich jedoch leicht handhaben und später immer weiter an die Bedürfnisse des Projekts anpassen.

Schritt 1: Die Projektbeteiligten identifizieren

Wer sind die Visionäre, Entscheider, Know-how-Träger, Administratoren, Redakteure und Nutzer der späteren Lösung? Sie alle haben verschiedene Erfahrungen und Vorstellungen zu den Anforderungen des Projekts. Diese Stakeholder sollten Agentur und Kunde während des ersten Projekt-Kickoffs aufnehmen. Weitere Projektbeteiligte kommen im Lauf des Anforderungsprozesses in der Regel immer wieder hinzu. Dies können neben dem Auftraggeber auch andere Dienstleister sein.

Schritt 2: Die Requirements aufnehmen

Im zweiten Schritt teilt die Agentur die Projektbeteiligten in Gruppen ein und interviewt sie. Die Gruppen können sich nach Themengebieten oder Positionen richten (etwa Entscheider, IT, Redaktion, Marketing, Nutzer oder Administratoren). Es hat in der Regel keinen Sinn, alle wichtigen Projektbeteiligten an einen großen Tisch zu holen – zu oft gibt es Terminschwierigkeiten und unproduktive Randdiskussionen. Außerdem sind nicht immer alle Details für jeden Projektbeteiligten interessant.

Schritt 3: Anforderungen strukturieren und analysieren

Hat die Agentur die verschiedenen Gruppen interviewt und sich Notizen zu den unterschiedlichen Anforderungen gemacht, sortiert, versioniert und strukturiert sie diese, um sie im Anschluss auf Zusammenhänge und Widersprüche hin zu analysieren. Dabei sollte man die Anforderungen auch möglichst deutungsfrei in funktionale und nichtfunktionale sowie in Muss-, Soll- und Kann-Anforderungen unterteilen.

Schritt 4: Die Anforderungen validieren lassen

Um sicher zu gehen, dass die so formulierten Anforderungen zutreffen, sich nicht unbemerkt Interpretationen eingeschlichen haben oder Widersprüche verblieben sind, sollte das Projekt-Team nun die Anforderungen zurückspiegeln – also mit dem Auftraggeber besprechen. Dabei ist es oft sinnvoll, mehrere Gruppen mit Schnittmengen in eine Diskussion einzubeziehen. So kann die Agentur ein Feingefühl dafür entwickeln, wie sie das Dokument verfassen kann, um sich in der Umsetzung auf sicherem Terrain zu bewegen – und dem Kunden die Abnahme zu ermöglichen.

Schritt 5: Iterieren, Iterieren, Iterieren

Durch das Zurückspiegeln der Anforderungen und die nachfolgende Abstimmung kommen oft neue Stakeholder, Prozesserkenntnisse oder Detailanforderungen zu Tage. Das Requirements Engineering durchläuft also die Schritte eins bis vier so lange, bis die Anforderungen und Zusammenhänge für Auftraggeber und Agentur klar sind. Kommen keine neuen Fakten mehr auf und sind alle Widersprüche aufgelöst, geht es zum nächsten Schritt.

Schritt 6: Die Abnahme der Anforderungen

Das Requirements-Engineering-Dokument liegt nun in einer definierten Version vor. Damit die Entscheiderkreise im Unternehmen das Dokument besser einschätzen können, sollte die Agentur Management Summaries und Einleitungen zu den großen „Kapiteln“ beifügen. Außerdem sollte der Projektverantwortliche auf Kundenseite diese Version des Dokumentes schriftlich abnehmen. Damit ist es die Grundlage für Konzeption, Design und Umsetzung des Webprojekts.

Kommen klassische Projektmethoden zum Einsatz, so ist das Dokument entsprechend umfangreich. Die Agentur sollte für die Abnahme daher genug Zeit einplanen. Bei agilen Entwicklungsmethoden geht nicht nur die Abnahme des Dokumentes schneller, sondern auch die Iterationsschritte eins bis vier.

Die Tools für das Requirements Engineering

Spezialisierte Tools wie Visure bieten umfangreiche Funktionen für die Definition, Organisation und Validierung aufwändiger Software-Projekte. Sie sind aber nicht immer einfach zu bedienen und eignen sich eher für große Projekte. (Screenshot: Visure)

Spezialisierte Tools wie Visure bieten umfangreiche Funktionen für die Definition, Organisation und Validierung aufwändiger Software-Projekte. Sie sind aber nicht immer einfach zu bedienen und eignen sich eher für große Projekte. (Screenshot: Visure)

Für das Requirement Engineering stehen mächtige Spezialwerkzeuge zur Verfügung. Diese sind jedoch nicht immer leicht zu handhaben und eignen sich daher oftmals eher für umfangreiche Projekte. Daneben können Agentur und Kunde auch mit
Online-Tools arbeiten, die ihnen schon vorher bekannt sind. Die folgenden Cloud-Dienste erleichtern zudem die Arbeit in verteilten Teams: Für die Planung und Projektleitung eignen sich etwa Trello oder Asana, für Notizen und Protokolle Evernote oder Minutes.io. Abhängigkeiten und Prozesse lassen sich gut mit MindMeister oder Quircktools Smaps abbilden. Und das Requirements-Engineering-Dokument teilt und bearbeitet man in verteilten Teams zum Beispiel mit Google Docs oder DBook.

Requirements Engineering platzieren

Um das Requirements Engineering einzuführen, gibt es eigentlich nur vier geeignete Zeitpunkte. Das Erfassen und Abstimmen der Anforderungen geschieht

  • als ein eigenes Vorprojekt, mit dem die Agentur die Aufwände des eigentlichen Projekts überhaupt erst definieren kann.
  • zu Projekt- oder Sprint-Beginn, um alle Anforderungen zu definieren – auch solche, die sich auf das Konzept und Design auswirken.
  • vor Beginn der technischen Umsetzung, um auf sicherem Terrain zu programmieren.
  • nach dem Scheitern eines Projekts oder bei Übernahme eines gescheiterten Projekts, um die Umsetzung im zweiten Anlauf sicher durchzuführen.

Fazit

Das Requirements Engineering erfordert Übung, bringt aber viele Vorteile mit sich – und zwar nicht nur für die Agentur, sondern auch für den Kunden: Er erhält einen besseren Einblick in die Details seines Ziels und kann so auch besser einschätzen, welche Anforderungen ein absolutes Muss und welche „nur“ wünschenswert sind.

Er vermeidet unnütze Diskussionen und Interpretationen ungeklärter Umsetzungsdetails, die Umsetzung verläuft gradliniger und zügiger. Darüber hinaus hat er eine saubere Grundlage für die Kostenkalkulation. Das schützt ihn davor, am Ende des Budgets mit einem halbfertigen Projekt dazustehen. In der agilen Entwicklung zeigt das Requirements Engineering frühzeitig, ob das Budget reicht und ob das Team in kommenden Sprints nur noch Muss-Anforderungen umsetzten sollte.

Nicht zu unterschätzen ist auch, dass der Auftraggeber ein wichtiges Kontrollwerkzeug für die Qualität der Umsetzung erhält. Darüber hinaus kann ein gutes Requirements-Engineering-Dokument auch der internen Kommunikation des Kunden dienen: Wenn in größeren Unternehmen nicht nur Einzelne über die Auftragsvergabe bestimmen, hilft es bei der Abstimmung und Absicherung der Ansprechpartner. Sobald Kunden dies verstanden haben, sollte die Umsetzung kein Problem mehr sein.

Mehr zu diesem Thema

Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

2 Kommentare
Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Michael
Michael

„Für das Requirement Engineering stehen mächtige Spezialwerkzeuge zur Verfügung.“
Welche denn?
Interessantes Thema, leider etwas oberflächlich behandelt. Interessant wird, wie die unterschiedlichen Anforderungen dann im Detail zu dokumentieren und vor allem zu visualisieren sind. UML alleine reicht oft nicht.

Antworten
mTOOLs
mTOOLs

Der Artikel fasst die Kernthemen des Requirements Engineering gut zusammen, aber von den gelisteten Tools kann man wirklich keines als Spezialwerkzeug bezeichnen.
Wir sind Hersteller von wirklichen Spezialwerkzeugen: objectiF RM, in-STEP RED und in-STEP BLUE. Mehr dazu gibt es auf: http://www.microtool.de.
Aber auch IBM, Polarion u.a. bieten echte Werkzeuge für Requirements Engineering an.
Wer sich wirklich im Bereich Anforderungsanalyse, Dokumentation, Traceability und Anforderungsmanagement verbessern will, sollte schon eher nach einem echten Spezialwerkzeug Ausschau halten.

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!

Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Digitales High Five
Holger Schellkopf (Chefredakteur t3n)

Anleitung zur Deaktivierung

Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder