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.

Elaboration of requirements (RM/AM)

Preconditions

  1. RM and AM systems are configured so as to enable integration.
  2. RM and AM users have a means of communication (for example, email, tasking system etc.)
  3. 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.
  2. AM user discovers the collection of requirements
    1. Alternative: the AM user uses OSLC delegated selection UI.
    2. Alternative: the AM user is informed of the collection by some other means.
  3. OPTIONAL: AM user creates a model element corresponding to the requirement collection with an elaborates relationship them (c).
  4. 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.
  5. AM user extends the model (e) during the process of modelling until the required level of elaboration has been acheived.
  6. AM user creates new derived requirements (f) in the RM system creating an elaborates relationship between each requirement and model element (g).
  7. AM user creates satisfaction relationship between top-level requirements and the requirements resulting from the elaboration (h).
  8. The modelling activity continues until each of the input requirements has a satisfying derived requirement.


Postconditions

  1. Each top-level requirement in the requirement collection has trace relationship to satisfying derived requirements in the RM system.
  2. Each top-level requirement in the requirement collection has trace relationship to elaborates model elements in the AM system.
  3. Each derived requirement is satisfying at least one input requirement.
  4. Each input requirement is satisfied by at least one derived requirement.
  5. 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.
  2. The use of collections enables reasoning about changes to the "scope of work" but there are no scenarios to address this.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. The scenario is only the happy path: the post-conditions may be too strong?

Here is a picture of the resulting traceability:

Elaboration

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.

Topic attachments
I Attachment Action Size Date Who Comment
pngpng Drawing1.png manage 38.3 K 26 Mar 2010 - 15:49 IanGreen elaboration
pptppt 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
 
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