How to manage internal requirements

[Tonu]

I am trying to figure out the best way to arrange (functional) requirements in the model.
Requirements that spread over several use-cases are clear -- they can be placed on a separate diagram and linked to appropriate use-cases using a "Realization" link.

For the requirements specific to a certain use-case, "internal requirement" is the most natural way. However I haven't found a way how to manage them later. Making a requirement external and placing it under the Use-case node in project hierarchy is even better -- this way the requirements are visible in the tree. However, neither of cases will take the requirement to the Requirements Matrix.

I do not fancy creating a separate diagram for each use case to connect requirements and use cases, as the only thing I want to show is the containment of requirement in the Use-case ... and that is what I already specified by making requirement internal to the use-case (or placing it as a subnode of the use-case).

Is there any other way to get ALL requirements in tabular format?

Thanks in advance!
Tonu

[thomaskilian]

Tonu,
the requirements handling in EA has been discussed formerly in broad. It certainly depends on what and how you want to do things. If you have a mixture as described above you won't be able to get a complete list. For that reason I once decided to only use external requirements. I package them as appropriate and can easily make reports. Also I have written some simple scripts to manage requirements (e.g. tags for Unassigned, Due, History, etc.). I'm still waiting for a "consistent" approach to Requirements (and Issues and Tests and Glossary and....) from Sparx. As long as this is not in reach I stay in the "Element World" and use external requirements.

[Tonu]

Thanks, Thomas!

I almost came to the same conclusion myself.
I am still fighting with a temptation to keep requirements internal and make a skript for reporting, but hopefully I will manage to persuade myself to save this effort :-)

What seems to be worth considering (if anybody from Sparx happens to read this) is to extend the Relationship Matrix to read also the <<implements>> dependencies that are created between use-case and requirement when requirement is placed under the use case in element hierarchy.

This would save quite some manual work in cases when there is large amount of requirements and most of them are specific to one use-case only.

But for now, yes, packaging requirements manually will do the job