Wesentliche Erkenntnisse
- Anforderungserhebung ist eine passive Sammlung bestehender Artefakte und geäußerter Bedürfnisse, während Anforderungsermittlung ein aktiver Entdeckungsprozess ist, der unausgesprochene Bedürfnisse aufdeckt.
- Zu den Anforderungsermittlung Methoden gehören semi-strukturierte Interviews, kontextbezogene Untersuchungen, moderierte Workshops, Prototyping und User Story Mapping, um Grundprobleme aufzudecken.
- Projekte mit starkem Fokus auf Erhebung riskieren, in die Falle der geäußerten Bedürfnisse zu tappen, was zu übersehenen nicht-funktionalen Anforderungen, Stakeholder-Passivität und späten Überraschungen führt, die kostspielige Nacharbeit erfordern.
- Die gewählte Terminologie bestimmt die Erwartungen der Stakeholder. „Erhebung“ signalisiert passive Sammlung, während „Ermittlung“ zu kooperativen Problemlösungspartnerschaften einlädt.
- Moderne Standards wie IIBA BABOK und ISO/IEC/IEEE 29148 verwenden die Terminologie der Anforderungsermittlung, was die Notwendigkeit einer tieferen Entdeckung im Requirements Engineering widerspiegelt.
Der Unterschied zwischen Erhebung und Anforderungsermittlung beeinflusst direkt, ob Sie das bauen, was Stakeholder sagen, dass sie wollen, oder was sie tatsächlich brauchen. Entdecken Sie, warum dieser Unterschied wichtig ist 👇
Definition der Anforderungserhebung
Was ist Anforderungserhebung? Es ist das Sammeln bereits vorhandener Artefakte, dokumentierter Anfragen und geäußerter Bedürfnisse aus verfügbaren Quellen. Einige schnelle Beispiele sind das Importieren von Tickets aus einem Backlog oder das Zusammenstellen von in E-Mails erwähnten Funktionen. Bei der Erhebung geht man davon aus, dass Anforderungen bereits in dokumentierter oder geäußerter Form vorliegen und lediglich systematisch gesammelt und geordnet werden müssen.
Historisch gesehen dominierte dieser Begriff die Praktiken der Wasserfall-Ära, in der Business Analysten alles im Voraus in umfangreichen Spezifikationsdokumenten dokumentierten. Die Konnotation ist passiv: Stakeholder sagen Ihnen, was sie wollen, Sie schreiben es auf und machen weiter. Kein Widerspruch, kein Nachforschen, kein „aber warum brauchen Sie das?“. Es wirkt effizient, bis Sie erkennen, dass diese Anfragen das eigentliche Problem nicht lösen.
Hier sind die gängigen Techniken zur Anforderungserhebung:
- Dokumentation von Feedback aus Besprechungen
- Organisieren von Stakeholder-Inputs
- Sammeln von Spezifikationen aus verschiedenen Quellen.
Bei der Erhebung von Anforderungen konzentrieren sich Teams typischerweise darauf, vorwiegend geäußerte Bedürfnisse zu dokumentieren, anstatt tiefere Probleme zu untersuchen.
Sie wissen wahrscheinlich aus Ihrer Erfahrung, dass reale Projekte chaotisch sind. Stakeholder artikulieren möglicherweise oberflächliche Anforderungen, ohne die zugrundeliegenden Workflow-Probleme oder Entscheidungskriterien zu erklären, die diese Anfrage antreiben. Erhebung allein kann diese Nuancen nicht erfassen.
Hier sind die Herausforderungen bei einem Anforderungserhebungsansatz:
- Verzerrung bei expliziten Anforderungen: Man erfasst, was Stakeholder sagen, dass sie wollen, aber nicht immer, warum sie es wirklich brauchen. Das führt dazu, dass die ursächlichen Probleme oder angestrebten Endergebnisse übersehen werden.
- Spezifikationsträgheit: Alte Prozesse werden in neue Systeme übertragen. Sie digitalisieren Dysfunktionalität, anstatt Arbeitsabläufe zu verbessern.
- Späte Überraschungen: Nicht-funktionale Anforderungen (NFRs) wie Skalierbarkeit, Disaster Recovery oder Prüfpfade tauchen erst auf, nachdem die Entwicklung begonnen hat, was kostspielige Nacharbeit auslöst.
- Stakeholder-Passivität: Wenn sie denken, dass ihre Aufgabe nur darin besteht, „Ihnen Anforderungen mitzuteilen“, ziehen sie sich von der Validierung und dem Testen zurück, bis es zu spät ist, um gegenzusteuern.
- Blinde Flecken: Sie verpassen implizites Wissen wie Workarounds, Insider-Wissen und Sonderfälle. Menschen erkennen erst, dass diese wichtig sind, wenn etwas schief geht.
Hat die Erhebung einen Platz? Ja. Wenn Sie ein Legacy-System 1:1 ersetzen und maßgebliche Artefakte (Gesetze, SLAs, bestehende Verträge) den Umfang bereits definieren. Aber selbst dann benötigen Sie die Anforderungsermittlung, um Lücken zu validieren und stille Workarounds aufzudecken, die das alte System funktionsfähig halten. Betrachten Sie die Erhebung als Teilmenge der Ermittlung, nicht als eigenständige Methode. Sie ist ein nützlicher Input, aber niemals allein ausreichend.
Erforschung der Anforderungsermittlung
Standards wie IIBA BABOK und ISO/IEC/IEEE 29148 verwenden die exakte Terminologie der Anforderungsermittlung. Sie zeigen, dass Anforderungsermittlung und -engineering im Vergleich zur Anforderungserhebung den entgegengesetzten Ansatz verfolgen. Kurz gesagt, ist dieser Ansatz mehr wie aktives Entdecken statt einfaches Sammeln.
Was ist also Anforderungsermittlung? Es ist ein Ansatz zur Aufdeckung sowohl ausgesprochener als auch unausgesprochener Bedürfnisse. Sie binden Stakeholder durch strukturierte Techniken wie Interviews, Beobachtung, Workshops und Prototyping ein. Dies bringt die Bedürfnisse zum Vorschein, die sie nicht leicht artikulieren können, die Einschränkungen, von denen sie annehmen, dass Sie sie bereits kennen, und den Kontext, der über Erfolg oder Misserfolg einer Funktion im Feld entscheidet.
IIBAs BABOK positioniert „Elicitation and Collaboration“ (Ermittlung und Zusammenarbeit) als zentralen Wissensbereich mit spezifischen Aufgaben: Vorbereitung für die Ermittlung, Durchführung der Ermittlung, Bestätigung der Ergebnisse. Beachten Sie die Verben: durchführen, bestätigen und vorbereiten. Sie zeigen an, dass Sie tatsächlich Sitzungen orchestrieren sollten, die ein gemeinsames Verständnis schaffen.
Warum ist dies schwieriger? Weil Stakeholder oft nicht wissen, was sie brauchen, bis sie es sehen. Der Anforderungsermittlungsprozess hilft Ihnen, dieses Hindernis anzugehen.
Zu den gängigen Methoden der Anforderungsermittlung für Software gehören:
- Semi-strukturierte Stakeholder-Interviews und Laddering-Fragen
Decken Sie das „Warum“ hinter dem „Was“ auf. Stellen Sie tiefere Fragen, um Motivationen, Entscheidungskriterien und Einschränkungen aufzudecken. - Kontextbezogene Untersuchung
Beobachten Sie Benutzer in ihrer realen Umgebung, um Arbeitsabläufe zu verstehen und Schmerzpunkte oder Workarounds zu identifizieren, die sie möglicherweise in Meetings nicht erwähnen. - Anforderungsworkshops
Nutzen Sie Event Storming oder Brown-Paper-Sessions, um Prozesse gemeinsam abzubilden, Vokabular abzustimmen und abteilungsübergreifende Konflikte aufzudecken. - Prototyping
Präsentieren Sie einfache Skizzen oder klickbare Mockups, damit Stakeholder auf etwas Greifbares reagieren können, anstatt auf abstrakte Beschreibungen. - Beobachtungsbasierte Ermittlung
Beobachten Sie Benutzer bei der Ausführung täglicher Aufgaben, um Probleme zu identifizieren, die sie in Interviews möglicherweise nicht beschreiben können. - User Story Mapping
Visualisieren Sie die gesamte Benutzerreise und teilen Sie sie in Releases auf, um den Überblick zu behalten und effektiv zu priorisieren. - Softwarespezifische Ermittlungstechniken
Dazu gehören Wireframing, User Journey Mapping und technische Spike-Untersuchungen, um Plattformeinschränkungen und -möglichkeiten aufzudecken.
Ich liebe es, Prozessdiagramme zur Anforderungsermittlung zu verwenden. Einfach mit dem bestehenden Prozess beginnen, dann über den zukünftigen Zustand sprechen und dann über die Lücken. Bilder sind ein großartiges Werkzeug, und wenn es noch kein Diagramm gibt, versuchen Sie, schnell eines mit der Gruppe zu erstellen, und es wird Ihnen viel Einblick geben!
Agile Teams integrieren die aufgelisteten Techniken oft in iterative Entdeckungszyklen.
Alle Anforderungsermittlung Methoden haben eines gemeinsam: Zusammenarbeit. Sie sollten keine Anforderungen von Menschen extrahieren. Ein viel besserer Ansatz ist, stattdessen gemeinsam mit ihnen Verständnis zu schaffen. Auf diese Weise ist es möglich, mit Discovery-Praktiken Schritt zu halten, bei denen Stakeholder-Berührungspunkte parallel zu Delivery-Sprints verlaufen. In solchen Fällen verhindert die Anforderungsermittlung die Last-Minute-Überprüfung, die eine Veröffentlichung drei Wochen vor dem Start entgleisen lässt.
Der Wechsel von Erhebung zu Anforderungsermittlung erfordert die richtige Plattform zur Unterstützung kollaborativer Entdeckung. aqua cloud, eine KI-gestützte Test- und Anforderungsmanagement-Lösung, ist genau ein solches Werkzeug, das moderne Ermittlungspraktiken unterstützt. Mit aqua können Sie Ermittlungssitzungen in Echtzeit dokumentieren, strukturierte Hierarchien pflegen, die sich mit dem Input der Stakeholder weiterentwickeln, und Abhängigkeiten durch interaktive Grafiken visualisieren, die Verbindungen aufzeigen, die Stakeholder möglicherweise während Interviews nicht artikulieren. Der KI-Copilot der Plattform wandelt Ermittlungsergebnisse automatisch in strukturierte Anforderungen um. Er analysiert Workshop-Notizen, Sprachaufnahmen und sogar handgezeichnete Skizzen, um Anforderungen zu generieren, die mit der Terminologie und dem Kontext Ihres Projekts übereinstimmen. aqua integriert sich in Ihren bestehenden Workflow durch bidirektionale Synchronisation mit Jira und Azure DevOps. Es verfügt auch über native Verbindungen zu Confluence, Jenkins, Selenium und anderen Entwicklungstools über REST API. Dies bedeutet, dass die während der Ermittlungssitzungen entdeckten Anforderungen direkt in Ihr Backlog fließen, ohne manuellen Transfer.
Verwandeln Sie Stakeholder-Gespräche in nachvollziehbare Anforderungen mit 97% weniger manuellem Aufwand
Zentrale Unterschiede zwischen Erhebung und Ermittlung
Anforderungsermittlung vs Anforderungserhebung unterscheiden sich in drei Dimensionen: Engagement-Haltung, Entdeckungstiefe und Stakeholder-Erwartungen. Erhebung ist reaktiv. Sie ziehen aus bestehenden Quellen oder nehmen eingehende Anfragen entgegen. Ermittlung ist proaktiv. Sie strukturieren Gespräche, führen Experimente durch und hinterfragen Annahmen, um zu entdecken, was wirklich benötigt wird. Erhebung behandelt Anforderungen und ihre Vorteile oft als festgelegt. Ermittlung behandelt sie als Hypothesen, die es zu validieren gilt.
Die Terminologie bestimmt, wie viel Zusammenarbeit Sie erhalten werden und wie verantwortlich sich Menschen für die Ergebnisse fühlen. Der Unterschied zwischen Agile Anforderungserhebung vs. Anforderungsermittlung wird bei komplexen Projekten wichtig, bei denen Stakeholder ihre Bedürfnisse möglicherweise nicht vollständig verstehen.
Hier ein Nebeneinandervergleich dieser beiden Ansätze:
| Aspekt | Erhebung | Ermittlung |
|---|---|---|
| Haltung | Passive Sammlung | Aktive Entdeckung und Mitgestaltung |
| Quelle | Bestehende Dokumente, Tickets, geäudferte Anfragen | Stakeholder-Engagement, Beobachtung, Experimente |
| Tiefe | Oberfle4chlich; nimmt Klarheit an | Untersucht Kontext, Einschre4nkungen, implizites Wissen |
| Validierung | Minimal; nimmt an, dass Eingaben korrekt sind | Kontinuierlich; Prototypen und Tests validieren Annahmen |
| Stakeholder-Rolle | Anbieter von Antworten | Mitarbeiter bei der Problemlf6sung |
| Risiko | Falle der gee4udferten Bedfcrfnisse; fehlende NFRs und Kontext | Hf6herer Aufwand zu Beginn, aber reduziert spe4te Nacharbeit |
| Standardausrichtung | Veraltete Terminologie (Wasserfall-Erbe) | Bevorzugt in BABOK, ISO 29148, INCOSE-Leitlinien |
Den richtigen Begriff zu verwenden ist wichtig, weil er bestimmt, wie Sie Sitzungen planen, welche Techniken Sie einsetzen und ob Stakeholder vorbereitet erscheinen, um kritisch zu denken oder nur Funktionsanforderungen bei Ihnen abzuladen. Wenn Ihr BA-Playbook immer noch „Anforderungserhebung“ sagt, signalisieren Sie einen passiven, checklisten-gesteuerten Prozess, auch wenn Sie tatsächlich kollaborative Workshops durchführen. Ändern Sie die Sprache zu „Ermittlung und Zusammenarbeit“, und Sie laden Menschen zu einer Entdeckungspartnerschaft ein.
Dieser Unterschied zeigt sich auch in den Ergebnissen. Von der Ermittlung geleitete Projekte bringen nicht-funktionale Anforderungen frühzeitig zum Vorschein, so dass sie in das Design eingebaut werden, anstatt später hinzugefügt zu werden. Sie reduzieren das Risiko „wir haben das Falsche gebaut“, indem sie Funktionen auf reale Arbeitsabläufe und messbare Ergebnisse stützen. Sie erzeugen Stakeholder-Buy-in, weil Menschen bei der Gestaltung der Lösung mitgeholfen haben, anstatt sie nur zu erhalten. Erhebungslastige Projekte liefern oft genau das, was verlangt wurde, und scheitern dennoch, weil die Anfrage unvollständig, veraltet war oder nicht das Grundproblem adressierte.
„Wir sollten versuchen, sie explizit zu machen, weil alle Teammitglieder die Fakten und Zahlen kennen müssen, und es sollte keine Missverständnisse und Annahmen beim Design und Codieren geben. Wenn es Dinge gibt, die ‚implizit‘ sind, machen Sie sie explizit, indem Sie sie klar im Anforderungsdokument darlegen.“
Venkat Ramakrishnan auf Ministry of Testing
Wir sollten versuchen, sie explizit zu machen, weil alle Teammitglieder die Fakten und Zahlen kennen müssen, und es sollte keine Missverständnisse und Annahmen beim Design und Codieren geben. Wenn es Dinge gibt, die 'implizit' sind, machen Sie sie explizit, indem Sie sie klar im Anforderungsdokument darlegen.
Reale Anwendungen: Wann erheben vs. ermitteln
Wann macht jeder Ansatz Sinn? Die Antwort hängt von der Problemunsicherheit, der Domänenreife und der Komplexität der Einschränkungen ab. Wenn Sie in einer gut verstandenen Domäne mit maßgeblichen Artefakten arbeiten, kann die Erhebung Ihre Arbeit verankern. Aber Sie werden sich dennoch auf die Ermittlung stützen, um Lücken zu füllen. Wenn Sie ein neues Produkt, eine komplexe soziotechnische Änderung oder eine risikoreiche Domäne wie sicherheitskritische Systeme angehen, ist die Anforderungsermittlung unverhandelbar. Hier sind ein paar abstrakte Szenarien, um besser zu verstehen, wann Anforderungen erhoben und wann ermittelt werden sollten:
Szenario 1: Regulatorischer Ersatz oder Paritätsmigration (erhebungsgeleitet)
Sie ersetzen ein Legacy-Policenverwaltungssystem für ein Versicherungsunternehmen. Das neue System muss bestehende Funktionalität replizieren und gleichzeitig aktualisierte regulatorische Standards erfüllen. Hier definieren Artefakte wie Gesetze, SLAs, Underwriting-Handbücher und Compliance-Checklisten bereits den Großteil dessen, was Sie benötigen. Sie können durch Katalogisierung dieser Quellen, Zuordnung zu Fähigkeiten und Aufbau einer Rückverfolgbarkeitsmatrix erheben. Aber selbst in diesem Szenario werden Sie gezielte Ermittlungssitzungen durchführen, um Sonderfälle zu validieren und undokumentierte Workarounds aufzudecken. Sie werden auch bestätigen, wie nicht-funktionale Einschränkungen wie Disaster Recovery und Audit-Logging in der neuen Architektur funktionieren sollten. Die Erhebung gibt Ihnen die Baseline. Die Ermittlung erfasst, was die Dokumente übersehen haben.
Szenario 2: Neues Produkt oder Geschäftsmodell (ermittlungsgeleitet)
Sie bauen eine SaaS-Plattform für QA-Teams, um Testautomatisierung über verteilte CI/CD-Pipelines zu koordinieren. Etwas, das in dieser Form noch nicht existiert. Stakeholder können Ihnen kein Anforderungsdokument geben, weil sie noch herausfinden, was das Problem wirklich ist. Hier beginnen Sie mit Discovery-Interviews, um die Ergebnisse zu verstehen, die Teams anstreben. Solche möglichen Ergebnisse können schnellere Feedback-Schleifen, bessere Flakiness-Sichtbarkeit und einfachere teamübergreifende Berichte umfassen. Sie führen kontextbezogene Untersuchungen durch und beobachten QA-Ingenieure bei der Triage von Testfehlern. Sie erstellen Prototypen leichtgewichtiger Dashboards, um zu testen, welche Metriken tatsächlich helfen, und iterieren basierend auf Usability-Sitzungen. Die Erhebung erfolgt später. Sobald Sie auf eine Richtung konvergiert sind, werden Sie NFRs aus Sicherheitsrichtlinien, Compliance-Standards und Infrastrukturbeschränkungen erheben. Die Ermittlung treibt die Entdeckung an. Die Erhebung vervollständigt sie.
Die Wahl zwischen Erhebung und Anforderungsermittlung ist selten binär. Die eigentliche Frage ist, wann man was betonen sollte. Behandeln Sie die Erhebung als Ergänzung, die maßgebliche Details einbringt. Behandeln Sie die Ermittlung als Motor, der entdeckt, was wirklich wichtig ist. Auf diese Weise bauen Sie, um zu lösen, anstatt einfach nach Spezifikationen zu bauen.
Effektive Anforderungsermittlung generiert bedeutende Outputs aus Workshops, Interviews und Beobachtungssitzungen. Die Verwaltung all dieses entdeckten Wissens erfordert eine Plattform, die Schritt hält. aqua cloud, eine dedizierte Test- und Anforderungsmanagement Lösung, zentralisiert Ihren gesamten Ermittlungsprozess durch Validierung und Rückverfolgbarkeit. Mit aquas Requirements Engineering-Tool können Sie ermittelte Anforderungen in flexiblen Hierarchien organisieren, Versionsverlauf mit vollständigen Prüfpfaden verfolgen und durch Inline-Diskussionen und Genehmigungsworkflows zusammenarbeiten. Der KI-Copilot der Plattform zur Erstellung von Anforderungen beschleunigt die Dokumentation, indem er Ermittlungsartefakte wie Besprechungsprotokolle oder Whiteboard-Fotos in testbare Anforderungen umwandelt. Echtzeit-Dashboards visualisieren die Abdeckung und Beziehungen zwischen Anforderungen und Testfällen. aqua verbindet sich mit Tools, die Ihr Team bereits verwendet, durch Integrationen mit Jira, Azure DevOps, Confluence, TestRail und CI/CD-Plattformen wie Jenkins und GitLab. Egal, ob Sie kontextbezogene Untersuchungen oder Interviews durchführen, aqua stellt sicher, dass nichts, was während der Ermittlung entdeckt wird, verloren geht.
Sparen Sie bis zu 12,8 Stunden pro Woche, während Sie 100% Rückverfolgbarkeit über Ihren gesamten Workflow aufrechterhalten
Fazit
Hier ist die Erkenntnis: Verwenden Sie „Anforderungserhebung“ nur, wenn Sie bestehende Dokumente auflisten. Anforderungsermittlung spiegelt einen proaktiveren Ansatz wider. Es verändert, wie Sie mit Stakeholdern arbeiten, welche Methoden Sie wählen und wie tief Sie das eigentliche Problem hinter ihren Anfragen verstehen. Ermittlung verwandelt Erhebung in Entdeckung, wo Sie versteckte Bedürfnisse identifizieren und den Kontext klären. Erhebung hat immer noch Wert beim Umgang mit Legacy-Systemen oder COTS-Spezifikationen, aber Ermittlung schließt Lücken und vermeidet die Wiederholung gebrochener Prozesse. Beginnen Sie Projekte mit dieser Denkweise, um Lösungen zu schaffen, die wirklich funktionieren.
