Anforderungen eliminieren

• wenn Sie kontinuierlich Anforderungen von Kunden und Fachabteilungen erhalten,
• wenn Produktmanagement und Vertrieb immer neue Anforderungen formulieren oder
• es neue Gesetze, Normen und Richtlinien gibt, die zu weiteren Anforderungen führen?

Natürlich könnten Sie einfach einen Annahmestopp verhängen und Veränderungen ignorieren, wahrscheinlich würden sich dann aber Ihre Kunden schon bald einen neuen Partner suchen. Sie benötigen also einerseits die Offenheit für zusätzliche Anforderungen und andererseits die Möglichkeit, vorhandene, nicht realisierte Anforderungen zu eliminieren.

Vollständigkeit, Stakeholderziele und Systemkontext im Blick

Wenn Sie Anforderungen eliminieren wollen, könnten Sie beginnen, diese auf formale Vollständigkeit zu überprüfen. Arbeiten Sie in Ihrer Softwareentwicklung mit einem Anforderungsmanagement-Werkzeug, dann gelingt die Überprüfung auf Vollständigkeit ziemlich leicht. Schnell finden Sie Anforderungen, bei denen die Beschreibung, der erwartete Nutzen, Abnahmekriterien oder Quellenangaben fehlen.

Doch was passiert, wenn Sie diese Anforderungen identifiziert haben? Können Sie diese nun einfach löschen? Vermutlich nicht. Es ist sogar ziemlich wahrscheinlich, dass nun zusätzlicher Aufwand entsteht, denn wie wollen Sie die Wichtigkeit einer Anforderung beurteilen, wenn sie nicht (oder noch nicht) vollständig formuliert wurde? Ergo: Anforderungen bei fehlenden Informationen zu eliminieren, ist ein Weg, um die Menge an Anforderungen zu reduzieren. Der zusätzliche Aufwand zur Überprüfung und die Gefahr, eine wichtige – noch nicht vollständig spezifizierte – Anforderung zu eliminieren, sollten aber beachtet werden.

Wissen Sie warum es wichtig ist, die Stakeholder Ihrer Entwicklung und deren Ziele zu kennen? Aus den Zielen der Stakeholder ergeben sich oftmals Anforderungen. Wenn sich Ziele widersprechen, dann sollten Sie möglichst frühzeitig – idealerweise im Rahmen der Stakeholderkommunikation – entscheiden, welches Ziel von welchem Stakeholder wichtiger ist und in der Folge adressiert wird. In der Konsequenz können Sie die Anforderungen eliminieren, die zur Erreichung der weniger wichtigen Ziele notwendig gewesen wären. Zieldiagramme eignen sich übrigens sehr gut zur Visualisierung von Stakeholdern und Zielen.

Nach den Zielen der Stakeholder könnten Sie sich auch die Definition des Systemkontexts anschauen. Mit dem Systemkontext definieren Sie die Grenzen Ihrer Software- und Systementwicklung, das heißt Sie bestimmen einen Bereich, für den Sie Anforderungen erfassen wollen. Wollen Sie bspw.  ein neues System A implementieren, das mit System B kommuniziert, dann ist es für Ihre Entwicklung irrelevant, ob es Anforderungen für System C gibt. Diese Anforderungen könnten Sie eliminieren.

Anforderungen auf Redundanzen und Prioritäten prüfen

Es gibt zahlreiche Ursachen, die zu redundanten Anforderungen führen:

• Sie werden von verschiedenen Personen erfasst, die keinen Überblick über bereits vorhandene Anforderungen haben.
• Sie werden so formuliert, dass sie sich in Teilen überschneiden.
• Oder die Erhebung der Anforderungen liegt zeitlich so weit auseinander, dass sich der Autor nicht mehr sicher ist, ob er früher bereits eine ähnliche Anforderung formuliert hatte.

