Anforderungen erheben: Methoden auswählen und sinnvoll kombinieren

Die besten Methoden zur Anforderungserhebung sind jene, die zu dem passen, was Sie noch nicht wissen. Interviews zeigen, was einzelne Personen brauchen. Workshops klären Konflikte zwischen ihnen. Beobachtung und Dokumentenanalyse zeigen, wie die Arbeit wirklich abläuft, und Prototypen prüfen Ideen, bevor Sie sie umsetzen. Eine einzelne Methode reicht nie, deshalb kombinieren die meisten Softwareprojekte drei oder vier. Dieser Leitfaden erklärt, was jede Methode sichtbar macht, wie Sie eine Kombination wählen und wie Sie die Ergebnisse in Anforderungen überführen, die eine Entwicklerin umsetzen und ein Stakeholder freigeben kann.

Kurz gefasst

• Die Erhebung umfasst die ganze Arbeit: Bedürfnisse identifizieren, dokumentieren, analysieren, validieren und freigeben. Das Ermitteln ist der aktive Teil, in dem Sie Bedürfnisse aus Menschen herausholen.
• Interviews und Workshops bringen Bedürfnisse zur Sprache. Beobachtung und Dokumentenanalyse zeigen, wie heute gearbeitet wird. Prototypen zeigen, was möglich wäre.
• Beginnen Sie mit Zielen, Kontext und Stakeholdern, und sammeln Sie erst danach detaillierte Anforderungen.
• Machen Sie Qualitätsanforderungen messbar, damit aus «schnell» eine Zahl wird, die jemand prüfen kann.
• Anforderungen, die niemand validiert hat, sind wertlos. Schliessen Sie deshalb jede Runde mit einem Review ab.

Was Anforderungserhebung bedeutet (und wie sie sich vom Ermitteln unterscheidet)

Anforderungserhebung ist der umfassende Prozess, in dem Sie identifying, documenting and organizing what a system needs to do. Dazu gehören das Finden der Stakeholder, das Ermitteln der Bedürfnisse, deren Analyse, die Validierung und die Freigabe. Das Ermitteln ist der aktive Teil davon: Bedürfnisse, Erwartungen und Rahmenbedingungen aus Nutzer:innen, Entwickler:innen, Regulierungsstellen und Fachleuten herausarbeiten.

Über die Begriffe wird gestritten. Der Anforderungsexperte Robin Goldsmith hält «sammeln» und «ermitteln» für irreführend, weil Anforderungen nicht fertig herumliegen. Er spricht lieber davon, talk about discovering requirements, indem man Daten analysiert. Karl Wiegers und Candase Hokanson argumentieren ähnlich: Eine gute Analystin behandelt das Ermitteln as exploration and discovery, not just collection.

Die praktische Lehre daraus: Niemand reicht Ihnen eine fertige Liste. Ein Gründer sagt «wir brauchen eine App mit einem Dashboard». Was das Geschäft braucht, liegt meist darunter: weniger manuelle Auswertungen, schnelleres Onboarding, weniger Support-Anfragen. Ihre Methoden dienen dazu, von der ersten Aussage zur zweiten zu gelangen.

Vor jeder Methode: Ziele, Kontext und Stakeholder

Die Forschung der Requirements-Engineering-Gruppe der Universität Zürich ist bei der Reihenfolge eindeutig. Bevor Sie Details ermitteln, clarify the system’s goals and vision, consider its context, and identify stakeholder roles and their representatives. Wer diesen Schritt überspringt, erhält im ersten Workshop fast immer eine lange, unscharfe Wunschliste.

Erledigen Sie zuerst diese drei Dinge:

