Podcast-Folge #4
Wie du Anforderungen über die gesamte Projektlaufzeit sicher monitorst und steuerst 

User Story: Anforderungen schreiben leicht gemacht

Starten wir ohne Umschweife – du hast gerne wieder Zettel und Stift zur Hand.
Eine der wohl einfachsten Wege, um Anforderungen zu formulieren, ist über User Stories:

Eine User Story ist stets gleich aufgebaut und zwar wie folgt:

• Ich/Wir als <Rolle/Unternehmen>
• wollen <Feature/Ergebnis/Aktion>,
• sodass wir im Anschluss <spezifischer Nutzen>

Anhand eines Beispiels wird es klarer – du erinnerst dich an das Lieblingsgetränk deines Kunden mit Ananas-Kokos-Geschmack? Da könnte die zentrale Anforderung als User Story in etwa so lauten:

• Ich als Konsument und Fan dieses Getränks
• will im Sommer gerne die Geschmacksrichtung Ananas-Kokos trinken,
• sodass ich mich ein bisschen wie im Urlaub (am Stand, am Meer, unter Palmen) fühle.

User Stories sind deshalb so toll, weil man sich so herrlich in die Zielperson – hier den Nutzer oder Konsumenten – hineinversetzen kann.

Zudem gibt es genug Spielraum für Eigenverantwortung. Also um zu entscheiden, wie man den Kundenwunsch realisiert, denn den Weg dahin zeigt die Anforderung nicht auf. Dafür sind Ziel und Absichten glasklar und nachvollziehbar. Du weißt worauf du hinsteuern muss, warum die Zielperson sich das wünscht und was du testen oder überprüfen musst, um herauszufinden ob der Kunde zufrieden sein wird.

Als Zielperson oder Rolle, die du hier einsetzt, können natürlich auch andere Stakeholder fungieren. z. B. die interne Qualitäts-Abteilung. Lass mich auch dazu ein Beispiel formulieren:

• Wir als interne Qualitäts-Abteilung
• wollen, dass das Produkt die gleichen internen Hygiene-Standards erfüllt wie alle anderen Geschmacksrichtungen des Produkts,
• damit wir dem Kunden weiterhin das beste Geschmackserlebnis bieten können.

Die User Story gibt dir auch hier Klarheit darüber, für wen du das machst, was das Ergebnis sein soll und wieso es das braucht bzw. wofür das gut ist.

Besonders wenn es um die Beschreibung des Ergebnisses und des Nutzens geht, können wir jedoch noch wesentlich präziser werden. Warum? Ich bemühe wieder ein Beispiel:

Weg vom Ananas-Kokos-Getränk hin zu einem Mars Rover. Genau, ein Mars Rover. Ich liebe Abwechslung. Wir sind noch in der Entwicklung. Und für ein bestimmtes Mess-Instrument an Bord des Rovers wurde spezifiziert, dass es „eine sehr geringe Betriebstemperatur braucht, damit die notwendigen Analyseprozesse überhaupt chemisch ablaufen können“.

Im Weltall bedeuten sehr geringe Temperaturen sowas wie 270°C unter Null. Also zerbricht man sich fleißig ein paar Tage lang den Kopf, wohin man die Stickstofftanks unterbringen könnte, um dann bei Bedarf die Apparatur auf der Marsoberfläche (auf der zwischen 20°C am Tag in der Sonne und -85°C nachts herrschen) stark herunterkühlen zu können.

Schließlich will es das Team von Ingenieur:innen genau wissen und fragt die Chemiker:innen, welcher Temperaturbereich denn für wie lange entscheidend ist. Denn das bestimmt schließlich die Größe der Stickstofftanks. Daraufhin kommt die Rückmeldung, dass für mindestens 5 Minuten zwischen 0 und 5°C herrschen müssen. Ziemlich kalt auf der Erde, aber was bedeutet das für die Tanks auf dem Mars?

Das Ende der Geschichte kannst du dir denken: Man musste kurzerhand eine Heizung einbauen, keine Kühlung.

