Anforderungen mit Verfallsdatum

Es sind zu viele. Die Menge ist zu groß. Es ist einfach nicht zu schaffen und jeden Moment kommen neue hinzu. Die Rede ist von Anforderungen. Von Kunden und Interessenten erhalten Sie Anforderungen. Das Produktmanagement erstellt Wettbewerbsvergleiche und das Ergebnis führt zu neuen Anforderungen. Marketing und Vertrieb wollen Verkaufschancen verbessern und auch das führt zu neuen Anforderungen. Neue Gesetze, Normen, Regeln, freiwillige Auflagen – alles führt zu Anforderungen. Irgendwann verlieren Sie den Überblick. Die Menge der Anforderungen ist zu groß. Und nun? Wie können Sie Anforderungen reduzieren oder eliminieren? Nach welchen Kriterien gehen Sie vor? Was halten Sie von der Idee, Anforderungen mit einem Verfallsdatum zu versehen?

Die Prüfung formaler Kriterien

Wenn Sie die Menge der Anforderungen reduzieren wollen, liegt es nahe, Anforderungen auf formale Kriterien zu überprüfen. Sie können beispielsweise überprüfen, ob jede Anforderung eine Quelle, einen Beschreibungstext, einen erwarteten Nutzen oder ein Abnahmekriterium hat. Arbeiten Sie in Ihren Projekten mit einem Anforderungsmanagement-System finden Sie leicht die Anforderungen, die Ihren formalen Kriterien nicht genügen. Es könnte allerdings sein, dass Ihre Software Sie daran hindert, eine Anforderung als definiert zu deklarieren, wenn die hinterlegten formalen Kriterien noch nicht erfasst wurden. Das würde bedeuten, dass Sie erst weitere Arbeit in die formale Beschreibung der Anforderungen investieren müssten, bevor Sie sich Gedanken machen können, ob Sie die Anforderungsmenge um genau diese eine Anforderung reduzieren. Anforderungen anhand der Existenz formaler Kriterien zu eliminieren, kann also ein Mittel zur Reduzierung von Anforderungen sein, muss es aber nicht.

Die Prüfung des Systemkontexts

Bei der Entwicklung von Systemen ist die Definition des Systemkontexts eine der ersten Aufgaben. Mit dem Systemkontext bestimmen Sie die Grenzen Ihrer Entwicklung, das heißt Sie legen einen Bereich fest, für den Sie Anforderungen erfassen wollen. Definieren Sie beispielsweise, dass Sie ein neues System C bauen wollen, das mit System B interagieren soll, ist es für Ihr Projekt unerheblich, ob es neue Anforderungen für System A gibt. System A liegt in der sogenannten irrelevanten Umgebung. Gibt es Anforderungen zur Kommunikation zwischen System B und System C, so ist es an Ihnen zu definieren, ob diese Anforderungen zu Ihrem Scope gehören oder eben nicht.

Haben Sie zu Beginn eines Projekts einen solchen Systemkontext definiert, können Sie sich bei jeder neuen Anforderung fragen, ob diese in der zu beachtenden Umgebung liegt. Falls nicht, gibt es aus Sicht Ihres Projekts keinen Grund, diese Anforderung weiter zu verfolgen. Definieren Sie den Systemkontext verspätet im Laufe eines Projekts oder ändert sich der Systemkontext aufgrund einer Verschiebung des Scopes, können Sie vorhandene Anforderungen entsprechend überprüfen und gegebenenfalls eliminieren. Natürlich können Sie die so gefundenen Anforderungen auch in ein anderes Projekt transferieren – so oder so: die Menge der Anforderungen lässt sich dadurch reduzieren.

Die Prüfung der Ziele

Kennen Sie die Stakeholder Ihrer Entwicklung und deren Ziele? Aus den Zielen ergeben sich häufig Anforderungen. Wenn sich Ziele von Stakeholdern widersprechen, dann müssen Sie zu einem Zeitpunkt in Ihrer Entwicklung entscheiden, welches Ziel von welchem Stakeholder wichtiger ist. Zieldiagramme sind hierfür übrigens ein gutes Ausdrucksmittel. Idealerweise treffen Sie eine solche Entscheidung möglichst frühzeitig und kommunizieren Sie diese mit den betroffenen Stakeholdern. Folglich können Sie die Menge der Anforderungen um die Anforderungen reduzieren, die dem nachrangigen Ziel entsprechen.

Die Prüfung auf unbewusste Redundanz

