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.
-- TorgeKummerow - 08 Feb 2010

This is a real scenario so its maybe a bit messy:

1) We have a chaptered list of Customer Requirements. Those requirements don't have child requirements.

2) We create a new requirement document with the same chapters and derive System Requiremtns from the Customer requirements. The Customer Requirements are linked by links of the type <<derrived>> to the new System Requirements. The System requirements again don't have child requirements. They lie flat in their according chapters.

3) We import only the requirements, without the chapters into a System Modelling Tool.

4) We model those requirements with most likely blackbox model elements at this point of the project.

5) Each model element has to be linked to at least one requirement with the linktype <<satisfy>>.

6) We break down the requriements into several smaller requirements and link them together with the <<derived>> type in the modelling tool.

7) We export the model data and the new requirements back into the requirements management tool. The model data does not need to be complete, just as an human readable overview.

8) Each link between the previously imported requirements (step 3) and the model elements has to be reflected in the RM Tool.

9) The newly create equirements are put into a new requirements document with the same chapters as in step 1 . Again flat. Again linked to their originating requirements as <<derived>>

10) Now we can see if we missed any requirements, which is, if they are not linked to an imported model element and go back to the modelling tool in the case we did.

11) Now we have completed a round trip. We continue at step 3 with the new requirements document.

12) This goes on, until we have a completely defined and working system, where every element and behaviour is linked to one requirement that can be backtraced to a customer requirement


-----------------

Conclusion:

-We need tree like chapters(I geuss we have that with the bags)

-We need the possibility to link requirements to other requirements as well to any other object (RM -> RM we have, but I think its not possible to link RM -> ? or?)

-We need to have linktypes (We already agreed on that I guess)

-We need id's that identify each requirement to make it possible to "recognize" them again in any of the paritcipating tools. (We have that)

-We need a human readable documentation of the requirement implementation supporting any kind of data (images, pdf, text, doc, ...) [We talked about that once if I remember right. am not sure how it ended]

- Identifying unlinked requirements or model elements through Query

Topic revision: r3 - 22 Feb 2010 - 17:20:28 - IanGreen
Main.RmEADSTraceabilityScenario1 moved from Main.EADS_Traceability_Scenario_1 on 22 Feb 2010 - 17:20 by IanGreen - put it back
 
This site is powered by the TWiki collaboration platform 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