How to improve EA requirement traceability

[Alexandre Silva]

Since there's no link tab at the requirement properties window, how do we  trace the requirement links to other objects such as graphic user interfaces or use cases ?

[JohnDoe]

... simply draw a line between your requirement and these elements.

Greetings
Bernd

[«Midnight»]

Often a realization or a trace link will work. There should be some examples in the EAExample project.

[Alexandre Silva]

First of all, thank you a lot for the answers...but the question is the traceability: after we have the requirement linked to other objects, we would like to see all the requirement links starting at the requirement.  
I mean, something that works like a link tab at the requirement properties window.
For example, starting at a use case, we can browse and determine which objects this use case is linked to. Is there some analog way to do this starting at the requirement ?

[«Midnight»]

Hierarchy view? [Or whatever it's called these days.]

[RoyC]

You could use the Relationships Hierarchy, as David suggests.

Alternatively, have a look at the Relationships window (View | More Windows | Relationships). If you click on a Requirement in the Project Browser, the window shows you the relationships in which that Requirement is a member.

The Relationships Matrix might give additional information, but if you are not sure where the relationships might lead to, you'd have to specify relatively high levels in the package hirearchy for the source and target packages, and that might not give you the detail you want. Have a look anyway.

[Dermot]

Sounds like Roys comment: View | More Windows | Relationships.  Is what you need.  However there is a section "Traceability and Relating External Requirements" in the Requirements whitepaper that covers more clearly the other options - see:
http://www.sparxsystems.com.au/resources/whitepapers/index.html

[Alexandre Silva]

Thank you BerndWill, Midnight, Roy and Dermot.
All the tips you gave where helpful, and the relationships window was exactly what we where looking for...thank you all for your commitment on helping newbies like me to improve the tool utilization. As our project grows, it's important to be assisted by people like you who are experienced and know the good practices. As we improve our knowledge, we are committed too to share it with everyone who needs help.

[JohnDoe]

you're very welcome !

just drop any question you have to this forum.

Greetings
Bernd

[Alexandre Silva]

Hello there...here goes another issue we are having some doubts about how to deal with:
Is it possible to represent an activity diagram in a hierarchical tree structure ? Creating a sequence diagram or a GUI diagram, all its objects and components are created below the main tree view, not beside, at the same level. In an activity diagram, all of the components are represented at the same level. If I create more than one activity diagram at the same level, their components will be mixed up, causing some trouble to organize then an to determine to which diagram they belong to. Is there a way to avoid mixing activity diagrams components, rather than separate the diagrams in different packages ?

[Frank Horn]

If I create more than one activity diagram at the same level, their components will be mixed up, causing some trouble to organize then an to determine to which diagram they belong to

I would create all activities on the top level which logically belong there (e.g. all public methods of a class, or all tasks planned in project management system, or whatever). There can still be more than one diagram on this level since an activity does not belong to a diagram. The diagram only shows it, and the same activity can be shown one various diagrams, e.g. to show different groups of elements depending on it.

Then I would make each activity which deserves a detailed interior of its own a composite element, thus creating a child diagram. Activities dragged from the toolbox to such a child diagram will be created one level down, belonging to the parent activity. This can be done recursively, of course.

[JohnDoe]

If this is your scenario:


This would be a solution:


Since you can reuse all of these elements, you shouldnt think in terms of "Actor1 and UseCase1 BELONG to Diagram1". You can use any of these elements in other diagrams as often as you like. The structure in the package view is not relevant for the display of diagrams. The package view is there to collect and group elements according to your needs.

But as you said, you would not like to split these two diagrams in two packages. Hmm. Why not ? What is the reason, why you dislike to use the package nesting feature ?

Greetings
Bernd

[«Midnight»]

In fact, you could actually have all four of the elements continue to be owned by the TestModel package. The Model1 and Model2 packages would continue to be owned by TestModel, and would continue to own the diagrams in turn.

Depending on what you want to see on your diagrams, you should set the Show Namespace option (on the diagram properties dialog) as appropriate for your needs.

David

[Alexandre Silva]

Thanks again for the support...
We solved the problem considering everything you said in the previous posts, plus using the hyperlinks feature. We separated all of our diagrams in a different 'master diagrams package', and used the links to make the connections, under the idea of a 'Project Portal'.
Bernd, you're absolutely right !! Actually, there's no reason to avoid using the package hierarchy. That's what EA is made for, to separate and organize the way you model and browse your projects.
Frank, we will start using the child diagrams feature as soon as we upgrade our version of EA. I did evaluate this feature and it's very useful, thank you for the tip.
David, the idea of using the Show Namespace option was very useful as well. I had no idea about the functionality of this option, and after your advice I made a fell tests and it worked fine !!

Thanks again for the patience and the effort on helping us.

Alex

[Alexandre Silva]

In time...I made a FEW tests...sorry about the poor english, I'm improving it...