Business-Analyst-Interviewfragen

Was ist der Unterschied zwischen funktionalen und nicht-funktionalen Anforderungen?

Funktionale Anforderungen beschreiben, was das System tun muss – ein Nutzer kann sein Passwort zurücksetzen, eine Rechnung lässt sich exportieren. Nicht-funktionale Anforderungen beschreiben, wie gut es das tun muss: Antwortzeit, Anzahl gleichzeitiger Nutzer, Verfügbarkeit, Sicherheit, Barrierefreiheit. Genau die nicht-funktionalen Anforderungen vergessen Teams aufzuschreiben, und genau sie erzwingen am ehesten eine architektonische Neufassung, wenn sie erst spät auffallen.

Wie schreibst du eine User Story? Was sind Abnahmekriterien?

Eine User Story folgt dem Muster „Als Rolle möchte ich eine Aktion, damit ein Nutzen entsteht" – der letzte Teil zählt am meisten, weil er das Warum festhält und dem Team erlaubt, bessere Lösungen vorzuschlagen. Abnahmekriterien definieren „fertig" in testbaren Begriffen, oft im Given-When-Then-Format, das den Standardfall, Grenzfälle und Fehler abdeckt. Eine Story ohne Kriterien ist eine Einladung, sie auf drei verschiedene Arten zu interpretieren.

Welche Techniken zur Anforderungserhebung nutzt du?

Interviews gehen in die Tiefe der Perspektive einer einzelnen Person, Workshops bringen Konflikte zwischen Stakeholdern früh ans Licht, Beobachtung zeigt, was Menschen tatsächlich tun statt was sie sagen, Dokumentenanalyse erfasst bestehende Regeln, und Prototypen liefern konkretes Feedback, das eine abstrakte Diskussion nie hervorbringt. Die Wahl hängt davon ab, wie gut die Domäne bereits verstanden ist – je unklarer das Problem, desto mehr setzt man auf Beobachtung und Prototypen.

Was machst du, wenn Stakeholder widersprüchliche Anforderungen stellen?

Man macht den Konflikt sichtbar, statt still eine Seite zu bevorzugen: beide Positionen dokumentieren, die jeweilige Begründung und den Kompromiss. Danach bringt man die Stakeholder mit Daten zusammen – Nutzungszahlen, Kosten, Risiko – und holt eine Entscheidung von der Person ein, die das Ergebnis verantwortet. Der Fehler ist, den Konflikt im Stillen zu lösen, denn die unterlegene Seite erfährt davon erst bei der Abnahme, und die Arbeit wird abgelehnt.

Was ist MoSCoW-Priorisierung? Gib ein Beispiel.

MoSCoW sortiert Anforderungen in Must have, Should have, Could have und Won't have this time. Must-Punkte sind die, ohne die das Release keinen Wert hat; Won't ist die nützlichste Kategorie, weil sie Ausschlüsse explizit macht und schleichendem Scope Creep vorbeugt. Eine verbreitete Disziplin ist, Must auf etwa sechzig Prozent der Kapazität zu deckeln, damit Raum bleibt für das, was sich bei der Umsetzung zwangsläufig zeigt.

Welche UML-Diagramme hast du schon verwendet? Wann nimmst du ein Use-Case-Diagramm, wann ein Sequenzdiagramm?

Ein Use-Case-Diagramm zeigt, welche Akteure mit welchen Systemfunktionen interagieren – gut geeignet für Scoping-Gespräche mit dem Business. Ein Sequenzdiagramm zeigt die zeitlich geordneten Nachrichten zwischen Komponenten und richtet sich an Entwickler, die eine Interaktion entwerfen. Aktivitäts- und BPMN-Diagramme liegen dazwischen und beschreiben Prozessabläufe, und ein Zustandsdiagramm ist das richtige Werkzeug, wenn eine Entität einen Lebenszyklus hat, etwa eine Bestellung oder ein Schadensfall.

Was sind BRD, FRD und SRS? Worin unterscheiden sie sich?

Ein BRD hält Geschäftsbedürfnisse und -ziele in der Sprache des Business fest – das Warum. Ein FRD übersetzt das in konkretes Systemverhalten – das Was. Ein SRS ist die vollständige Spezifikation mit funktionalen und nicht-funktionalen Anforderungen, Randbedingungen und Schnittstellen, meist für ein technisches Publikum. Viele agile Teams ersetzen alle drei durch ein Product Backlog plus schlanke Begleitdokumente und halten formale Spezifikationen nur dort vor, wo es die Compliance verlangt.

Wie überprüfst du, dass die Anforderungen für das Entwicklungsteam klar sind?

Das stärkste Signal sind die Fragen, die beim Refinement gestellt werden – Schweigen bedeutet meist, dass sich das Team nicht wirklich damit auseinandergesetzt hat, nicht dass alles klar ist. Praktische Prüfungen sind, einen Entwickler die Story in eigenen Worten wiedergeben zu lassen, die Abnahmekriterien vor Entwicklungsbeginn mit der QA durchzugehen und in einer Prototyp- oder Example-Mapping-Session versteckte Annahmen aufzudecken. Alles, was hier auffällt, ist um ein Vielfaches günstiger als nach der Umsetzung.