Scenario B: A change request is satisfied

This scenario deals with the case where a request for enhancement first comes in from a change management system (as opposed to being first input in the requirements management system).

1. A change request is created to address some deficiency in the product. Some other process is responsible for establishing the nature of the change. Here we assume that a change to a requirement is identified.
2. A requirement is created to reflect that change request; a link between the change request and the requirement is created
3. The requirement is targeted for a certain sprint/milestone
   1. How the targeting is done is not relevant to this scenario, but one way to do so is via customized attribute groups
   2. If the requirement is planned for the next iteration, continue; otherwise, stop
4. Elaboration and/or refinement of the requirement and UI designs are requested
5. The requirement is updated to reflect this process
   1. If the elaboration is sufficient, continue
   2. If not, go through another round of clarifying the requirement
6. The change in the requirement is communicated to interested parties
   1. Any necessay updates to the linked change request can be made
7. The rest of the steps are the same as Scenario A

Post-conditions

• The requirement and change requests are either
  • Deferred, or
  • Completed (with all related test cases passing)