Anforderungserhebung als Mindmap: kostenlose Vorlage für Analysten

Anforderungserhebung als Mindmap: kostenlose Vorlage für Analysten

Die interaktive MindMap-Zeichenfläche zu dieser Erklärung — jede Bahn, jede Zeile und jeder Pfeil oben gehört zu einem echten QueryChart-Diagramm, das Sie öffnen und bearbeiten können.

So lesen Sie diese Mindmap

• Beginnen Sie mit „Stakeholder“ und „Geschäftsbedarf“, um zu sehen, wer beteiligt ist und warum. „Nutzerbedürfnisse“ beschreibt den Bedarf aus Sicht der Nutzer, „Funktionale Anforderungen“ und „Nicht funktionale Anforderungen“ übersetzen ihn in das, was das System leisten muss, und wie gut.
• Gestrichelte Pfeile zeichnen die Argumentation nach. Eine Fähigkeit unter „Priorität“ wird zum Beispiel durch das Erfolgsmaß in „Zielergebnis“ begründet, und ein Sicherheitsbedarf in „Sicherheit und Datenschutz“ kann mit einer technischen Grenze in „Technische Grenzen“ kollidieren.

Stakeholder

„Stakeholder“ steht am Anfang, weil hinter jeder Anforderung jemand steht. Tragen Sie unter „Sponsoren“ ein, wer zahlt, unter „Endnutzer“, wer das Ergebnis nutzt, und unter „Freigeber und Unterstützer“, wer es freigeben oder unterstützen muss.

Befragen Sie alle aus „Endnutzer“, nicht nur deren Vorgesetzte. Ein häufiger Fehler ist, Anforderungen nach der Schilderung des Sponsors zu schreiben, die sich auf Arbeit bezieht, die er gar nicht mehr macht.

Geschäftsbedarf

„Geschäftsbedarf“ erklärt, warum das Projekt existiert. „Zu lösendes Problem“ ist das Problem oder die Chance, „Zielergebnis“ das Ergebnis, das als Erfolg gelten würde, und „Erfolgsmaß“ die Messgröße, die ihn belegt.

Jede Anforderung an anderer Stelle der Mindmap sollte sich hierauf zurückführen lassen. Gelingt das nicht, fragen Sie, welchem Bedarf sie dient, oder streichen Sie sie.

Nutzerbedürfnisse

„Nutzerbedürfnisse“ hält fest, was Menschen erledigen müssen. Formulieren Sie „Zu erledigende Aufgaben“ als Aufgaben aus Sicht der Nutzer und erfassen Sie unter „Aktuelle Schmerzpunkte“ die Schmerzpunkte der heutigen Arbeitsweise.

„Nutzungskontext“ enthält die Situation, in der Nutzer arbeiten, etwa am Handy, an lauten Orten oder unter Zeitdruck. Diese Details entscheiden oft mehr über den Entwurf als die Aufgaben selbst.

Funktionale Anforderungen

„Funktionale Anforderungen“ listet auf, was das System leisten muss. „Kernfähigkeiten“ sind die Hauptfähigkeiten, „Geschäftsregeln“ die Regeln, die es anwenden muss, und „Schnittstellen“ die Schnittstellen zu anderen Systemen oder Teams.

Formulieren Sie jede so, dass sie sich testen lässt, zum Beispiel: Das System sendet innerhalb einer Minute eine Bestätigung. Nutzen Sie „Testbare Aussage“ als Vorbild für die Formulierung der Details.

Nicht funktionale Anforderungen

„Nicht funktionale Anforderungen“ betrifft, wie gut das System arbeiten muss. „Leistung“ legt Geschwindigkeit und Kapazität fest, „Sicherheit und Datenschutz“ behandelt Sicherheit und Datenschutz, „Benutzbarkeit und Zugang“ Benutzbarkeit und Barrierefreiheit.

Das sind die Anforderungen, nach denen man gern nicht fragt und über die man nach dem Start streitet. Geben Sie jeder, wo möglich, eine Zahl oder einen Standard.

Randbedingungen

„Randbedingungen“ listet die Grenzen auf, die die Lösung nicht überschreiten darf. „Budget und Zeit“ sind Budget und Zeit, „Technische Grenzen“ technische Grenzen wie bestehende Systeme, und „Recht und Richtlinien“ rechtliche oder interne Vorgaben.

Prüfen Sie jede Anforderung früh gegen „Technische Grenzen“. Eine Anforderung, die einer harten Randbedingung widerspricht, ist eine Entscheidung für den Sponsor, keine Aufgabe für das Team.

Wie die Zweige zusammenhängen

Bedürfnisse fließen nach unten. „Geschäftsbedarf“ liefert den Grund, „Nutzerbedürfnisse“ die Sicht der Nutzer, und „Funktionale Anforderungen“ und „Nicht funktionale Anforderungen“ sind die daraus abgeleiteten Anforderungen. Eine Anforderung ohne Quelle in den ersten drei Zweigen ist ein Kandidat zum Streichen.

