Use Cases: Defining Scope
This chapter is from the book
This chapter is from the book
This chapter is from the book
Scope is the word we use for the extent of what we design as opposed to someone else's design job or an already existing design.
Keeping track of the scope of a project, or even just the scope of a discussion, can be difficult. The consultant Rob Thomsett introduced me to a wonderful little tool for tracking and managing scope discussions—the in/out list. Absurdly simple and remarkably effective, it can be used to control scope discussions for ordinary meetings as well as project requirements.
Simply construct a table with three columns. The left column contains any topic; the next two columns are labeled "In" and "Out." Whenever there might confusion as to whether a topic is within the scope of the discussion, add it to the table and ask people whether it is in or out. The amazing result, as Rob described and I have seen, is that while is it completely clear to each person in the room whether the topic is in or out, the views are often opposing. Rob relates that sometimes it requires an appeal to the project's steering committee to settle whether a particular topic really is within the scope of work or not. In or out can make a difference of many work-months. Try this technique on your next project or perhaps your next meeting.
Table 3.1 is a sample in/out list we produced for our purchase request tracking system.
Table 3.1 A Sample In/Out List
|
Topic |
In |
Out |
|
Invoicing in any form |
|
Out |
|
Producing reports about requests (e.g., by vendor, by part, by person) |
In |
|
|
Merging requests into one PO |
In |
|
|
Partial deliveries, late deliveries, wrong deliveries |
In |
|
|
All new system services, software |
In |
|
|
Any nonsoftware parts of the system |
|
Out |
|
Identification of any preexisting software that can be used |
In |
|
|
Requisitions |
In |
|
Use the in/out list right at the beginning of the requirements or use case writing activity, to separate the things that are within the scope of work from those that are out of scope. Refer to it whenever the discussion seems to be going off track or some requirement is creeping into the discussion that might not belong. Update the chart as you go.
Use the in/out list for topics relating to both the functional scope and the design scope of the system under discussion.
3.1 FUNCTIONAL SCOPE
Functional scope refers to the services your system offers and that will eventually be captured by the use cases. As you start your project, however, it is quite likely that you won't know it precisely. You are deciding the functional scope at the same time you are identifying the use cases—the two tasks are intertwined. The in/out list helps with this, since it allows you to draw a boundary between what is in and what is out of scope. The other two tools are the actor-goal list and the use case briefs.
The Actor-Goal List
The actor-goal list names all the user goals that the system supports, showing the system's functional content. Unlike the in/out list, which shows items that are both in and out of scope, the actor-goal list includes only the services that will actually be supported by the system. Table 3.2 is one project's actor-goal list for the purchase request tracking system.
To make this list, construct a table of three columns. Put the names of the primary actors—the actors having the goals—in the left column; put each actor's goals with respect to the system in the middle column; and put the priority, or an initial guess as to the release in which the system will support that goal, in the third column. Update this list continually over the course of the project so that it always re-flects the status of the system's functional boundary.
Some people add additional columns—trigger, to identify the use cases that will get triggered by time instead of by a person, and business priority, development complexity, and development priority, so they can separate the business needs from the development costs to derive the development priority.
Table 3.2 A Sample Actor-Goal List
|
Actor |
Task-level Goal |
Priority |
|
Any |
Check on requests |
1 |
|
Authorizor |
Change authorizations |
2 |
|
Buyer |
Change vendor contacts |
3 |
|
Requestor |
Initiate a request |
1 |
|
|
Change a request |
1 |
|
|
Cancel a request |
4 |
|
|
Mark request delivered |
4 |
|
|
Refuse delivered goods |
4 |
|
Approver |
Complete request for submission |
2 |
|
Buyer |
Complete request for ordering |
1 |
|
|
Initiate PO with vendor |
1 |
|
|
Alert of nondelivery |
4 |
|
Authorizer |
Validate Approver's signature |
3 |
|
Receiver |
Register delivery |
1 |
The actor-goal list is the initial negotiating point between the user representative, the financial sponsor, and the development group. It focuses the layout and content of the project.
The Use Case Briefs
I will keep repeating the importance of managing your energy and working at low levels of precision wherever possible. The actor-goal list is the lowest level of precision in describing system behavior, and it is very useful for working with the total picture of the system. The next level of precision will either be the main success scenario or a use case brief.
The use case brief is a two-to-six sentence description of use case behavior, mentioning only the most significant activity and failures. It reminds people of what is going on in the use case. It is useful for estimating work complexity. Teams constructing from commercial, off-the-shelf components (COTS) use this description in selecting the components. Some project teams, such as those having extremely good internal communications and continual discussion with their users, never write more than these use case briefs for their requirements; they keep the rest of the requirements in the continual discussions, prototypes, and frequently delivered increments.
Table 3.3 Sample Use Case Briefs
|
Actor |
Goal |
Brief |
|
Production Staff |
Modify the administrative area lattice |
Production staff adds administrative area metadata (administrative hierarchy, currency, language code, street types, etc.) to the reference database. Contact information for source data is cataloged. This is a special case of updating reference data. |
|
Production Staff |
Prepare digital cartographic source data |
Production staffs convert external digital data to a standard format and validate and correct it in preparation for merging with an operational database. The data is cataloged and stored in a digital source library. |
|
Production and Field Staff |
Commit up-date transactions of a shared check-out to an operational database |
Staff applies accumulated update transactions to an operational database. Nonconflicting transactions are committed to the operational database. The application context is synchronized with the operational database. Committed transactions are cleared from the application context, leaving the operational database consistent, with conflicting transactions available for manual/interactive resolution. |
You can prepare the use case brief as a table, as an extension to the actor-goal list, or directly as part of the use case body in its first draft. Table 3.3 is a sample of briefs, thanks to Paul Ford, Steve Young, and Paul Bouzide of Navigation Technologies.