D4P: Use Case Guidelines

CS 486 - Senior Capstone Design

Use Case Guidelines and Samples

Use Cases

Use Cases, also called "user scenarios" or "user stories", can provide a useful way of documenting the designers conceptions of what users will do with a planned software application and how it will get done, i.e., what the users does to accomplish some task, and how the application will respond.

Use Cases are organized around the tasks that end-users want to accomplish with the application. To help the user achieve a specific goal, the software presents a series of tasks and screens to be completed; the use case for a particular user goal describes:

The end-user goal
The end-user, i.e., the role (e.g. "graduate secretary") of the person and what, if any, knowledge they bring to the task.
The tasks or steps that the user completes to achieve the goal
The system responses to each user task or step.
An overview of how the architecture works to accomplish the task.

A series of Use Cases is created, one for each principal goal that users have in utilizing the software. This approach helps to ensure that:

The software includes the key functionality expected. It's easy to see if there are missing or superfluous goals.
The system responses will be understandable and helpful to users.

Example: Development of a script editor.

In Spring2002, the Enscrypt team was tasked with developing a script editor for automated production facility machinery. The use case below is one of a set of about 20 Enscrypt developed to describe the functional behavior of their system. I have taken the liberty of editing and improving their version slightly to better illustrate what is needed.

Use Case 9: Delete A SSL Function From A Synchronous SSL Script

Scenario: Joe has been using the Enscrypt system to edit his code, and has just decided that he would like to delete a SSL function from a synchronous SSL Script.
Actors: Joe, Automation Specialist. Joe has moderate command of the SSL language and basic experience using ENSCRYPT tools.
User Steps and system responses:

Joe selects a function from the Available Function list box of a currently open Synchronous SSL Script in the Synchronous Script Creator window in Figure 7.
Explanation: Joe will click on the function name in order to select it. The function name will be highlighted in the list box.

Joe clicks on the Remove button.
Explanation: The selected function will be removed from the List of Used Functions and also from the file. Joe will be able to see the updated Synchronous SSL Script in the SSL Script File text box.

When Joe has finished deleting the function, he clicks on the Save button located in the bottom right hand corner of the window.
Explanation: A Save window will appear, prompting Joe to enter in a name of the file.

Joe enters a valid name and clicks on the OK button within the Save window.
Explanation: The program will capture the data in the Synchronous Script File text box and save it to the specified file name, which Joe created. The save window will disappear and control will transfer back to the Synchronous Script Creator.

To Exit, Joe clicks on the Close button in the bottom right hand corner.
Explanation: A check will be performed to make sure that the data inside the Synchronous Script File text box has been saved. The file has been saved, so the current window disappears and control returns back to the opening screen.

Joe clicks on the X button in the ENSCRYPT- Intel Script Editor window.
Explanation: The program will completely shut down.

System Behavior: The main architectural components in play here are the User Interface Generator (UIG) module and the Scripting Manager (SM). The UIG handles display including the workspace, buttons and menus. To create the function list box contents, the UIG talks to the SM, which knows about all defined functions and parameters.

The example above comprises one complete Use Case. As you can see, if gives a very good "feel" for how the system behaves, i.e., how all the discrete functionality you listed out in earlier sections of the functional specification actually fits into the everyday life of the end-users. This makes Use Cases an excellent tool for exposing shortcomings in the spec, and potential misunderstandings about systems function. Which is good, because the functional specification is the last chance to get this straight between you and the client --- after this, any changes will require negotiating a change order. While not too stressful in the Capstone world, this can be quite arduous in the real world where it often involves deciding how the change affects the cost of the final product, i.e., how much more/less the client is going to pay you for it. Not fun.