Erfassen funktionaler Anforderungen mit Use Cases und User Stories

• Funktionale Anforderungen beschreiben, wie das Produkt oder die Dienstleistung die Kundenbedürfnisse erfüllt. Dazu gehören Merkmale und Funktionen in Anwendungsfällen, die dokumentieren, wie Benutzer mit dem Produkt oder der Dienstleistung interagieren werden.
• Nichtfunktionale Anforderungen sind Betriebs- und Produktattribute, die für den Benutzer manchmal nicht offensichtlich sind, einschließlich Leistung, Benutzerfreundlichkeit, Haltbarkeit, Sicherheit und Finanzen (Preis und Kosten).

BEARBEITEN SIE DIESE ABBILDUNG – FUNKTIONALE ANFORDERUNGEN VS. NICHT-FUNKTIONALE ANFORDERUNGEN

Funktionale Anforderungen können als das angesehen werden, was das Produkt für den Kunden tun muss, während nichtfunktionale Anforderungen als Einschränkungen betrachtet werden können, die das Produkt oder die Dienstleistung erfüllen muss.

Funktionale Anforderungen erfassen das beabsichtigte Verhalten des Systems. Dieses Verhalten kann als Dienste, Aufgaben oder Funktionen ausgedrückt werden, die das System ausführen muss. In der Softwareentwicklungsbranche hat sich der Use-Case-Ansatz schnell zu einer weit verbreiteten Praxis zur Erfassung funktionaler Anforderungen entwickelt. Dies gilt insbesondere für die objektorientierte und UML-Community, aus der sie stammen, aber ihre Anwendbarkeit ist nicht auf objektorientierte Systeme beschränkt.

Welche Techniken zur Erfassung funktionaler Anforderungen?

Funktionale Anforderungen werden typischerweise in Form von Anwendungsfällen oder Benutzerszenarien erfasst. Diese Begriffe werden manchmal synonym verwendet, bedeuten aber etwas anderes.

• Anwendungsfälle konzentrieren sich mehr auf das System und darauf, was es tun muss, um die Bedürfnisse der Benutzer zu erfüllen.
• User Stories hingegen zeigen die Produktfunktionalität aus der Sicht des Benutzers und spezifizieren Benutzerrollen und spezifische Ziele, die sie erreichen möchten.

Erfassen funktionaler Anforderungen mithilfe von User Stories

User Stories sind eine leichtgewichtige Methode, um schnell das „Wer“, „Was“ und „Warum“ der Anforderungen an ein Produkt zu erfassen. Einfach ausgedrückt sind User Stories Ideen, die die Bedürfnisse der Benutzer zum Ausdruck bringen. User Stories sind kurz und jedes Element enthält normalerweise weniger als 10 oder 15 Wörter. User Stories sind „To-Do“-Listen, die Ihnen helfen, die Schritte entlang des Projektpfads zu identifizieren. Sie tragen dazu bei, dass Ihr Prozess und das resultierende Produkt Ihren Anforderungen entsprechen.

User-Story-Vorlage

User Stories erfassen nur die wesentlichen Elemente einer Anforderung:

• Für wen ist es?
• Was erwartet es vom System?
• Warum ist es wichtig (optional?)?

Hier ist ein einfaches Format einer User Story, das von 70 % der Praktiker verwendet wird:

Rolle  – Der Benutzer sollte ein tatsächlicher Mensch sein, der mit dem System interagiert.

• Seien Sie so genau wie möglich
• Das Entwicklungsteam ist KEIN Benutzer

Aktion  – Das Verhalten des Systems sollte als Aktion geschrieben werden.

• Normalerweise einzigartig für jede User Story
• Das „System“ ist impliziert und wird nicht in die Geschichte geschrieben
• Aktiv, nicht Passiv („Ich kann benachrichtigt werden“)

Nutzen  – Der Nutzen sollte ein reales Ergebnis sein, das nicht funktional oder außerhalb des Systems ist.

• Viele Geschichten können dieselbe Leistungserklärung haben.
• Der Nutzen kann für andere Benutzer oder Kunden sein, nicht nur für den Benutzer in der Story.

Wie identifiziere ich funktionale Anforderungen mit Anwendungsfällen?

Um die funktionalen Anforderungen des Systems vollständig zu verstehen, müssen Sie wissen, für wen das System bestimmt ist, dh wer wird das System verwenden?

Die Antwort auf diese Frage lautet: der Akteur in der Use-Case-Analyse

