Task Scripts: An Alternative to the Use Case
Ian Graham describes an alternative to the use case that he calls the task script: "For each incoming message flow in the context model, it should be established what the role player or external agent would normally expect to happen in the form of a stated goal and a script beginning with an event."3
The task script (see Figure 8.4) is a description of the typical behavior of actors and external entities that is necessary to meet the stated goals of a system. The task script, like the use case, becomes the basis for system testing and acceptance. Graham's important observation is that the task script itself is an object that can be organized into composition, classification, and usage structures. Task scripts can be decomposed down to the level of atomic tasks that refer directly to system objects and their operations. The ideal task script is written in terms of SVDPI sentences. There may be subscripts. There may be side-scripts, which deal with exceptions. The text of the script can be analyzed (see "Abbott Textual Analysis" in this chapter) to find objects and operations.
Figure 8.4 Graham task card.
Benefits of the Use Case and Task Case Approaches
Chandra Vemulapalli, in an Internet posting, cited the following benefits for the use case approach:
Capturing requirements from user's perspective.
Users are involved.
One way of estimating the percentage of requirements captured.
Prioritizing use cases for "phased delivery" according to user's immediate needs.
A better way of estimating the percentage of requirements completed during development.
A good way to start identifying objects from scenarios.
Test plan can be immediately generated based on use cases.
Easier user validation.
Helps technical writers in structuring the overall work on the users manuals at an early stage.
Better traceability throughout the system development process.
Quality of the software is improved by identifying the exception scenarios earlier in the development process.