Change of stereotype to "Functional"

[Geert Bellekens]

Ian,

I think you can add requirement types yourself.
Can you not create a type called "ToBeDefined" and set that as the default one?

I agree that it's weird that EA allows you to create requirements without a type, only to change the type to "functional" afterwards.

I just did some experimenting, and it seems that the default "functional" is somehow hardcoded in EA. If I delete the "functional" requirement type then there is no default, and the type field remains blank.
If I add "functional" again then that is used again as the default.

So I guess the workaround for your problem is to delete the "functional" requirement type and add a "funktional" or "functionally" or another variation if you still need that one but don't like it to be the default.

Geert

[Glassboy]

So I guess the workaround for your problem is to delete the "functional" requirement type and add a "funktional" or "functionally" or another variation if you still need that one but don't like it to be the default.

Or accept that the majority of requirements are functional and leave it alone, as we know when you start fooling around with the Pareto Principal the resulting mess is bigger than the original problem.

[qwerty]

I simply (as stated) created my own requirement which is just a requirement. Whether functional or non-functional just depends on the package where it has been put. Especially NFRs follow a pattern that is rather broad (legal, performance, etc.; you can find examples on the net). So creating a package structure is much more appropriate. Similarly you can group functional requirements.

q.

[Paolo F Cantoni]

So I guess the workaround for your problem is to delete the "functional" requirement type and add a "funktional" or "functionally" or another variation if you still need that one but don't like it to be the default.

Or accept that the majority of requirements are functional and leave it alone, as we know when you start fooling around with the Pareto Principal the resulting mess is bigger than the original problem.

But that's not Ian's beef as I understand it.  If Functional is to be the default value, then it should appear (as the default) in the input.

For all the enumerative properties we can affect, we create either a formal default intrinsic value from the domain, or use the extrinsic value «Uninitialized» (no value has been entered).  We, typically,  also allow the extrinsic value «Undetermined»  (I haven't decided yet, but I did have a think about it).

Paolo

[Ian Mitchell]

The disease is spreading!
Just tried this again in V15 Beta, and now 'Defect' elements have the same problem:
- drop onto a diagram - no stereotype
- edit the properties - stereotype automatically set to 'Functional'.
This is just a bug. Plain and simple.

[namealreadytaken]

While I agree the data manipulation is a bug. I am tad confused.

Under what circumstances would a requirements engineer not be aware, based on requirements elicitation findings, which stereotype to apply when initially recording the requirement? Presumably, the requirements engineer should know what requirement stereotype to apply from the start and not try to figure out the stereotype at a later date.

The suggested workaround is to name the package based on the stereotype (e.g., NFR). If the requirements engineer is not sure of which stereotype to apply, how would he/she to created the requirement in the NFR package?

Thanks

[Ian Mitchell]

An answer from Sparx, via a very prompt response to a bug report:

"It depends on Visual Style. If you set the "ribbon | Start | Visual Style | Use Property List for Elements" option, it won't be a problem because the stereotype field can be blank. Unfortunately, with that option switched off, the type field is a list box and there is no option for a blank stereotype. "

Now can anyone tell me, honestly, that they would have predicted that as the solution.
But it does at least work.
I wonder what else it does....

[Ian Mitchell]

So I did as Sparx suggested (now using v15) but I decided I didn't like that it removed the dockable properties windows, so I switched it off.
Now I don't get any dockable properties windows any more. Even after an EA re-start.
How do I get them back ? Anyone?

[Ian Mitchell]

It seems that a click on an element shows the old-style, modal Properties dialog.
Alt-Enter (who knew that) shows the dockable properties.
Was this the case in V14? I thought the old modal window could just be docked ?