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).

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.

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:

Requirement work item form

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 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 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 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:

  7. Choose Save Save Work Item.

    Note Note

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

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].

Note Note

The Requirements Overview and Requirements Progress reports require that you create links between requirements and tasks and between requirements and test cases.

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 Add New Linked Work Item New.

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

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

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

    The Add new Linked Work Item dialog box opens.

    Add new linked work item dialog box
  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:

  7. Choose Save 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 Add Links Link to.

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

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

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

    The Add Link to Requirement dialog box opens.

    Add link to requirement dialog box
  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.

    Link task to user story dialog box
  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 Save Work Item.

    Note Note

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

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 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 Paste or press CTRL-V to paste it.

    • Choose Add Attachment 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 Save Work Item.

To add a hyperlink to a Requirement

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

    Add hyperlink dialog box
  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 Save Work Item.

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

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 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

Requirement workflow

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft