4.2. The Requirements Capture Process

We start with a top-level view of the problem we are
solving and the key areas of functionality that we must address
in any solution. This is our vision
document, and should be just a few pages long.

For example the top-level view of an automated teller
machine (ATM) might be that it should support the
following.

Cash deposit, cash withdrawal and account inquiries
by customers.

Maintenance of the equipment by the bank's
engineers, and unloading of deposits and loading of cash by
the local bank branch.

Audit trail for all activities sent to the
bank's central computer.

From this top-level view we can extract the principal
activities of the system, and the external agents (people,
equipment) that are involved in those activities. These
activities are known as use cases and the
external agents are known as actors.

Actors may be people or machines. From a practical
standpoint it is worth knowing the stakeholder behind any
machine, since only they will be able to engage with the
requirements capture process.

Use cases should be significant activities for the
system. For example customer use of the ATM machine is a use
case. Entering a PIN number is not.

There is a gray area between these two extremes. As we
shall see it is often useful to break very large use cases into
smaller sub-use cases. For example we may have sub-use cases
covering cash deposit, cash withdrawal and account
inquiry.

There is no hard and fast rule. Some architects will
prefer a small number of relatively large use cases, others
will prefer a larger number of smaller use cases. A useful rule
of thumb is that any practical project ought to require no more
than about 30 use cases (if it needs more, it should be broken
into separate projects).

We then show the relationship between use cases and
actors on one or more use case diagrams. For a large project
more than one diagram will be needed. Usually groups of related
use cases are shown on one diagram.

We must then give a more detailed specification of each
use case. This covers its normal behavior, alternative
behaviors and any pre- and post-conditions. This is captured in
a document variously known as a use case
specification or use case
scenario.

Finally, since use cases are functional in nature, we
need a document to capture the non-functional requirements
(capacity, performance, environmental needs etc). These
requirements are captured in a document known as a
supplementary requirements
specification.

4.2.1. Process Steps

The steps in the requirements capture process can be
summarized as follows.

Capture an overall view of the problem, and the
desired characteristics of its solution in the
vision document.

Identify the use case and
actors from the vision document and
show their relationships on one or more use
case diagrams.

Give detailed use case
specifications for each use case, covering
normal and alternate behavior, pre- and
post-conditions.

Capture all non-functional requirements in a
supplementary requirements
specification.

In any iterative development process, we will
prioritize, and early iterations will focus on capturing the
key behavior of the most important use cases.

Most modern requirements capture processes agree that
it is essential that the authoritative representative of the
customer is fully involved throughout the process.