„Randbedingungen“ drückt nach oben zurück. Eine Randbedingung kann einen Bedarf unbezahlbar machen, was Sie zu „Geschäftsbedarf“ zurückführt, um zu fragen, ob ein kleineres Ergebnis akzeptabel ist, und zu „Stakeholder“, um es abzustimmen.

Wo die Mindmap endet und andere Diagramme beginnen

Nutzen Sie die Mindmap zum Sammeln und Ordnen. Um zu beschreiben, wie Arbeit heute fließt und künftig fließen soll, zeichnen Sie eine Prozesslandkarte oder ein Flussdiagramm, und nehmen Sie ein Swimlane-Diagramm, wenn Anforderungen von Übergaben zwischen Teams abhängen.

Ein Organigramm kann die Stakeholder- und Freigabestruktur dokumentieren, und ein Gantt-Diagramm übernimmt, sobald die Anforderungen zu einer terminierten Lieferung werden.

Wichtige Zusammenhänge und Erkenntnisse

• Jede Anforderung sollte sich auf einen Geschäftsbedarf und einen Stakeholder zurückführen lassen.
• Nutzerbedürfnisse werden als Aufgaben geschrieben, funktionale Anforderungen als testbares Verhalten.
• Nicht funktionale Anforderungen fehlen in frühen Entwürfen am häufigsten.
• Randbedingungen werden von Menschen entschieden und erscheinen daher auch unter Stakeholdern.
• Eine Anforderung ohne Priorität wird als genauso dringend behandelt wie alle anderen.

Wann Sie diese Darstellung nutzen

• Stakeholder-Interviews vorbereiten und die Antworten auf einer gemeinsamen Mindmap festhalten.
• Den Entwurf eines Anforderungsdokuments vor der Freigabe auf fehlende Kategorien prüfen.
• Ein kleines internes Tool eingrenzen, für das eine vollständige Spezifikation zu viel wäre.

So funktioniert es

1. Die Beteiligten ermitteln

   Benennen Sie „Projektanforderungen“ um, tragen Sie die Stakeholder unter „Stakeholder“ ein und markieren Sie, mit wem Sie noch nicht gesprochen haben. Führen Sie Interviews, bevor Sie die übrigen Zweige füllen.

2. Bedürfnisse so erfassen, wie man sie hört

   Tragen Sie Gründe unter „Geschäftsbedarf“, Nutzeraufgaben unter „Nutzerbedürfnisse“ und Systemverhalten unter „Funktionale Anforderungen“ ein. Vermerken Sie die Quelle in jedem Knoten, damit Sie nachprüfen können.

3. Grenzen und Konflikte prüfen

   Vergleichen Sie jede Anforderung mit „Nicht funktionale Anforderungen“ und „Randbedingungen“, ziehen Sie Verbindungen bei Konflikten und tragen Sie die offenen Konflikte zu den Stakeholdern aus „Stakeholder“.

Häufig gestellte Fragen

Was ist der Unterschied zwischen funktionalen und nicht funktionalen Anforderungen?

Funktionale Anforderungen sagen, was das System tut, etwa eine Rechnung erstellen oder einen Alarm senden. Nicht funktionale Anforderungen sagen, wie gut es das tun muss: Geschwindigkeit, Sicherheit, Verfügbarkeit, Barrierefreiheit. Beide sind nötig, und die nicht funktionalen werden meist spät entdeckt, wenn man nicht direkt danach fragt.

Warum mit Stakeholdern beginnen statt mit Funktionen?

Weil jede Anforderung einen Eigentümer hat, der sie erklären und bei Bedarf ändern kann. Mit Funktionen zu beginnen ergibt eine Liste, die niemand verteidigen oder priorisieren kann. Mit Menschen zu beginnen sagt Ihnen, wen Sie befragen müssen und wer zustimmen muss, wenn zwei Anforderungen kollidieren.

Wie detailliert sollten Anforderungen auf einer Mindmap sein?

Detailliert genug, um sie zu erkennen und zu besprechen, kurz genug, um sie zu überfliegen. Nutzen Sie die Idee für eine kurze Aussage und die Notiz für die Quelle oder die Testbedingung. Wird ein Zweig zu voll, verlagern Sie ihn in eine Anforderungsspezifikation oder ein Backlog mit User Stories.

Können Stakeholder die Mindmap direkt prüfen?

Ja. Teilen Sie das Diagramm mit den Prüfern, lassen Sie sie einzelne Anforderungen kommentieren und halten Sie über den Versionsverlauf fest, was sich zwischen Prüfrunden geändert hat. Das macht die Freigabe verlässlicher, als Dokumente hin- und herzumailen.

Mit dieser Anforderungs-Mindmap starten

Öffnen Sie die Vorlage als eigene Fläche, benennen Sie das Projekt und beginnen Sie mit den Stakeholdern, mit denen Sie sprechen müssen.

Mit dieser Anforderungs-Mindmap starten