Anforderungen an die Benutzeroberfläche in User Storys

Ich bin mir nicht sicher, ob dies im ux.stackexchange-Forum oder hier sein sollte.

Im Rahmen eines Uni-Projekts hat uns der Kunde ein Briefing mit obligatorischen und optionalen Features gegeben, aus denen wir User Stories bauen müssen. Eine der obligatorischen Anforderungen ist, dass jeder Kontotyp ein anderes UI-Design haben sollte.

Wie brechen Sie das in eine User Story und Funktionalität herunter, bevor die Entwicklung begonnen hat? Könnte es einfach eine User Story auf hohem Niveau sein, die später aufgeschlüsselt wird? Wenn ja, bin ich etwas verwirrt darüber, was das "damit ..." sagen würde.

Es ist erwähnenswert, dass wir der herkömmlichen User-Story-Struktur folgen müssen.

Mögliches Duplikat, zumindest lesenswert: pm.stackexchange.com/questions/20239/…
Der Link betrifft die Zerlegung von Geschichten, aber meine Fragen konzentrieren sich auf das Thema UI-Anforderungen und wie man diese in einer Geschichte festhält.
Gibt es einen Geschäftswert, der mit jedem Kontotyp verbunden ist, der ein anderes UI-Design hat?
@BarnabyGolden Es wird nur vom Kunden verlangt und sie haben den Geschäftswert nicht wirklich erweitert
Das macht es schwierig, die Frage zu beantworten. Der „damit …“-Teil einer User Story bezieht sich normalerweise auf den Wert, den das Unternehmen aus der Fertigstellung der Story zieht. Ich könnte mir so etwas vorstellen wie: „Als Website-Benutzer möchte ich einfach erkennen, dass ich als Superuser angemeldet bin, damit ich nicht versehentlich eine Seite lösche.“ Aber ohne zu wissen, was der Kunde will, ist es schwierig, die Geschichte zu vervollständigen.
@BarnabyGolden für das Beispiel, das Sie gerade gegeben haben, würde das nicht nur funktionieren, wenn eine Person zwei Zugriffsebenen hätte?
Ich denke, es ist wirklich die Schuld von mir und meiner Fraktion, es nicht in Frage zu stellen
Ja, es würde nur funktionieren, wenn sie mehrere Zugriffsebenen hätten. Sie können sehen, warum Geschichten typischerweise von Product Ownern oder Stakeholdern in Organisationen geschrieben werden. Es ist schwierig, kundenorientierte Geschichten ohne viel Kontext zu den Anforderungen zu schreiben.
Um ehrlich zu sein, habe ich die meisten Fragen geschrieben, da bestimmte Mitglieder der Gruppe den Sinn des Sammelns von Anforderungen nicht wirklich verstehen/sehen und ich diese Anforderung nicht aufgegriffen habe.
@BarnabyGolden Trotzdem danke, ich werde meinen Vorgesetzten fragen, ob ich eine Funktion / einen Kontext dafür bekommen kann

Antworten (3)

Es gibt verschiedene Arten von Anforderungen

  • Funktionale Anforderungen beschreiben Merkmale oder Verhaltensweisen, die das System unterstützen muss
  • Nichtfunktionale Anforderungen beschreiben Fähigkeiten des Systems wie Leistung, Wartbarkeit, Sicherheit usw.
  • Einschränkungen sind Anforderungen, die Ihre Gestaltungsfreiheit einschränken, z. B. Anforderungen, welcher Technologie-Stack verwendet werden soll oder dass es sich um eine Webanwendung handeln muss.

User Stories eignen sich hervorragend, um funktionale Anforderungen zu erfassen. Sie sind viel schwieriger auf nicht-funktionale Anforderungen anzuwenden und für Constraints geradezu unmöglich. Das liegt daran, dass Einschränkungen und bestimmte Arten von nicht funktionalen Anforderungen alle User Stories betreffen. Sie können nicht alleine bearbeitet werden und man kann nie sagen, dass sie "fertig" sind.

Die Anforderung, dass verschiedene Arten von Benutzern ein unterschiedliches Aussehen und Verhalten für ihre Benutzeroberfläche haben müssen, ist eine Einschränkungsart von Anforderung, da sie nichts beschreibt, was dem Benutzer des Systems zugute kommt (es sei denn, es gibt andere Anforderungen, die Kontext hinzufügen die Vorteile klar), aber es schränkt Ihre Freiheit bei der Gestaltung des Systems ein.

Da Einschränkungen sich nicht für das User-Story-Format eignen, würde ich Ihnen raten, die Anforderung klar als Einschränkung zu kennzeichnen und nicht zu versuchen, sie als User-Story umzuschreiben.

Ich denke, diese Antwort zeigt gut, was Sie tun könnten. Stellen Sie sich zunächst diese Fragen:

Liefert diese Geschichte an sich einen Mehrwert?

Gibt es eine Möglichkeit, weniger zu tun und trotzdem Wert zu liefern?

Wenn die Antwort auf die erste Frage „nein“ lautet, dann haben Sie sie zu weit heruntergebrochen … oder es ist etwas, woran Sie überhaupt nicht arbeiten sollten. Wenn die Antwort auf die zweite „Ja“ lautet, dann haben Sie sie nicht ausreichend aufgeschlüsselt .

Sobald Sie sich eine Geschichte mit minimalem Umfang erstellt haben, die von sich aus einen Mehrwert bietet, müssen Sie nur noch die folgenden zwei Fragen beantworten (und in der Geschichte dokumentieren):

Für wen ist diese Geschichte wertvoll?

Wie bietet diese Geschichte einen Mehrwert?

Wenn Sie keine dieser Fragen beantworten können, sollten Sie sich die Frage „Liefert diese Geschichte an sich schon einen Mehrwert?“ noch einmal ansehen.

Ich würde wahrscheinlich separate User Stories erstellen, um jeden einzigartigen Kontotyp und das damit verbundene UI-Design, Akzeptanzkriterien und Abhängigkeiten zu erfassen. Auf diese Weise könnten Sie jede Story separat ausführen und den erfolgreichen Abschluss jedes Kontotyps verfolgen.

Wenn es einige allgemeine Codeartefakte gibt, die jede Story verwenden und auf denen sie aufbauen kann, trennen Sie diese Arbeit in eine eigene Story und führen Sie sie zuerst aus.

Diese Aufschlüsselung würde es Ihrem QA-Team ermöglichen, die Benutzeroberfläche jedes einzelnen Kontotyps separat zu testen und festzustellen, ob die Arbeit abgeschlossen ist und die Akzeptanzkriterien erfüllt.

Sind Akzeptanzkriterien mit der Definition of Done verknüpft?
Akzeptanzkriterien sind die Dinge, die vereinbart wurden und die in der endgültigen Lieferung der Geschichte ausgestellt werden müssen. Dies können auch negative Anforderungen sein (Dinge, die die Software nicht erfüllen soll). Akzeptanzkriterien können auch von Ihrem QA-Team und während der Demo zur Akzeptanz durch den Product Owner verwendet werden.
Anforderungen an die Benutzeroberfläche in User Storys
AntwortenHierDatenschutz-Bestimmungen1y, 0v