Das Schreiben guter Softwareanforderungen erfordert Geschicklichkeit, Übung und Geduld. Die wichtigsten Fragen, mit denen wir konfrontiert sind, sind:
Welche Art von Sprache verwenden wir?
Welchen Detaillierungsgrad brauchen wir?
In welcher Form sollen wir die Anforderungen dokumentieren und darstellen?
Viele Organisationen improvisieren ihre eigenen Methoden, wenn sie mit den Anforderungen des Schreibens konfrontiert sind. Die Gefahr besteht jedoch darin, dass bereits kleine Versehen zu Problemen bei der Implementierung und Ausführung führen können.
Wenn eine Anforderung mehrdeutig oder schwer lesbar ist, wird sie möglicherweise falsch interpretiert oder nicht vollständig gelesen.
Wenn bestimmte Details fehlen, kann dies zu einem fehlerhaften oder zufälligen Design führen.
Wenn Geschäftsregeln nicht vollständig und klar definiert sind, kann dies zu fehlenden oder fehlerhaften Funktionen führen.
Wenn es an Spezifität mangelt, führt dies dazu, dass etwas gebaut wird, das anders ist als beabsichtigt.
Wir können uns gegen diese Szenarien schützen, indem wir einige solide Praktiken befolgen. Dies soll eine Grundierung für diejenigen sein, die neue Anforderungen an das Schreiben stellen, aber es kann auch für erfahrene Personen hilfreich sein. Wir können sogar neue Ideen und Anforderungen entwickeln, indem wir einfach etwas mehr als einmal betrachten. Die Anforderungen werden häufig im Verlauf des Projekts definiert, verfeinert, ergänzt und gelöscht, oder an einem beliebigen Punkt, an dem etwas angezeigt und überprüft werden kann.
Natürlich ist es aufgeräumter, alles im Voraus genau zu planen und dann einfach den Plan auszuführen, der der Wasserfall-Ansatz ist. Der Wasserfallansatz funktioniert gut für Projekte, die vorhersehbar sind oder einer wiederholbaren Formel folgen. Für Projekte, bei denen das Endergebnis jedoch unsicher ist, ist es schwieriger. Selbst bei einer langen und detaillierten Entdeckungsphase werden Anforderungen selten in Stein gemeißelt; und selbst wenn es verfolgt wird, neigt das Endergebnis dazu, all die Dinge aufzudecken, über die die Leute nicht vorgegangen sind oder darüber nachgedacht haben, was zu einem unbefriedigenden Ergebnis führt. Sie dienen als Ausgangspunkt für andere Artefakte und sind nützlich, um den geschäftlichen Wert auszudrücken und um Planung und Schätzung auf höchster Ebene durchzuführen.
Die am häufigsten verwendete Vorlage zum Schreiben einer User Story ist die von Mike Cohn beliebte:
Als a will ich das so.
Mit anderen Worten, wir beantworten folgende Fragen:
Wer: Wem nutzen wir das?
Was: Was machen wir?
Warum: Warum machen wir das?
Dies ist einfach, es ist leicht zu verstehen, es stellt einen geschäftlichen Wert dar und impliziert keine bestimmte Lösung oder Implementierung. Dies ist wichtig, da übergeordnete Anforderungen das Problem definieren sollten, nicht die Lösung. User Stories erleichtern die Diskussion mit Teammitgliedern und nichttechnischen Mitarbeitern, um ein Projekt auf seiner Basisebene zu planen und zu verstehen.
Ich finde es hilfreich, User Stories auf zwei Ebenen zu betrachten. Geschichten auf hoher Ebene und Geschichten auf niedriger Ebene (oder Untergeschichten), die eine Eltern-Kind-Beziehung zueinander haben. Wir können uns vorstellen, die Anforderungen auszubauen, indem wir ein paar Durchgänge machen, um die Geschichten zu verfeinern.
Ein erster Schritt bei der Iteration der Anforderungen wäre zum Beispiel die Definition von Storys auf hoher Ebene, die den Anwendungsbereich umfassend beschreiben.

Tags: Software, Softwareentwicklung, Entwicklung von Mobilen Apps, Entwickler