Question about usage of <<refine>>,<<satisfy>> relationship
Jun Aoki
I wonder if I can use <<refine>> relationship from a requirement
to another requirement. I think NamedElement includes requirement.
So, it seems to be OK. But to read "Overview" of "16 Requirement", it seems
to be intended from other element to requirement.
Can I use <<refine>> ralationship between requirements that have
different semantic levels?
As the same, can I use <<satisfy>> ralationship between requirements
one of that fulfills the other requirement?
Thanks
Remy Fannader
In that case it all depends of what will happen of those relationships.
If they can be processed by some logical engine (like a Prolog interpreter) it's worth to think about it. Otherwise I suggest basic relationships: include, and, or, xor.
--
You received this message because you are subscribed to the Google
Groups "SysML Forum" group.
Public website: http://www.SysMLforum.com
To post to this group, send email to sysml...@googlegroups.com
To unsubscribe from this group, send email to
sysmlforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
GeorgeW
Stephan Roth
the <<refine>> dependency is part of the UML4SysML subset. It is a
predefined standard stereotype of UML2 metaclass Abstraction, which is
a specialization of metaclass Dependency.
<<refine>> means that the client element(s) are at a "later" semantic
level than the supplier(s). In SysML Requirements Diagram, <<refine>>
can be used to express that the client model element(s) are an
increase in detail compared to the Requirement which acts as the
supplier. And of course refinement can be used between requirements.
But a more typical case in practice is the refinement of a Requirement
with the help of e.g. a use case.
As opposed to that, the <<satisfy>> Dependency is a stereotype of
UML4SysML::Trace. <<satisfy>> means, that the client elements fulfills
the requirement. Although it is allowed to model a <<satisfy>> between
two requirements, it makes no sense for me and feels weird. A
requirement is a need of what a particular system should be or
perform. In my humble opinion a need cannot be satisfied by another
need.
Kind regards,
Stephan Roth
Dragos DOBRE
Remy
necessarily depend upon the machine meant to process the requirements.
So, is there any implementation of this kind of interpreter ? and if
there is one, how does it understand those relationships?
On Jun 24, 11:11 pm, Dragos DOBRE <dobre.dra...@gmail.com> wrote:
> Hi Jun,
>
> I my opinion, what it counts is the semantics that someone gives to the
> SysML artefacts. In your case, you can use the two relationships between
> requirements. For example, in case of a requirement with ambiguity you could
> use a refine relationship to remove this ambiguity or to qualify and
> quantify requirements. This is the case for Method B where a machine
> specification is refined. In a systems engineering process stakeholder
> requirements are refined and satisfied by systems requirements (derived
> requirements also can appear). You can find in Harmony
> requirements.
>
> Regards,
> Dragos
>
Aoki...@ogis-ri.co.jp
>Can you give an example of what you mean by different semantic levels?
I'm thinking to use <<refine>> relationship between "Requirements of user
purpose" and "Requirements of the system".
For <<satisfy>> relationship, I'm thinking about such a situation -- There
are 2 stakeholders who have different requirements. I analyse each
stakeholder's requirements using <<derivedReq>> and <<refine>> to clear
system requirements. In analyse stage, I may find that a derived or refined
requirement of a stakeholder fulfills the other stakeholder's one. In such
cases, I want to mark such relationships using <<satisfy>>.
In both case, <<refine>> and <<satisfy>> may be meaningless for the result
of the analysis, but I want to remain the process of my thought -- Why I
define the requirement for system.
I think requirement diagram is more powerfull to use like above.
For traceability purpose, I think tables like QFD(Quality Function Deployment)
are more usefull to manage traceability.
Thanks
Aoki...@ogis-ri.co.jp
What you say is what I want to do!.
I don't waver to use <<refine>> and <<satisfy>> between requirement.
Thanks
Dragos DOBRE Wrote:
>Hi Jun,
>
>I my opinion, what it counts is the semantics that someone gives to the
>SysML artefacts. In your case, you can use the two relationships between
>requirements. For example, in case of a requirement with ambiguity you could
>use a refine relationship to remove this ambiguity or to qualify and
>quantify requirements. This is the case for Method B where a machine
>specification is refined. In a systems engineering process stakeholder
>requirements are refined and satisfied by systems requirements (derived
>requirements also can appear). You can find in Harmony
>method<https://www.ibm.com/developerworks/mydeveloperworks/groups/service/html/communityview?communityUuid=dbc39547-3619-4c31-9535-0b583a4e6190>satisfy
------------------------------------------------------------
青木 淳
オージス総研 ソリューション開発本部
組み込みソリューション部 第一チーム
Email Aoki...@ogis-ri.co.jp
TEL 03-5440-4191 FAX 03-5440-4506
090-3231-4651
Dan George
I really liked your opinion that a need cannot be satisfied by another
need: it clarifies that a requirement is a need (not a description of
a solution to a need) and, once one accepts that predicate, anyone can
understand the relationship is invalid. Your succinct phrasing will
come in handy for me.
What relationship(s) might be used to show that two requirements
express a common need? I'm thinking of reuse and want to apply the
following logic: if I have a need and I find a realized system with
and equivalent need I can consider reusing the realized system. The
realized model would have links between its requirement and satisfying
elements. I could iterate through those elements and link them via
<<satisfies>> to my equivalent requirement in my system.
Alternatively, I could link my requirement to the requirement
associated with the realized system. Which relationship should I use,
<<trace>>?
Another option is to promote the reusable requirement to a reusable
requirements package and include it in both models. My new requirement
would be deleted and the existing, equivalent requirement used in its
place. That seems like the best thing to do. Unfortunately, sometimes
the requirements sets are not so easily modified.
Thanks,
Dan
Remy Fannader
SysML can be very confusing as SW and HW artifacts can be combined without specifying modeling stages.
Wagner
In my opinion, you could use the <<refine>> relationship between two
requirements when you have the situation where the two requirements are
related exactly to the same stakeholder's need, but one gives more details
than the other. In that case, you could have a <<refine>> relationship
between the more specific requirement to the more generic requirement.
However, I wouldn't use this relationship between two stakeholder's
requirements. I would use the generic <<trace>> relationship and leave the
<<refine>> relationship for my model elements, such as use cases refining
stakeholders' requirements.
In the situation for system requirements, I would say that you shouldn't
use the <<refine>> relationship, since they are requirements being created
as the result of an analysis process of the stakeholders' requirements. For
me, it would sound weird to have that relationship between requirements you
have come up with. If that is the case, probably you should revist your
requirements, since you could eliminate or split some of them. You would
have the <<deriveRqt>> relationship between the stakeholders' requirements
and your system's requirements and also between requirements in different
levels of abstraction. Remember that, for example, two stakeholder's
requirements could be derived to the same system requirement.
For the <<satisfy>> relationship, I would definitely not use between
requirements. This relationship should be used between your model elements
and requirements to state how you are planning to satisfy the requirements.
You can use this relationship in all abstraction levels using different
model elements (i.e. model elements in different abstraction levels). At the
end, you can have a traceability matrix to know if you are covering all your
requirements, not forgetting any of them or overspecifying your system.
I hope this helps.
Best regards,
Wagner
Aoki...@ogis-ri.co.jp
I uses requirements model to analyse stakeholder's requirements and find
system's requirements.
There are NOT SW/HW at this stage. In my process, that's issues of the
next stage.
Thanks
Aoki...@ogis-ri.co.jp
Thank you for your careful explanation.
> In my opinion, you could use the <<refine>> relationship between two
>requirements when you have the situation where the two requirements are
>related exactly to the same stakeholder's need, but one gives more details
>than the other.
Yes, I'd like to use the <<refine>> at the above stiuation.
>However, I wouldn't use this relationship between two stakeholder's
>requirements.
In that case, I think that there may be some cases I'd like to use the
<<satisfy>>. I think there may be a case in which one of a stakeholder's
requirement fulfill another stakeholder's requirement. In that case, I'd
like to use the <<satisfy>> because using <<trace>> isn't recommended in
SysML specification and I think <<satisfy>> is more suitable.
Thanks
Wagner Schalch
Just to quote SysML specification:
1) "... it is recommended that the trace relationship not be used in
conjunction with the other requirements relationships described
above.". Meaning, you can use the <<trace>> relationship between
requirements when no other relationship is used. It is indeed a weak
relationship, but when dealing with stakeholders' requirements, why
not?
2) "The satisfy relationship describes how a design or implementation
model satisfies one or more requirements.". Meaning, you could not use
this relationship between requirements, since a requirement should
never express the solution to the problem, but the problem itself. You
model elements will specify the solution to the problem and,
therefore, can satisfy requirements.
I hope this helps.
Best regards,
Wagner
> Dear Wagner,
>
> Thank you for your careful explanation.
>
> > In my opinion, you could use the <<refine>> relationship between two
> >requirements when you have the situation where the two requirements are
> >related exactly to the same stakeholder's need, but one gives more details
> >than the other.
>
> Yes, I'd like to use the <<refine>> at the above stiuation.
>
> >However, I wouldn't use this relationship between two stakeholder's
> >requirements.
>
> In that case, I think that there may be some cases I'd like to use the
> <<satisfy>>. I think there may be a case in which one of a stakeholder's
> requirement fulfill another stakeholder's requirement. In that case, I'd
> like to use the <<satisfy>> because using <<trace>> isn't recommended in
> SysML specification and I think <<satisfy>> is more suitable.
>
> Thanks
>
Dan George
One requirement <<satisfies>> another when the model element that
satsifies the former also satisifies the latter. Thus, reqmt1<-reqmt2<-
(model element) is an alternative for reqmt1<-(model element)->reqmt2.
Since the primary goal is to understand how a requirement is satisfied
it seems like the latter is a better representation. If using the
reqmt<-reqmt pattern and reqmt1 changes, there is an extra step to
find model element and re-validate. If the change to reqmt1
invalidates the <<satisfies>> relationship from the model element then
a "where used" or "satisfies what" analysis can be done to decide what
to do. In that analysis reqmt2 will show up and a good decision can be
made without changing reqmt2 (although that would still be an option).
Make sense?
On Jun 26, 8:09 pm, <Aoki_...@ogis-ri.co.jp> wrote:
> Dear Wagner,
>
> Thank you for your careful explanation.
>
> > In my opinion, you could use the <<refine>> relationship between two
> >requirements when you have the situation where the two requirements are
> >related exactly to the same stakeholder's need, but one gives more details
> >than the other.
>
> Yes, I'd like to use the <<refine>> at the above stiuation.
>
> >However, I wouldn't use this relationship between two stakeholder's
> >requirements.
>
> In that case, I think that there may be some cases I'd like to use the
> <<satisfy>>. I think there may be a case in which one of a stakeholder's
> requirement fulfill another stakeholder's requirement. In that case, I'd
> like to use the <<satisfy>> because using <<trace>> isn't recommended in
> SysML specification and I think <<satisfy>> is more suitable.
>
> Thanks
>
Aoki...@ogis-ri.co.jp
>It is indeed a weak relationship, but when dealing with stakeholders' >requirements, why not?
Because I'd like to use the relationship in conjunction with the other
requirements relationships like <<derivedReq>>,<<refine>> and so on.
>since a requirement should never express the solution to the problem,
>but the problem itself.
I couldn't find such a definition in SysML specification.
In my opinion, relations between requirement and solution are relative.
Solutions for a stakeholder's requirement are requirements of the
system. Solutions for a system's requirement are requirements of the
sub system. Solutions for a sub system's requirement may be requirements
of the SW/HW or sub-sub system.
I think that there is NO design or implementation when you're analysing
the top level requirements.
Thanks
Dan George
participants will have good insight.
I have struggled with the distinction of a requirement describing a
problem and not the solution. I keep getting stuck with the notion
that the designation is a matter of perspective. I can say that a part
does X. Looking from the outside, X is a solution to a problem to be
of any use. Looking from the inside, my part is required to do X if it
is to be useful.
I really like the idea of restricting requirements to describe a
problem. It helps separate proposals that are just someones pet
solution from those that are truly the best for the customer. However,
when it comes to managing requirements I am tempted to link a
requirement of the system to a requirement of a subcomponent because,
well, if the component does what it purports to do then it solves my
system problem.
Some suggest using requirement for problem and "specification" for
solution. I find that unsatisfactory because it implies that I must
duplicate information just to have one of each kind. Also, SysML
doesn't have an element of type specification. However, if I say
requirements only describe a problem then what model element says what
a component will do? I'd like to think I can use external description
of the component and not have to delve into its implementation.
I bet you guys can help me out here.
Thanks,
Dan
Wagner Schalch
I totally agree that it is really difficult to get good
requirements. Specially, because stakeholders don't give them directly
to you. Usually, they already give you a solution for the problem. It
is part of the System Engineer job to get the needs and constraints
out of those sentences. It is a really difficult job. We must keep in
mind that requirements should not guide your solution to the problem,
but constrain it (i.e. limit the space to search for solutions). The
more solution-oriented your requirements are, the less options for a
solution you will have.
For sure, your stakeholders' requirements must be linked to your
system requirements that, in their turn, must be linked with subsystem
requirements and so on. That is the basic principle of traceability
and you should use the <<deriveRqt>> relationship. You must always
know why you are doing something, at any level of decomposition, and
that you can answer through requirements satisfaction (e.g.: One
subsystem is doing something because it satisfies certain
requirements).
That leads me to something you've mentioned. I qoute: "I can say
that a part does X". In this case, 'X' is a function performed by some
part of your system to satisfy a requirement. 'X' is not a requirement
itself. It's already the solution. When you say "specification", I can
imagine the functional specification of your system. You can use
activities in activity diagrams to state what your system will do to
satisfy certain requirements (some requirements are satisfied by other
things rather than functions). An 'Activity' is the model element in
SysML that you could use to specify a function a component will do. To
do so, you use the <<allocate>> relationship between the activity and
the component (a block). This is one possibility among others.
Best regards,
Wagner
Remy Fannader
Then, you take very different use cases and verify that the distinction can always be made unambiguously.
For instance (1) shooting down a missile and (2) forclosing on a mortgage. In both cases requirements will define user interfaces, inputs, expected outputs, and timing constraints.
Remy Fannader
"Problem" and "Solution" are much too general to be of any help. For both examples above (missile and mortgage) problems and solutions are defined by stakeholders. Requirements describe how the system will HELP with the solution.
Wagner
Remy Fannader
All depends on what we mean by solution. For example, how to decide about a mortgage forclosure or firing a missile are solutions, and system analysts have nothing to say about it.
That the reason why I'm not at ease with the Problem/Solution approach: usually it doesn't give a clear answer.
Regards.
Dan George
keep coming to the conclusion that terms problem or solution are
relative to perspective. That would be okay as long as the perspective
is called out. Still, I feel like I'm missing something valuable
because so many people use to the terms as absolutes.
Respectfully,
Dan
On Jun 29, 11:38 am, Remy Fannader <cami...@gmail.com> wrote:
> Hi Wagner,
> All depends on what we mean by solution. For example, how to decide about a
> mortgage forclosure or firing a missile are solutions, and system analysts
> have nothing to say about it.
> That the reason why I'm not at ease with the Problem/Solution approach:
> usually it doesn't give a clear answer.
> Regards.
>
>
>
>
>
>
>
>
> > **
>
> > I respectfully disagree with your opinion. It is up to you, as a system
> > engineer, to get the good requirements from the stakeholders. If they state
> > the solution, you should try to find the real need behind it and then you
> > will find the problem to solve. Requirements don't help the solution. On the
> > contrary, if you didn't have any requirement, you could provide any solution
> > to the problem. Requirements constrain the search space for solutions.
>
> > Regards,
> > Wagner
>
> > ----- Original Message -----
> > *To:* sysml...@googlegroups.com
> > *Sent:* Tuesday, June 28, 2011 2:26 PM
> > *Subject:* Re: [SysML Forum] Re: Question about usage of
>
> > @Wagner,
> > "Problem" and "Solution" are much too general to be of any help. For both
> > examples above (missile and mortgage) problems and solutions are defined by
> > stakeholders. Requirements describe how the system will HELP with the
> > solution.
>
>
> read more »
David Oliver
Requirements define a solution space in the sense that the solution must meet and satisfy the requirements. The problem space is defined through the
effectiveness measures, optimization crieria, CTQ's - what ever you wish to call them. A time keeping clock is the solution to a time keeping requirement. An atomic clock is an
optimized design that meets optimization concerns that may include robustness, transportability, accuracy, etc. They open the solution to exploration as a problem space.
DAve Oliver
Remy Fannader
So, what about forclosing a morgtage or firing a missile ? who should give the solution ?
Rémy.
Szewczyk Beniamin
Sent from Brembo BlackBerry®
Inviato: Friday, July 01, 2011 05:55 AM
A: sysml...@googlegroups.com <sysml...@googlegroups.com>
Oggetto: Re: [SysML Forum] Re: Question about usage of <<refine>>,<<satisfy>> relationship
This e-mail and any attachments is confidential and intended for the addressee(s) only. Access to this email by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail.
Whilst Brembo Group companies take reasonable care to ensure that any attachment to this e-mail does not contain software viruses, this cannot be guaranteed and you should therefore carry out your own virus checks before opening any attachment.
Brembo Group companies accept no responsibility or liability for any damage that you suffer as a result of software viruses.
David Oliver
Folks,
It sounds like folks are wrestling with the basic relationships between a solution space, problem space and requirements. We are in the biz of crafting systems that resolve problems. Here is a link to few slides that discuss the topic.
The problem just plane exists. The problem was there even before we showed up on the scene. It is the starting point for our investigation. The problem is completely independent of any requirements that may be written. In fact the problem knows nothing of the requirements. Now the requirements on the other hand rely heavily on the problem space. The properties and their relationships that we described in the problem space model form the basic vocabulary for our requirements. Generally the problem space is first thing I model, well maybe I might start with a context diagram, it’s a tossup.
As for solution spaces, one things we all have observed is that there many different designs can satisfy a single set of requirements, some solutions are good and some of which are not so good. For example if our requirement is to break a window a slingshot or a BB gun are both dandy solutions. However the solution space for the sling shot is very different than the solution space for the BB gun.
One last topic, Dad’s favorite, how to find the effectiveness measures that are needed for the trade-off analysis between candidate solutions. My experience is the best and simplest measures can often be found in your models of the problem space, and the solution spaces of each candidate solution as well as the project space which is also a good thing to model .
Dave M Oliver (younger and better looking)
Remy Fannader
It sounds like you just don't know how to answer the question...
Rémy
Dan George
thanks for putting together the slides. They illustrate the issue of
perspective because moving the rock might be the solution to using the
field for crops. From that perspective, the move the rock requirement
is a solution and <<satisfies>> a part of the problem of preparing the
field for cultivation. Likewise, obtain a mammoth becomes a problem to
be solved within the context of the mammoth option. Each problem
solved leads to more problems to solve. The solution at one level
becomes the problem at the next.
Dan
On Jul 2, 7:23 am, David Oliver <dmodmo...@gmail.com> wrote:
> Folks,
>
> It sounds like folks are wrestling with the basic relationships between a
> solution space, problem space and requirements. We are in the biz of
> crafting systems that resolve problems. Here is a link to few slides that
> discuss the topic.
>
> > *Inviato*: Friday, July 01, 2011 05:55 AM
> > *A*: sysml...@googlegroups.com <sysml...@googlegroups.com>
> > *Oggetto*: Re: [SysML Forum] Re: Question about usage of
>
> > Dave O.
> > So, what about forclosing a morgtage or firing a missile ? who should give
> > the solution ?
> > Rémy.
>
>
> read more »
D Smith CSEP
I feel that Dave gave an excellent snapshot of separating the areas of the development process and how they can influence each other. The PowerPoint example is very illustrative while being humorous as well. Some of the parameters might seem outrageous, but they make the point that we frequently completely fail to consider important issues, such as the political ones.
Just consider all the current political “issues” over the seemingly simple yes/no answer to the question of whether to raise the debt ceiling for the US. All these political issues (primarily along party lines and many based on bad assumptions, i.e., BOGUS) are essentially outside the basic question and relate to another problem space: dealing with how to manage the debt problem. These two problems have different time constraints for solving and affect the particular solution to each.
Probably one of the first and most important questions to ask is “Are the benefits to solving the problem worth the cost?” One example of where two different answers were pursued was the supersonic transport (circa 1950). The US decided the cost to benefit ratio was too high while the Concorde consortium charged ahead. History tells us which one was the better answer.
Regards
Darold K. Smith
PE (Software, Computer, and Electrical Engineering, Inactive)
903 217-8259 (M)
903 883-0124 (H)
Jack Ring
D Smith CSEP
You see, an obvious and yet overlook consideration!
Darold K. Smith
PE (Software, Computer, and Electrical Engineering, Inactive)
CSEP (INCOSE Certified Systems Engineering Professional Emeritus)