Book a Demo

Author Topic: requirements architecture traceability  (Read 8498 times)

bholey

  • EA Novice
  • *
  • Posts: 9
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
requirements architecture traceability
« on: July 31, 2005, 04:32:04 pm »
Hi
I am trying to provide requirements to architecture traceability on a fairly large project.

I have a well defined component model. I noticed that under component model - properties I can add requirements the component addresses. This is good. However when I generate documentation for the component model, the documentation does not contain any requirements information.

Is there a different way to map requirements to architecture.

I was hoping that as part of document generation I would get a table stating components --> requirements mapping.

any suggestions.


regards
bholey

bholey

  • EA Novice
  • *
  • Posts: 9
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
Re: requirements architecture traceability
« Reply #1 on: July 31, 2005, 09:13:13 pm »
As an afterthought perhaps requirements ---> sub-system traceability is perhaps more appropriate in terms of architecture traceability.

would packages be the equivalent of sub-systems.

In any case would be happy to hear how others are
providing requirements to architecture traceability.


Thanks
Bholey

thomaskilian

  • Guest
Re: requirements architecture traceability
« Reply #2 on: August 01, 2005, 04:00:12 am »
Some time ago I came to the conclusion to use Requirement elements from the toolbox, place them in structured packages and relate them (via the Relationship Matrix) with the appropriate element. In that way I'm able to adorn each Requirement with Tags to carry information I need (e.g. Resposible, etc.). I also have written a few macros to check consitency and trace changes of Requirements.

There is also an EA based tool called Raquest which you might test (I'm quite happy with my solution, so I can't tell much about it).

Regarding subsystems: you can stereotype a package as <<subsystem>>.
« Last Edit: August 01, 2005, 04:02:05 am by thomaskilian »

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: requirements architecture traceability
« Reply #3 on: August 01, 2005, 04:08:17 pm »
Quote
Some time ago I came to the conclusion to use Requirement elements from the toolbox, place them in structured packages and relate them (via the Relationship Matrix) with the appropriate element. In that way I'm able to adorn each Requirement with Tags to carry information I need (e.g. Resposible, etc.). I also have written a few macros to check consitency and trace changes of Requirements.

There is also an EA based tool called Raquest which you might test (I'm quite happy with my solution, so I can't tell much about it).

Regarding subsystems: you can stereotype a package as <<subsystem>>.
To echo Thomas's points.  Somewhere else, the Sparxians conceded that it is best to see the Element based requirements as responsibillities - which ties in very nicely with the CRC view of Classes and makes it clearer why they aren't more globally visible.  Also, as part of EA's unique UI, they are actually denoted as responsibilities on some dialogs...

HTH,
Paolo
« Last Edit: August 01, 2005, 04:09:21 pm by PaoloFCantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

fwoolz

  • EA User
  • **
  • Posts: 435
  • Karma: +0/-0
  • We have met the enemy, and he is us.&lt;Pogo, 1970&gt;
    • View Profile
Re: requirements architecture traceability
« Reply #4 on: August 04, 2005, 10:31:38 am »
Another "aye" vote with Thomas & Paolo for using requirement elements where traceability is needed. [I just so happen to be working on a model right now with several hundred requirements (from a written specification) and supporting requirements from referenced standards.]

The relationship matrix is a great tool for connecting the requirements to the associated model elements & artifacts. In addition, the RTF template editor makes it possible to cook up custom reports that allow you to generate what in effect a specification listing the requirements.

Cheers,
Fred Woolsey
Interfleet Technology Inc.

Always be ready to laugh at yourself; that way, you beat everyone else to the punch.


bholey

  • EA Novice
  • *
  • Posts: 9
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
Re: requirements architecture traceability
« Reply #5 on: August 07, 2005, 11:40:09 pm »
Where do I specifiy that e.g Requirement 1.1 is implemented by a following sub-system xyz.

The Relationship matrix asks me to specify source and target but how does it figure which specific requirements are implemented by certain sub-systems.


At the moment I have created a custom functional requirements diagram
 - created requirements elements and inserted  them in packages
- I then have my component model with packages(stereotype sub-system) and components within them.

When I select either the requirements package or the package in the component model, I am able to define a relationship matrix with the source, target etc but there is no grid generated.

I am obviously missing something fundamental here

Any assistance appreciated.

Regards
Bholey

thomaskilian

  • Guest
Re: requirements architecture traceability
« Reply #6 on: August 08, 2005, 03:59:47 am »
I guess you use packages as subsystems. In that case the RM actually does not work since it can only relate Elements, not Packages. Probably it's worth while to ask for an enhancement in that respect.

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8110
  • Karma: +119/-20
    • View Profile
Re: requirements architecture traceability
« Reply #7 on: August 08, 2005, 03:17:35 pm »
Thomas, you can specify Package as either the source or target type.

Simon

bholey

  • EA Novice
  • *
  • Posts: 9
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
Re: requirements architecture traceability
« Reply #8 on: August 08, 2005, 08:00:00 pm »
Yes I can specify package as either source or target.
However back to my original question, where do I specify that a particular requirement is implemented by a specific element, be it component or package.

I think this is required so that the relationship matrix can then generate the matrix.

Please clarify as I am not able to make any progress here.

Is there an example of achieving  requirements traceability via relationship matrix.

regards
Bholey

thomaskilian

  • Guest
Re: requirements architecture traceability
« Reply #9 on: August 09, 2005, 01:45:47 pm »
Quote
Thomas, you can specify Package as either the source or target type.

Simon


I shouldn't post at my Mac :-[
(or you guys come out with a Mac version ;D)

thomaskilian

  • Guest
Re: requirements architecture traceability
« Reply #10 on: August 10, 2005, 01:50:53 am »
Quote
...
However back to my original question, where do I specify that a particular requirement is implemented by a specific element, be it component or package.
...

View/Relationship Matrix
Select Source: with the ellipsis; Type Requirement
Select Target: with the ellipsis; Type (element/package)
Specify Link Type: (Realisation) and Direction: (S->T)

Now the matrix is ready. Select  any crossing by click, shift click or ctrl click. Right click into selection and Create new relationship...  An X will appear and indicate that a relationship has been created. Try right clicking into an X. Try also right clicking in the upper part of the matrix (where Source: etc. is located).

Not sure, but also RTFM ;)