Wir alle erleben es immer wieder: jemand möchte etwas von uns, ist aber nicht fähig sein Anliegen so zu beschreiben, dass es auch jeder versteht. Mit welchen kleinen Tipps man seine Wünsche schriftlich festhalten kann und warum Lücken und Mängel in so einer Beschreibung viel kosten können, lesen Sie hier.
“Wir machen das so, weil der Kunde das braucht!”
vs
“Der Kunde braucht das, weil er dadurch einfacher arbeiten kann.”
Allein die Perspektive oder die Betrachtungsweise zu ändern, kann schon viel bringen, wie man bei diesen beiden Aussagen sehen kann – beides höre ich übrigens öfters in meinem beruflichen Alltag als Agile Coach.
Viele Anforderungen sind einfach nicht gut – weil sie unverständlich, kompliziert, mehrdeutig, unvollständig oder unstrukturiert sind. Die meisten Anforderungsbeschreibungen die ich kenne, müssen überarbeitet werden. Doch wie weiß man, ob eine Requirements description passt?
Anforderungen verständlich schreiben
Eine gute Anforderungsspezifikation muss vollständig und verständlich sein, dh beim Leser muss sich ein Bild im Kopf aufbauen und wissen was gemeint ist. Darum sollte die Beschreibung einfach (geläufige Begriffe, wenige Fremdwörter, kurze Sätze), geordnet (klarer Text-Aufbau, roter Faden, logische Ordnung), gekürzt (keine ausschweifenden Formulierungen, auf Nutzinformation beschränken) und lebendig wertvolle Zusatzinformationen mit konkreten Anwendungs-Beispielen oder Testdaten) sein.
Tipps:
- korrekte Rechtschreibung verwenden
- Fremdwörter vermeiden / nur Begriffe verwenden, die ein neuer Mitarbeiter auch versteht
- Abkürzungen in einem Glossar erklären
- maximal 2 Zeilen je Satz verwenden
- pro Satz nur eine Anforderung verwenden
- logische Struktur initiieren + einhalten
- Aufzählungszeichen / Nummerierungen verwenden
- Anforderung + Details zusammenhalten
- reale Beispiele zur Verdeutlichung geben + dadurch Testen erleichtern
- wichtige Zusammenhänge visualisieren
- Abläufe mit Modellen + Bildern ergänzen
Requirements debts sichtbar machen
Produktverantwortliche, Product Owner, Requirements Engineers und Business Analysts kennen den Begriff “Anforderungsschulden”: sie versuchen den von Entwicklern geforderten Anforderungsspezifikationen gerecht zu werden, ohne zu viel Zeit für eine Anforderung zu verschwenden. Oft versucht man Qualitätskriterien einzuführen, die erfüllt sein müssen, bevor die Spezifikation dem Team übergeben wird. Zu viele Notizen und Kommentare sowie verschiedene Formatierungen und keine Struktur erschweren das Lesen immens. Jedes nochmalige Lesen und jede Korrektur kosten Zeit.
Beispiele für Qualitätsmängel
- Rechtschreibfehler: einen Schreibfehler zu korrigieren kostet 10-20 sec – bei 30 Fehlern also gleich mal 5-10 min investiert
- komplexe, zu lange Sätze: für jede Korrektur entsteht mind. 1 min Aufwand – bei 10 Sätzen also leicht 10-15 min
- schwammige Begriffe oder fehlende Glossareinträge: Begriffe auszutauschen oder in einem anderen Dokument zu ergänzen kostet Zeit: 5 min sind leicht drin, das ganze multipliziert mit 6 Begriffen macht satte 30 min
- fehlender Akteur wie “der Kunde” oder “es”
- unklare Abgrenzung der Anforderung
Sie sehen: der jeweilige Mangel multipliziert mit der Häufigkeit der Anforderung multipliziert mit mehreren Anforderungen in einem Backlog ergibt Korrekturaufwände die ganze Tage füllen können.
Unternehmen sind oft bereits, das zu investieren. Gemessen an Bugs oder Technical Debts die entstehen können wenn falsch oder nicht nachhaltig umgesetzt wird, sind das Peanuts! Deshalb macht es Sinn, sich für die Fragen und Unklarheiten im Team Zeit zu nehmen.
Ich selbst leite Meetings, wo 3 Personen 2 Stunden beschäftigt sind, um die mangelhafte Formulierung 1 Anforderung zu entschlüsseln. Die Überarbeitung dieser ist aber immer die bessere Entscheidung.
Einfacher ist oft mehr
Sicher ist fehlendes Fachwissen oder Domänenwissen ein Nachteil und verlangt viel Einarbeitungszeit und Wissenstransfers. Aufwände für offene Fragen, Besprechungen, Diskussionen, erneuten Rückfragen und erneuten Nacharbeiten am Produkt sind normal in agilen Umgebungen. Und vergessen wir bei alldem nicht: Eine Beschreibung einer User Story in Scrum ist oft nur das Versprechen auf ein Gespräch.
Struktur reinbringen!
Dabei wäre alles so einfach: Requirements Debt zeigen die Anforderungsqualität und vermitteln ein Gefühl um vergleichen oder bewerten zu können. Die einfachste Möglichkeit ist sicher, eine strukturierte Form reinzubringen – etwa mit vordefinierten Absätzen und auszufüllenden Themen. Dies sieht man oft bei User Storys:
Template einer User Story
Titel: Epic-Titel:* Story Titel
Als … möchte ich … um damit …
Abnahmekriterien:
- Definiert was gemacht werden muss, damit die User Story abgenommen wird.
- zB Geschäftsbedingungen, UI Beschreibung, Felder, Validierung, …
Nicht-Ziele:
- Was steht nicht im Fokus?
- Was gehört dediziert nicht zum Umfang?
Keine Funktionsanforderung:
- Mengengerüst, Antwortzeiten, …
Datenmigration:
- Falls notwendig, zB wenn neue Parameter benötigt werden
Rollen/Rechte:
- Müssen neue Rechte erstellt werden?
- Müssen vorhandene Rechte geändert werden?
Spezifikation/Anforderung:
- Links zum Styleguide oder Domain Model
- Welche Properties/Zustände gilt es zu beachten (zB Optimistic Concurrency)?
Referenzen:
- Mockups, Skizzen, Architekturkonzept, …
Usecase/Beispiel:
- Mit einfachen Worten beschreiben, wie das Feature im echten Leben genutzt wird.
- Benutze Personas, vermeide Fachausdrücke, verwende leichte und einfache Wörter.
Kontakt:
- Name des Stakeholders/Verantwortlichen für event. direkte Rückfragen
Verwenden Sie diese Vorlage nach Belieben und melden uns gerne ein, was Ihnen geholfen hat und was Ihnen fehlt: Nachricht senden
