Häufige Fehler bei der Anforderungsanalyse

Der spannendste Prozess der gesamten Software-Entwicklung ist für mich die Anforderungsanalyse. Hier wird entschieden, ob die Software wirklich eine Lösung für ein Problem darstellt, oder neue Probleme verursacht. Fehler in diesem Prozess sind meist sehr teuer und können ein gesamtes Projekt zum Scheitern verurteilen.
In meiner Arbeit habe ich viele schlechte Anforderungen erhalten. Die hauptsächlichen Fehlerquellen liegen in den folgenden Bereichen:

 

Substantive werden immer in Klassen modelliert

Das scheint ein Klassiker zu sein. Immer wieder ist mir dieser Fehler begegnet. Dabei wird offensichtlich mit dem Kunden gesprochen und seine Wünsche in einem Prosa-Aufsatz festgehalten. Dieser Aufsatz wird dann analysiert und Substantive als Kandidaten für Entities (Klassen) abgeleitet. Eine Modellierung als eigenständige Klasse erschwert aber immens die Implementierung und die spätere Wartung.

Besser: Viele dieser Substantive sind in Wahrheit Typen von übergeordneten Klassen, durch einen generischen Ansatz werden sowohl bei der Implementierung, als auch bei der späteren Wartung der Software hohe Aufwände gespart.

 

User-Interfaces werden von Modell-Klassen abgeleitet

Offensichtlich ist es zum durchdenken einfacher, wenn man pro Klasse eine Listenansicht und eine Bearbeitungsmaske gestaltet. Schließlich hat doch jeder Entwickler schon einmal eine MS Access-Datenbankanwendung mit den coolen Wizards erstellt.  Doch hier denkt man nicht an den Endanwender. Denn dieser benötigt oft Daten aus unterschiedlichen Klassen auf einer Maske, um sinnvoll mit dem System zu arbeiten.

Besser: Eine Analyse der Use-Cases ist unumgänglich. Die Ergebnisse sollten in sinnvolle Userinterfaces umgewandelt werden.

 

User-Interfaces werden nur verbal beschrieben

Aus einer verbalen Beschreibung ist es nicht möglich, eine Benutzeroberfläche zu bauen, die genau den Vorstellungen des Endkunden entspricht. Daher werden notgedrungen Fehler entstehen, wenn auf ein Mockup verzichtet wird.

Besser: Mit einfachen Mockup-Tools wie z.B. Pencil, Powerpoint, Word, eine Skizze zeichen. Zur Not reicht fürs erste eine einfache Zeichnung mit Kugelschreiber und Papier.

 

Geschäftsprozesse werden nur verbal beschrieben

Manche Analysten weigern sich immer noch, gängige Ablauf-Diagramme zu verwenden. UML ist inzwischen ein Standard, aber das hat sich leider noch nicht überall herumgesprochen. Dabei werden wichtige Zusammenhänge durch die Verwendung einer graphischen Darstellung viel besser veranschaulicht.

Besser: Die Verwendung eines UML-Werkzeugs, um Prozesse visuell darzustellen, erleichtert allen die Klärung der Anforderungen.

 

Modell-Klassen werden auf reine Getter- und Setter beschränkt

Eine etwas übertriebene Auslegung der Trennung von Modell- und Business-Logik sieht vor, die Modell-Klassen auf reine Getter- und Setter-Methoden zu beschränken. Logik, die zwar eine Klasse betrifft, aber über einen reinen Getter hinaus geht, wird dabei in eine eigene Schicht verschoben. Dadurch entsteht Wartungsaufwand für eine neue Software-Schicht.

Besser: Logik, die ein Objekt einer Klasse betrifft, kann und soll direkt in der Modell-Klasse abgebildet werden.