1. Schreiben Sie das Ziel in einem oder zwei Sätzen auf. Zum Beispiel: «Die Zeit, die unser Verkaufsteam für die Erstellung von Offerten braucht, sinkt von 40 auf 10 Minuten.» Wenn Ihnen das nicht gelingt, ist genau das Ihr erstes Workshop-Thema.
2. Zeichnen Sie den Kontext auf. Welche Systeme, Teams, Lieferanten, Gesetze und bestehenden Abläufe berühren das Produkt? Ein Shop, der an ein ERP und einen Zahlungsanbieter angebunden ist, hat Anforderungen, die ausserhalb des Shops liegen.
3. Listen Sie die Stakeholder-Rollen auf und benennen Sie für jede eine reale Person. Denken Sie an Nutzer:innen, Einkauf, Betrieb, Finanzen, IT und Recht. Wo Sie keine reale Person erreichen, empfiehlt dasselbe Zürcher Material den Einsatz von clarify the system’s goals and vision, consider its context, and identify stakeholder roles and their representatives.

Wenn Sie neu in einer Organisation sind, beginnen Sie mit Lesen. Bestehende Systemdokumentation und Organigramme sind eine foundational way to understand business objectives, bevor Sie die Zeit anderer Leute beanspruchen.

Die wichtigsten Methoden zur Anforderungserhebung

Eine systematische Übersicht über Studien zum Ermitteln von Anforderungen zeigt, dass jede Methode anderes sichtbar macht: interviews clarify individual needs and motivations, while observation highlights real-world workflows. Das Zürcher Kursmaterial fasst es knapp: clarify the system’s goals and vision, consider its context, and identify stakeholder roles and their representatives. So sieht das in der Praxis aus.

Interviews

Das Einzelgespräch ist das Arbeitspferd. Es eignet sich für Menschen, die in der Gruppe nicht offen sprechen: die Finanzverantwortliche, die den wahren Schmerz beim Reporting kennt, oder der Betriebsleiter, der ein kaputtes Werkzeug täglich umgeht.

• Zeigt: individuelle Bedürfnisse, Motive, Sprachgebrauch, verborgene Rahmenbedingungen.
• Geeignet, wenn: es wenige Stakeholder gibt, Themen heikel sind oder Sie in die Tiefe müssen.
• Tipps: Fragen Sie nach dem letzten Mal, als etwas schiefging, nicht danach, was sich jemand «wünscht». Fragen Sie so lange «warum», bis Sie bei einem geschäftlichen Grund ankommen. Bleiben Sie bei 45 Minuten und schicken Sie danach eine schriftliche Zusammenfassung.

Workshops

Ein Workshop bringt mehrere Stakeholder mit einer klaren Agenda in einen Raum (oder in eine Videokonferenz). Es ist der schnellste Weg, Konflikte zu finden und zu klären.

• Zeigt: Uneinigkeit zwischen Abteilungen, Prioritäten, gemeinsame Sprache.
• Geeignet, wenn: mehrere Gruppen vom selben Produkt abhängen oder Sie Entscheidungen brauchen, nicht nur Informationen.
• Tipps: Laden Sie die Person ein, die entscheiden kann, nicht nur jene, die Bescheid weiss. Enden Sie mit einer priorisierten Liste, nicht mit einer offenen. Fünf bis acht Personen sind handhabbar.

Beobachtung und Mitlaufen am Arbeitsplatz

Menschen bei der Arbeit zuzusehen zeigt, was Interviews verpassen, denn Menschen beschreiben den offiziellen Ablauf und machen dann etwas anderes. Eine Lagermitarbeiterin führt vielleicht neben dem offiziellen System eine eigene Tabelle. Diese Tabelle ist eine Anforderung.

• Zeigt: tatsächliche Abläufe, Behelfslösungen, Unterbrechungen, parallel genutzte Werkzeuge.
• Geeignet, wenn: Sie einen bestehenden Ablauf ersetzen oder automatisieren.
• Tipps: Planen Sie pro Rolle einen halben Tag ein, notieren Sie, was die Leute tun, nicht was sie sagen, und fragen Sie im Anschluss zu jeder Behelfslösung nach.

Dokumentenanalyse

Bestehende Handbücher, Prozessbeschreibungen, Verträge, Support-Tickets, Auswertungen und alte Spezifikationen zeigen, was die Organisation bereits weiss. Sie sind zudem günstig zu lesen und kosten niemanden Zeit.

