Previous | Table of Contents | Next |
3.2.1. Scenarios and Use Cases
The raw data for this design were gathered from contextual inquiries (CIs) conducted with users from six different corporations. These data included information on their existing work practice and tools, as well as on possible changes to the current practice that this new application might support. The hours of discussions and observations were summarized into reports for each customer, which were circulated back to the customer for comment and revision. These summaries were structured according to high-level scenarios. These scenarios were an amalgam of narrative information, as well as some observation and interpretation from the CI team. A scenario did not typically correspond to a single task, but usually captured a flow of tasks in a sense how the users defined their job responsibilities and means to fulfill them. The data captured within a scenario included task information, critiques of current tools, policies, and opinions. The customers all found these reports accessible and useful. The separate reports were consolidated into a single, cross-customer summary.
There are several different types of end users of system management applications who were observed at work in operations centers using existing tools and manual procedures. In the case study scenario below, the end user is the operator, who uses the application to watch the status of resources, gathers first level information when there is a problem, and then usually notifies an expert for problems they cannot solve. The operators report to a manager, who also has specific requirements for the application, but is not typically using it day in and day out to monitor (they often set up and administer the application, as well as set policies for the operators). The scenario is simply called Monitoring, and was derived from general and specific information from operators and their managers. The comments below were descriptions given by end users and are accurate reflections of observed work as well.
Such quotations are taken from an overall discussion and are meant to show how simple narrative serves as a starting point for design. Even this small sample of data outlines several critical (and sometimes conflicting) requirements the user interface needs to fulfill. One obvious example is the ability to monitor many objects at once while at the same time avoid being swamped or creating a condition where individual systems cannot readily be brought into focus. Also, users made it clear that accurate detection of problems was critical, and discussion surrounding this point suggested that, if not actual compensation, at least customer satisfaction was strongly influenced by success in this regard.
As useful as the scenario data were, they lacked sufficient structure for all aspects of design. Strength of the data in conveying the end user perspective was also a weakness because it did not provide a systematic decomposition that could be related into the overall software design process. Therefore, from the scenarios a set of use cases was defined. A Use-case is a sequence of transactions in a system whose task is to yield a result of measurable value to an individual actor of the system (Jacobson, I. et al., The Object Advantage, 1994, p. 105). While use cases are sometimes described as defined in the absence of users, for this project the use case definition was driven from the end user data and then reformulated, if need be, to tie into relevant details of the underlying system architecture.
The Monitoring scenario had a corresponding Monitoring use case, in which the value is bound to the fundamental challenge for the operator, namely being able to observe efficiently and effectively status changes. Two more specific use cases, as extensions of the basic use case defined specific interactions between the actor an operator and the management system. These extension use cases specify a substantial subcourse of actor-system interactions and capture two ways monitoring can be done. Figure 3.5 illustrates the use cases and their relationship. The textual definition of the main monitoring use cases is below.
Figure 3.5 Example use case analysis and structure.
Monitoring Managed Systems Events provide information about the systems, and are used as the basic indicators of system state change for operators. Access to the state change information comes from two modes: looking for a change in the system icon or some related icon (e.g., parent icon) or through viewing the event log.
Viewing Managed Topology Viewing managed topology is started when the operator launches the application. They use a graphic display of the managed systems to watch for changes in health of the systems. The topology includes all managed systems and any superimposed hierarchy (e.g., grouping by type). The health of the system is visually indicated.
Previous | Table of Contents | Next |