Requirement (CMMI)

You can learn how to fill in the details of a requirement work item in this topic. A requirement communicates functionality that is of value to the customer of the product or system. Each requirement should briefly state what a user wants to do with a feature of the software and describe it from the user's perspective. For more information, see Planning the Project (CMMI).

For information about how to create this type of work item, see Work Items and Workflow (CMMI).

In this topic

Related topics

Defining a Requirement Linking a Requirement to Other Work Items Adding Details, Attachments, or Hyperlinks to a Requirement Changing the State of a Requirement

Process Guidance Planning the Project (CMMI) Arranging Requirements into a Product Plan Verifying Requirements Workbooks Triage Workbook (CMMI) Dashboards and Reports Progress Dashboard (CMMI) Requirements Overview Report (CMMI) Requirements Progress Report (CMMI) Field Reference Titles, IDs, Descriptions, and History Field Reference Assignments and Workflow Field Reference Planning, Ranking, and Priorities Field Reference Effort, Schedules, and Tracking Work Field Reference Requirement Field Reference (CMMI) Areas and Iterations Field Reference Link Controls, Restrictions, and Field Reference Attachment Controls and Field Reference

Required Permissions

To view a requirement, you must be a member of the Readers group or your View work items in this node must be set to Allow. To create or modify a requirement, you must be a member of the Contributors group or your Edit work items in this node permissions must be set to Allow. For more information, see Managing Permissions.

Defining a Requirement

When you write a requirement, you should focus on who the feature is for, what they want to accomplish, and why. You should avoid descriptions that specify how the feature should be developed.

When you create a requirement, you must specify only the title. However, you can further define the Requirement by specifying a variety of other kinds of information, as the following illustrations show:

When you define a requirement, you must define the Title. You can leave all other fields blank or accept their default values.

To define a requirement

1. In Title (required), type a short description.

   Good Requirement titles reflect the value to the customer or functionality that the team must implement.

2. In the right section of the work item form, specify one or more of the following types of information:

   • In the Assigned To list, choose the name of the team member who owns the Requirement.

     Note

     You can assign work items only to members of the Contributors group.

     If you leave the requirement unassigned, it is automatically assigned to you.

   • In the State list, leave the default value, Proposed. In the Reason list, leave the default value, New.

     For more information about the State field and how you use it to track workflow, see Changing the State of a Requirement later in this topic.

   • In the Priority list, choose the level of importance for the Requirement on a scale of 1 (most important) to 4 (least important).

   • In the Triage list, choose the triage substate.

     Valid values are Pending (default), More Info, Info Received, and Triaged. This field identifies a level of triage for requirements that are in the Proposed state.

   • In the Blocked list, choose Yes if an issue is blocking progress toward the implementation of the Requirement.

   • In the Committed list, choose Yes if a commitment has been made to implement the Requirement.

   • In the Area and Iteration lists, choose the appropriate area and iteration.

     Note

     The project administrator for each team project defines area and iteration paths for that project so that the team can track progress by those designations. For more information, see Create and Modify Areas and Iterations.

   • In Type, choose the type of requirement that you are defining.

     The default value is Functional.

3. On the DESCRIPTION tab, describe the requirement and the criteria that the team will use to verify whether it has been fulfilled.

   You should provide as much detail as necessary to ensure that a developer can implement the Requirement and that a tester can test the requirement.

   Your team will use this information to create work items for tasks and test cases. For more information, see Task (Agile) and Test Case.

4. On the ANALYSIS tab, describe the impact to the customer if the requirement is not implemented.

   You might want to include details on the Kano model about whether this Requirement is in the Surprise, Required, or Obvious categories.

5. On the OTHER tab, specify the following types of information:

   • Under Subject Matter Experts, choose the names of up to three team members who are familiar with the problem area and expectations that the customer has for this requirement.

   • In the Original Estimate box, type a number that represents the hours of work that the requirement might take to implement.

     Note

     In general, you define the following two fields later in the development cycle and not when you first define the requirement.

   • In the Integrated in list, choose the name or number of the build in which the development team has integrated the requirement.

   • In the Test list, choose the status of the user acceptance test for this Requirement.

     Valid values are Pass, Fail, Not Ready, Ready, or Skipped. You should specify Not Ready when the requirement is in the Active state and Ready when the requirement is in the Resolved state.

