Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - PeterHeintz

Pages: 1 ... 24 25 [26] 27 28 ... 37
I have not used this feature yet and due to the silence, I assume there are not many forum members using that feature as well.

One of the forum members who know a lot about document templates is Geert. Either he is out or even he does not know.

If nobody answers, I would send a mail to

I think that this will not work.

What I did was creating a stereotype having all common tagged values (I named “Abstract Requirement”) and I derived those common tags by connecting my real stereotypes with "Generalize".
When I look on that realization (done a while ago) I do not understand anymore why “Abstract Requirement” is really abstract (in other words I cannot select that stereotype as user).
But this is the way it works for me.

General Board / Re: Links to Q&A's / Source Documentation
« on: May 24, 2016, 02:50:28 am »
Yes in EA any kind of those things is somehow related to an element, however a element can also be a package containing lots of elements.
Anyhow, if it does not suite to your needs, just forget it.

I am not 100% sure, but I think there is no feature for that.
Such stuff works for properies but not for tagged values (99%).

General Board / Re: Links to Q&A's / Source Documentation
« on: May 24, 2016, 02:20:54 am »
There is an EA feature called element discussion that might provide you what you need. In theory if your partners would have access to your model you would not need any document or e-mail at all.

However to be honest, I have not jet seriously used that feature (does not mean that it is useless/ I just have no experience on that feature).

I assume then that if I were to use/build a documentation template that I could display that field in each Requirement Catalogue entry?
Yes with a document template you can do that.
Looking at RaQuest... being so green to EA, I'm probably not going to understand the benefits for another year.
With RaQuest you can handle the requirements more in a table rather than as elements in the properties dialog or on a diagram + some other features.
I used Raquest many years but now not any more. This is mainly because of the Specification Manager is there for a while, satisfies my need and the other features I do not need, further on Raquest does not fit well to own defined requirement profiles.
As long as you do not have requirements engineers not able to specify requirements in EA or defined by some strong organizational policies to use something else (not working in huge endeavor) I assume that doing requirements engineering in EA is good.

I rust realized that when I put SysML properties connected with a connector having a label with a direction to a second diagram that the triangle and the connection remain.!?
“Inconsistently correct systems DON'T EXIST!”

Of cause! I am not unrealistic.
I do not intend to proselytize dignified OMG.
Just wanted to find out with this issue, if I am interpreting something entirely wrong.

Just for info:
Instead of embedding the auto numbering in the title, you can assign it to the alias of the element. So as long as you do not edit the alias you have no risk to delete the number by mistake.

If you e.g. intent to bind use cases to user requirements I would hold the use cases separate and connect them e.g. with refinement or dependency or trace relation with a configured relationship matrix (Tool/Relationship Matrix). At least that works fine for me.

I don’t think there is a standard best-practice here.

However I can give you some information what we are doing, influenced by SPES2020
User requirements we call goals and we use the KAOS goal framework for that. To be able to use that we created a own profile to support that notation.

Any other requirement we call solution oriented requirements and those are typically modeled with activities (behavior), state machines (states), SysML Bocks/UML Classes (interfaces). For those currently also textual requirements (SysML Requirments) as some kind of hook or other type of requirements exist. Those textual requirements we differentiate in functional (hook for behavior, states and interfaces), quality (some kind of synonym for non-functional), and constraints.
Your idea regarding different number schema will not work (at least not out of the box) if you want to use auto numbering, because there is only one auto number for a meta type (Requirement). Of cause you can handle that manually or by some kind of scripts.
If we would not use a own language for user requirements, I would put them in a separate package.

To be honest, I am far away of being an expert in reading UML specs but I belief that to have the triangle or not is a sharp but it annotates the UMLEdge
Anyhow I have the feeling UML spec leaves plenty room for interpretation but a sense making interpretation would be to remain the direction on different diagrams.
I personal like and use this annotation/shape for very conceptional things just because it makes reading simpler than role names.

Don’t be so grounchy! :) :) :)

Well, that indicator is uml standard and I found an example on page 202 showing the intention as I use it.

It is not the association direction (if any), it is the direction of the label (how it should be read).
And label is label on whatever diagram it is.

Yes, that's my impression as well.

I use connector direction to provide reading directions for users.
“Car” “has” “Engine” were the direction from “has” goes from Car to Engine to ensure that the user does not read “Engine” has “Car”.

However this direction is not bound to the connector but to the connector on a diagram.
In other words each time I use the connector in an other diagram I have to set the direction anew.

I thing binding the direction to the connector only should be there.
Is there a sense in that current implementation or is that just a wrong implementation? :-\

Any opinions?

Pages: 1 ... 24 25 [26] 27 28 ... 37