Requirements capture is the process of identifying what
the “customer” wants from the proposed
The key at this stage is that we are in the problem
domain. At this stage we must describe everything from the
“customer” perspective and in the language of the
The biggest risk we have in requirements capture is to
start thinking in terms of possible solutions. That must wait
until the Analysis Phase (see
Chapter 5, Analysis). One of the steps of the
Analysis Phase will be to take the output of the Requirements
Phase and recast it in the language of a deemed solution.
Remember we are using both a
incremental, and an
We may well come back to the requirements process again
as we break down the problem into smaller chunks, each of which
must have its requirements captured.
We will certainly come back through the requirements
phase on each iteration as we seek to define the requirements
of more and more of the system
The only part of the requirements notation specified by
the UML standard is the use case diagram. The remainder is
process specific. The process described in this chapter draws
heavily on the Rational Unified Process.