6. On the Implementation, Change Requests, Test Cases, and All Links tabs, you can create links from the requirement to other work items, such as tasks, change requests, test cases, bugs, and issues.

   On the Attachments tab, you can attach specifications, images, or other files that provide more details about the Requirement to be implemented.

   For more information, see the following sections later in this topic:

   • Linking the Requirement to Other Work Items

   • Adding Details, Attachments, or Hyperlinks to a Requirement

7. Choose Save Work Item.

   Note

   After you save the requirement, the identifier appears in the title under the work item toolbar.

Linking a Requirement to Other Work Items

By creating relationships between requirements and other work items, you can plan projects more effectively, track dependencies more accurately, view hierarchical relationships more clearly, and find relevant information more quickly. From the work item form for a Requirement, you can create a work item that is automatically linked to the Requirement, or you can create links to existing work items.

You use the Implementation, Change Requests, Test Cases, and All Links tabs to create links for specific types of work items and specific types of links. For more information about the restrictions for each tab, see Linking Work Items [CMMI].

To create a task, bug, change request, test case, or other work item and link it to a requirement

1. Open the work item form for the requirement, and perform one of the following actions:

   • To create and link to a task, bug, or sub-requirement, choose the Implementation tab, and then choose New.

   • To create and link to a change request, choose the Change Requests tab, and then choose New.

   • To create and link to a test case, choose the Test Cases tab, and then choose New.

   • To create and link to any other type of work item, choose the All Links tab, and then choose New.

   The Add new Linked Work Item dialog box opens.

   

2. In the Link Type list, leave the default value, or choose one of the following options:

   • To link to a task, a bug, or a sub-requirement, choose Child.

   • To link to a change request, choose Affected By.

   • To link to a test case, choose Tested By.

   • To link to any other type of work items, choose Related or another type of link that represents the relationship that you want to track.

3. In the Work Item Type list, choose the type of work item that you want to create.

4. In Title, type a short but specific description of the work to be performed.

5. (Optional) In Comment, type additional information, and then choose OK.

   A work item form for the type of work item that you specified opens with the information that you have provided.

6. Specify the remaining fields as the following topics describe:

   • Task (CMMI)

   • Bug (CMMI)

   • Change Request (CMMI)

   • Test Case

   • Issue (CMMI)

   • Risk (CMMI)

   • Review (CMMI)

7. Choose Save Work Item.

To link several existing work items to a requirement

1. Open the work item form for the requirement, and perform one of the following actions:

   • To link to one or more tasks, bugs, or sub-requirements, choose the Implementation tab, and then choose Link to.

   • To link to one or more change requests, choose the Change Requests tab, and then choose Link to.

   • To link to one or more test cases, choose the Test Cases tab, and then choose Link to.

   • To link to one or more work items of other types, choose the All Links tab, and then choose Link to.

   The Add Link to Requirement dialog box opens.

   

2. In the Link Type list, leave the default value, or choose one of the following options:

   • To link to a task, a bug, or a sub-requirement, choose Child or Parent.

   • To link to a change request, choose Affected By.

   • To link to a test case, choose Tested By.

   • To link to any other type of work item, choose Related or another type of link that represents the relationship that you want to track.

3. Choose Browse.

   The Choose Linked Work Items dialog box appears.

   

4. Type the items in Work item IDs, or browse for the items to which you want to link.

   You can also run a team query to locate the work items to which you want to link. These queries include Active Bugs, Change Requests, Open Tasks, Open Test Cases, and Open Tasks.

5. Select the check box next to each work item that you want to link to the Requirement.

   For more information, see Find Work Items to Link or Import.

6. (Optional) Type a description for the work items to which you are linking.

7. Choose OK, and then click Save Work Item.

   Note

   Both the requirement and the work items to which you linked it are updated.

Adding Details, Files, and Hyperlinks to Requirements

You can add details to requirements in the following ways:

• On the Details tab, type information in the Description field or the History field.

• Attach a file.

  For example, you can attach an e-mail thread, a document, an image, a log file, or another type of file.

• Add a hyperlink to Web site or to a file that is stored on a server or a Web site.

To add details to a Requirement

1. Choose the Details tab, and, in History, add comments that you want to capture as part of the historical record.

   Every time that a team member updates the work item, its history shows the date of the change, the team member who made the change, and the fields that changed.

   You can format information to provide emphasis or capture a bulleted list. For more information, see Requirement Field Reference (CMMI).

2. Choose Save Work Item.

To attach a file to a Requirement