SMARTER-Prinzipien: Dos and Don'ts beim Formulieren von Anforderungen

Gute Anforderungen sind stets nach einem Prinzip beschrieben, dass sich SMARTER nennt. Die Abkürzung SMART kennst du mitunter bereits. Das und auch das -ER hinten dran erkläre ich dir kurz, sodass du es ganz sicher auf deinem Zettel zusammen bringst.

• Das S steht für spezifisch. In welcher Situation muss das Aggregat funktionieren? Auf dem Mars, im All, bei Tag, bei Nacht, für wie lange, einmal oder mehrmals.
• Das M in SMART steht für messbar. Erst mit den 0 bis 5°C wird die Anforderung im Mars Rover Beispiel wirklich erfass-/greif-/messbar.
• A steht für atomar (also im früheren Sinne von „unteilbar“). Das soll meinen, dass eine Anforderung keine andere Anforderung passiv codieren soll, sondern genau eine Sache beinhalten und unabhängig greifbar oder erfassbar macht. Ich veranschauliche das immer in der Form, dass ich mit dem Finger auf eine Stelle/oder Sache zeigen können muss. Am Beispiel des Mars Rovers wäre es weniger elegant in ein und dieselbe Anforderung rein zu formulieren „dass die Messung bei Tag bei ca. 20°C und bei Nacht bei ca. -85°C stattfinden können muss“. Daran ist nichts falsch, aber es ist leichter zu verfolgen, zu testen, zu berücksichtigen, wenn wir daraus zwei einzelne Anforderungen machen. Denn Tag und Nacht werden nicht gleichzeitig eintreten. Und will ich die Funktion testen, wären es auch zwei verschiedene Testaufbauten.
• R steht für realistisch. Es macht keinen Sinn, unrealistische Anforderungen in den Katalog mit aufzunehmen. Sie müssen umsetzbar sein – für dich und dein Team. Wenn nicht, diskutiert sie so lange, bis es geht. Sonst ist ja das Projekt zum Scheitern verurteilt oder sprengt irgendwann jedweden Kostenrahmen, um es doch zu realisieren.
• Und T, das steht für traceable, also nachvollziehbar in seiner Funktion und seinen Abhängigkeiten. Dann kann man es nämlich später auch testen, ob es das gewünschte Verhalten auslöst.

Wie eingangs erwähnt gibt es dann noch das -ER in SMARTER.

• E wie evaluated: jemand prüft, ob die Anforderung SMART formuliert ist. Wenn ja, bekommt es den Stempel „evaluated“. Anhänger agiler Methoden fänden das ganz sicher übertrieben, doch gerade bei extrem sicherheitsrelevanten und großen Projekten, in denen kein Spielraum für Fehler ist (wir können nicht so ohne weiteres einen zweiten Mars Rover ins All schießen), macht so eine Erweiterung durchaus Sinn. Dort gibt es sogenannte Requirements Manager. Also Personen, deren Job genau das ist, was wir gerade als einen Teil eines Projektes besprechen. Auch macht es gerade bei neuen Anforderungen Sinn, das E wie „evaluated“ zu benutzen, damit die erst im laufenden Projekt hinzukommenden Anforderungen sauber eingebettet werden und eventuelle Widersprüche aufgelöst werden können.
• Das R steht für re-usable: Auf die Gefahr hin etwas zu springen, liefert doch hier das Getränkebeispiel das anschaulichere Bild. Sich nicht an der Flasche zu schneiden ist eine re-usable, also wiederverwendbare Anforderung. Diese musst du ja nicht für jedes neue Getränke-Projekt mit aufführen. Stattdessen kannst du das einmalig als Standard-Anforderung definieren. Darauf referenziert dann jedes künftige Projekt als internen Qualitäts-Standard, der zwingend einzuhalten ist. Verständlich ist, dass dies etwas aufwendiger beschrieben werden muss – soll es doch allgemeingültig sein. Doch einmal definiert – Bingo – sparst du dir in jedem zukünftigen Projekt wertvolle Zeit und hältst das Anforderungs-Set übersichtlich und kannst dich auf die neuen Umfänge, den neuen Anteil im Vergleich zum Bisherigen konzentrieren. Und so das Projekt wesentlich schlanker managen. Pure Komplexitätsreduktion. Purer Zeitgewinn.
  Und so entstehen auch Basis-Merkmale, die sich ins Kano-Diagramm aus Teil 1 einordnen lassen.

