Book a Demo

Author Topic: Shared Requirements  (Read 4596 times)

David OD

  • EA User
  • **
  • Posts: 56
  • Karma: +0/-0
    • View Profile
Shared Requirements
« on: May 14, 2010, 02:57:12 pm »
I could be opening a can of worms with this one :P, but let's see...

We are using EA and RaQuest to manage requirements, analysis and design for a broad range of related projects within a single repository.  There are some projects that have the concept of common requirements, in that all the projects have the same set of base requirements, plus their own domain specific ones.  Ideally the wording of these requirements would be consistent across all projects, and it would be possible to see which projects shared a particular requirement.

Some of us have previously used the CalibreRM product (and are still getting therapy!  ;D).  It had a feature whereby you could set up a folder of shared requirements.  Then for a specific project, you could create a mapped requirement.  This mapped requirement acted as a local placeholder, but the text and attributes of the shared requirement were copied over to the mapped one, and could not be locally edited.

In EA (and RaQuest), I could set up a "common" requirement, and then create local instances of it that trace back to the common one.  this is the only way to get similar functionality that I can see, although it doesn't provide the fixed text option that CaliberRM does.  

Does anybody have any thoughts, comments or religious statements to make about shared/common requirements?  ;)
Regards
David

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Shared Requirements
« Reply #1 on: May 14, 2010, 05:14:51 pm »
Well, we do it by having a shared package and exporting from the source and importing into the targets.  We recommend separate repositories for each project.

That way, if anyone is stupid enough to attempt changes to the (specially stereotyped) shared requirements their changes get overwritten next cycle..

HTH,
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

David OD

  • EA User
  • **
  • Posts: 56
  • Karma: +0/-0
    • View Profile
Re: Shared Requirements
« Reply #2 on: May 17, 2010, 07:54:12 am »
Quote
That way, if anyone is stupid enough to attempt changes to the (specially stereotyped) shared requirements their changes get overwritten next cycle..

Paolo

I love it!!  ;D   Not quite what I was after, but none the less a suitable way of dealing with infidels who play with shared requirements!!

Unfortunately it isn't ideal for us, as we have a single project (large related programme of work), but certainly food for thought...
Regards
David

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Shared Requirements
« Reply #3 on: May 17, 2010, 09:47:10 am »
Quote
[size=18]...[/size]
Unfortunately it isn't ideal for us, as we have a single project (large related programme of work), but certainly food for thought...
Just 'cos you have one main project doesn't mean you have to have one repository.  Just have a special repository for the shared requirements and export from there...

Over a number of years I've come to the view that we ALWAYS have a series of coordinated projects that need not be in the same physical repository - even (possibly) in your case.  You just need a suitable coordination mechanism.

HTH,
Paolo
« Last Edit: May 17, 2010, 05:51:34 pm by PaoloFCantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13523
  • Karma: +574/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Shared Requirements
« Reply #4 on: May 17, 2010, 03:42:19 pm »
David,

We have a common model that is used by multiple separate projects.
To be able to share the common model with the different project (some of them in separate databases) we have version controlled the common model. (TFS)

Only certain people have rights to check-out the common model (managed at the VC level) so we can control what happens to the common model.

I guess the same principle can be applied to requirements?

Geert

Nick Pearce

  • EA Novice
  • *
  • Posts: 3
  • Karma: +0/-0
    • View Profile
Re: Shared Requirements
« Reply #5 on: November 23, 2010, 09:39:50 am »
I'm interested to know how you all organize your requirements in the shared models. I am a solution architect so I am interested in not only reusing requirements between projects but also reusing artifacts such as the systems and hardware components. In essence, I would like to be able to use EA for more than just requirements management on a project. Being able to leverage the traceability reporting across all systems and even between business processes would be an enormous asset. Has anyone ventured this far down the rabbit hole?

ART IT - Negócios

  • EA Novice
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Re: Shared Requirements
« Reply #6 on: December 19, 2010, 04:23:33 am »
I have a similar situation, I need to generate a HTMLreport from a Root Node that have some linked elements (Requirements, UseCases, Systems, etc..) from another Root Node.

When generation is complete, I cannot access the information that belongs to the other root, even if both root had been generated.

Is there a way to link elements between roots of the same EAP, in order to have them all in the HTML Report ?

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13523
  • Karma: +574/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Shared Requirements
« Reply #7 on: December 19, 2010, 02:44:19 pm »
Mauro,

I don't really use the HTML report myself, but have you tried moving down the models one level?
So iso having a root node for each model, you have one single root node, and use the view's as root of your models?
I'm not sure if that's going to solve anything, but it's worth a try.

Geert