Requirements Engineering Methoden

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.

Je tiefer ich in die Anforderungshierarchie abtauche, desto mehr Grundannahmen über die Lösung sind ja notgedrungen schon getroffen. Die nichtfunktionalen Randbedingungen, der Markt, die technischen Möglichkeiten: wenn ich all diese Faktoren ausblende, um möglichst reine Analyse zu betreiben, werde ich für das vorrangige Ziel, nämlich ein bezahl- und realisierbares Produkt zu bauen, vermutlich keine übermäßig wertvolle Arbeit vollbringen. Ich halte den Diskurs daher auch für eher akademisch. Zumal ja auch die Zielgruppe ihre Bedürfnisse nicht abstrakt äußert, sondern fast immer gebunden an Lösungsideen: "Hier möchte ich das einfach mit Drag-und-Drop verschieben können". (Was nicht heißt, dass man geforderte "Lösungen" nicht erst einmal bezüglich der dahinterliegenden Ziele hinterfragen sollte.)

Der Prozess ist doch immer iterativ: Ich analysiere das Geschäft des Kunden, beschreibe daraus eine Anforderung. Dazu wird eine Lösung konzipiert. Kosten und Adäquatheit der Lösung werden von den Verantwortlichen der nächsten Lösungsstufe eingeschätzt. Falls nicht angemessen, wird man einen Schritt zurückgehen, die Anforderung modifizieren usw.

Etwas anders mag das im Bereich Innovation und Vorentwicklung sein, wo der Freiraum gegeben sein sollte, gewachsene Rahmenbedingungen erst einmal zu ignorieren.

Ich glaube es geht um Problem und Lösung.
In der Praxis finde ich es nützlich Anforderungen (Probleme) inklusive der evtl. vorhandenen Lösungen aufzuschreiben. Wichtig ist nur, die Lösung als solche zu kennzeichnen.
Manchmal ist es ja praktisch, die vom Stakeholder genannte Lösung als Teil der Lösungsbeschreibung (Konzept) zu verwenden. Erkennt man etwas jedoch nicht als vorgefasste Lösung, so verbaut man sich die Möglichkeit von etwas Neuem, oder einer in Summe besseren Lösung.
Beispiel: Die Anforderung lautet: "Dateien per copy&paste von einem Verzeichnis in ein anderes verschieben." Wer hier die Lösung nicht als solche erkennt, verhindert gewissermaßen das drag&drop.