Requirements Engineering Methoden

Die Art und Weise der Dokumentation von Anforderungen hat Einfluss auf die Analyse der Anforderungen. Meine Erfahrung ist, dass eine geeignete Dokumentationsmethodik die Analyse unterstützen kann.
Ich habe die folgenden Erfahrungen mit diesen Dokumentationsmethoden gemacht:

Sammlung von Requirements a la "Das System muss ...", strukturiert nach Thema der Anforderung
Keine Unterstützung für die Analyse, da die Anforderungen keine Beziehung zueinander haben.
Ein weiterer Nachteil ist die schwere Lesbarkeit. Der Leser muss die Anforderungen in seinem eigenen mentalen Modell zusammen setzen.
Geeignet für sehr formale Rahmenbedingungen, da einzelne Anforderungen referenziert / abgenommen / etc. werden können.
Mein Tipp: Hierarchische Übersichtsabschnitte um den Zusammenhang und das Big Picture der Anforderungen zu bekommen.

Use-Case-Modellierung (in Text-Szenarien oder als Aktivitätsdiagramm)
Use-Cases erleichtern, sicherzustellen, dass das System dem Anwender ermöglicht, sein Ziel zu erreichen. Ausnahmen und Fehlerfälle können methodisch ermittelt werden.
Meine Lieblings-Dokumentation für alle Benutzerinteraktionen, insbesondere wegen der Zielorientierung.
Ein Nachteil ist die hohe Freiheit beim Dokumentieren. Use-Cases können auf unterschiedlicher Ebene modelliert werden - was bewusst geschehen muss.
Geeignet insbesondere für Systeme mit Benutzerinteraktion.
Mein Tipp: Ein gutes Buch zum Thema besorgen.

UML-Modell (insb. Zustandsdiagramme / Klassendiagramme)
OOA-Modelle unterstützen, das System vollständig zu analysieren inkl. aller Ausnahmen. Es fällt leicht, alle Systemaspekte auf einer Abstraktionsebene zu analysieren.
Großer Nachteil ist die hohe Einstiegshürde zum Lesen und Interpretieren der OO-Modelle. Der Leser benötigt Grundverständnis der (technischen) Sprache UML.
Geeignet falls alle Leser UML verstehen oder als Hilfsmittel für den Analytiker, Vollständigkeit zu erreichen.
Mein Tipp: Mit anderen Methoden mischen, ggf. Redundanz in Kauf nehmen zugunsten der leichteren Lesbarkeit.

Scott Sehlhorst schreibt einen interessanten Artikel über Business Requirements, dass sie relativ stabil sind. Die Bedingungen eines Geschäfts, also der Markt in dem das Geschäft agiert, ändern sich relativ langsam. Im Vergleich zu den System Requirements sind die Business Requirements also relativ stabil.
Geht man bei der Analyse von den stabilen Business Requirements aus und verbindet die System Requirements streng mit den Business Requirements, desto stabiler wird die Systemspezifikation.
Wichtig ist noch, den Scope eines Projekts in Bezug auf die Business Requirements zu definieren, um Scope Creep zu verhindern.
Sein Fazit ist, dass Business Requirements essenziell und wichtig für ein Projekt sind, insbesondere wenn die System Requirements nicht einfach sind.

Interessant in diesem Zusammenhang finde ich die weiteren Faktoren, welche bei der Definition der System Requirements berücksichtigt werden. Die System Requirements werden aufgestellt auf Basis der Business Requirements, von Randbedingungen / Einschränkungen des Lösungsraums sowie der Kreativität.
Wie oft ändern sich Randbedingungen?
Der kreative Anteil der System Requirements ist sicher nicht sehr stabil. Schließlich basieren diese auf den Erfahrungen aus ähnlichen Systemen, aus verfügbaren Technologien und aus üblichen Ansätzen in ähnlichen Problemstellungen. Diese ändern sich in der IT relativ schnell. Jeder weitere befragte Stakeholder kann theoretisch eine andere Meinung haben und die bisherige Kreativität infrage stellen...

