Title

Required. The title should be as descriptive as possible.

Area

The area is used to group the quality of service requirement into an appropriate feature or team area. The area must be a valid node in the project hierarchy.

Iteration

The iteration in which the quality of service requirement is implemented in code.

Type

There are five types of quality of service requirements: Load, Stress, Performance, Platform, Other, and Security.

Assigned To

The current person that the quality of service requirement is assigned to.

State

Required. A quality of service requirement can be in the Active, Resolved, or Closed states.

Reason

The reason a quality of service requirement is in the current state. For example, a requirement can be in the Closed state because it was Completed.

Description

The description provides an area to describe the quality of service requirement. Provide as much detail as possible to ensure a developer can implement the requirement, and that a tester can test the requirement.

History

This history is a running discussion about the quality of service requirement that accumulates additional written entries as changes are made. Each time a change is made to the requirement, an entry is made in the History field describing what change was made and why, as well as any additional pertinent information about the change.

Issue

Issue is a Yes or No value indicating if the scenario is blocked on progress. If this field is set to Yes, the scenario will display on the project manager’s issue report.

Exit Criteria

Exit Criteria is a Yes or No value indicating if the quality of service requirement is part of the iteration backlog. This field is used to synchronize the various views of the backlog (the scenario list, quality of service requirement list, and iteration plan). If the exit criteria field is set to Yes, the quality of service requirement displays in the project checklist query and work product. This field will be renamed to "iteration backlog" in a future release.

Rank

Rank indicates how important the quality of service requirement is relative to all requirements for the software product.

Integration Build

The Integration Build is the build number in which the requirement is integrated by the development team.

ID

The ID is the unique identification number assigned to the quality of service requirement.

Rough Order of Magnitude

The rough order of magnitude estimate is a measure of the complexity of the scenario or quality of service requirement. If the work item requires a half dozen or less 1-2 day development tasks to implement, choose 1. If the work item requires between a half dozen and a dozen 1-2 day development tasks to implement, choose 2. If it is larger than this, choose 3 and consider splitting the scenario or quality of service requirement.