Manche Firmen, gerade global agierende Konzerne, deren Projektteams über mehrere Standorte verteilt sind, setzen sogar auf eine Formulierungsvorgabe – ähnlich wie die User Story. Das Ziel ist eine einheitliche Schreibweise von Anforderungen, um Missverständnisse vom Start weg zu reduzieren.

"Nur harte Kriterien statt hätte, wäre, könnte!"

• Bspw. verbieten sie den Konjunktiv. Statt „hätte, wäre, könnte“ sind nur harte Kriterien erlaubt, was dann wie folgt lautet: „das Produkt oder die Sache MUSS, dies und jenes“.
• Zudem wird auf bestimmte Events/Use Cases und deren Abhängigkeiten eingegangen. Gehen wir zurück zu unserem Kunden und seinem Lieblingsgetränk mit Ananas-Kokos-Geschmack. Hier würdest du die Abhängigkeit wie folgt beschreiben: „Wenn die Flasche geöffnet wird, dann muss der Kunde Ananas & Kokos riechen können, sobald er die Flasche an seinen Mund heranführt, um den Eindruck von Piña Colada zu erhalten“.
• Oder es werden Zustände beschrieben: „Für den Fall, dass der Kunde die Flasche nicht auf einmal austrinkt, dann muss sie durch ihn mithilfe des Originaldeckels wiederverschließbar sein“.
• Sogar ungewollte Ereignisse können erfasst werden. Dieses Beispiel hatten wir bereits: „Wenn der Kunde aus der Flasche trinkt, darf er sich nicht an Lippe oder Zunge schneiden“.
• Und Optionen müssen als solche gekennzeichnet sein: „Wenn der Konsument den Deckel aufmacht, muss in Zeiten einer Promotion der Gewinnspielcode auf der Innenseite des Deckels gut lesbar aufgedruckt sein“.

Fällt dir was auf? Ist „Gut lesbar“ eine SMART formulierte Anforderung? Spezifisch ja, doch schon bei messbar tun wir uns beide schwer. Wie wäre es stattdessen mit „zwischen Schriftgröße 12 und 16, schwarze Lettern auf weißem Grund, Schriftart ohne Serifen bspw. Arial. Nur Großbuchstaben oder Zahlen“. 

Yes, das kannst du gut messen. Denn gut lesbar … was heißt das schon … mit Brille, ohne, aus welcher Entfernung. Kurzum: es wäre zu subjektiv.

Schau also, dass du Anforderungen objektivierst – die Deutung und die Bedeutung sollen unabhängig vom Betrachter oder der Betrachterin klar nachvollziehbar sein.

Anforderungen im Wandel – Änderungen managen

Kommen wir zum letzten Punkt für diese Folge und zum Thema Anforderungen. Einem sehr wichtigen.

Bereits eingangs hatte ich erwähnt, dass das, was wir bis hierher besprochen haben, ja im Prinzip lediglich eine Momentaufnahme ist.

Über die Zeit können sich Geschmäcker, Wünsche, der Bedarf und somit die Anforderungen wandeln.

Oft wird auch erst über die Zeit klar genug, was tatsächlich gemeint ist. Und erst dann bin ich in der Lage, die Materie zu durchdringen und richtig gute Anforderungen zu formulieren. Mit zunehmendem Verlauf des Projektes steigt in der Regel die Klarheit und Informationssicherheit.

Und so wird aus dem initialen Anforderungs-Set, über die Zeit ein Neues, bestehend aus:

