Requirement States and Transitions

Requirements capture and track what the product needs to do to solve the customer problem. There are several types of requirements: scenario, quality of service, functional, operational, and interface. As requirements are identified, they begin in the Proposed state. When a requirement is accepted for the current iteration, it moves to the Active state and is analyzed to create tasks to implement it. When the tasks are complete and system tests are passed showing that the requirement is successfully implemented, it moves to the Resolved state. Finally, when the requirement is validated, it is moved to the Closed state.

New

A new requirement work item can be created whenever a requirement is identified.

New to Active

New	A requirement is proposed as a New requirement when it is first created.

Proposed

A proposed requirement has been identified but is not being work on yet. Proposed requirements move to the Active state when they will be implemented in the current iteration. Requirements are closed if they are rejected.

Proposed to Active

Accepted

A requirement is activated as Accepted when triage approves the requirement to be implemented in the current iteration.

Proposed to Closed

Rejected

A requirement is closed as Rejected if triage determines that it cannot be implemented, or if it is no longer needed by the customer.

Active

An active requirement is currently being implemented. Tasks are created to write code, test, and document the requirement in the product. When the tasks are complete, the requirement moves to the Resolved state. A requirement can also be closed if it is split, abandoned, or determined to be out-of-scope.

Active to Resolved

Code Complete & System Test Passed

A requirement is resolved as Code Complete & System Test Passed when all code is implemented and all system tests pass for the requirement.

Active to Closed

Split	A requirement is closed as split when further review indicates that the requirement is too large, or that it needs more granular definition. When splitting a requirement, create the new requirements and link to them from the original requirement. The new requirements should be accepted as Active.
Abandoned	A requirement is resolved as abandoned if it is no longer deemed necessary to implement.
Out-of-scope	A requirement is resolved as Out-of-scope if it no longer makes sense to implement in the current version of the product. An out-of-scope requirement can later be reintroduced if circumstances change.

Resolved

A resolved requirement is implemented in code and passes system tests. Resolved requirements must be validated with the customer to ensure that the requirement is implemented according to customer expectations. If validation tests pass, the requirement is closed, otherwise it is reactivated for further work.

Resolved to Closed

Passed validation test

A requirement is closed as Passed validation test when the requirement is validated as successfully meeting customer expectations.

Resolved to Active

Failed validation test

A requirement is reactivated as Failed validation test if the validation test indicates that one or more customer expectations are not met. Further work must be done to address the problems which are documented as bugs.

Closed

A closed requirement is no longer being worked on. Requirements are closed when they are rejected, or when they are successfully implemented, verified, and validated.

Closed to Active

Closed in error	A requirement is reactivated as Closed in error if the requirement was inadvertantly closed.
Reintroduced in scope	A requirement is reactivated as Reintroduce in scope when it was closed as Out-of-scope, but conditions have changed and the requirement must be implemented.