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

Project Portal
| Requirement
### Work Item Database
Overview |
States and Transitions |
Fields |
### Process Guidance |
Activities |
Workstreams |
Requirement Fields 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.
Field | Description
--- | ---
Title | Required. The title should be as descriptive as possible.
Area Path | The Area Path is used to group the requirement into an appropriate feature or team area. The area must be a valid node in the project hierarchy.
Iteration Path | The iteration in which the requirement is planned to be implemented in code.
Type | What kind of requirement this work item represents. Valid values are Scenario, QoS, Functional, Operational, or Interface.
Assigned To | The current person that the requirement is assigned to.
State | A requirement can be in the Proposed, Active, Resolved, or Closed states.
Reason | The reason a requirement is in the current state. For example, a requirement can be in the Closed state because validation tests passed.
Description | The description provides an area to describe the 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 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.
Subject Matter Experts | List of subject matter experts familiar with the problem area of the customer that this requirement represents (maximum of three).
Impact Assessment | A written explanation of what impact this requirement has if not implemented for the customer. Include details on the Kano model about whether this requirement is in the Surprise, Required, or Obvious categories.
Committed | Indicates if the requirement is committed in the project or not. The values for this field are Yes or No.
Priority | A subjective ranking of how important the requirement is to implement. Priority is used to determine the order in which requirements are implemented. Valid values are 1, 2, and 3.
Integrated In | The build number in which the requirement is integrated by the development team.
ID | The unique identifier used to identify the requirement. Team Foundation Server automatically creates the ID when the work item is created.
Attachments | Contains the files that have been linked to the requirement. For example, scenario requirements should include an attachment of the scenario description document.
User Acceptance Test | The status of the user acceptance test for this requirement. Valid values are Pass, Fail, Not Ready, Ready, or Skipped. Use Not Ready when the requirement is in the Active state. Use Ready when the requirement is in the Resolved state.
Created By | Identifies who created the requirement. This information appears in the History field and not in its own field.
Created Date | Identifies when the requirement was created. This information appears in the History field and not in its own field.
Changed By | Identifies the person who last made a change to the requirement.
Changed Date | Identifies the date the requirement was last changed.
Closed By | Identifies the person who closed the requirement.
Closed Date | Identifies the date the requirement was closed.
Triage | This field is used during the Proposed state. It provides sub-states for a requirement awaiting a triage decision. Valid values are Pending (default), More Info, Info Received, Triaged.
Estimate | An estimate in person hours to implement the requirement.
Remaining Work | An estimate in person hours of the work remaining to implement the requirement. This information appears on the Details tab.
Completed Work | An estimate in person hours of the time spent to date to implement the requirement. This information appears on the Details tab.
Blocked | Indicates if progress on implementing the requirement has been blocked. The values for this field are Yes or No. If an Issue work item has been opened to track the blocking problem, a link should be made to that work item as well.
Links | This field shows the other work items that have been linked to the requirement.
Resolved By | Identifies who resolved the requirement. This information appears in the History field and not in its own field.
Resolved Date | Identifies when the requirement was resolved. This information appears in the History field and not in its own field.
© 2005 Microsoft Corporation. All rights reserved. MSF for CMMI Process Improvement: 1.00.0000.00 |