• Zeigt: geltende Regeln, Datenfelder, Schnittstellen, wiederkehrende Probleme.
• Geeignet, wenn: zu Beginn jedes Projekts, und besonders bei der Ablösung eines Altsystems.
• Tipps: Behandeln Sie Dokumente als Behauptungen, die zu prüfen sind. Alte Dokumentation ist oft überholt, gleichen Sie sie mit der Beobachtung ab.

Umfragen und Fragebogen

Umfragen erreichen viele Menschen zu geringen Kosten. Sie eignen sich, um etwas zu bestätigen, das Sie bereits vermuten, etwa welche von fünf Funktionen Kundinnen und Kunden am wichtigsten ist. Für Entdeckungen, an die noch niemand gedacht hat, taugen sie schlecht.

• Zeigt: Muster über eine grosse Nutzergruppe hinweg.
• Geeignet, wenn: Sie viele Nutzer:innen und eine konkrete Frage haben.
• Tipps: Bleiben Sie unter zehn Fragen und führen Sie vorab ein paar Interviews, damit Sie die richtigen Fragen stellen.

Ideensammlung

Eine Ideensammlung bringt schnell viele Optionen hervor. Sie eignet sich für frühe Produktphasen, in denen das Problem klar ist, die Lösung aber nicht. Das Ergebnis sind Rohideen, keine Anforderungen, deshalb gehört ein Priorisierungsschritt dazu.

• Zeigt: mögliche Lösungen und Ideen, die Stakeholder bisher nicht ausgesprochen haben.
• Geeignet, wenn: Sie in der Ideenphase stecken oder ein Workshop ins Stocken geraten ist.
• Tipps: Trennen Sie das Entwickeln der Ideen vom Bewerten und messen Sie die Ideen danach am Ziel, das Sie aufgeschrieben haben.

Prototypen

Ein klickbarer Entwurf oder eine grobe lauffähige Version lässt Menschen auf etwas Konkretes reagieren. Stakeholder können oft nicht sagen, was sie brauchen, wissen aber sofort, was an einem Bildschirm falsch ist.

• Zeigt: Bedienprobleme, fehlende Schritte, unausgesprochene Erwartungen.
• Geeignet, wenn: die Oberfläche zentral ist, die Nutzer:innen die Idee nicht kennen oder die Stakeholder uneins sind, wie «es» aussehen soll.
• Tipps: Testen Sie mit echten Nutzer:innen, nicht nur mit der Auftraggeberin. Werfen Sie die Annahmen des Prototyps weg, nicht nur seine Pixel.

User Stories und Anwendungsfälle

User Stories («Als Verkaufsmitarbeiter möchte ich eine frühere Offerte duplizieren, damit ich in wenigen Minuten ein neues Angebot verschicken kann») sowie Anwendungsfälle und Szenarien bringen Erkenntnisse in eine Form, aus der ein Team etwas bauen kann. Das Zürcher Material führt scenarios and use cases, glossaries, process models and object models unter den Analysetechniken auf, die unstrukturierte Informationen in richtige Anforderungen überführen.

• Zeigt: Lücken in Abläufen, Sonderfälle und welche Schritte den Nutzer:innen am wichtigsten sind.
• Geeignet, wenn: nach dem Ermitteln, um das Gehörte zu strukturieren.
• Tipps: Hängen Sie an jede Story Abnahmekriterien, damit Team und Auftraggeberin sich einig sind, was «fertig» bedeutet.

So wählen und kombinieren Sie Methoden

Das International Requirements Engineering Board hält fest, dass there is no universal requirements process: Er muss auf den Entwicklungskontext, die Projektart (linear oder agil) und die Verfügbarkeit der Stakeholder zugeschnitten werden. Wählen Sie deshalb anhand von drei Fragen.

1. Was wissen Sie noch nicht?

Unbekannt	Passende Methoden
Welches Problem am meisten wiegt	Interviews, Dokumentenanalyse
Wie heute gearbeitet wird	Beobachtung, Dokumentenanalyse
Wer was will und wo es Konflikte gibt	Workshops
Wie die Lösung aussehen soll	Prototypen, Ideensammlung
Wie verbreitet ein Bedürfnis ist	Umfragen
Was das Team als Nächstes bauen soll	User Stories mit Abnahmekriterien

