Export Requirements to Excel

[khanabdulr]

Is there a way to export all requirements (Internal and External ) to a excel sheet

I have a packagex under which I have a use case ..under which I have a activity diagram....each activity in the activity diagram has requirements associated to it. Is there a way I can get all the requirements in PackageX into Excel sheet

Thanks,
AK

[Harley]

Right click on the package in project view --> Import/Export --> CSV Import/Export...

hth
Harley

[khanabdulr]

I have tried doing that.....but it only exports the external requirements.....that too only at the package level....i have requirements assigned to some of the activities underneath...

[Paolo F Cantoni]

I have tried doing that.....but it only exports the external requirements.....that too only at the package level....i have requirements assigned to some of the activities underneath...

As with the Relationship Matrix, AFAIK, you can't do it for internal Requirements.  Make them external and link to the classifier.

HTH,
Paolo

[khanabdulr]

What about gettting all the requirements in the package (at different levels) into a excel sheet...

[sargasso]

Here we gooooo!

1) internal and external requirements (and indeed all internal/external dichotomies in EA) are not the same things!

2) Anything "externalised" is an element in its own right.  It has the (relevant?) features of the UML element from which Sparx has spawned the element.  These are stored in the t_object tabel of the repository with a Type set to the element type name i.e. "Requirement".  These can be imported into an excel spreadsheet by using MS SQLQueries of the ilk "Select * from t_objects where type = 'Requirement';"

3) Internal requirements are element features, not elements.  In the case of requirements, they are held in the t_objectrequirements table.  Importing them into excel is a tad more tricky.

TIP:  Make a decision - use either external or internal requirements, not both.  Unless you have a very very good reason to treat them differently as they are disfferent.

For example - you can create EA tests (an internal item) on external requirements - linked directly!  Thus reqt-test traceability is easy-peasy.  You cant create tests on internal requirements only on the "owing" element and since this results in an M:N relationships you can't get a reqt-test trace.

OTOH !  You can "copy/translate" internal requirements into test cases with the flick of a wrist but not external.

IMO ! EA6 should be a complete restructure of the db to remove all these incomplete transitives - I know it would be a LOT OF WORK and it would render ALL OLD MODELS USELESS.  But by jimminy, by crikey, by ...  I am getting very tired of this hassle.

bruce

[Paolo F Cantoni]

What about getting all the requirements in the package (at different levels) into a excel sheet...

Works for me... I exported from a View with requirements below it connected by a Nesting relationship.  They all seem to have exported.

Including some non-requirements

Paolo

BTW: I did discover a bug in the process... You can't seem to edit an existing CSV specification

[Marty]

Hi all,

In regards to the difference between internal and external requirements I thought this might clear up some of the confusion.

External Requirements are first class modeling elements intended to allow modelers and analysts to fully model and document a set of “functional” and “non-functional” requirements which typically exist outside the system being built within the business domain. External requirements provide the business rules and constraints which the system being built must realize.

Internal requirements are element “responsibilities” within the system.
For example
–
Open the database
–
Update a record
–
Store user details

These responsibilities do not necessarily have a 1 to 1 correspondence with external requirements.

External requirements are generally linked to system elements through “realization links”. This implies that particular system level elements are responsible for implementing a particular business requirement or rule. The realization link to the external element traces to the definition of or reason for that work being done. The system elements “responsibilities” will be completely different describing what that element is responsible or required to do.

Generally, internal responsibilities are “unique” within the system. For example, only one class would be responsible for opening and updating the database.
A persistence management class may be linked to external requirements such as “store customer details”, and have inner responsibilities like “open database” “commit transaction” etc. A customer class, plus a persistence class together may implement the external requirement “store customer details” but each class has very different responsibilities.

The Move external function was added to help people externalize requirements when it becomes apparent it is a first class requirement and not a class responsibility.

The Matrix view was designed to visualize the implementation of “external” or “business” requirements (and other relationships) and check cross-references. This is important to check that all requirements are implemented and to know exactly which elements implement those requirements.

Given element responsibilities are unique to an element a matrix view of these is not useful.

Perhaps to clear up any ambiguity it might be useful to rename the internal requirements to “Responsibilities”.

I hope this helps

[Paolo F Cantoni]

[SNIP]
Perhaps to clear up any ambiguity it might be useful to rename the internal requirements to “Responsibilities”.

Thanks Marty, It helps me.  Your posting describes pretty much what I'd (and most others) had sussed out.

One question however...  It would seem to be a good idea to rename the internal requirements Responsibilities, so long as they are the Responsibilities displayed when we tick the Responsibilities and Inherited Responsibilities checkboxes in the Set feature visibility dialog.

Can you confirm this please?

If this is the case, then you MUST rename them.  To complete the task already started...

Consistency, Consistency, Consistency! ^TM

Paolo

[Marty]

Hi Paolo,

I’m glad it was of some help and yes they will be the Responsibilities displayed when the option in the set feature visibility dialog is set.

Best Regards,

Marty