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.

Kategorien: Allgemein