1. Aktualisierten Anforderungen – die brauchen ein Update. So zum Beispiel könnte der Kunde sagen, dass ein wenig Ananas-Kokos-Geschmack schon reicht, sonst hat er das Getränk nach einer Woche schon über.
   
   
2.  Dann kommen neue Anforderungen dazu – die müssen mit aufgenommen und in Bezug zu den bisherigen gesetzt werden. Das gilt für deren Priorität genauso wie für deren Abhängigkeiten. 
   Bspw. soll das Ananas-Kokos-Getränk nun dem Trend folgen und zuckerfrei sein.
   
   
3. Und manche Anforderungen werden obsolet. Der Kunde will keinen wiederverschließbaren Deckel, weil er erkannt hat, dass es eh frisch am besten schmeckt und wie bei Bier definitiv nicht auf die Idee kommt, es wieder zu verschließen und in den Kühlschrank zu stellen. Hier ist dann wichtig, dass ihr die Arbeit daran einstellt und das Thema nicht weiterverfolgt.
   Häufig sind wir beim Weglassen nicht so gut wie beim Dazutun. Und wenn die Kommunikation nicht stimmt, dringt eine solche Information gar nicht bis zu den Personen durch, die daran arbeiten, dass die Flasche wiederverschließbar ist. Der Frust ist natürlich groß, wenn dann herauskommt, dass die Arbeit vergebene Lebensmühe war. Und ja auch von niemandem honoriert werden wird. Nicht vom Kunden und nicht von der Projektleitung.

Kernbotschaft:

Zusammenfassend siehst du, dass es sehr gut sein kann, dass am Ende des Projektes etwas anderes herauskommt, als ursprünglich beschrieben. Etwas, das lediglich im Kern noch den Anforderungen zu Beginn des Projekts entspricht. Je länger das Projekt dauert, desto wahrscheinlicher ist das sogar.

Du kannst es dir also nicht erlauben, einmal die Anforderungen abzufragen und ein Jahr später das Ergebnis abzuliefern. Die Chance ist riesig, dass du etwas ablieferst, das nicht mehr gebraucht wird. Oder zumindest nicht mehr ganz genau so gebraucht wird. Selbst wenn es ursprünglich so vereinbart war, wird die Akzeptanz nicht vorhanden sein und das tolle Produkt zum Ladenhüter.

Und genau daher kommt die extreme Dynamik in Projekten, die so viel Stress und Chaos auslösen kann. Mehr darüber erfährst du in den Folgen #20 und #21.

Oft hilf es schon, dir selbst und deinem Team genau diese Tatsache vor Augen zu führen. Für den Wandel von Änderungen habe ich dir deshalb oben ein Schaubild verlinkt, das sehr schön verdeutlicht, wie sich die Ausgangslage im Projektzeitverlauf verschiebt.

Das bedeutet auch, dass du ein gewisses System benötigst, die Anforderungen aktuell zu halten und mit dem Team zu teilen. Wie das genau funktionieren kann, das teile ich in der Podcast-Folge zum Thema Requirements Change Management in den Folgen #26 und #27.

Die größte Herausforderung vor diesem Wissen und Hintergrund ist jedoch, dass wenn du nicht all deine entscheidenden Stakeholder kennst, du mitunter wichtige Anforderungen verpasst. Daher geht es in der nächsten Podcast-Folge #5 zunächst einmal um Stakeholdermanagement.

An der Stelle sage ich meinen Dank und spreche das Angebot aus, dass du auf mich zukommen kannst. Schreib mir gerne bei LinkedIn oder via Email an chris@pm-botschaft.com oder such mich per Suchmaschine. Dort kannst du auch gleich ein Telefonat mit mir vereinbaren, das dir in die Agenda passt. Dann unterhalten wir uns über deine täglichen Herausforderungen im Projekt und sehen gemeinsam, wie sich diese am besten angehen lassen.

Danke fürs Zuhören und auf bald.

Keep on rockin' und auf zur Brillanz!

Chris