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:

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.