Quality of Service Requirement States and Transitions
The states of a quality of service work item. Quality of service requirements document characteristics of the system such as performance, load, availability, stress, accessibility, serviceability, and maintainability. These requirements usually take the form of constraints on how the system should operate.
New
Quality of service requirements can be created in the quality of service requirements list found in the requirements folder in the document library or by using the new work item menu in Team Explorer.
New to Active
|
New |
A quality of service requirement is activated as a new requirement when it is first created. |
Active
Quality of service requirements begin in the active state. The business analyst creates the requirement, provides a descriptive title, and fills in the description field with as much detail as possible about the requirement.When the requirement is fully written, the business analyst assigns it to a lead developer. The Specified field is set to Yes and the requirement remains in the active state while it is being implemented. The lead developer coordinates efforts with other developers to implement the requirement.
Active to Resolved
|
Completed |
A quality of service requirement is resolved as Completed when the development team completes writing code for the requirement. The lead developer assigns the requirement to a tester. |
|
Deferred |
A quality of service requirement is resolved as Deferred if it cannot be implemented in the current iteration. A requirement could be deferred because the team does not have enough time, or because blocking issues were discovered. Update the Iteration field to the correct iteration in which the requirement will be implemented. If the requirement is deferred to the next software product release version, leave the Iteration field blank. Be sure to include a detailed description of why the requirement was deferred, and when it is planned to be implemented. |
|
Removed |
A quality of service requirement is resolved as Removed if it is no longer deemed necessary to implement. When removing a requirement, check the Issue, and Exit Criteria fields. Typically these fields should be set to No for a removed quality of service requirement. |
Resolved
When the quality of service requirement is implemented in code, the lead developer sets the state to Resolved. The lead developer also assigns the requirement to a tester so that testing can begin.
Resolved to Closed
|
Completed |
A quality of service requirement is closed as Completed when the tester indicates that it has passed its tests. When completing a requirement, check the Issue, and Exit Criteria fields. Typically these fields should be set to No for a completed quality of service requirement. |
|
Deferred |
A quality of service requirement is closed as Deferred because it could not be implemented in the current iteration. |
|
Removed |
A quality of service requirement is closed as Removed because it is no longer deemed necessary to implement. |
Resolved to Active
|
Test Failed |
A quality of service requirement is returned to the active state if it fails one or more tests. The tester must reassign it to the original lead developer. Also, the tester should create appropriate bugs for the test failures. |
Closed
The tester closes a quality of service requirement if it passes its tests. A requirement is also closed if it is Deferred, Removed, or Split into more requirements.
Closed to Active
|
Reactivated |
A deferred quality of service requirement is reactivated when its assigned iteration begins. If the requirement must still be written, assign it to a business analyst. If the requirement is ready to be implemented, assign it to a lead developer. If a removed requirement is reactivated, follow the same process as for a deferred requirement. | | 
