Capability Pattern: Requirements
This capability pattern covers the activities and workflow for the Requirements discipline.
DescriptionWork Breakdown StructureTeam AllocationWork Product Usage
Relationships
Description

To help explain the work involved in the Requirements discipline, the activities and work products are organized into a capability pattern for the discipline.

Each activity represents a high-level goal that needs to be achieved to perform effective requirements management. Analyzing the problem and understanding the stakeholders needs are the primary requirements goals during the Inception phase of a project. During the Elaboration and Construction phases, the emphasis shifts more towards initially defining and subsequently refining the system definition in terms of the detailed requirements. Managing the system scope and ongoing requirements change are addressed continuously throughout the project.

The workflow diagram, shown on the Work Breakdown Structure, shows the activities in a logical, sequential order. These activities are applied continuously in varied order, as needed, throughout the project. The Requirements discipline capability pattern sequences the activities in the order that you would most likely apply them in the first iteration of a new project.


 

Properties
Event-Driven
Multiple Occurrences
Ongoing
Optional
Planned
Repeatable
Usage
Usage Notes

Decide How to Perform the Workflow

The following decisions should be made regarding the Requirements discipline's workflow:

  • Decide how to perform the workflow by looking at the activities in this workflow. Study the diagram with its guard conditions. Decide which activities to perform and in which order.
  • Decide what parts of the Requirements activities to perform. The table below shows some parts that can be introduced relatively independently from each other.
  • Decide when, during the project lifecycle, to introduce each part of the workflow. As a general rule, the Requirements discipline should be introduced early in the project.
Part of workflow Comments
Use-Cases Some projects do not employ use-cases, which means that the project will not develop artifacts such as a Use-Case Model, Use-Case Package and Use Case. Instead use the Software Requirements Specification. 
Activity: Manage Changing Requirements This can be introduced after a few iterations in the project when there is a stable baseline.  

Document the decisions in the Development Case under a section dealing with the Requirements discipline.

More Information