Entwicklung & Design

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

Seite 2 / 3

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.

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

2 Kommentare
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!

Hey du! Schön, dass du hier bist. 😊

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

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

Danke für deine Unterstützung.

Digitales High Five,
Stephan Dörner (Chefredakteur t3n.de) & das gesamte t3n-Team

Anleitung zur Deaktivierung