2. Wen erreichen Sie, und wie viel Zeit bekommen Sie von diesen Personen? Fünf stark ausgelastete Führungskräfte sind mit kurzen Interviews und einem Entscheidungsworkshop besser bedient als mit einer Reihe langer Sitzungen. Bei Hunderten von Endnutzer:innen braucht es eine Umfrage, gestützt auf eine Handvoll Interviews.

3. Wie teuer ist eine falsche Annahme? Eine Marketing-Website lässt sich nach dem Start korrigieren. Ein Zahlungsablauf, ein System mit ERP-Anbindung oder ein regulierter Prozess nicht, dort investieren Sie mehr Zeit in Beobachtung und Prototypen.

Drei Kombinationen, die funktionieren

• Neues Produkt oder MVP: Interviews mit Stakeholdern, ein Workshop zur Zielklärung, ein klickbarer Prototyp, getestet mit fünf Personen aus der Zielgruppe, danach User Stories. So bleibt die erste Version klein und auf Fakten gestützt.
• Ablösung eines Altsystems: Dokumentenanalyse, Beobachtung jeder Nutzerrolle, Interviews zu Behelfslösungen, danach ein Workshop, um zu entscheiden, welche alten Verhaltensweisen bleiben. Alte Systeme verbergen Geschäftsregeln, an deren Entstehung sich niemand erinnert.
• Automatisierung eines wiederkehrenden Ablaufs: Beobachtung des Ablaufs von Anfang bis Ende, ein kurzer Workshop zur Einigung über Ausnahmen und ein Prototyp des automatisierten Ablaufs, durchgespielt an einer Stichprobe echter Fälle.

Mischen Sie in jedem Fall eine Methode, die erfasst, was Menschen sagen, mit einer, die prüft, was sie tun.

Qualitätsanforderungen: die vergessene Kategorie

Stakeholder sprechen über Funktionen. Geschwindigkeit, Sicherheit, Verfügbarkeit oder Bedienbarkeit erwähnen sie selten, bis etwas ausfällt. Die Zürcher Forschung führt vernachlässigte Qualitätsanforderungen und Rahmenbedingungen unter den häufigsten Problemen auf und rät, Qualitätsanforderungen clarify the system’s goals and vision, consider its context, and identify stakeholder roles and their representatives.

Vage Aussagen brauchen Zahlen. Eine Anforderung wie «das System soll schnell sein» ist laut derselben Quelle clarify the system’s goals and vision, consider its context, and identify stakeholder roles and their representatives. Zum Beispiel:

• Statt «schnell»: «Suchergebnisse erscheinen bei 95 Prozent der Anfragen innerhalb von zwei Sekunden.»
• Statt «sicher»: «Mitarbeitende melden sich mit Zwei-Faktor-Authentifizierung an, und Kundendaten werden in der Schweiz gespeichert.»
• Statt «einfach zu bedienen»: «Eine neue Mitarbeiterin erstellt ohne Schulung in weniger als zehn Minuten eine Offerte.»

Stellen Sie die Fragen direkt: Wie viele Nutzer:innen gleichzeitig? Was passiert, wenn das System eine Stunde ausfällt? Welche Daten sind Personendaten? Forschende der Universität Zürich und der FHNW warnen zudem, dass quality models must be tailored to the project’s context, damit sie als Erhebungsrahmen taugen. Nutzen Sie Checklisten also als Anregung, nicht als Drehbuch.

Häufige Probleme und wie Sie damit umgehen

Dasselbe Zürcher Material benennt die Probleme, denen Sie begegnen werden: clarify the system’s goals and vision, consider its context, and identify stakeholder roles and their representatives. Hier sind praktische Antworten darauf.

