RmRequirementElaboration < Main

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>RmTraceabilityScenarios>RmRequirementElaboration (22 Aug 2011, IanGreen) (raw view)

---+ Elaboration of requirements (RM/AM)

Preconditions
   1 RM and AM systems are configured so as to enable integration.
   1 RM and AM users have a means of communication (for example, email, tasking system etc.)
   1 A collection of requirements has been defined (a).

Scenario
   1 The RM user defines a requirement collection (b) which contains input requirements that are to be elaborated in the AM system.
   1 AM user discovers the collection of requirements 
      1 Alternative: the AM user uses OSLC delegated selection UI.
      1 Alternative: the AM user is informed of the collection by some other means.
   1 OPTIONAL: AM user creates a model element corresponding to the requirement collection with an _elaborates_ relationship them (c).
   1 For each requirement in the requirement collection, the AM user creates a model element (d) and an _elaborates_ relationship between the requirement and the model element (e). 
      1 Alternative: in general the correspondance will not be 1-to-1.
   1 AM user extends the model (e) during the process of modelling until the required level of elaboration has been acheived.
   1 AM user creates new derived requirements (f) in the RM system creating an _elaborates_ relationship between each requirement and model element (g).
   1 AM user creates _satisfaction_ relationship between top-level requirements and the requirements resulting from the elaboration (h).
   1 The modelling activity continues until each of the input requirements has a _satisfying_ derived requirement.

<br />Postconditions
   1 Each top-level requirement in the requirement collection has trace relationship to _satisfying_ derived requirements in the RM system.
   1 Each top-level requirement in the requirement collection has trace relationship to _elaborates_ model elements in the AM system.
   1 Each derived requirement is _satisfying_ at least one input requirement.
   1 Each input requirement is satisfied by at least one derived requirement.
   1 The satisfaction relationships are justified by the model which elaborates the input requirements.


Discussion

The traceability created in this scenario can be somewhat more complex than has been suggested here. For example, it is likely that cardinalities of relationships will other than one-to-one as has been shown here. The essence of the story is that derived requirements are obtained as a result of analysis. and that a modelling tool is used to support this analysis.

Questions:
   1 A requirement collection abstracts how the totality of the requirements to be elaborated is described ("scope of work"), but in fact this seems superflous to the scenario. It could be written without mention of collection, were it acceptable to deal with a single top-level requirement at a time.
   1 The use of collections enables reasoning about changes to the "scope of work" but there are no scenarios to address this.
   1 Does it make sense for a relationship between collections to distribute over the contents of things in those collections? For example, _elaborates_ between a requirement collection and a UML package.
   1 I would like to understand better the _derived_ relationship over requirements which are created by this scenario. I don't believe they are short-cuts and would like to highlight that somehow in the scenario.
   1 There are other inputs to the modelling - for example, the qualification strategy. Do we want/need to include that? It could left to the scenario preconditions.
   1 Modelling activites will in general also give rise to other, non-requirement artefacts, such as qualification requirements, as well as requirements which relate to other aspects of the system (for example, software, test equipment). Should we try to include these? I wanted the scenario to be reasonably focussed.
   1 The scenario is only the happy path: the post-conditions may be too strong?

Here is a picture of the resulting traceability:

<img width="758" alt="Elaboration" src="http://open-services.net/pub/Main/RmRequirementElaboration/Drawing1.png" title="Elaboration" height="820" />

Main.IanGreen - 22 Mar 2010

End user can use any kind of relationship - it is simply a _trace_ relationship.

eg rm tool makes certain relationships.

am tool wants to make links - rm tool provides list of supported relationships

currently think of "elaboration".

write reqs (high or low). these are elaborated (esp mdd). create am resource to capture the requirement. then these are "elaborated" - creates trace between rm and am "elaborates".

also. ea customers on am side use models to specify new requirements. - created as a result of modelling activity. eg business process optimizatoin. from business process model, create requirements describing automation of certain activities - these are _specification_ activies (requoirements specificed by AM EA resource).

we can provide support as first-class constructs. we would have elaboratedby and specifiedby. trace views to show these.

example - high-level req specs. certian characteristics. low level - concrete data objects, associations to other dataobjects

need to be tracked as requiremens themselves (textual/visual)

creating new requirement - in delegated UI - would you like to create relationship to some existing requirement? delegated UI could offer this ability.

Attachments

Topic attachments
I	Attachment	Action	Size	Date	Who	Comment
png	Drawing1.png	manage	38.3 K	26 Mar 2010 - 15:49	IanGreen	elaboration
ppt	Scenario.ppt	manage	494.0 K	03 May 2010 - 14:27	IanGreen	Torge's interpretation of the scenario

Topic revision: r6 - 22 Aug 2011 - 09:23:56 - IanGreen

Main

Webs
Main
Sandbox
TWiki

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