Die Prüfung auf Redundanz, sprich auf ähnlich formulierte Anforderungen, die dasselbe meinen, dies aber nur unterschiedlich ausdrücken, ist eine gute Möglichkeit, Anforderungen zu eliminieren. Es gibt viele Gründe für redundante Anforderungen: Anforderungen werden von unterschiedlichen Personen erfasst, die schlicht nicht wissen, dass entsprechende Anforderungen bereits existieren. Oder die zeitliche Erfassung zweier Anforderungen liegt so weit auseinander, dass der Autor sich nicht mehr an die bereits vorhandene Anforderung erinnert. Entscheidend bei der Prüfung auf Redundanz ist, ob Redundanzen beabsichtigt sind. So kann es sein, dass in einem Gesamtsystem mehrere Teilsysteme dieselbe Funktion parallel ausführen sollen oder dass in einem System eine redundante Funktion im Falle eines Fehlers ausgeführt wird. Die Menge an Anforderungen lässt sich also um unbewusste Redundanzen reduzieren.

Die Prüfung der Prioritäten

Anforderungen werden priorisiert. Die Praxis zeigt, dass eine Priorisierung mit Stufen wie „hoch, mittel, niedrig“ oder „must, should, could, won’t“ häufig dazu führt, dass jede Anforderung in die höchste Prioritätsstufe eingeordnet wird. Dies liegt daran, dass der Verfasser der Anforderung fürchtet, eine niedriger priorisierte Anforderung besäße keinerlei Chance auf Realisierung. Würde er zusätzlich noch fürchten, dass die von ihm erfasste und nicht maximal hoch priorisierte Anforderung eliminiert werden könnte, so würde wohl jeder Verfasser seine Anforderung als „mega-wahnsinnig-unglaublich-wichtig“ einstufen.

Es gibt Organisationen, die arbeiten mit absoluten und nur einmalig zu vergebenden Prioritäten. Dies hat den Vorteil, dass keine Anforderung genauso wichtig ist wie eine andere. Eine Anforderung mit Priorität 863 ist wichtiger als eine Anforderung mit Priorität 716. Enthält die Anforderungsliste 1.000 Elemente, können Sie so sehr leicht erkennen, wie viele Anforderungen noch wichtiger und wie viele weniger wichtig sind. Manche Organisationen vergeben sogar absolute Prioritäten unabhängig von der tatsächlichen Menge der vorhandenen Anforderungen. So lässt sich noch leichter ausdrücken, dass die Anforderung xyz mit einer Priorität von 2.000 doppelt so wichtig ist, wie die Anforderung abc mit Priorität 1.000. Leider hilft diese Erkenntnis zwar bei der Priorisierung, nicht aber bei der Reduzierung der Anforderungen, denn ab welcher Prioritätsgrenze sollten denn Anforderungen eliminiert werden, wenn ständig neue Anforderungen hinzukommen?

Für die Priorisierung von Anforderungen gibt es neben den einfachen qualitativen Verfahren auch analytische Priorisierungsverfahren wie die „Wiegers’sche Priorisierungsmatrix“ oder das „Kano-Modell“ mit Basis-, Leistungs- und Begeisterungsmerkmalen. Diese Verfahren verursachen deutlich mehr Aufwand als die einfachen Priorisierungsverfahren, liefern aber in der Regel Ergebnisse mit größerer Aussagekraft. Leider lässt sich auch hier nicht eindeutig ableiten, wie Sie mit den gewonnenen Ergebnissen die Menge der Anforderungen reduzieren können. Als Hersteller sollten Sie nicht auf Basismerkmale verzichten, denn diese sind für Kunden und Anwender selbstverständlich, werden aber erst dann bewusst zur Kenntnis genommen, wenn sie nicht vorhanden sind. Auch auf Leistungsmerkmale sollten Sie nicht verzichten, denn Kunden fordern diese explizit und sind sie nicht vorhanden, ist der Kunde unzufrieden. Und auf Begeisterungsmerkmale werden Sie nicht verzichten wollen, denn sie bieten die größte Chance sich vom Wettbewerb abzuheben. Leider sind sie nicht leicht zu ermitteln, wenn Sie also tatsächlich Begeisterungsmerkmale identifiziert haben, sollten Sie diese nicht eliminieren.

Umsetzungdatum, Wiedervorlage und Verfallsdatum

