Chapter 4.  Requirements Capture

Table of Contents

4.1. Introduction
4.2. The Requirements Capture Process
4.2.1. Process Steps
4.3. Output of the Requirements Capture Process
4.3.1. Vision Document
4.3.2. Use Case Diagram
4.3.3. The Use Case Specification
4.3.4. Supplementary Requirement Specification
4.4. Using Use Cases in ArgoUML
4.4.1. Actors Akteure
4.4.2. Use Cases
4.4.3. Associations
4.4.4. Hierarchical Use Cases
4.4.5. Stereotypes
4.4.6. Documentation
4.4.7. System Boundary Box
4.5. Case Study
4.5.1. Vision Document
4.5.2. Identifying Actors and Use Cases
4.5.3. Associations (To be written)
4.5.4. Advanced Diagram Features (To be written)
4.5.5. Use Case Specifications (To be written)
4.5.6. Supplementary Requirements Specification (To be written)

4.1.  Introduction

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