Test, Issue, Defect,… Requirement dependencies

[PeterHeintz]

Test, Issue, Defect, Requirement are some EA build in elements.

The major difference in comparison to other stuff like classes is that you can set a Type rather than a Stereotype when opening the property dialog. However the type is somehow a stereotype.    So far so good.

However there is some stereotype dependency looking strange to me.
In my MDG I have define some stereotyped requirements and when I create a requirement I can select one of those stereotypes as type of my requirement. Apart of thinking why it is called type and not stereotype it is good for me.

However, when I create other stuff like Defect, Issue I see the same Types/Stereotypes I have created for requirements only.

So it seems to me that Test, Issue, Defect is regarded as a kind of Requirement by EA.
What is the sense of that? Any idea?
From my perspective it is just nonsense!

[qwerty]

No. It's Sparxian thinking. Us Earthlings are not able to understand that. Just take it granted. It won't be changed. And even if, it would get worse.

q.

[PeterHeintz]

Making sense would make sense!

[Eve]

So it seems to me that Test, Issue, Defect is regarded as a kind of Requirement by EA.

I think there's a conceptual inheritance between these types to give them all the same behavior, basic rendering etc.

[Uffe]

It makes some level of sense to me, as issues, requirements, defects, changes etc, are all conceptually related: they talk about what something should (or shouldn't) do, not about what something is or how something works. (Not sure about test here, tests talk more about how something is QA'd.)

That said, to say that an issue or a change is a type of requirement is taking that relationship a step too far in my opinion. Rather, I would say that they should all be instances of some other metaclass -- call it specification ("something which specifies"). That way, a requirement stereotype wouldn't be applicable to issues, etc.

It should be noted that requirements are not part of the UML standard because reasons.¹ Sparx added them because, hey, turns out a lot of people actually need a way to specify requirements even if they work in UML.² So Sparx is free to do what they want with these elements in terms of definition and semantics.

It should also be noted that EA's requirements are a bit of a hack. There are requirement types, which can be configured in a project (meaning the configuration is stored in the project database) along with weights which are used in project estimation. The type is stored in the stereotype column of individual requirements, and that's where Sparx went wrong -- it should have been a tagged value.

So if you use project estimation, your stereotyped requirements won't affect the estimate. For that to work, you need to configure those stereotypes to be in-project requirement types as well.

In all it's a bit of a mess. But it could be fixed if Sparx decided it's worth spending the hours on. With not-too-many tweaks and fixes, EA could become a pretty good tool for requirements engineering. Which is still a thing in these days of, what is it, post-scrum? or are we at post-post-scrum by now?, but of course only in fringe small-scale industries like aerospace, defence, automotive and places like that.


/Uffe

¹ My hunch is that Ivar Jacobsson, who to my knowledge has not been involved in any actual software engineering for the past thirty years, decided that use cases are always better because they kinda worked in some project at Ericsson in the seventies so there.
² There are requirements in SysML. I guess mr Jacobsson kept his grubby little paws off that one.

[PeterHeintz]

Hi Uffe,
Do you know a way that I can have stereotyped "Defects" and "Requirements" where the Properties/Type list is independent from each other. I remember somehow that I added in General Types/Requirements some entries (stereotype names) to be able to switch my requirement stereotypes with the Properties/Type field. And I know, that I got it managed to show not all what is defined General Types/Requirements.

[Glassboy]

It should also be noted that EA's requirements are a bit of a hack. There are requirement types, which can be configured in a project (meaning the configuration is stored in the project database) along with weights which are used in project estimation. The type is stored in the stereotype column of individual requirements, and that's where Sparx went wrong -- it should have been a tagged value.

In the last five years I seem to have become an architectural archaeologist doing anything from digging into running processes on servers to find applications and then mapping them back through users to organisational functions, or looking at deployed business services and trying to determine whether they align to the original requirements.

The functionality in EA could be incredibly useful to me with even a few simple changes.  Things like supporting the MoSCoW method as standard.  No "customer" of mine has ever cared about the priority and status fields.

[qwerty]

The functionality in EA could be incredibly useful to me with even a few simple changes.  Things like supporting the MoSCoW method as standard.  No "customer" of mine has ever cared about the priority and status fields.

+10

q.

[Paolo F Cantoni]

The functionality in EA could be incredibly useful to me with even a few simple changes.  Things like supporting the MoSCoW method as standard.  No "customer" of mine has ever cared about the priority and status fields.

+10

q.

+10

Paolo

[PeterHeintz]

Yes, there is a lot of power in EA, but too often it cannot be used just because of some unnecessary constraints implemented, some very small stuff not implemented, some inconsistency and so on.
If e.g. 10% of the efforts spend for releases would focus in such stuff, it would help a lot.

Examples for me are:
Remove the blocking to handle Packages like other elements where not needed (e.g. Specification View, Kanban,..)
Show really the SQL results in Matrix rows and columns
Remove the poor (almost useless) element selection dialogs e.g. Add/Create Link… by the existing useful  once you find when setting a classifier or a property type.
Solve design shortcuts choosen years ago like this forum topic.

[qwerty]

You should have a beer with skiwi ;-)

q.

[Uffe]

In fairness, MoSCoW priorities can be easily configured into either the priority or the status fields. Using status even gives you the option to visualize it.

If you want that to be the standard in your organization, you also have the option of creating a base project with those settings.

/U

[qwerty]

As said: rather than putting lots of effort in putting in more and more useless gimmicks some base cleanup would work wonders. If there were a simple concept to configure your own properties for elements, that would remedy a lot. Means you make a cut and get rid of old burdens. (I will probably not see that in my lifetime.)

q.

[Glassboy]

In fairness, MoSCoW priorities can be easily configured into either the priority or the status fields. Using status even gives you the option to visualize it.

If you want that to be the standard in your organization, you also have the option of creating a base project with those settings.

I could, but the problem is when I share things with other organisations.  It would probably even be ok if I had a personal copy of EA and could maintain a MDG independent of my employer, but the licence cost buys me a lot of toys.  :-)

[Geert Bellekens]

I could, but the problem is when I share things with other organisations.  It would probably even be ok if I had a personal copy of EA and could maintain a MDG independent of my employer, but the licence cost buys me a lot of toys.  :-)

Must be cheap toys then 

Geert