System Issues

[thomas.kilian]

In the system issues I'm missing a due date. There is one date field that is obviously intended to denote a closing time, but none for a due date. Also this field should appear in the list in order to sort agains it. Further I'd like to have something to tag issues in order to create groups of issues.

[thomaskilian]

Me again,
I just started to work with issue elements (instead of the system issues). In general I can do much more working with issues in a certain package: assign relations, add tags, show in diagrams. Now I ask a simple question: what for we need the system issues  Moreover there are two different views - from the system tab and from the project menu. Both with slightly different functionality. Wouldn't it make sense to remove these views since the "basic" functionality of UML (and thus EA) allows us to describe things better? And doing so   wouldn't it be convenient to add default attributes to the issues like "due date", "responsible", "owner", "resolution" (preferably with a history) and "date closed"?

Just another thought: instead of adding these attributes, tags could do it too. I only needed some mechanism to keep track of tags under certain circumstances. I remeber in ROSE I had the possibility to chain automation in events (like add, change or delete element). Having this in EA would really be a huge step forward. Just a thought, though  

[sargasso]

Hiya tk, you old schizophreniac

Here's how I use the two, at least in terms of the issues tabs you can extrapolate to tasks and problems.

In general, when things arise that we dont have an answer to, that are related to elements not yet modelled (or modelled but not yet "published") that require either discussion with stakeholders or escalation through the project heirarchy, we add them as system issues.  They are thus captured and can be handled at the next appropriate talkfest.
Note, we do not manage real issues (i.e. things that must be resolved beyond the modellers authority/responsibility level) through EA.  We do, however use it as a means to quickly capture them for later transcription to the project/program issues register if necessary.
An example would be something like "We have not been able to get a signed off definition of the <product x> default pricing parameters from the marketing deopartment.  This spec was promised as the definitive example for defining the default price structure parameters.   Alphonso from marketing says they do not have such a document.  This prevents us from completing the price rule logical design."

On the other hand element issues are specific to the model (diagram even), many of them are or will be resolved in the course of developing the solution design.  As they are associated with the element concerned and can be included in the generated documentation we have found that they do not tend to "get lost" in the general project  wash.  In addition, by using the ctl-space element tagging feature, (the little red triangle) the user gets a memory jog every time they add the element to a model that "something is awry here".

I agree that the EA issues model leaves things to be desired in terms of an issues management system, even at the element level.  I have started several times to build an extension add-in to give me the data, control, reporting etc  that I "need" in this respect . Sadly, the real project keeps getting in the way of completing it! ...  :-/

Bruce

[sargasso]

... and while I'm at it...

Issues etc frequently arise on connectors as well as elements.  I realise this is a major db change for EA but by crikey its really really needed.

... and while I'm at it...

Similarly, connectors need a files tab!

Bruce

[thomaskilian]

Hi Bruce,
thanks for the feedback. In the beginning I also used the system issues to keep track of things as you wrote about. But later I desparately missed the ability to create links to elements - mainly requirements. So I ended up with having packages containing general (the formerly used system tab) and specific issues. The latter receive (trace) relations to requirements and in a later stage use cases, classes etc. Closed issues are moved to another packed. Tags I currently handle manually (with some scripting support).
Probably a different approach would be to have the ability of making the system issues "external". Just like you can do it with element issues.

[mikewhit]

In some ways, the arrival of the EA requirements add-in RaQuest did not go down well with me, since it seemed to me that Sparx would then have no incentive to improve EA's handling of requirements within the modelling framework.

Oh for enough time to write an addin !

But Thomas' comment about linking to requirements tells me other people have this need as well.

Requirements, Test and, it seems, Issues need another 'View' onto the model itself so that links can be made without interfering with/obscuring the design model.