Scenario Requirements Analysis Method (SCRAM)
Ziel:
Auf der Basis von Benutzungsszenarien, Low-Fidelity-Prototypen (wie Paper Mock-Ups), Designentscheidungen und Benutzerworkshops ermöglicht SCRAM eine sehr frühe Anforderungsvalidierung von interaktiven Systemen.
Beschreibung:
Die SCRAM Methode liefert eine systematische Anleitung für die Verwendung von Szenarien bei der Anforderungserhebung und –analyse.
Grundlegende Konzepte
Die Methode kombiniert vier im RE etablierte Techniken:
- Prototypen und Konzeptdemonstratoren: stellen entworfene Artefakte dar, auf die Benutzer reagieren können
- Szenarien: die designten Artefakte werden in einem situierten Kontext präsentiert, um Benutzern die Möglichkeit zu geben, die Beziehungen zu ihrer Arbeit und ihren Aufgaben herzustellen
- Design-Begründungen: Die Absichten und Begründungen hinter dem Design werden den Benutzern ausdrücklich vermittelt, um die Benutzer ausdrücklich in den Designprozess einzubeziehen
- Partizipative Anforderungsvalidierung: in Workshops und Walkthroughs werden die Benutzer aktiv in den Designprozess einbezogen
Vorgehen
- Initiale Anforderungserfassung und Domänenanalyse: Verwendung von herkömmlichen Techniken, wie z.B. Interview. Ziel ist es, genügend Informationen zu sammeln, um einen ersten Demonstrationsprototypen erstellen zu können.
- Spezifikation und Entwicklung des Demonstrationsprototypen: Im Allgemeinen wird ein Wizard-of-Oz-Prototyp erstellt. Ziel ist die Demonstration von Systemabläufen in Beziehung zu typischen Benutzeraufgaben.
- Analyse und Validierung der Anforderungen: Die Benutzer werden gebeten, den Prototypen und die Designentscheidungen dahinter zu kritisieren.
- Auswertung: Die Daten der Validierungssession werden analysiert und die Schlussfolgerungen daraus werden den Benutzern zugänglich gemacht.
Zur spezifizierten Designoption existieren (partielle) Alternativen.
Das vorgeschlagene Design basiert auf expliziten Begründungen/Designentscheidungen.
Diese Technik erfüllt folgende Praktiken:
Aufgaben und Geschäftsprozesse erhebenFunktionale Anforderungen erheben
Rationale dokumentieren
Prototyping
Literaturverweis: