Requirements Engineering Methoden

Bei Spirit Link ist es relativ selten, dass wir ein Lastenheft erhalten. Um so schwieriger scheint es mir zu sein, in ein Projekt einzusteigen, in dem der Kunde ein Lastenheft liefert.

Ein Lastenheft beschreibt die Anforderungen des Kunden. Fast noch wichtiger sind die Randbedingungen für das Projekt und die Ziele der Anwender.
Häufig sind Lastenhefte meiner Kunden jedoch keine guten Lastenhefte.
- Typischerweise enthält das Lastenheft alle relevanten funktionalen Anforderungen
- Sehr oft fehlen die Randbedingungen
- Fast immer fehlt das "Warum", die Ziele der Anwender
- Ab und zu: das Lastenheft ist nicht mehr aktuell, und es sind viele Anforderungen nicht enthalten oder entfallen (der Klassiker)
- Typisch auch: Anforderungen auf unterschiedlichen Ebenen (siehe Blogeintrag "Abstraktionsgrad von Anforderungen")

Es ist meinen Kunden nicht vorzuwerfen, dass ihre Lastenhefte nicht perfekt sind - es ist nicht ihre Aufgabe, zu spezifizieren. Meine Kunden sind häufig Anwender oder Abteilungen, die sich mit Geschäftsprozessen beschäftigen.
Ich verstehe es als meine Aufgabe, deren Welt zu analysieren und anschließend die bestmögliche Lösung zu finden. Auch wenn ich ein Lastenheft vom Kunden erhalte, hinterfrage ich immer die Ziele der Anwender, um mögliche bessere Lösungen für die Aufgabe zu finden oder (häufiger) weitere Funktionen, die den Anwendern das Leben erleichtern können.
Mit diesem Wissen kann ich meinen Kunden beraten, wie die beste Lösung für seine Herausforderung aussieht.

In einem Projekt erhielt ich sinngemäß das Feedback "Warum fragen Sie das? Das steht doch alles im Lastenheft."
Letztlich geht es darum, dem Kunden die Motivation für diese vielen Fragen transparent zu machen.

Ich nutze gerne UML. Vielleicht liegt es daran, dass ich bei Sophist viele viele UML-Trainings gehalten habe.
Typischerweise verwende ich UML als Ergänzung zu sprachlichen Spezifikationen, z. B. für
- Zusammenhänge von Dingen (Objekten), z. B. Eine Organisationsstruktur im Klassendiagramm
- Lebenszyklus von Dingen im System, z. B. ein Dokument im Knowledge Management System im Zustandsdiagram
- Kommunikation zwischen Systemen im Sequenzdiagramm
- Natürlich das Use-Case-Diagamm als Übersicht der Dienstleistung des Systems

Selten, aber es kommt auch vor: eine vollständige objektorientierte Analyse habe ich bisher in einem Projekt durchgeführt. Alle Use-Cases habe ich vollständig durch Zustandsdiagramme spezifiziert.
Die Besonderheit war, dass der Kunde UML liebte und ich mit ihm zusammen die Diagramme entworfen habe, die alle Funktionen definierten. Es war phantastisch. Präzise, vollständig, Klar.

Die meisten Kunden würden diese Diagramme allerdings nicht verstehen.
Daher spezifiziere ich meist mit Sprache und ergänze wo sinnvoll durch Diagramme. Mein Ziel ist, einerseits den Kunden eine verständliche Spezifikation zu liefern und andererseits präzise und eindeutig zu definieren. Kunden verstehen Sprache (fast :) immer, allerdings sind komplexe Zusammenhänge schwer beschreibbar. Diese fasse ich in ein Diagramm und ergänze die sprachliche Beschreibung.