Title

Required. The title should be as descriptive as possible.

Affected Area

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

Planned Iteration

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.

SME's

List of subject matter experts familiar with the problem area of the customer that this requirement represents. 

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 Must Have, Should Have, Could Have, and Won't Have.

In Build

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.

File Attachments

Links to files or other work items. For example, scenario requirements should include an attachment of the scenario description document.

UAT

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.

Changesets

Identifies the changesets which introduced the work resulting from implementing the requirement.

Created By

Identifies who created the requirement.

Created Date

Identifies when the requirement was created.

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.

Approved By

Identifies who approved the requirement for implementation.

Approved Date

Identifies when the requirement was approved for implementation.