Variations on Video Usage Scenario Template:

Instructions and Example

Mark Notess

17 September 2010

 

Introduction

The purpose of this template is to aid the Variations on Video functional requirements process by providing a simple but standard format for describing the video usages we hope to enable as a result of our work. These usage scenarios are higher-level and less technical than use cases. Use cases are more of a tool for figuring how to structure the software. Usage scenarios help surface requirements and are user-oriented rather than system-oriented, making it easier to use them in discussions with end users. Having higher-level scenarios also reduces the temptation to jump prematurely to implementation details.

 

Instructions

The template consists of the following parts.

  1. Title. This should be brief, just a line or so that indicates the kind of activity the scenario describes and allows it to be distinguished from other scenarios.
  2. Source. Identifies the author(s) and institution(s) who contributed to the scenario.
  3. Last modified. Even if we keep these in a wiki, a printout needs a date.
  4. Summary. The summary is a short paragraph describing generically what the  scenario is about. This should just be two or three lines. (Although a summary may be a bit redundant in a completed usage scenario, having a place to put a summary is helpful if we initially want to create a group of summaries, turning them into scenarios later.)
  5. Scenario. The scenario proper is a story of use . It should be grounded in a real or plausible context rather than being generic. The scenario has the following parts.
    1. Context. The context helps set the stage for why the scenario matters. What is it that the users want to do and why? What are the circumstances that make this scenario interesting or challenging? The context is the beginning of the story and should be written as narrative rather than as exposition.
    2. Users. These are the players in the scenario. Name them and identify their roles.
    3. <User>’s View. Tell the story from the perspective of each distinct user role. The details of the story should be grounded in the same real example as the rest of the scenario rather than being generic. Have a separate “view” section for each user role.
  6. Assumptions. These are the prerequisites or dependencies—often technical or workflow-related—that must be in place for the scenario to work.
  7. Issues. These are known problems or unanswered questions about what users really need or about what is technically feasible.

Example)

 

Variations on Video Usage Scenario: Providing Opera Performance Examples for Student Performance Preparation

Mark Notess, Phil Ponella, Indiana University

Last modified: 9 September 2010

 

Summary: After seeing the announcement for next year’s opera performances, the music library places video recordings of the operas on reserve so that students planning to audition or selected to perform can watch previous IU performances and other productions of interest.

 

Scenario

 

Context: Each year, IU stages seven full operas. Students audition for performance parts, sing in the chorus, play in the pit orchestra, and participate in other aspects of production.

 

Users: orchestral librarian (Natasha), reserves coordinator (Raul), student digitizer (William), and student performer (Rachel)

 

Orchestral librarian view: Natasha uses the IUCAT online catalog to look up video holdings for each of the seven operas planned for production next year. She selects videos of three or four productions of each opera (where available: one opera is a world premiere), and emails a list to the opera department and conductors asking whether they would suggest any additional production videos for inclusion or purchase. She receives a reply from one conductor suggesting the addition of a recent Metropolitan Opera performance to the collection. Natasha sends off a purchase request. She sends a the full list of videos to Raul.

 

Reserves coordinator view: Raul looks at Natasha’s list. He creates digitization requests for the operas not yet in the Variations system. He uses the Variations access control system to create reserve lists.

 

Student digitizer view: William digitizes videos, puts them into Variations, and notifies the coordinator that they are available.

 

Student performer: Rachel, having been selected as one of the performers for the part of “Queen of the Night” in the Magic Flute, decides to review her part in several performances of the opera before attending the first rehearsal. On her iPad Safari browser she starts up the Variations app she downloaded from last night. She is has to provide her network ID and passphrase to authenticate. She scrolls through her reserves lists and picks the opera list, selects the opera, and selects one of the videos to watch. The video loads, but she quickly touches the track list button and picks the first scene in which she appears. The scene begins to play. Rachel moves playback forward until she finds the place where her character appears on stage. She creates a bookmark there. Rather than watching the performance, she decides to bookmark the other places in that and the other performances where she appears. On her laptop that evening she runs Variations and uses the bookmark editor to organize the bookmarks by scene instead of by video. This makes it easy for her to compare performances of the same part later on her iPad between classes.

 

Assumptions:

1.        Student employees will digitize video.

2.        iOS device support.

3.        Reserve lists are handled within Variations (or this could be a customization just for IU).

 

Issues:

1.        New purchases are likely to be DVDs, at least for awhile. What about the DMCA?

 

 

Blank Template

Variations on Video Usage Scenario:

Source:

Last modified:

 

Summary:

 

Scenario

 

Context:

 

Users:

 

<User1>’s view:

 

<User1>’s view:

 

Assumptions:

1.     

Issues:

1.