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.

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.

Diesen Blogartikel hat Christian Wünsch für HOOD geschrieben.