Advanced Requirements Engineering
Eine Ebene tiefer heißt: konkreter, kleiner, näher an der Lösung. Bis zur User Story bleibt alles implementierungsfrei.
ISO/IEC/IEEE 29148:2018 · SAFe · Cockburn · Bass/Clements/Kazman
Die Take-Rate der Infotainment-Premium-Option maximieren, um die hohen lokalen Fertigungskosten auszugleichen.
Hat Business Objectives, aber keine Kinder. Alles darunter wird nicht aufgehängt, sondern traced — keine Verbindung ⇒ Gold-Plating.
Als Fahrer möchte ich während der Fahrt telefonieren, so dass ich weiterfahren kann.
Bewusst grob — ein Bündel von Funktionalität, weder singular noch complete. Von SMART gelten hier nur Specific und Relevant.
Als Fahrer möchte ich während der Fahrt eine Telefonnummer wählen, so dass ich mit einem Gesprächspartner sprechen kann.
Muss bounded sein: vollständig in genau einem PI entwickelbar und testbar. Sonderfälle auf derselben Ebene — Architecture Enabler und Operational Feature .
Als Fahrer möchte ich während der Fahrt die Telefonfunktion und die Wähloption auswählen, so dass ich anschließend eine Rufnummer eintippen kann.
Muss die Subsysteme spannen und Nutzerinteraktion beschreiben. „CAN-Message-Matrix-Layer aktualisieren“ wäre der Fehler, der den Wert verliert.
Der Dialer-Service soll die eingegebene Rufnummer vor der Übergabe an den Telefonie-Stack nach E.164 normalisieren.
Technische Spezifikation für Software, Hardware und Schnittstellen. Daneben das Sub-System Requirement, das manche Organisationen zusätzlich führen.
| Kategorie | Format | Wird verfeinert durch |
|---|---|---|
| Functional | User-Story-Format | Use Case → Features → User Stories → GWT |
| Operational Quality extern, vom Nutzer erlebbar |
Requirements-Sentence-Format | Quality Scenarios — als AC oder als eigenes Operational Feature |
| Developmental Quality intern, für Entwicklung und Wartung |
Requirements-Sentence-Format | Architecture Enabler → Architektur |
| Constraint Budget, Termin, Recht, Technologie |
Requirements-Sentence mit „will“ | nichts — Constraints werden nicht zerlegt |
User-Story-Format · Value Focus
Als ein <Rolle / Typ von Nutzer> möchte ich <dies tun>, so dass <ich dieses Ziel erreiche>.
Prüffrage: Gibt es einen benennbaren Nutzer und einen Wert für ihn?
Requirements-Sentence-Format · System Focus
[Condition] Subject Imperative Action Object [Constraint] shall verbindliche Anforderung should Ziel oder Empfehlung, nicht bindend will gesetzte Absicht → Constraints
Prüffrage: Ist die Verbindlichkeit explizit — shall, should oder will?
GWT-Format · Acceptance Criteria der User Story
Given Zustand der Welt vor dem Verhalten When das Verhalten, das spezifiziert wird Then die erwartete Änderung als Folge
Prüffrage: Ist daraus direkt ein Testfall ableitbar?
Source of Stimulus wer oder was löst aus Stimulus WHEN welches Ereignis Artifact welches Element ist betroffen Environment GIVEN Normal · Peak · Overload Response THEN wie reagiert das Element Response Measure Latency · Jitter · Miss Rate …
| Kategorie | wenn sie fehlt |
|---|---|
| Basic wird vorausgesetzt | starke Unzufriedenheit |
| Performance je mehr, desto besser | sinkt linear |
| Delighter Wettbewerbsvorteil | keine Unzufriedenheit |
| Indifferent Noise | kaum Wirkung — Aufwand verschwendet |