Requirements Engineering Methoden

Ich bin über einen interessanten Ansatz zum Requirements Engineering von nicht funktionalen Anforderungen gestoßen, dem aspektorientierten RE.
Aspektorientierte Programmierung ist eine Methode, um querschnittliche Themen wie Sicherheit, Verfügbarkeit, Persistenz in der Software-Architektur zu kapseln. In der klassischen Objektorientierung ist dies schwer möglich, weshalb die Aspektorientierung neue Konzepte eingeführt hat.

Das aspektorientierte Requirements Engineering führt explizite Methodiken ein, um diese querschnittlichen Aspekte in der Spezifikation separat zu beschreiben.
Es ist vielleicht nicht neu, nicht funktionale Anforderungen separat zu dokumentieren. Hier werden explizite Vorteile davon beschrieben. Z. B. ist die Verbindung zur Software-Architektur (aspektorientiert!) sehr einfach.
Außerdem wird immer wieder die Wichtigkeit dieser Anforderungen als Grundlage für die Architektur betont.
Ich nehme mir die Artikel zum Thema vor, in der Hoffnung auf weitere Anregungen - auch wenn bei Spirit Link nicht aspektorientiert programmiert wird...

Referenz: Early Aspects.net

Die Strategie oder die Ziele einer Applikation sind grundlegende Entscheidungen bei ihrer Entwicklung. Manchmal ist es allerdings schwer, diese Entscheidungen zu treffen.
Viele Kunden haben nicht die Erfahrung oder können aufgrund der Abstraktheit der Strategie und der Ziele diese Entscheidung nicht treffen.

In seinem Vortrag über IA Strategy nannte Olly Wright auf der EuroIA 2006 die Personas als guten Startpunkt für eine Strategiediskussion.
Personas beschreiben, welche Anwender mit welchen Zielen das System verwenden. Siehe auch Wikipedia.
Auf ihrer Grundlage kann die Strategie ermittelt werden. Die Strategie beschreibt letztlich, welche Anwender welches Ergebnis erreichen können sollen. Sie hat daher direkte Auswirkung auf die Personas.
Im ersten Schritt stellt der Analytiker mögliche Personas auf, die dann im Workshop mit den Kunden verifiziert werden.

Ein Ansatz für die Strategie- oder Zielediskussion sind konkrete Konzeptions-Ergebnisse, die möglichst direkt aus der Strategie und den Zielen resultieren, wie z. B. Personas oder Use-Cases. Auf ihrer Grundlage können dann wieder Rückschlüsse für die Strategie und die Ziele getroffen werden.

Ich bin gespannt, dieses Vorgehen auszuprobieren. In meinem letzten Projekt, das aufgrund unklarer Ziele litt, wäre dies sicher anstrengend gewesen, hätte aber zum Erfolg führen können...

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.

Der Begriff Anforderungsanalyse bzw. Requirements Engineering schließt streng genommen nur die Analyse ein. D. h. das Ermitteln von bestehenden Informationen und Wissen.

Was ist aber mit der Konzeption?
Also dem Entwickeln von etwas Neuem? Sind Requirements Engineers nur die Moderatoren, die andere dazu bringen das Neue zu entdecken und zu formulieren?

Wikipedia ist sich auch nicht einig. Im deutschen Artikel Anforderungsanalyse werden nur Anforderungen (Forderung = "Was") beschrieben. Der englische Artikel Requirements Engineering schließt auch die System Requirements Specification (SRS) ein, welche das Verhalten des Systems beschreibt (Konzept = "Wie").

Vielleicht liegt dem nur ein ungenau definierter / benutzer Begriff "Anforderung" zugrunde? Das Wort beschreibt eine Forderung, also kein Konzept. Siehe auch den Post Was und Wie.
Wikipedia definiert übrigens eine Anforderung als Teil des Lastenhefts, also als Forderung.

Ich nutze den Begriff "Requirements Engineering" eigentlich übergreifend - also als Analyse und Konzeption. Ich bin Analytiker und Konzepter.
Streng genommen sind jedoch beide wichtige Schritte bei der Entwicklung eines Systems, die eng verzahnt und doch unterschiedlich sind.