Reverse Integration with DOORS

[Heather Wallace]

Are there any plans to automate or facilitate the return trip from Enterprise Architect to DOORS.  The import from DOORS is so seamless that it is a shame we cannot also seamlessly achieve the export of model elements into DOORS modules and specifically the export of traces between the model elements mastered in EA and requirements imported from DOORS.

I believe there is an open standard for the architecture tool / DOORS interface which is used by IBM for their tools??  :-/

[qwerty]

I guess the answer is CSV :-/ You can export your requirements that way and import it into DOORS. However, if you use DOORS it does not make much sense to also capture requirements inside EA. Just place them in DOORS and synch back to EA.

q.

[Uffe]

My guess would be that there are no such plans, no.

Tool vendors tend to be happy to import stuff from other tools, but not as happy to export stuff to them.

/Uffe

[rothnic]

I guess the answer is CSV :-/ You can export your requirements that way and import it into DOORS. However, if you use DOORS it does not make much sense to also capture requirements inside EA. Just place them in DOORS and synch back to EA.

q.

We thought this would suffice, but we are currently looking for 2-way solutions. The reason is just because of entrenched methods of currently working. There are requirements people who need DOORS, it is the adopted tool of choice and we continue to maintain the baseline requirements in that. However, we know we can create much better requirements by doing analysis in a tool like EA.

The issue comes where we start doing more analysis using SysML when we get the system of system level requirements for our system. We want to derive these requirements into a more detailed spec through functional analysis, or alter existing requirements. If only one-way syncing exists, there is risk that something will end up being missed.

It definitely would be an appreciated feature, among other things like creating the actual requirement relationships between requirements, activities, etc based on doors attributes. Currently, I believe it will only add tags.

[qwerty]

Personally I would use DOORS just to extract requirements from Word documents sent in by the customer. Then just leave them as they are and continue with a different process in EA where those requirements were transferred. However, it is difficult as "responsible persons" tend to use their known tool chain (that is all that Rational stuff with following change management etc.) and setup a mess of an overall process.

The reason why I would do that is that once you have synthesized the use cases you will need to change requirements (not possible, wrong condition, alternatives), add new requirements (e.g. internal non-functional ones) and adapt use cases. This can not be done with DOORS but only in EA (or maybe in RSA? But how is actually still using that?).

q.

[rothnic]

Personally I would use DOORS just to extract requirements from Word documents sent in by the customer. Then just leave them as they are and continue with a different process in EA where those requirements were transferred. However, it is difficult as "responsible persons" tend to use their known tool chain (that is all that Rational stuff with following change management etc.) and setup a mess of an overall process.

The reason why I would do that is that once you have synthesized the use cases you will need to change requirements (not possible, wrong condition, alternatives), add new requirements (e.g. internal non-functional ones) and adapt use cases. This can not be done with DOORS but only in EA (or maybe in RSA? But how is actually still using that?).

q.

We have a complicated hierachy of requirements at each level on the government side. We essentially look like a customer to the higher level system of systems group. We take their spec, then we(our requirements team) derive our own system spec. So, what we'd like to do is mature that spec since it is recognized as our specification instead of creating a new spec. When that one is mature, we create an RFP and put it on contract. Then the contractor develops their own spec that traces up to our level, which traces up to the higher level. So yeah, it is more organizational pressures that push us down this road.

We are still working through the business process, but we'd like to have regular reviews with the requirements team to "accept" the changes/additions. A more automated process for managing the relationships between requirements (vice scripting it), and sending changes back to DOORS would be nice.

[Sam Courtney]

Have you looked at this integration?
http://www.agosense.com/english/media-library/demo-videos/sparx-ea---ibm-rational-doors

Not sure if it is 2 way or not - I missed the session.

[qwerty]

Have you looked at this integration?
http://www.agosense.com/english/media-library/demo-videos/sparx-ea---ibm-rational-doors

Not sure if it is 2 way or not - I missed the session.

Hu. Seeing alone how the requirements were entered in DOORS made me shudder. Then creating two shadows (DOORS requirements in EA and EA Diagram copies in DOORS) which create ambiguity². Well, it's a German product from Swabia. It must be perfect.

q.