Use Cases oder User Stories erfassen funktionale Anforderungen, die das Verhalten als Dienste, Aufgaben oder Funktionen ausdrücken kann, die das System ausführen muss. Anwendungsfälle definieren die Interaktion zwischen dem Benutzer und dem Systemdienst, die dabei helfen können, die funktionalen Anforderungen des zu entwickelnden Systems zu definieren. Oder mit anderen Worten, was das Produkt oder die Dienstleistung leisten muss, um die Bedürfnisse und Wünsche des Kunden zu befriedigen.

Ein Anwendungsfall beginnt mit einem „Akteur“ oder „Wer“, einem bestimmten Nutzer des Produkts oder der Dienstleistung.

Ein Akteur ist eine Person oder ein externes System, das bei der Interaktion mit dem System eine Rolle spielt. Instanzen von Akteuren können Einzelpersonen oder externe Systeme sein; jedoch stellt jeder Akteur eine einzigartige und wichtige Perspektive des Systems bereit, eine Perspektive, die jeder Instanz (tatsächliche Person/Benutzer) des Akteurs gemeinsam ist.

Echter Benutzer vs. Anwendungsfallakteur

Um den Zweck des Systems vollständig zu verstehen, müssen Sie wissen, für wen das System bestimmt ist, dh wer es verwenden wird. Die unterschiedlichen Benutzertypen werden als Akteur (Rollen) dargestellt.

Der Unterschied zwischen einer Rolle und einem einzelnen Benutzer besteht darin, dass eine Rolle eine bestimmte Klasse von Benutzern und nicht einen tatsächlichen Benutzer darstellt. Verschiedene Benutzer können dieselbe Rolle spielen, wobei jeder Benutzer eine Instanz eines Akteurs darstellt.

Diese Unterscheidung zwischen Akteuren und Instanzen von Akteuren wird im Folgenden veranschaulicht:

Die folgende Abbildung zeigt einen Fall, in dem Mary und John Kunden eines Verkaufsautomaten sind. Wenn sie den Verkaufsautomaten benutzen, wird jeder durch eine Instanz eines Akteurs namens Kunde dargestellt, der Zugriff auf bestimmte Funktionen des Systems erwartet (in diesem Fall das Drucken von gekauften Lebensmitteln).

BEARBEITEN SIE DIESE ABBILDUNG DES VERKAUFSAUTOMATEN

Umgekehrt kann derselbe Benutzer mehrere Rollen spielen (dh dieselbe Person kann verschiedene Rollen spielen).

Zum Beispiel Dr. Gates, der Komiteemitglied der Computer Society ist. Er ist verantwortlich für die Verwaltung des Mitgliedschaftsverwaltungssystems, wie das Hinzufügen und Entfernen von Benutzerkonten. Wenn er dies tut, spielt er eine Rolle namens Administrator (Schauspieler). Derselbe Dr. Gates kann jedoch auch Mitglied der Computer Society sein. In diesem Fall würde er auch eine Rolle namens „Member“ (Schauspieler) spielen.

Wie man die funktionalen Anforderungen erhält, indem man die Anwendungsfälle des Systems identifiziert

Ein Anwendungsfall kann identifiziert werden, indem den Stakeholdern die folgenden Arten von Fragen gestellt werden (die sie aus Sicht der Akteure beantworten müssen):

• Was versuchen Benutzer in dieser Rolle zu erreichen?
• Was müssen Benutzer können, um diese Rolle zu erfüllen?
• Was sind die Hauptaufgaben von Benutzern in dieser Rolle?
• Welche Informationen müssen Benutzer in dieser Rolle prüfen, erstellen oder ändern?
• Worüber müssen Benutzer in dieser Rolle vom System informiert werden?
• Was müssen Benutzer in dieser Rolle dem System mitteilen?

Beachten Sie, dass:

Anwendungsfälle werden häufig verwendet, um Funktions- und Systemanforderungen zu ermitteln und darzustellen, da ein Anwendungsfall die Interaktionen und Aufgaben definiert, die zur Erfüllung eines bestimmten Geschäftsziels erforderlich sind. Sie sind jedoch normalerweise keine gute Möglichkeit, nichtfunktionale Anforderungen wie Systemleistung und -qualität zu definieren.

Verweise

• User Story vs. Use Case für agile Softwareentwicklung
• Was ist eine User-Story?
• Was ist User Story Mapping?
• Identifizieren Sie Benutzeranforderungen mit Anwendungsfalldiagrammen
• Wie verwendet man Wireframes mit User Stories?
• Anwendungsfallgesteuerter Ansatz für die agile Entwicklung
• Was ist eine Anwendungsfallspezifikation?