Diese Ursachen führen zu unbewussten und ungewollten Redundanzen. Diese zu eliminieren, ist sinnvoll. Idealerweise sollten Sie bei der Überprüfung jedoch auf bewusst angelegte Duplikate achten. Eine unbedacht gelöschte Anforderung A, die sich sowohl in Komponente 1 als auch in Komponente 2 wiederfindet, könnte sonst teuer werden.

Die Priorisierung von Anforderungen ist ein weites Feld. Bietet sie auch Optionen zur Eliminierung von Anforderungen? Werfen wir einen Blick in die Praxis. Es gibt Organisationen, in denen die meisten Anforderungen als “wichtig” eingestuft werden. Aus Sicht des Erstellers einer Anforderung ist dies nachvollziehbar, denn er möchte sicherstellen, dass seine Anforderung auch tatsächlich realisiert wird und die Chancen sind bei einer höheren Priorisierung deutlich größer als bei einer niedrigen. Schaut sich nun eine Organisation die Anforderungen mit den niedrigsten Prioritäten an, um sie eventuell zu eliminieren, dann können Sie sicher sein, dass zukünftig bei Prioritäten wie “niedrig, mittel, hoch”, “1, 2, 3” oder “must, should, could, won’t” jeder Ersteller permanent darauf achtet, dass seine Anforderung in der höchsten Stufe eingeordnet wird. Damit wäre die Priorisierung an sich gescheitert – keine gute Idee.

Gibt es vielleicht andere Priorisierungsverfahren, die bei der Reduzierung von Anforderungen helfen könnten? Das Kano-Modell mit seinen Basis-, Leistungs- und Begeisterungsmerkmalen liefert bspw. wertvolle Erkenntnisse für die Priorisierung von Anforderungen. Leider lässt sich auch bei diesem qualitativen Modell nicht ableiten, wie Sie die Menge der Anforderungen reduzieren können. Auf Basismerkmale können Sie schlicht nicht verzichten, denn diese sind für den Anwender selbstverständlich, auch wenn sie erst bewusst wahrgenommen werden, sofern sie fehlen. Auf Leistungsmerkmale können Sie auch nicht verzichten, denn diese werden ausdrücklich von Anwendern gefordert und verglichen. Und niemand verzichtet auf Begeisterungsmerkmale, denn die sind sehr schwer zu identifizieren und Begeisterung wollen Sie nicht eliminieren. Bei der Anforderungseliminierung hilft Ihnen Noriaki Kano also nicht weiter.

Eine weitere Option beim Bewerten von Anforderungen ist eine absolute Priorisierung. Bei ihr werden Prioritäten nur einmal vergeben, es gibt also bspw. nur einmal Priorität 108. Hat eine Anforderung die Priorität 109 ist sie wichtiger als die Anforderung mit der Priorität 108. Natürlich verursacht eine solche Form der Priorisierung viel Aufwand, das Ergebnis ist aber stets eindeutig. Haben Sie bspw. 4.000 verschiedene Bewertungen vergeben, dann könnten Sie vielleicht die niedrigsten 100, 200 oder möglicherweise 500 Anforderungen eliminieren, oder?

Die Releasezuordnung und das Verfallsdatum

Kennen Sie Anforderungen, die 3 Jahre nach ihrer Erhebung noch umgesetzt wurden? Nach 4 oder 5 Jahren? Ist das bei Ihnen die Regel oder die Ausnahme? Wenn es die Regel ist, wie sieht es mit Anforderungen aus, die vor 8, 9 oder 10 Jahren erfasst wurden? In den meisten Organisationen gibt es einen Punkt, ab dem Anforderungen nur noch altern, aber nicht mehr umgesetzt werden. Sie sind vergraben in Anforderungslisten oder Product Backlogs, fast ohne reale Chance implementiert zu werden. Wenn jetzt noch jeden Tag neue Anforderungen hinzukommen, sinken die Chancen praktisch auf null.

