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.