V10 Requirements diagrams are trashed upon upgrade

[Tad Anderson]

Requirement diagrams show all notes and compartments after upgrading and they cannot be turned off.  I have submitted it as a bug but want to post here also.

Here is an example

[KP]

Those don't look like requirements to me. They look more like SPEM Deliverables. As a first step, try disabling the SPEM technology (Settings > MDG Technologies).

[Tad Anderson]

You are correct.  It is a SPEM deliverable, but it should not be.  Turning off SPEM does not help and we should not have to do that.

The problem is EA 10 is using the Stereotype to define the Type instead of the Type.  These requirements had a Stereotype of "Deliverable" and a Type of "Requirement".

Disabling SPEM before opening the project also does not work.  Changing the requirement to Functional (one predefined for Type Requirement) fixes it, but the custom stereotype of Deliverable cannot be created or use without Deliverable changing to a SPEM type even with SPEM disabled.

This is not good.  We will not be able to upgrade until this is fixed.  We have a ton of diagrams that will be affected.  These diagrams have been through multiple major version upgrades (8,9) and we had no problem.

[KP]

You are correct.  It is a SPEM deliverable, but it should not be.  Turning off SPEM does not help and we should not have to do that.

Actually I've changed my mind on that. I don't think it is a SPEM deliverable, but something that looks like one. For starters, the stereotype of an EA SPEM deliverable is «SPEM_Deliverable», not «Deliverable». So there must be some other stereotype either in your model or in your technology paths that is conflicting.

The problem is EA 10 is using the Stereotype to define the Type instead of the Type.

I've been here since EA 3 and requirements have used the stereotype field for their type in all that time - it's not just an EA 10 thing.

There is definitely a conflicting stereotype, and I don't think it's one of ours because nobody here can reproduce the problem. The first step to finding the conflicting stereotype is to select a requirement and go Settings > UML Types and see if there is a matching stereotype in the stereotypes table. Otherwise, try disabling all technologies - hopefully that will unload the shape script that is causing the problem - and enable them one at a time until the problem comes back.

[Tad Anderson]

Figured it out.  It was a being affected by a custom profile I had written.   I am not sure why upgrading to 8 and to 9 didn't affect it this way, but deleting the profile worked.

Thanks for your feedback and help.

[skiwi]

Figured it out.  It was a being affected by a custom profile I had written.

Wot, no apology?

[Tad Anderson]

Wot, no apology?

For what?  It should not have used a custom profile over the Sparx loaded profile.  It is still a bug. Like I said above these projects went through 2 other major version upgrades with no issue.

[Eve]

It should not have used a custom profile over the Sparx loaded profile.

Requirement types have always been a stereotype, and Sparx Systems doesn't have any profiles that define a stereotype by that name. When you created those elements they would have been assigned to that profile. The only thing that's strange is that I'm not sure what prevented that drawing from being used in the old versions, to me it seems like we implemented something new that allowed your profile to work.