• Zwei Abteilungen wollen das Gegenteil. Klären Sie das nicht per E-Mail. Setzen Sie beide mit der Person, die das Ziel verantwortet, in einen Workshop und entscheiden Sie anhand des schriftlichen Ziels.
• Ein Stakeholder sagt «baut einfach X». Fragen Sie, was heute ohne X passiert und was sich mit X ändert. Menschen beschreiben oft eine Lösung, wenn sie ein Problem meinen.
• Niemand weiss, was gebraucht wird. Zeigen Sie etwas. Ein grober Prototyp oder ein ähnliches Produkt bringt oft mehr als eine weitere Sitzung.
• Begriffe bedeuten Unterschiedliches. Führen Sie ein Glossar. «Kunde» kann im Verkauf eine Käuferin und in der Entwicklung ein Benutzerkonto meinen.
• Eine Schlüsselperson ist nicht verfügbar. Benennen Sie eine Vertretung mit Entscheidungsbefugnis oder arbeiten Sie mit einer Persona und markieren Sie die Annahme, damit Sie sie später prüfen.
• Der Umfang wächst ständig. Priorisieren Sie Anforderungen (muss, sollte, könnte) in jedem Workshop und halten Sie fest, wer welchen Punkt aus welchem Grund gewünscht hat.

Dokumentieren, validieren und aktuell halten

Schreiben Sie Anforderungen in der Form auf, die die Leserschaft braucht. Ein Business Requirements Document beschreibt die übergeordneten Ziele. Eine Systemspezifikation, auf Deutsch Pflichtenheft in German, beschreibt, was das System tun wird. Schweizer Kundinnen und Kunden kennen den deutschen Begriff häufig, und es lohnt sich zu fragen, ob in einer Ausschreibung oder einem Vertrag ein Pflichtenheft erwartet wird.

Ein brauchbares Minimum für ein kleines Projekt:

1. Ziel und Erfolgsmessgrössen.
2. Stakeholder-Rollen und wer entscheidet.
3. User Stories oder Anwendungsfälle, nach Priorität geordnet, jeweils mit Abnahmekriterien.
4. Qualitätsanforderungen mit Zahlen.
5. Schnittstellen, Daten und Rahmenbedingungen wie Budget, Termine und rechtliche Vorgaben.
6. Offene Fragen und Annahmen, mit zuständigen Personen.

Dann validieren Sie. Das IREB-Handbuch sagt unmissverständlich, dass there is no universal requirements process. Validierung kann eine gemeinsame Durchsprache mit den Stakeholdern sein, ein Review des Prototyps oder Testfälle, die vor Baubeginn aus den Abnahmekriterien abgeleitet werden. Freigabe heisst: Personen mit Entscheidungsbefugnis haben das Dokument gelesen und bestätigen, dass es ihren Bedürfnissen entspricht.

Arbeiten Sie in einer regulierten Branche wie Medizintechnik oder Automobil, kommt mehr dazu. Regulierte Industrien verlangen oft identifying, documenting and organizing what a system needs to do nach Normen wie FDA 21 CFR 820.30 oder ISO 26262. Fragen Sie Ihre Compliance-Stelle, welche Normen gelten, bevor Sie ein Dokumentationsformat wählen.

Halten Sie das Dokument schliesslich lebendig. Forschung an der Universität Zürich zeigt, dass up-to-date requirements specifications prevent the loss of the rationale behind past decisions und spätere Diskussionen über Funktionen erleichtern. Wenn sich eine Entscheidung ändert, halten Sie den Grund gleich daneben fest.

Ein Vorgehen Schritt für Schritt, das Sie diese Woche starten können

1. Ziel und Erfolgsmessgrössen schriftlich festhalten und von der auftraggebenden Person bestätigen lassen.
2. Stakeholder und Kontext auflisten: Rollen, Systeme, Regeln, bestehende Dokumente.
3. Zuerst lesen: Dokumente, Tickets, Auswertungen, Organigramme.
4. Interviews führen, eine Person pro Rolle, zu kürzlich erlebten realen Situationen.
5. Die zwei oder drei wichtigsten Abläufe beobachten.
6. Einen Workshop durchführen, um Konflikte zu klären und Prioritäten zu setzen.
7. Den riskantesten Teil als Prototyp bauen und mit echten Nutzer:innen testen.
8. Stories mit Abnahmekriterien und messbaren Qualitätsanforderungen schreiben.
9. Validieren und freigeben, danach bei jeder Änderung des Umfangs ein Review einplanen.

