Requirements Engineering Methoden

Auf der EuroIA zeigte mir Casper Honijk in irgendeiner Diskussion ein Bild über Abstraktionsebenen von Anforderungen, das genauso wie meins aussah!
Was mich bestätigt, dass ich auf dem richtigen Weg bin :-)


Casper nutzt die Namen der Ebenen für die Kommunikation über seinen Konzeptions-Prozess mit seinen Kunden. Z. B. macht er deutlich, dass ein Lastenheft des Kunden nur die "Needs" beschreibt, bis zum Requirements aber noch viel Arbeit auch des Kunden nötig ist.

Interessant fand ich, dass er die verschiedenen Ebenen verknüpft und eine durchgängige Traceability erzeugt. (Würde mich sehr interessieren, dies in Aktion zu sehen – ich bin nicht überzeugt, dass Traceability grundsätzlich funktioniert!)
Auf diese Weise ist z. B. sichergestellt, dass ohne Needs keine Requirements entstehen. Findet der Analytiker kein Bedürfnis, wird auch keine Software dazu erstellt.

Die Namen der Ebenen sind einerseits eine gute Idee, allerdings würde ich sie anders benennen...
Gut, weil sie die Kommunikation mit Anwendern unterstützen. Die Namen sind einfach weitere Bezeichnungen neben "Lastenheft" und "Pflichtenheft".
Ich hätte die Needs "Requirements" genannt. Huch, die stehen ja wo anders...

Ich bin nicht Ihrer Meinung, dass Needs "Requirements" genannt werden. Meiner Auffassung nach sind das zwei unterschiedliche Dinge. Needs beschreiben die Wünsche, also Vorstellungen der Stakeholder und werden beispielsweise mit User Stories festgehalten. Ob daraus aber umsetzbare Requirements werden, steht auf einem anderen Blatt Papier. Insofern finde ich die Grafik passend.