Fallen und Kostentreiber

Das war die Nutzen Seite – wenden wir uns jetzt den Kosten zu. Im Folgenden gehe ich auf die potentiell teuren Fehler ein, ohne die Reihenfolge zu gewichten.

Gratwanderung zwischen Verständlichkeit und Übersicht

Um Anforderungen übersichtlich zu halten, sollte das „Gesamtwerk“ nicht zu umfangreich werden. Gleichzeitig sollten (zumindest) die Beteiligten auch nach vielen Jahren noch verstehen, was denn in der Anforderung xy gemeint war, wichtige Details dazu dürfen nicht fehlen. In diesem Zwiespalt ist es eine gute Strategie,

• eine klare Zielgrupe zu definieren. So unterschieden sich z.B. die folgenden Gruppen in Ihren Informationsbedürfnissen:
  • der Autor selbst (was benötigt er, um sich in einem Jahr noch an die vorhanden Informationen zu erinnern?), oder
  • ein Fachbereichsmitarbeiter (was benötigt er, um eine Anforderung bewerten zu können?).
• mit einer hohem Abstraktionsebene anzufangen und auf dieser Ebene konsistent zu werden.
• in begründeten Einzelfällen wichtige Details festzuhalten.

Unterschiedliche Sichten

Im einfachsten Fall wird nur eine Sicht auf Anforderungen benötigt – diese Sicht verbindet typischerweise die fachliche Architektur mit den erfassten Anforderungen. Relativ schnell sind aber weitere Sichten notwendig: Für das Testteam, für Projektteams, zur Weiterspezifikation, für den Betrieb oder für Schulungen. Ein Ansatz, der Ansichten für unterschiedliche Aspekte nicht berücksichtigt, wird nicht ausreichen.

Verstoß gegen DRY (Don't Repeate Yourself)

In Anforderungen werden wichtige fachliche Zusammenhänge beschrieben. Diese Zusammenhänge werden an vielen Stellen erläuternd gebraucht. Denken Sie nur an Testbeschreibungen, Arbeitspakete, Pflichtenheft, Projektpläne, Handbücher, Statusberichte, Verträge oder Fehlermeldungen. An all diesen Stellen ist man stets versucht, mal kurz den ein oder anderen Teil einer Anforderung hin zu kopieren. Sobald sich eine derart verstreute Anforderung verändert, sind die Kosten recht plastisch klar. Das bedeutet, die Herausforderung liegt darin, den Komfort von Copy/ Paste mit Redundanzfreiheit zu kombinieren.

Besseres Problemverständnis führt zu Strukturänderungen

Mit zunehmendem Verständnis des fachlichen Problems geht auch fast immer der Wunsch nach einer Änderung der bestehenden Struktur einher. Nach A. Cockburn tut der Requirements-Analyst gut daran, die funktionale Dekomposition nicht in den Anforderungen zu berücksichtigen. Nichts desto trotz sind Anforderungen mit der zukünftigen fachlichen Architektur – in der sich die Strukturänderungen zeigen – gedanklich gekoppelt. Alle Menschen, die mit dem System hantieren, haben das Bedürfnis zu einer sinnvollen Gliederung. Im vorgestellten Ansatz wird diese Struktur über eine oder mehrere Ansichten reflektiert. Je besser sich daher Struktur und Inhalt der Anforderungen trennen lassen, desto weniger kostet dieser Umstand.

Anforderungsveränderung über die Zeit

Wie immer entwickelt sich die Welt derart rasant, dass die IT Mühe hat, Schritt zu halten. Das trifft auch auf gemanagte Anforderungen zu – und zwar in zwei Dimensionen: Die Veränderung von Anforderungen ist auf Ebene der einzelnen Anforderung von Interesse – wie hat sich die Anforderung entwickelt? Wer hat die Veränderung veranlasst? Was waren die Gründe für die damalige Entscheidung und bestehen diese Gründe noch? Die Veränderung von ganzen Anforderungs-Netzen – im Sinne von: Anforderungen weiter analysieren während eine stabile Version parallel umgesetzt wird. Der Umgang mit diesen beiden Versionierungs-Anforderungen wird im Anhang beschrieben.