Middle Business Analyst — Business-Analyst-Interviewfragen

Wie priorisierst du Anforderungen, wenn jeder behauptet, seine sei kritisch?

Indem man den Trade-off sichtbar macht, statt über Wichtigkeit zu streiten: was jede Anforderung bringt, was sie kostet und worauf man verzichtet, wenn man die andere zuerst macht. MoSCoW funktioniert, wenn die Kategorien gedeckelt sind, sonst wird alles zum Must. Die Frage, die die meisten Debatten beendet, ist, was passiert, wenn das erst im nächsten Quartal ausgeliefert wird.

Wie gehst du mit einer Anforderung um, die sich mitten in der Entwicklung ändert?

Erst die Auswirkung bewerten, bevor man zustimmt oder ablehnt – was noch davon abhängt, was bereits gebaut ist, was die Verzögerung kostet. Dann ist es eine Entscheidung mit einem Verantwortlichen, kein Gefallen. Schleichender Scope Creep, bei dem jede Änderung klein ist und niemand die Summe verfolgt, ist der Grund, warum aus einem Zwei-Monats-Projekt sechs Monate werden.

Was ist eine Traceability-Matrix und wann lohnt es sich, sie zu pflegen?

Eine Abbildung von Anforderungen auf Design, Code und Tests, die sie erfüllen. Es lohnt sich, wenn man Abdeckung nachweisen muss – regulierte Branchen, Audits, Sicherheit – anderswo ist es Bürokratie. Die ehrliche Version ist ein Link vom Ticket zum Test, keine Tabelle, die niemand pflegt.

Wie modellierst du einen Prozess, und was bringt das eigentlich?

BPMN oder ein einfaches Schwimmbahnen-Diagramm, das zeigt, wer was tut und wo die Übergaben liegen. Der eigentliche Nutzen ist nicht das Bild – beim Zeichnen fallen die Schritte auf, die niemand benennen konnte, und die Entscheidungen ohne Verantwortlichen. Die meisten Prozessprobleme entdeckt man beim Modellieren, nicht beim Lesen des Modells.

Was ist der Unterschied zwischen Validierung und Verifikation von Anforderungen?

Verifikation fragt, ob die Anforderung gut formuliert ist – klar, testbar, konsistent mit den anderen. Validierung fragt, ob es die richtige Anforderung ist – ob sie tatsächlich dem Geschäftsbedürfnis dient. Ein Dokument kann die Verifikation vollständig bestehen und trotzdem das falsche System beschreiben.

Wie schreibst du Anforderungen für eine Integration mit einem externen System?

Man beginnt beim Vertrag: welche Daten die Grenze überqueren, in welcher Form, wie oft, und was passiert, wenn die Gegenseite nicht erreichbar ist oder Fehlerhaftes liefert. Die Fehlerfälle sind die eigentliche Anforderung – eine Spezifikation, die nur den Idealfall beschreibt, erweist sich beim Testen als unvollständig, und dann wird es teuer.