Requirements Engineering Methoden

Auf der EuroIA hatte ich eine spannende Unterhaltung mit Patrick Roelofs über User Centered Design, als ich ihn nach der Bedeutung seines neu gegründeten Unternehmens EXPERIENCE FIRST fragte.
Immerhin ist der Begriff "User Centered Design" (UCD) in aller Munde und wird als wertvoll angesehen.

Patricks Aussagen:
User Centered Design erfüllt primär die Anforderungen der Anwender mit der Gefahr, dass die Anforderungen des Unternehmens nicht erfüllt werden und damit das Projekt scheitert.
User Experience beschäftigt sich dagegen mit dem Erlebnis des Benutzers auf der Website. Das Unternehmen will die Anwender zu Kunden machen und hat daher ein Interesse, das Erlebnis zu beeinflussen.
User Experience bringt die Anforderungen des Kunden mit denen des Unternehmens zusammen.

Die Anforderungen des Unternehmens (Business Requirements) beschreiben Eigenschaften der Website, welche die Anwender aus Sicht des Unternehmens nutzen sollen. Dass die Business Requirements erfüllt werden ist die Voraussetzung dafür, dass das Projektziel erreicht wird. Z. B. will das Unternehmen, dass seine Kunden es als innovativ wahrnimmt.
Die Anforderungen der Anwender Anwender (User Requirements) zeigen die Erwartungen der Anwender. Werden die User Requirements nicht erfüllt, nutzt niemand die Website. Anwender erwarten z. B. aktuelle Trends zu interessanten Themen.
Das Ziel ist, Business Requirements und User Requirements zusammen zu bringen. Das Ergebnis sind die Use-Cases, welche die Möglichkeiten der Website beschreiben. Sie sollen den Anwendern ermöglichen, die von ihnen gewünschten Aktivitäten im Sinne des Unternehmens durchzuführen und zeigen die Innovationskraft des Unternehmens durch Artikel über aktuelle Trends...
Projektziele stehen über den Business und User Requirements als die Ziele, die das Unternehmen mit dem Projekt erreichen will. Im Beispiel könnte die Website im Rahmen der Marketingstrategie das Bild des Unternehmens stärken.

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...