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

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 requirements ("top-level" requirements) that are to be elaborated in the AM system.
  2. AM user discovers the collection of requirements.
  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 requirements (f) in the RM system creating an elaborates relationship between each requirement and model element.
  7. AM user creates derived relationship between top-level requirements and the requirements resulting from the elaboration (g).


Postconditions

  1. Each top-level requirement in the requirement collection has trace relationship to 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.

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 37.7 K 26 Mar 2010 - 14:00 IanGreen elaboration
Edit | Attach | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r3 - 26 Mar 2010 - 14:03:32 - 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