Antwort

In der Geschichte der Systemanalyse ist eine der schwierigsten Aufgaben, nicht offensichtliche, vage oder versteckte Anforderungen zu identifizieren und zu formalisieren. Oft kann der Kunde selbst nicht klar erklären, was genau benötigt wird, oder verwendet Begriffe, ohne die tatsächlichen Erwartungen zu offenbaren.

Schlüsselmerkmale:

• Implizite Anforderungen werden durch Analyse, aktives Zuhören, klärende Fragen, Interviews und Beobachtungen ermittelt.
• Die Formalisierung erfolgt in einer Sprache, die sowohl dem Kunden als auch den Entwicklern verständlich ist (z. B. unter Verwendung von User Stories, BPMN-Szenarien).
• Es ist unbedingt notwendig, die präzisierten Formulierungen mit dem Kunden zu dokumentieren und abzustimmen, um Mehrdeutigkeiten zu vermeiden.

Historie der Frage

Das Problem nicht formalisierten Anforderungen ist seit den ersten Implementierungsprojekten bekannt. Ursprünglich wurden dafür einfache Interviews verwendet, heute kommen auch Techniken wie User Story Mapping, Prototyping und Facilitation zum Einsatz.

Problem

Implizite Anforderungen führen zu falschen Aufgabensetzungen, unnötigen Arbeitsaufwendungen und Konflikten zwischen den Parteien.

Lösung

Verwenden Sie Interviewtechniken, Visualisierung (Prozesskarten, Prototypen), Facilitation und eine klare Dokumentation der Ergebnisse. Überprüfen Sie das Feedback nach jeder Phase der Anforderungserfassung.

Fragen mit einem Haken.

Kann man alle Anforderungen im Voraus vor Projektbeginn formalisieren?

Nein, viele Anforderungen werden im Laufe der Arbeit durch Prototyping und Klärung des Projekts präzisiert und identifiziert.

Sollte man nur die ausdrücklich geäußerten Wünsche des Kunden aufzeichnen?

Nein, der Analyst sollte auch mit impliziten Erwartungen arbeiten, die Geschäftsziele analysieren und versteckte Bedürfnisse erkennen.

Ist die Aufgabe des Systemanalytikers nur, die Anforderungen in ein Lastenheft zu übersetzen?

Nein, der Analyst ist auch verantwortlich für die Formalisierung, Abstimmung und Klärung der Anforderungen sowie für die Identifizierung von Widersprüchen.

Typische Fehler und Anti-Patterns

• Interimsvereinbarungen nicht dokumentieren.
• Alle Anforderungen als gleich wichtig ansehen.
• Nur das dokumentieren, was ausdrücklich gesagt wurde, ohne die realen Prozesse zu analysieren.

Beispiel aus dem Leben

Negativer Fall:
Der Analyst hat alles, was der Kunde gesagt hat, im Projekt aufgezeichnet, ohne Details zu klären. Vorteile: die Entwicklung begann schnell, Zeitersparnis bei der Analyse.
Nachteile: viele Nacharbeiten, Konflikte mit dem Kunden aufgrund falscher Erwartungen.

Positiver Fall:
Der Analyst erstellte Prototypen, führte Klärungssitzungen durch und dokumentierte die impliziten Anforderungen zusammen mit dem Kunden.
Vorteile: hohe Genauigkeit der Anforderungen, zufriedener Kunde, weniger Konflikte.
Nachteile: Kosten für Facilitierung und Feedbacksammlung.