Wenn Sie als Stakeholder in einem Softwareprojekt Anforderungen formulieren müssen, sollten Sie auf einige Dinge achten, um die Kommunikation möglichst reibungslos zu gestalten.
User Story
Mit User Stories lassen sich Anforderungen und neue Funktionen aus Sicht des Anwenders beschreiben. Eine Userstory sieht strukturell immer so aus:
[Als User] [möchte ich X], [um Y zu erreichen].
Wer möchte was und warum. Weiterhin sollte eine User Story mit Akzeptanzkriterien versehen werden. Das liefert weiteren Kontext und dient der späteren Abnahme, um zu prüfen, ob die User Story richtig umgesetzt wurde.
Beispiel für eine User Story:
Als Kunde möchte ich ein Kundenkonto anlegen, um meine vorherigen Bestellungen anzusehen.
AK:
- Im Kundenkonto gibt es in der linken Navigation einen Link “Meine Bestellungen”
- Liste der Bestellungen ist auf 5 begrenzt …
Aufgabe (Task)
Die Beschreibung einer Aufgabe folgt keiner strikten Definition. Dennoch ist es ratsam sie möglichst genau zu beschreiben, sodass alle Projektteilnehmer wissen, was gemeint ist.
Negatives Beispiel
Das Icon auf der Produktseite ändern.
Diese Aufgabe erfordert viel Hintergrundwissen und kann zu Fehlinterpretationen führen. Bei der Beschreibung einer Aufgabe sollten keine offensichtlichen Rückfragen offen bleiben. Bei dieser Beschreibung hingegen könnten folgende Rückfragen entstehen:
- Um welches Icon handelt es sich?
- Um welche Produktseite handelt es sich?
- Gilt das für alle Produktseiten, oder nur bestimmte?
- Was bedeutet ändern? Muss die Grafik ausgetauscht werden, oder nur die Größe angepasst?
Man sieht, je weniger Rückfragen zu einer Aufgabe offen bleiben könnten, desto leichter und schneller wird klar was zu tun ist. Folglich hat eine gut beschriebene Aufgabe direkten Einfluss auf die Bearbeitungszeit.
Positives Beispiel
Das Icon im Footer (URL) muss durch dieses (Anhang) ersetzt werden. [Screenshot]
Fehler (Bug Report)
In jedem System kann es mal zu ungewolltem Verhalten kommen. Je genauer allerdings das Problem beschrieben wird, desto schneller lässt es sich auch beheben.
Negatives Beispiel
Im Checkout kommt es zu einem Fehler.
Mit einer solchen Fehlerbeschreibung zu arbeiten ist unglaublich aufwendig. Denn es liegen keine nähere Informationen vor, diese müssen entweder mühselig nachgefragt und selbst getestet werden. Genauso wie bei der Meldung eines Unfalls sollte man einige Kerninformationen übermitteln, damit die Einsatzkräfte möglichst schnell helfen können. Daher kann für die Beschreibung von Fehlern folgende Blaupause nützlich sein:
Vorbedingungen Soviel Information über die Umgebung wie möglich. Z.B. Betriebssystem, Browser Version, etc., auf welcher URL, Kundenkonto, Gastkonto, vorherige Bestellungen etc.
Schritte zur Reproduktion Klare, reproduzierbare Schritte, um das Verhalten auszulösen
Erwartetes Verhalten Was sollte im Idealfall passieren?
Aktuelles Verhalten Was passiert stattdessen? Welche Fehlermeldung im genauen Wortlaut erscheint?
Bestenfalls wird eine Fehlerbeschreibung noch mit Screenshots unterfüttert. Hier ein Beispiel:
Vorbedingungen
- Chrome, Windows 10
Schritte zur Reproduktion
- Ins Kundenkonto einloggen
- Produkt (URL) in den Warenkorb legen
- In den Checkout gehen und auf “Weiter” klicken
Erwartetes Verhalten
- Zahlungsmethoden werden angezeigt
Aktuelles Verhalten
- Fehlermeldung “we cannot retrieve the payment method code” erscheint
Fazit
Sparen Sie sich und Ihrem Team wertvolle Zeit, indem Sie Anforderungen künftig genauer und strukturierter erfassen.