Scott Sehlhorsts Erklärung der Business Requirements greift mir allerdings etwas zu kurz: Sie wären das "was", während die System Requirements das "wie" beschreiben. Ja, das stimmt, aber... (vgl. "Was und Wie")
Meine Erklärung im Artikel über Business Goals gefällt mir noch immer ganz gut...

Dennoch teile ich Scott Sehlhorsts Schlussfolgerung, dass Business Requirements die wichtige Basis für jedes Software-Projekt sind. Ohne sie fehlt die wichtigste Basis für System Requirements und deren Priorisierung.

Kürzlich hatte ich einem Projekt mal wieder die Gelegenheit, Business Goals und ihre Bedeutung für ein Software-Projekt zu erklären. Den Gedankengang möchte ich bei dieser Gelegenheit vorstellen.

Business Goals sind ein wichtiger Grundstein für jedes Software-Projekt. Was will das Unternehmen mit dem System erreichen?
Nur wenn die Business Goals bekannt sind, können fundierte Entscheidungen in der Konzeption getroffen werden.

Business Goals beantworten, welche Mehrwerte durch das System geschaffen werden. Jede Entscheidung in der Konzeption kann so an den Mehrwerten gemessen werden - und eine Priorisierung der Requirements wird dadurch erst möglich!
Mithilfe der Mehrwerte kann das Projekt fundiert akquiriert werden (inhouse oder als Auftragnehmer).

Um so erstaunlicher, dass kaum ein Auftraggeber über Business Goals nachdenkt. Ich habe die Erfahrung gemacht, dass die Business Goals zwar intuitiv erkannt werden, aber selten explizit formuliert werden. Als Konzepter benötige ich allerdings die Business Goals, um meinen Kunden zu beraten und schließlich den größten Wert für die Anwender und das Unternehmen herzustellen.

Also beginnt mein typisches Projekt damit, dem Kunden zu erklären was Business Goals sind und wofür sie gut sind…
Die Kunden reagieren unterschiedlich - manche sind aufgeschlossen, weil ich sie unterstütze, internes Buy-In zu betreiben. Andere sind verärgert, weil ich ihnen unterstelle, ihre Business Ziele nicht zu kennen.

Immerhin kann ich inzwischen gut erklären, was Business Goals sind: Der Mehrwert, den das Unternehmen mit dem System erreicht.
Und zwar konkreter als "Gewinn" oder "Effizienz in Projekten"… Abstrakter als "ein xyz-Verwaltungs-Tool"
Einen Schlüssel dazu liefert die Pyramide der Abstraktionsebenen der Requirements. Durch die Frage, wie der Gewinn / die Effizienz mit dem System verbessert wird und durch die Frage, warum das xyz-Verwaltungs-Tool benötigt wird, komme ich sehr gut auf die richtige Ebene ("Was und Wie").
Wichtig ist nur noch, den Stakeholder mit Sinn für Geld (Mehrwerte) und Interesse für die Prozesse (Prozessanalyse) zu befragen.

Auf Ed Yourdons Website ist ein Online-Buch über strukturierte Analyse verfügbar - aktuell bis Kapitel 16. Strukturierte Analyse ist nicht mein Spezialgebiet, hier sind trotzdem viele spannende Methoden, Ideen und Ansätze beschrieben - online verfügbar.
Z. B. Ansätze um Prozesse zu spezifizieren. Einige davon kenne ich noch aus der Uni... Hier sind sie umfassend und gut beschrieben.

Ed Yourdon ist ein Urgestein der IT. Kaum ein Thema, bei dem er nicht aktiv war und ist. Mitentwickler der OO-Methodik nach Coad/Yourdon beschäftigt er sich aktuell mit Web 2.0. Schön zu sehen, dass Ed Yourdon nicht von der UML abgelöst wurde sondern weiter gute Ideen produziert!