Project Issues vs. Issues

[jjyoung]

I setup a Package to hold all of my requirements.  During development of the requirements there are issues raised which need to be resolved.  It would be nice to be able to assign Project Issues to specific requirements, then when an RTF report is generated have those issues listed with the Requirement.  So far I've found no way to do it.

Any help would be appreciated.

[«Midnight»]

Perhaps something like a «trace» relationship. [You might find other variants that appeal to you.]

Here - in no particular order - are some tools that might help.

Check out the Relationship Matrix. This view will allow you to link elements of a source and target type. By setting the source and target scopes - the leftmost entries at the top of the view - to appropriate packages in your project hierarchy you can use the matrix to relate issues to requirements (for example) across packages. You can also get a high-level view of where these relationships are. You can open the Matrix from the EA main menu via View | Relationship Matrix.

[There's a limitation though. If you use a «trace» relationship, be aware that this is a stereotyped dependency. For some reason Sparx has not allowed us to create, manage or filter on stereotypes in the Matrix. Perhaps if you find the Matrix useful you'd care to submit a feature request using the link near the bottom of any forum page.]

Another useful tool is the Relationship pane. This is a dockable pane that you can open and put with your other common tools. It is best left in its default position across the width of the screen, for reasons you'll quickly see. It can be found from the main menu via View | More Windows | Relationships. You can also use the control-shift-2 shortcut. This gives you a quick view of what's linked to the currently selected element only. While you can delete links here you cannot create new ones (I believe).

Finally, check out the Hierarchy pane. Once again this is a dockable tool, but the default orientation is vertical. This tool also focuses on the currently selected element, but shows a multilevel hierarchy of links to other elements.

HTH, David

[OwenInCanada]

Have you tried using the Maintenance View? I don't know what it gives in terms of traceability, but it does have one maintenance instance per element.

How to:  

Select an element, such as a requirement. Select View/Maintenance from the main menu.
Now you can fill details of the issue into the maintenance pane of that element.

Hope that helps.

-Owen

[jjyoung]

I am using the maintenance view and it doesn't completely address my issues.  Some of it has to do with the use of External vs. Internal Issues.   The External Issues have a lot more capabilities with respect to tracking the resolution of issues w.r.t the Requirements that they're associated with.  However, tying them together in an RTF report has proven problematical.  When using Internal Issues it's easier to generated them in the RTF Reports, but they don't have a lot of the fields available in External Issues.  I suppose I could add that information by defining Tags, but I want to exhaust "standard" ways of doing it first.

[OwenInCanada]

I am at this stage myself: I have just defined a "Requirements with Maintenance" RTF export template to get the defect/change/issue/tasks captured together with the requirement details. (The purpose of these reports is to enable requirements review with people who are not EA experts, and to insulate requirements reviewers from the details of the design.)  

I can imagine that we will in future want to send internal and external requirements to different audiences. May I ask what is an "External Issue"? What interface is that available through?

Regards,

Owen

[jjyoung]

An external issue is an Entity in it's own right.  If you bring up the "Common" Toolbox you'll find it there.  You can drag it into a Requirements Diagram (or other diagrams).

After further investigation I discovered that I had a incorrect information in my last post.  It's the Internal Issues that have more capabilities, such as who it's assigned to, who found it, when it was resolved, etc.  If you create an External Issue you can access the same fields in the External Issue through the Maintenance Window.

[RoyC]

Take a look at:

http://www.sparxsystems.com.au/EAUserGuide/index.html?lifecycle.htm

An 'external issue' in jjyoung's terms is a Defect or Issue element that identifies problems with the model.  See:

http://www.sparxsystems.com.au/EAUserGuide/index.html?o1478.htm

An 'internal issue' is a statement that identifies problems in project management or support. See:

http://www.sparxsystems.com.au/EAUserGuide/index.html?projectissues.htm

[jjyoung]

Thanks for your response.  It clears up something I was curious about.

Apparently I was extending the Internal/External Terminology a little too far (at least as far as EA-speak goes :-)).  I derived this through a corollary to Internal/External Requirements.

External Requirement - a requirement that is an Element, and can be linked to other Model Elements.  These requirements are shown inthe Project Browser.

Internal Requirement - a requirement that is entered at the level of an individual element.  This is available through the Properties window of the element under the Requirements tab.  These requirements don't appear to show up in the Project Browser or as separate Elements, although they can be converted to External Requirements.

"Internal Issue (my term)"/"Maintenance Element - Issue" (EA Term) - can be entered and seen under the Maintenance Window for any Element.  These Issues are not seen in the Project Browser OR in the Properties Window of the Element.

"External Issue (my term)"/"Public Issue" (EA Term) - This is the one created via the Common Toolbox.  It creates an Issue element which can be linked to one or more Elements.  These are seen in the Project Browser.