Bei einem kleinen Produkt passen die Schritte 1 bis 8 oft in zwei bis drei Wochen Teilzeitaufwand auf Kundenseite. Je mehr Stakeholder und Schnittstellen, desto länger dauert es, und diese Zeit ist günstiger als eine spätere Neuentwicklung der Software.

Anforderungen richtig erfassen, mit einem erfahrenen Team

Bei der Arbeit an den Anforderungen entscheidet sich, ob ein Projekt gelingt, und das hängt davon ab, wer im Raum sitzt. Bei Ampersand, einem kleinen Studio in Zürich, sind erfahrene Entwickler:innen vom ersten Gespräch bis zur Übergabe dabei. So bleiben jene Personen, die Ihre Bedürfnisse gehört haben, dieselben, die die Lösung bauen, und Anforderungen gehen unterwegs weder verloren noch werden sie umgeschrieben. Wenn Sie eine Website, App, Plattform, Schnittstelle oder Migration planen, finden Sie auf unserer Seite zu Preisen und Leistungen, wie wir unsere Arbeit aufbauen. Oder nehmen Sie über ampersand.ch Kontakt auf.

Häufige Fragen

Was ist der Unterschied zwischen Anforderungserhebung und Anforderungsermittlung?

Die Erhebung ist der gesamte Prozess: Stakeholder identifizieren, Bedürfnisse ermitteln, dokumentieren, analysieren, validieren und freigeben. Die Ermittlung ist der aktive Teil darin, bei dem Sie Bedürfnisse und Rahmenbedingungen aus Nutzer:innen, Fachleuten und weiteren Stakeholdern herausarbeiten. In der Praxis werden die Begriffe oft gleichbedeutend verwendet.

Welche Methode zur Anforderungserhebung ist die beste?

Keine ist für sich allein die beste. Interviews bringen Tiefe, Workshops lösen Konflikte, Beobachtung zeigt die tatsächlichen Abläufe und Prototypen prüfen Ideen. Wählen Sie die Mischung danach, was Sie noch nicht wissen, wen Sie erreichen und wie teuer eine falsche Annahme wäre.

Wie erheben Sie Anforderungen für ein Softwareprojekt?

Beginnen Sie mit dem Ziel, dem Kontext und den Stakeholdern. Kombinieren Sie danach Lesen, Interviews, Beobachtung und einen Workshop zur Priorisierung, und prüfen Sie riskante Teile mit einem Prototyp. Schreiben Sie Stories mit Abnahmekriterien und messbaren Qualitätsanforderungen und lassen Sie diese von den Personen mit Entscheidungsbefugnis validieren.

Welche Techniken werden in der Anforderungsanalyse eingesetzt?

Die Analyse formt das Gesammelte zu klaren Anforderungen. Übliche Hilfsmittel sind Glossare, Szenarien und Anwendungsfälle, Prozess- oder Aktivitätsmodelle, Verhaltensmodelle, Objekt- oder Klassenmodelle sowie hierarchische Strukturen von Zielen und Funktionen.

Wie gehen Sie mit Stakeholdern um, die nicht sagen können, was sie brauchen?

Zeigen Sie ihnen etwas Konkretes, etwa einen Prototyp, einen Bildschirm aus einem ähnlichen Produkt oder einen Musterbericht. Beobachten Sie, wie sie arbeiten, statt nur zu fragen, was sie wollen. Wo keine reale Person verfügbar ist, arbeiten Sie mit einer Persona und markieren Sie das als Annahme, die noch zu prüfen ist.

Quellen

• identifying, documenting and organizing what a system needs to do
• talk about discovering requirements
• as exploration and discovery, not just collection
• interviews clarify individual needs and motivations, while observation highlights real-world workflows
• clarify the system’s goals and vision, consider its context, and identify stakeholder roles and their representatives
• scenarios and use cases, glossaries, process models and object models
• Pflichtenheft in German
• quality models must be tailored to the project’s context
• up-to-date requirements specifications prevent the loss of the rationale behind past decisions
• there is no universal requirements process
• foundational way to understand business objectives