Scenarios are informal narrative descriptions, which are used to describe human tasks or activities that allow for the discussion and exploration of requirements, needs, and contexts (Rogers et al., 2007). They do not provide an explicit description of the way that a technological support or a software application is used to complete a task. However, they make use of the stories told by users, which describe the tasks that they need to perform and how they achieve something. These stories reflect the users’ goals or what they want to achieve. In addition, they provide interface designers with an understanding about why the users do things they way they do and what they are trying to accomplish. This in turn allows the interface designers to focus on the human activity instead of on the interaction with technology.
Although the users’ current process for performing their tasks can still be modified, it serves as a good place from where to start exploring the facilitators, irritations, contexts, and constraints under which the users operate. As well, it allows the interface designers to identify the products and stakeholders involved in the tasks. The construction of scenarios is the first step in the establishment of requirements.
Use cases, on the other hand, focus on the goals of users. It emphasizes the user’s interaction with the system instead of on the user’s task itself, although it still focuses more on the user’s perspective instead of on the system’s. In this technique, a scenario means a specific set of conditions or a path through the use case. Moreover, a use case represents a specific behavior example.
A use case intends to capture the goal of a user or actor in using the application. The main use case describes the group of actions that are most commonly performed, that is, the normal course, while the alternative courses of action are indicated at the bottom part of the use case. Use cases may also be graphically represented where an actor may be associated with multiple use cases in the same manner that a use case may be associated with multiple actors (Rogers et al.)
Unlike the scenarios technique, use cases have a more formal layout and are more useful during the conceptual design stage than during the data gathering phase. In developing a use case, the actors must first be identified and then their goals for using the system must also be identified where each goal will be represented by a use case.Finally, essential use cases are used to overcome the limitations of both use cases and scenarios where scenarios tend to focus on specific and realistic activities, which can obscure the bigger issues that are concerned with the wider view of the organization, whereas use cases tend to involve assumptions on the kind of technology or software application that will be used.
Essential use cases, on the other hand, try to refrain from making the assumptions that a traditional use case does and more generally represents a case than a scenario does. It is a structured narrative that consists of “a name that expresses the overall user intention; a stepped description of user actions; and a stepped description of system responsibility” (Rogers et al., p. 514). The responsibilities of the user and the system are segregated, which is useful during the conceptual design phase where the system scope and the task allocation are considered. It should also be noted that “essential use cases are associated with user roles” (Rogers et al., p. 514) rather than with actors and that the first step in using this technique is the identification of the user roles.
References
Rogers, Y., Sharp, H., & Preece, J. (2007). Chapter 10: Identifying Needs and Establishing
Requirements. In Interaction design: Beyond human-computer interaction (2nd ed.) (472-
526). Hoboken, NJ: John Wiley & Sons
