Activity: Define the System
This activity gains agreement on the scope of the system and outlines the key requirements.
Work Breakdown Structure
Purpose
The purpose of this activity is to begin converging on the scope of the high-level requirements by outlining the breadth of the detailed requirements for the system.
Description

This activity addresses:

The activities that focus on problem analysis and understanding stakeholder needs create early iterations of key system definitions including the features defined in the vision and a first outline of the detailed requirements. This activity, defining the system, focuses on identifying actors and use cases more completely by outlining their content (see Identify and Outline Requirements), as well as outlining the non-use-case-specific requirements in the System-Wide Requirements (see Detail System-Wide Requirements).

The Glossary is also refined as additional common terms are identified.

As you define new requirements, it is important to document any dependencies (e.g., Traceability) between these requirements (see Requirements Traceability).

Staffing

While it encourages team ownership and commitment to have all members of the project team participate in defining the system, this work is primarily coordinated and conducted by staff playing the Analyst role. Because this work often requires making tradeoff's between multiple requirements to make best use of the finite development resources, diplomacy, negotiation and mediation are important skills for the system analyst conducting this work.

Usage
Usage Guidance

This activity is primarily performed in iterations during the Inception and Elaboration phases, however it may be revisited as needed when managing scope and responding to changing requirements, as well as other changes in the project conditions.

Key Considerations

It should be noted that activities being performed in this capability pattern are not performed in sequence.  In fact, it is more-often the case that these activities are performed concurrently. For example, while identifying actors and use cases (Identify and Outline Requirements), we may encounter requirements that do not naturally align with a particular use case, in which case the requirement may be defined in the Supplementary Specifications (Detail System-Wide Requirements). Conversely, while identifying non-use-case-specific requirements (e.g., system-wide requirements), we may encounter requirements that only apply to a particular use case, in which case the requirement is associated with the use case.

Work Breakdown