This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
RmHome
>
RmScenarios
>
RmScenariosEADS
(01 Jul 2009,
TorgeKummerow
)
(raw view)
-- Main.TorgeKummerow - 30 Jun 2009 ---++++ 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 1 Requirements are extracted 1 Requirements get formalised 1 Prototype 1 is being developed and validated 1 Needs and/or requirements are refined according to prototype tests 1 Redo steps 2 & 3 1 Prototype 2 is constructed 1 *Alternative A*: Prototype 2 is too complicated. Start over with prototype 1 1 *Alternative B*: A different product line is build upon Prototype 1 1 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) 1 Requirements get collected and synchronized with an RM tool frequently (e.g. DOORS) 1 Duplicates are beeing removed 1 Requirements get formalized to be unambiguous and checkable (e.g. SCADE) 1 Requirements get managed: formalized version gets linked to textual version (E.g. through the OSLC service or RTP developed in CESAR) 1 Requirements get validated by formal verification and syntactic checks (e.g. RTP) 1 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 1 Security policy changes 1 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* <br /> *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. 1 Areas of low requirement coverage are identifed and handled 1 Areas with problematic requirements are identifed and handled *Post-Condition:* Problematic project parts can be handled and identiefied easier and earlier.
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r2
<
r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r2 - 01 Jul 2009 - 09:07:24 -
TorgeKummerow
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback