Requirements capture is the process of identifying what the “customer” wants from the proposed system.

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 “customer”.

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 iterative process.

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

	Note
	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.