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.1A 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.