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.

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 and requirement Type (which is defaulted to 'Functional'). 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 the top section of the work item form, specify one or more of the following types of information:

  2. On the Details 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 use cases, tasks and test cases. For more information, see Task (GovDev) and Test Case (GovDev).

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

  4. On the Use Cases and Change Requests tabs, you can create links from the requirement to related use cases and change requests.

    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:

  5. Click Save Save Work Item.

    NoteNote

    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 Use Cases, and Change Requests 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 (GovDev).

NoteNote

The Requirements Traceability and Requirements Progress reports require that you create links between requirements and use cases.

To create a use case and link it to a requirement

  1. Open the work item form for the requirement, and click the Use Cases tab and then click Add New Linked Work Item New.

    The Add new Linked Work Item dialog box opens.

     

    Add new linked use case dialog box
  2. In the Link Type list, leave the default value of Child as it is the only choice for linking of a use case.

  3. In the Work Item Type list, leave the default value of Use Case as it is the only allowed choice.

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

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

    A work item form for the use case opens with the information that you have provided.

  6. Specify the remaining fields as described in Use Case (GovDev).

  7. Click Save Save Work Item.

  8. Use a similar apporoach to create and link a change request to the requirement.

Adding Details and Attachments to Requirements

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:

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 and Workflow (GovDev).

To change the state of a requirement

  1. Open the work item form for the requirement.

  2. In the State list, click 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 click an option that matches your intent in the Reason list.

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

  3. Click 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

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

See Also