-- RainerE - 29 Jun 2009

additional scenarios for future versions

Scenario S1: Define Requirements Baseline
this is basically the Scenario that lead to the precondition of Scenario A

Pre-condition: A set of stakeholder requests exists and are ready to be evaluated for a new product or product release

Scenario:

1. Perform candidate Review
2. Identify dependant Requirements and create a semantic link between them
   (e.g. “cannot live without …”, “mutually exclude ..”, “has impact on …”
3. Decision to assign it to a release (e.g. including digital signature)
4. Prioritization
5. Generate Baseline Report
6. Review and finalize the Baseline

---

Scenario S2: Requirements Refinement
Similar to Scenario A, but does not yet lead to work packages, but to a decomposition of Requirements regarding different concerns; e.g. HW, SW, different system parts, etc. This is necessary for larger System s

Scenario:

1. refinement into sub requirements
2. assign sub requirements to area of concern

Post-condition:

whenever such a sub requirement gets assigned to a base line, verify that parent and sister Requirements are handled correctly

---

Scenario S3: Requirements Uniqueness

Combine Requirements which are similar or duplicates

Scenario:

1. Check stakeholder requests for similar and/or duplicate entries
2. Mark duplicates and associate them to primary request
3. For similar requests, create parent with combined functionality and add requests as child

---

Scenario S4: Customer Interaction

Customer input is typically captured in a CRM, Help Desk, or Support Center system; Input could be a complain/defect, request for enhancement or new product idea

(pre-condition of Scenario B);

Pre-condition: A customer input is logged in a CRM system, analyzed by the “field” team and considered to be relevant for product improvement

Scenario:

1. “field” team creates a Requirement in the RM system (including necessary data for the product improvement process and the ID of the customer input)
2. if Requirement is unclear, request more information via CRM system
3. On specific actions in the RM System triggers an update of the associated information in the CRM system
   e.g. “planned for product release”; “no plan to implement”, “released with version x of product y”

---

Scenario S5: Impact Analysis (Cost Estimation)

Before a Requirement can be decided on (e.g., added to a baseline) it requires a technical evaluation regarding impact and costs

Scenario:

1. Select Requirements which need impact analysis
2. Create one or more taks for impact analysis and assign it to a person/role
3. Assignee analyzes the impact, estimates cost and logs it with the task
4. Impact information of impact analysis tasks are (automatically) aggregated and added to the Requirement
5. Impact Analysis information is used in Scenario “Create Baseline”

---

Scenario S6: Stakeholder Management

Stakeholders should be managed in the RM system in order to associate them with the requirements
(Similar use cases for other Artifacts in Lifecyle: Products, Components, Roles,

Scenario:

1. add Stakeholder
2. remove Stakeholder
3. modify Stakeholder