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