Haben Sie beim Umgang mit Anforderungen schon einmal mit einem Verfallsdatum gearbeitet? Warum nicht? Haben Sie einmal die Erfahrung gemacht, dass eine Anforderung, die Sie vor zwei Jahren erfasst haben, tatsächlich noch realisiert wurde? Ja? Wie sieht es aus bei einer Anforderung, die vor drei Jahren erfasst wurde? Ist Ihre Antwort wieder „Ja“? Glückwunsch! Bei wie vielen Anforderungen war das der Fall? Vermutlich war es selbst bei Ihnen nur die Ausnahme und nicht die Regel. Vielleicht laufen Ihre Projekte keine zwei oder drei Jahre. Vielleicht erfassen Sie im Laufe eines Projekts keine neuen Anforderungen. Oder Sie arbeiten in einem sehr eingespielten Team und dokumentieren einfach weniger. In vielen Organisationen ist es aber die Regel, dass es einen Punkt gibt, an dem Anforderungen nur noch altern. Sie liegen fest im Backlog oder in Anforderungslisten, ohne Chance jemals realisiert zu werden. Und jeden Tag kommen neue Anforderungen hinzu. Der Berg wird immer größer, die Menge an Anforderungen steigt.

Was können Sie tun? Sie könnten einen Umsetzungszeitpunkt definieren, also einen Datum bestimmen, bis wann eine Anforderung umgesetzt werden sollte. Alternativ könnten Sie Anforderungen zukünftigen Entwicklungsreleases zuordnen. Das machen Sie vielleicht bereits heute, vermutlich aber nicht für jede Anforderung. Und das hat zwei Gründe:

1. Sie können die Umsetzung der Anforderung zum heutigen Zeitpunkt nicht beurteilen. Wenn Sie die Anforderung aber als relevant einstufen, könnten Sie mit einer Wiedervorlage arbeiten. So würden Sie zu einem späteren Zeitpunkt dieselbe Anforderung mit hoffentlich neuem Wissen beurteilen können und entscheiden, ob und bis wann oder in welchem Release sie umgesetzt werden soll.
2. Sie glauben nicht daran, dass diese Anforderung realisiert wird. Warum heben Sie die Anforderung auf? Sie könnten sie schlicht eliminieren (oder in anderen Worten mit einem Zustand wie „abgelehnt“ oder „archiviert“ versehen, so dass sie in Ihrem Anforderungssystem erhalten bleibt, Sie aber nicht bei Ihrer regelmäßigen Arbeit mit Anforderungen beeinflusst).

Alternativ zum Umsetzungsdatum könnten Sie mit einem Verfallsdatum arbeiten. Sie bräuchten keine explizite Wiedervorlage, denn bei der Einplanung von Anforderungen in zukünftige Releases arbeiten Sie praktisch immer gegen das Verfallsdatum. Doch wie weit in der Zukunft sollte ein Verfallsdatum liegen? Sie könnten sich die Beantwortung leicht machen und sagen, dass Sie jede Anforderung, die nicht binnen x Jahren oder y Monaten realisiert wird, zukünftig nicht mehr beachten wollen. Oder Sie könnten versuchen mittels Mengenüberlegungen eine Antwort zu finden. Fragen dazu wären: Wie viele Anforderungen verwalten Sie in Ihrem Anforderungsmanagement-System und wie viele davon können Sie in einem zu definierenden Zeitraum realisieren? Und wie viele Anforderungen kommen im Laufe dieses definierten Zeitraums hinzu? Oder Sie finden die Antwort in Abhängigkeit der Granularität der Anforderungen. Ein Epic setzen Sie nicht so schnell um wie eine Story. Die Implementierung einer neuen Datenbank für ein bestehendes System beansprucht viel mehr Zeit und Aufwand als das Einfärben eines vorhandenen Buttons in eine andere Farbe. Sie müssten sich also entscheiden, ob Sie für jede Granularitätsstufe ein Verfallsdatum etablieren wollen oder beispielsweise nur auf der Ebene von Stories.

Fazit

Vermutlich nutzen Sie zum heutigen Zeitpunkt beim Umgang mit Anforderungen weder Wiedervorlage noch Verfallsdatum. Auch wenn Organisationen häufig mit zu vielen Anforderungen kämpfen, sind Fragen nach dem Zeitpunkt einer Wiedervorlage oder nach der passenden Granularitätsstufe für die Verwendung von Verfallsdaten nicht leicht zu beantworten. Die Reduzierung der Anforderungen verursacht Aufwand, aber ohne diesen Aufwand wird der Berg an Anforderungen kontinuierlich anwachsen und die Übersicht und das permanente Arbeiten mit Anforderungen erschwert. Wenn Sie die Menge der Anforderungen dauerhaft reduzieren wollen, dann macht ein Umdenken Sinn. Die Verwendung von Wiedervorlagen oder von Verfallsdaten sind interessante Möglichkeiten für die gezielte Reduzierung bzw. Eliminierung von Anforderungen. Probieren Sie es doch einfach aus.

 

Hinweis:

Einige dieser Gedanken stammen aus einem Austausch auf XING mit Till-J. Faßold, Olaf Barheine und Rainer Wendt. Die Kommunikation finden Sie hier.