Scenarios

Scenario 1: Rapid prototyping

Comment: This scenario shows the need to revert not just a single item to a specific earlier version, but also all its related items.

Scenario:

1. Needs are identified
2. Requirements are extracted
3. Requirements get formalised
4. Prototype 1 is being developed and validated
5. Needs and/or requirements are refined according to prototype tests
6. Redo steps 2 & 3
7. Prototype 2 is constructed
8. Alternative A: Prototype 2 is too complicated. Start over with prototype 1
9. Alternative B: A different product line is build upon Prototype 1
10. Reverting/copying requirements and needs as well.

Scenario 2: RM Scenario in distributed projects

1. Each team specifies its textual requirements in NON-RM Tools (e.g. Word, Excel)
2. Requirements get collected and synchronized with an RM tool frequently (e.g. DOORS)
3. Duplicates are beeing removed
4. Requirements get formalized to be unambiguous and checkable (e.g. SCADE)
5. Requirements get managed: formalized version gets linked to textual version (E.g. through the OSLC service or RTP developed in CESAR)
6. Requirements get validated by formal verification and syntactic checks (e.g. RTP)
7. Test cases get generated for validation through simulation

Post-Condition:

Requirements can be managed and tested at any time in the project.

Scenario 3: Security

1. Requirements get published to a centralized repository
2. Security policy changes
3. Requirements get permanently deleted from centralized repository without disturbing the other repository resources.

Post-Condition:

No security violation due to openly accessable backups/archivesof those elements

Scenario 4: Visualization

Pre-condition:

The requirements are already managed and the implementation phase has begun.

The requirements got linked to the implemented parts.

The requirements are linked to problem reports if any.

The implemented parts can be visualized and identified in the visualisation in some way (e.g. CAD or Blue Prints)

Scenario:

1. The requirements are blend over the implementation visualization.
2. Areas of low requirement coverage are identifed and handled
3. Areas with problematic requirements are identifed and handled

Post-Condition:

Problematic project parts can be handled and identiefied easier and earlier.