Share ZU:
18 August 2015 @ Christian Wünch

Die vier Entwicklungsstadien einer Anforderung

Anforderungen entstehen üblicherweise im Laufe eines Entwicklungsprojektes und beeinflussen in hohem Maße dessen weiteren Verlauf. Sie sind die Grundlage vieler Entwicklungstätigkeiten und steuern damit zu einem nicht unerheblichen Teil das Geschehen. Änderungen in den Anforderungen führen häufig auch zu Änderungen der gesamten Projektsituation.

Um solche Veränderungen darstellen und den Entwicklungsprozess besser steuern zu können, sollte man den Fortschritt einer Anforderung strukturieren. Denn wie bei uns Menschen ist das Leben einer Anforderung in unterschiedliche Abschnitte bzw. Stadien unterteilt. Diese Stadien nennen wir im Requirements Management Zustände.

Während sich das Leben von uns Menschen allerdings in eine Vielzahl von Lebensabschnitten gliedert, ist die Existenzspanne einer Anforderung überschaubar und vergleichsweise einfach. Sie wird vor allem dadurch komplex, dass man zur vermeintlich besseren Kontrolle eine Unmenge von Zuständen einführt.

Eine solche Überbürokratisierung des Lebenszyklus einer Anforderung hilft aber meist selten, vor allem dann nicht, wenn sich der betroffene Projektmitarbeiter mit einem Reichtum an Zuständen konfrontiert sieht, die er als Laie gar nicht alle unterscheiden kann (und will). Hier besteht die Gefahr einer Fehlzuordnung oder Falschdiagnose, die den Projektfortschritt zurückwerfen kann.

Eine Reduzierung auf die wesentlichen Kernzustände einer Anforderung hilft, Komplexität einzuschränken und den gemeinschaftlichen Arbeitsrhythmus zu beschleunigen. So wird vermieden, dass Anforderungen falsch “geparkt” werden. Die folgende Darstellung zeigt den Minimal Flow einer Anforderung, der ihren grundsätzlichen Lebenszyklus vollständig abbildet und bei Bedarf erweitert werden kann.

Minimal-Workflow

proposed: Die Anforderung eines Stakeholders an das zu entwickelnde System liegt vor.

confirmed: Die Anforderung wurde geprüft und mit den betroffenen Personen abgestimmt (u.a. die Feststellung der Machbarkeit).

resolved: Die Anforderung wurde erfolgreich umgesetzt und wird vom System somit erfüllt.

closed: Die Anforderung wurde entweder nicht umgesetzt oder ist bereits fertig implementiert und getestet worden. Sie muss vom entsprechenden Entwicklungsprojekt nicht mehr weiter bearbeitet werden.

Es spricht natürlich nichts dagegen, diesen Zyklus den eigenen Gegebenheiten anzupassen und zu erweitern. Auch die Benennung der einzelnen Zustände sollte den bekannten Namenskonventionen und Vertrautheiten im Team entsprechen. Erfahrungen haben jedoch gezeigt, dass weniger Zustände für schnellere und effizientere Arbeitsabläufe sorgen und Missverständnisse vermieden werden.

Christian Wünch

Kontaktieren Sie Christian Wünch

Christian Wünch ist Consultant, Trainer und Coach bei der HOOD Group. Er berät unterschiedlichste Branchen aus Wirtschaft und Industrie auf den Gebieten der Systemanalyse und des Requirements Engineering. Seine Schwerpunkte liegen in der Analyse und Verbesserung von Systementwicklungsprozessen, RE-Einführungsstrategien sowie Requirements Management. Neben regelmäßigen Vorträgen und Veröffentlichungen für Konferenzen und Fachpresse zum Thema RE beschäftigt er sich mit den Möglichkeiten der Formalisierung von Anforderungen und sucht nach Wegen, natürlichsprachige Anforderungen für Systeme und Menschen verständlicher zu machen.