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

Project Portal
| Quality of Service Requirement
### Work Item Database
Overview |
States and Transitions |
Fields |
### Process Guidance |
Activities |
Work Streams |
Quality of Service Requirement Fields 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.
Field | Description
--- | ---
Title | Required. The title should be as descriptive as possible.
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.
Specified | Specified is a Yes or No value indicating if the quality of service requirement has been assigned to the development team. After the business analyst writes the scenario, this field should be set to Yes and the scenario should be assigned to a developer.
Exit Criteria | Exit Criteria is a Yes or No value indicating if the quality of service requirement is part of the exit criteria list. If this field is set to Yes, the requirement shows up on the project checklist.
Rank | Rank indicates how important the quality of service requirement is relative to all requirements for the software product. Valid values are 1 through 3.
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.
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.
(C) 2005 Microsoft Corporation. All rights reserved. Build 97 |