Overview |  | Roles |  | Work Items |  | Views |  | CMMI |  | Index |  | Glossary |

Project Portal
| Requirement
### Work Item Database
Overview |
States and Transitions |
Fields |
### Process Guidance |
Activities |
Workstreams |
Requirement States and Transitions This diagram shows the state transitions for a requirement work item. 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, safety, security, 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 Proposed
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.
Investigate | A requirement is activated as Investigate if triage determines that an investigation of the impact is necessary before acceptance is given. Requirements marked Active for investigation should be returned to the Proposed state when the investigation is complete.
###### 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.
###### Active to Proposed
Postponed | A requirement is re-proposed as postponed if it will not be included in the current iteration, but may be in future iterations.
Investigation Complete | If the requirements was activated as Investigate it is returned to the Proposed state once the investigation is complete for re-triage.
# 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
Validation Test Passed | A requirement is closed as Validation Test Passed when the requirement is validated as successfully meeting customer expectations.
###### Resolved to Active
Validation Test Failed | A requirement is reactivated as Validation Test Failed 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 inadvertently closed.
Reintroduced in scope | A requirement is reactivated as Reintroduced in scope when it was closed as Out-of-scope, but conditions have changed and the requirement must be implemented.
© 2005 Microsoft Corporation. All rights reserved. MSF for CMMI Process Improvement: 1.00.0000.00 |