An Introduction to Usage Scenarios

To simplify requirements elicitation, it's useful to think of user requirements as “scenarios”. Scenarios are textual descriptions of how users will make use of the system when it is deployed. They guide the requirements gathering process and serve as a baseline from which more detailed requirements may be elicited.

Here’s an example of a scenario:

John Jenkins wants to submit a job application to the HR Department of Centage Solutions. He accesses the website, creates a profile and provides his educational, professional and personal information. He also uploads a copy of his CV and certificates. He then proceeds to search for vacancies by providing a keyword. On viewing the available vacancies returned, he applies for the most suitable one.

The above scenario describes the way a certain "John Jenkins" would use the system. Scenarios are usually written in plain English so that all stakeholders have a common reference for discussion. 

Here are some characteristics of usage scenarios:

• Scenarios are a path through the system, illustrating one single flow of logic but may comprise multiple use cases. As seen in the example provided above, multiple use cases can be identified: “create profile”, “upload cv”, “fill application form”, etc.
• Scenarios may be in the form of a few short sentences or span multiple pages. The level of detail is usually determined by the number of functionalities/information required to make the scenario complete and understandable to stakeholders
• Information for constructing scenarios may be obtained by observing users, conducting focus group sessions and interviewing stakeholders to understand their intentions for the new system
• Scenarios are not designed to be a complete documentation of system functionality. Be aware that not all scenarios can be captured from the beginning. The analyst may start with a key scenario which forms the basis for further requirements elicitation. More scenarios may be drawn up as user requirements evolve and system development progresses.
• Scenarios should be free of technical jargon; they are best written in a language that is consumer/end-user focused.
• Scenarios typically refer to specific or named actors while use cases refer to generic actors. For example, “customer” is generic.
• Scenarios are usually applied at the beginning of the project (during discovery/elicitation) and may include pictures or illustrations for further explanation.

The usage scenario is an interesting and simple approach for presenting user requirements in a language that business users are sure to understand. For more information on scenarios, read Nadine Schaeffer's take on Use cases, scenarios and user stories.