Anforderungsmanagement

Letzte Änderung am 27. Juli 2023 by Christoph Jüngling

Die einen ignorieren es, andere wollen es dogmatisch mit tausenden von Dokumenten abgesichert wissen: Anforderungsmanagement. Es ist ein schwieriges Thema, und wie der Volksmund so schön sagt: “Allen Leuten recht getan ist eine Kunst, die niemand kann!”

Einig sind sich viele zumindest darin, dass so etwas nötig ist. “Wer nicht weiß, wo er hin will, braucht sich nicht zu wundern, wenn er ganz woanders ankommt.” Doch wie viel Aufwand für die Erfassung und Dokumentation der Anforderungen (engl. “requirements”) ist wirklich sinnvoll?

 

Anforderungen sollten …

  • vollständig
  • atomar
  • eindeutig
  • verständlich
  • identifizierbar
  • widerspruchsfrei
  • erfüllbar
  • überprüfbar

… sein. Siehe dazu auch den Artikel Anforderungsanalyse in der Wikipedia. Darin findest du nicht nur einige theoretische Erläuterungen, sondern auch weiterführende Links. An dieser Stelle will ich nur mit kurzen Worten beschreiben, was es mit diesen “Anforderungen an Anforderungen” auf sich hat.

Eine Anforderung sollte vollständig sein. Dinge wegzulassen, die selbstverständlich sind, kann sich später als böse Falle erweisen. Von einem simplen “das weiß doch jeder” bis hin zu Regressforderungen ist gewissermaßen alles drin.

Der Begriff atomar führt häufig zu einem original hessischen “hä?”. Gemeint ist damit, dass in einer Anforderung auch genau eine Sache gefordert werden soll. Eine Anforderung im Stil “ich möchte, dass die Oberfläche in einem zarten Blau gehalten ist, wobei die Buttons knallrot sein sollen und Hilfstexte lindgrün” ist definitiv nicht atomar (obwohl man vielleicht argumentieren könnte, es handele sich doch nur um eine Sache, die Oberfläche)! Hier haben wir aus meiner Sicht vier (!) Anforderungen: 1: Es gibt eine Oberfläche, 2: Basisfarbe Zartblau, 3: Buttons knallrot, 4: Hilfstexte lindgrün.

Doch auch die Aufsplittung in diese vier separaten Punkte verletzt immer noch den nächsten auf der obigen Liste, denn diese Aussagen sind nicht eindeutig. Oder kannst du genau beschreiben, welche Farbcodes zartblau, knallrot und lindgrün haben?

Die Frage, ob eine Anforderung verständlich ist, wird sicherlich zwischen Auftraggeber und -nehmer einvernehmlich geklärt werden müssen. Als generelle Empfehlung gilt, möglichst keine fachspezifischen Begriffe zu verwenden, ohne sie zu erklären (z.B. in einem Glossar).

Dass eine Anforderung identifizierbar sein sollte, ist schon aus praktischen Überlegungen heraus verständlich. Dazu sage ich später im Praxisteil noch etwas mehr.

Unsere Anforderungen widerspruchsfrei zu halten, kann schon richtig viel Aufwand bedeuten, besonders dann, wenn es sehr viele werden. Dennoch ist es ein verständlicher Wunsch, dass die Buttonfarbe in obigem Beispiel nicht gleichzeitig rot und blau sein kann.

Eine Anforderung sollte erfüllbar sein. Das klingt trivial, ist aber keineswegs immer gegeben. “Jede Reaktion der Benutzeroberfläche muss innerhalb von 3/10 Sekunden erfolgen.” kann unter Umständen schon an der Leistungsfähigkeit der eingesetzten Hardware oder des Netzwerkes scheitern. Damit wäre diese Anforderung rein aus der Sicht der Software möglicherweise nicht erfüllbar. Es handelte sich dann eher um eine Anforderung an das Gesamtsystem.

Auch der letzte Punkt, überprüfbar zu sein, wird gern ignoriert, ist jedoch gerade für den Abnahmetest von entscheidender Bedeutung. Wenn man zusätzlich die Prüfregeln vorab festlegen kann, ist in Hinblick auf Test-Driven-Development ein wesentlicher Schritt getan.

Das war ein kleiner theoretischer Exkurs. Bei Gelegenheit geht es dann darum, mit unserer bestehenden Entwicklungsumgebung solche Anforderungen zu verwalten und letztlich dann auch umzusetzen.

Ähnliche Artikel:

Schreibe einen Kommentar

Deine Email-Adresse wird nicht veröffentlicht.

fünfzehn + sechzehn =