1. On the Attachments tab, perform one of the following actions:

   • Drag a file into the attachment area.

   • Copy a file, and then choose or press CTRL-V to paste it.

   • Choose Add, and then choose Browse. In the Attachment dialog box, type the name or browse to the file that you want to attach.

     (Optional) In the Comment box, type more information about the attachment.

     To close the Attachment dialog box, choose OK.

2. Choose Save Work Item.

To add a hyperlink to a Requirement

1. On the All Links tab, choose Link to.

   

2. In the Link Type list, choose Hyperlink.

3. In the Address box, type the address of the target of the link.

   If the target is a Web site, type the URL, or copy it from your Internet browser and paste the URL into the Address box. If the target is a server location, type the address in the form of a UNC name.

4. (Optional) In the Comment box, type more information about the hyperlink.

5. Choose OK, and then choose Save Work Item.

Changing the State of a Requirement

A team can track the progress of a requirement by setting its State field to one of the following values:

• Proposed

• Active

• Resolved

• Closed

When you create a requirement, it is in the Proposed state by default. When the team accepts a requirement for the current iteration, the team moves the work item to the Active state and creates tasks to implement it. When the team completes the Tasks and system tests show that the team has successfully implemented the requirement, the team moves it to the Resolved state. Finally, when the team validates the requirement, the team moves it to the Closed state.

Any team member can change the state of a requirement.

For more information about the data fields that you can use to track work item states, see Assignments, Workflow, and Planning (CMMI).

To change the state of a requirement

1. Open the work item form for the requirement.

2. In the State list, choose Active, Resolved or Closed.

   • If you change the state from Proposed to Active, the Reason field automatically changes to Accepted.

   • If you change the state from Active to Resolved, the Reason field automatically changes to Code Complete and System Test Passed.

   • If you change the state from Resolved to Closed, the Reason field changes to Pass Validation Test.

   • If you change the state from Active to Closed, you should choose an option that matches your intent in the Reason list.

     Valid options are Split (default), Abandoned, and Out-of-Scope.

3. Choose Save Work Item.

Typical workflow progression: A team member creates a requirement in the default state, Proposed, with the default reason, New. A team member changes the state from Proposed to Active with the default reason, Accepted. A team member changes the state from Active to Resolved when the requirement is code complete and system tests have passed. A team member changes the state from Resolved to Closed when the requirement is validated as successfully meeting customer expectations. Atypical transitions: A team member changes the state from Proposed to Closed with the default reason, Rejected. A team member changes the state from Active to Proposed with the default reason, Investigated. A team member determines that the requirement is not relevant or out of scope and changes the state from Active to Closed. A validation test for the requirement fails. Therefore, a team member changes the state from Resolved to Active. A team member determines that the requirement was closed in error or is now in scope and changes the state from Closed to Active.

Requirement State Diagram

Proposed (New)

The following data fields are automatically captured when a team member creates a requirement:

• Created By: Name of the team member who created the requirement.

• Created Date: Date and time when the requirement was created, as recorded by the server clock.

From Proposed to Active

A team member can change the state of a requirement from Proposed to Active for the reasons that the following table describes:

Reason	When to use	Additional actions to take
Accepted	When the triage committee approves the requirement for implementation in the current iteration.	Assign the requirement to the team member who will implement it.
Investigate	When the triage committee determines that the team must investigate the customer impact before the committee will decide whether the team should implement the requirement.	Return the requirement to the Proposed state when the investigation is complete.

The following data fields are captured when a team member changes the state of a requirement to Active:

• Activated By: Name of the team member who activated the requirement.

• Activated Date: Date and time when the requirement was activated, as recorded by the server clock.

• State Change Date: Date and time when the state of the requirement was changed.

From Proposed to Closed

A team member can close a requirement that is in the Proposed state because of the reason that the following table describes:

Reason	When to use	Additional actions to take
Rejected	When the triage committee determines that the team cannot implement the requirement or the customer no longer needs it.	None.

The following data fields are captured when a team member closes a Requirement:

• Closed By: Name of the team member who closed the Requirement.

• Closed Date: Date and time when the Requirement was closed, as recorded by the server clock.

• State Change Date: Date and time when the state of the Requirement was changed.

Active

The team should implement only those requirements that are in the Active state. For active requirements, team members should create tasks for writing code, testing, and documenting the requirement. When all tasks are complete, the requirement moves to the Resolved state. A team member can also close a requirement if it is split, abandoned, or determined to be out of scope.

