[Requirements] Steigerung der Teamproduktivität durch richtige Benennung von Anforderungen

Die kostbarste Investition in einem IT- (oder jedem beliebigen) Projekt ist die menschliche Arbeitszeit. Diese Zeit möchte man möglichst effizient nutzen. Denn der wesentliche Teil dieser Zeit wird verwendet, um Sachverhalte zu verstehen und Wissen zu vermitteln – kurzgesagt für Kommunikation.

Für Kommunikation werden heute viele ausgeklügelte Methoden und Werkzeuge (Brainstorming, Workshops, Pin-Charts, etc) verwendet. Die einfachsten Schalter und Hebel bleiben aber oft ungenutzt. Eins dieser Mittel ist die effektive Benennung von Anforderungen.

Korrekte Benennung fördert die Produktivität: sie spart Zeit durch eine bessere Verständlichkeit, reduziert Komplexität und gewährt einen schnellen Überblick über Anforderungscluster. Ihre Wichtigkeit wird meist unterschätzt.

Wirft man einen Blick auf ein beliebiges Projektlaufwerk, so findet man oft Anforderungslisten mit Titeln wie z.B. „CR0001-Änderung Bestellbestätigung“ oder „ANF002-UltraIP@WiDO“. Dabei trifft man immer auf das gleiche Problem: unverständliche Namen. Das Problem hat zwei wesentliche Ursachen. Zum Einen werden die Namen viel zu allgemein gewählt, zum Anderen sind sie vielfach viel zu kryptisch, um eine klare Aussagekraft zu besitzen.

Der Weg zu einer guten Bezeichnung ist dabei ganz einfach. Man stelle sich vor, welche Frage der Leser (damit Ihr Kunde) der Bezeichnung bei der Durchsicht stellt.
Was den Leser interessiert sind primär nur drei Fragen. (1) Was ist das Objekt der Anforderung, (2) Was war verkehrt, also der Startzustand und (3) Wie soll es am Ende aussehen – der Endzustand. Gelingt es einem diese drei Fragen in Kürze zu beantworten, wird der Leser alle nötigen Informationen erhalten haben, die er für ein grobes Verständnis braucht. Denkt man genauer drüber nach, kann man, um die Bezeichnung kurz zu halten, die Frage (2) vernachlässigen. So reduziert sich die Formel auf was (1) und (3).

Aus dieser Erkenntnis lässt sich ein Grundschema und zwei Prinzipien für die Bezeichnung von Anforderungen ableiten.

Grundschema:
„Worum geht es?“ (A)
„Und was soll am Ende damit erreicht werden?“ (B)

Weitere Prinzipien, gegen die der Titel zu prüfen gilt:
– Ausdruck: Sind Benennungen positiv (additiv) ausgedrückt?
– Detailierung: Sind Worte ggf. zu allgemein gewählt?
Enthält der Titel ggf. unnötige oder umständliche Worte?

Beispiel 1:

Alt: Q-24712_Änderung_Snippetanzeige

Bei dieser Benennung wird nicht ganz klar, was die Änderung beinhaltet. Genaugenommen ist ein CR immer eine Änderung – insofern ist diese Benennung nicht ganz zielführend oder hier zu allgemein. Besser ist es eine Benennung zu wählen, die direkt auf die Fragen des zukünftigen Lesers eingehen, z.B.:

Besser: Q-24712_Snippeticons_keine_leeren_Icons

Bei einer solchen Benennung wird schneller klar, WAS (A) geändert wird und was damit erreicht werden soll (B). Bei diesem Beispiel ist für (B) aber eine subtraktive Formulierung gewählt, was das Verständnis immer noch erschwert. Deshalb sollte auch für (B) additive Ausdrucksweise verwendet werden.

Noch besser: Q-24712_Snippets_Anzeige_ausschließlich_nötiger_Icons

Beispiel 2:

Alt: Q-22195 -UltraIP@WiDO
Neu: Q-22195 WiDO_Produkte_NEU_im_PORTALxy

Wobei PORTALxy der Name eines Systems sein kann.

Beispiel 3:

Alt: CR0002_Änderung Bestellbestätigung
Neu: CR0002_Bestellbestätigung__monatlicher_Staffelpreis_NEU

 

Kurzinfo: This article discusses how using naming guidelines can improve the requirements management process and thus improve productivity of a team.

Anton

Anton

Anton ist freiberuflicher Software-Ingenieur und Projektleiter mit den Schwerpunkten: Prozessdesign, strukturierte Business Analyse / Fachkonzeption sowie fachliche Entscheidungsunterstützung.

More Posts - Website