Was könnten Sie alternativ tun? Sie könnten mit einem Umsetzungsdatum arbeiten, also einen Zeitpunkt definieren, zu dem eine Anforderung umgesetzt werden sollte. Evtl. machen Sie dies heute schon, indem Sie mit Releasezuordnungen arbeiten. Der Gedanke ist identisch. Haben Sie eine Anforderung einem Release zugeordnet, dann planen Sie diese auch zu realisieren. Wenn Sie die Realisierung einer konkreten Anforderung immer wieder verschieben, Sie also die Priorität verändern, kann es vorkommen, dass Sie die Anforderung irgendwann gänzlich aus der Releaseplanung entfernen und sie wieder in den Tiefen des Product Backlogs verschwindet. Eventuell wäre sie schon ein Kandidat für die Eliminierung.

Es gibt auch den Fall, in dem Sie die Umsetzung einer Anforderung (noch) nicht terminieren können. Ist die Anforderung dennoch relevant, könnten Sie für sie eine Wiedervorlage definieren und so später entscheiden, ob sie in einem konkreten Release umgesetzt werden soll. Wollen Sie sie stattdessen wieder verschieben, könnte auch sie ein Kandidat für eine Eliminierung sein. Und was passiert, wenn Sie nicht an die Umsetzung einer Anforderung glauben? Diese Anforderung können Sie unmittelbar eliminieren.

Alternativ zu Releasezuordnungen könnten Sie auch mit einem Verfallsdatum arbeiten. Dies führt bei der Anforderungsplanung dazu, dass Sie stets gegen das Verfallsdatum planen. Bei wichtigen Anforderungen definieren Sie ein frühes Verfallsdatum, bei allen anderen Anforderungen arbeiten Sie mit Standardwerten von x Jahren und/oder y Monaten. Zur Bestimmung der Standardwerte nutzen Sie Ihre Erfahrungen und schauen, wie viele Anforderungen Sie über einen definierten Zeitraum in der Vergangenheit realisiert haben. Alternativ können Sie auch mit Erfahrungswerten bei der Umsetzung von Epics, Features oder User Storys arbeiten und für jede Kategorie oder nur für einzelne ein Verfallsdatum etablieren. Beachten Sie bei der Bestimmung der Standardwerte, dass in dem definierten Zeitraum typischerweise eine Menge an zusätzlichen Anforderungen hinzukommt. Sobald Sie das Verfallsdatum beim Arbeiten mit Anforderungen verwenden, müssen Sie zukünftig keine Anforderungen mehr beachten, die nicht innerhalb des entsprechenden Zeitraums realisiert wurden.

Fazit: Anforderungen eliminieren

Das Eliminieren von Anforderungen verursacht Aufwand, aber ohne diesen Aufwand wird die Menge an Anforderungen kontinuierlich steigen und die Übersicht wird zumindest deutlich erschwert. Wenn Sie die Menge Ihrer Anforderungen dauerhaft reduzieren wollen, dann ergibt die Prüfung von Vollständigkeit, Stakeholderzielen und Systemkontext Sinn. Die Prüfung von unbeabsichtigten Redundanzen ist ebenfalls empfehlenswert. Und auch die Priorisierung von Anforderungen kann unter Umständen bei der Auswahl der Eliminierungskandidaten helfen. Das Arbeiten mit einem Verfallsdatum ist eine weitere Option für das Eliminieren von Anforderungen.

Das Eliminieren von Anforderungen müssen Sie übrigens nicht mit einem “Löschen” von Anforderungen gleichsetzen. Sie können Anforderungen auch mit Zuständen wie “stillgelegt” oder “archiviert” versehen, so dass Sie in Ihrer Anforderungsverwaltung erhalten bleiben, ohne Sie bei Ihrer kontinuierlichen Arbeit mit Anforderung zu beeinträchtigen.

Hinweis:

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!

Gerne empfehlen wir Ihnen unser Requirements Engineering Whitepaper als Download zum Mitnehmen.

Michael Schenkel hat im t2informatik Blog weitere Beiträge zum Umgang mit Anforderungen veröffentlicht, u. a.

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.