From Active to Resolved

A team member can resolve an active requirement for the reason that the following table describes:

Reason	When to use	Additional actions to take
Code Complete and System Test Passed	When the team checks in code to implement a requirement and all system tests have passed.	Assign the requirement to the team member who will test it.

The following data fields are captured when a team member resolves an active requirement:

• Resolved By: Name of the team member who resolved the requirement.

• Resolved Date: Date and time when the requirement was resolved, as recorded by the server clock.

• State Change Date: Date and time when the state of the requirement was changed.

From Active to Closed

A team member can close an active requirement because of one of the reasons that the following table describes:

Reason	When to use	Additional actions to take
Split (default)	When the requirement is too large or needs more precise definition.	Create one or more additional requirements, and link to them from the original requirement. The new requirements should be accepted as Active.
Abandoned	When the team no longer needs to implement the requirement.	None.
Out of Scope	When the team has insufficient time to implement the requirement for the current iteration or has discovered blocking issues.	Specify in which iteration the Requirement might be implemented. If the requirement is deferred to the next release of the software, leave the Iteration field blank, but describe in detail why the requirement was deferred and when the team should implement it.

The following data fields are captured when a team member closes an active requirement:

• Closed By: Name of the team member who closed the requirement.

• Closed Date: Date and time when the requirement was closed, as recorded by the server clock.

• State Change Date: Date and time when the state of the requirement was changed.

From Active to Proposed

A team member can change the state of an active requirement to Proposed because of one of the reasons in the following table:

Reason	When to use	Additional actions to take
Postponed	When the team will not implement the requirement in the current iteration but might in a future iteration.	None.
Investigation Complete (default)	When the team has investigated the requirement and is resubmitting it for triage.	None.

The following data fields are captured when a team member closes an active requirement:

• Changed By: Name of the team member who changed the state of the requirement.

• State Change Date: Date and time when the state of the requirement was changed.

Resolved

After a requirement has been implemented in code and passes system tests, the lead developer sets its state to Resolved and assigns the requirement to a tester. The tester then validates whether it has been implemented according to customer expectations. If it has, the tester closes the requirement. If it has not, the tester reactivates it for further work.

From Resolved to Closed

A team member can close a resolved requirement for the reason that the following table describes:

Reason	When to use	Additional actions to take
Validation Test Passed	When the requirement passes all validation tests that are associated with it.	Assign the requirement to the product owner.

The following data fields are automatically captured when a team member closes a resolved requirement:

• Closed By: Name of the team member who closed the requirement.

• Closed Date: Date and time when the requirement was closed, as recorded by the server clock.

• State Change Date: Date and time when the state of the requirement was changed.

From Resolved to Active

A team member can reactivate a resolved Requirement for the reason that the following table describes:

Reason	When to use	Additional actions to take
Validation Test Failed	When the validation test indicates that the requirement does not meet one or more customer expectations.	Document the problems as bugs, and assign the requirement to the lead developer.

The following data is automatically captured when a team member reactivates a resolved requirement:

• Activated By: Name of the team member who reactivated the requirement.

• Activated Date: Date and time when the requirement was reactivated, as recorded by the server clock.

• State Change Date: Date and time when the state of the requirement was changed.

Closed

The team should no longer work on any requirement that has been closed because it was rejected or successfully implemented, verified, and validated.

The team can reactivate a closed requirement if it comes back into scope. Usually a business analyst or program manager reactivates a closed Requirement.

From Closed to Active

A team member can reactivate a closed requirement for the reasons that are described in the following table:

Reason	When to use	Additional actions to take
Reintroduced in Scope	When resources have become available to implement the requirement.	Make sure that the implementation tasks, test cases, and details that have been defined for the requirement are complete and up to date.
Closed in error	When a requirement was accidentally closed.	Make sure that the implementation tasks, test cases, and details that have been defined for the requirement are complete and up to date.

The following data is automatically captured when a team member reactivates a closed requirement:

• Activated By: Name of the team member who reactivated the requirement.

• Activated Date: Date and time when the requirement was reactivated, as recorded by the server clock.

• State Change Date: Date and time when the state of the requirement work item was changed.

See Also

Concepts

Artifacts (CMMI)

Storyboard Backlog Items

Engage Stakeholders through Continuous Feedback

Work Item Field Reference for Visual Studio ALM

Other Resources

Work Items and Workflow (CMMI)