I am learning SySML. I am attempting to build a requirements diagram and then build relations between requirements and model elements.
Questions:
1) What are some good practices for Naming requirements? 2) How is the "Name" of a requirement typically used by stakeholders?
Background: I am currently struggling with how detailed to make the name. Not too detailed and not too vague. I either end up with a detailed repeat of the requirement text or a simple two word phase that becomes a "category" for a collection of similar requirements. I have not been able to reach a just right name, just yet. If I have a better understanding of how the requirement name is used by stakehoders, I may be able to better identify naming standards.
a good practice is to choose a name for a requirement that is a kind of
summary or abstraction of the detailed description which is assigned to the
"text" attribute.
For example: if you have a requirement "The system shall wipe the
windscreen automatically if waterdrops are detected on its surface.", a
good name could be "Rain detection".
If your system shall be compliant to a standard, a norm, etc., the
requirements text could be like "The system shall be compliant to ISO 61508
'Functional Safety of Electrical/Electronic/Programmable Electronic
Safety-related Systems*'*" and its name is "ISO 61508 Compliancy".
Don't use the name just for a requirements category. This should be done by
introducing new attributes with the help of the stereotype mechanism.
> I am learning SySML. I am attempting to build a requirements diagram and
> then build relations between requirements and model elements.
> Questions:
> 1) What are some good practices for Naming requirements?
> 2) How is the "Name" of a requirement typically used by stakeholders?
> Background: I am currently struggling with how detailed to make the
> name. Not too detailed and not too vague. I either end up with a detailed
> repeat of the requirement text or a simple two word phase that becomes a
> "category" for a collection of similar requirements. I have not been able
> to reach a just right name, just yet. If I have a better understanding of
> how the requirement name is used by stakehoders, I may be able to better
> identify naming standards.
> Thanks for your help.
> --
> 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 sysmlforum@googlegroups.com
> To unsubscribe from this group, send email to
> sysmlforum+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
Another challenge is changing the way our team references requirements. Previously, a requirement had a unique id (sequential number) and plain text. When we discussed requirements, we grouped them by common functionality and then referenced the unique id. The unique id did not change through out the life of the requirement. I could tack changes to a requirement based on the unique id.
With a SySML tool, there is a number, name, and text attribute. When using a tool to implement SySML requirements, the Name attribute, aside from just describing the text of the requirement, is ALSO the unique id. During the creation of requirements, the tool managed number is subject to change based on Containment hierarchy or manual renumbering. We are working to develop a methodology to uniquely reference each requirement. We will have to rely on Name rather than a unique number id. Will also need to better understand how to Package requirements, number them and use the containment hierarchy to manage requirements across their life cycle..
Thanks again for advice based on your team's experience.
On Sunday, September 23, 2012 5:15:38 AM UTC-4, Stephan Roth wrote:
> Hi MattS,
> a good practice is to choose a name for a requirement that is a kind of > summary or abstraction of the detailed description which is assigned to the > "text" attribute.
> For example: if you have a requirement "The system shall wipe the > windscreen automatically if waterdrops are detected on its surface.", a > good name could be "Rain detection".
> If your system shall be compliant to a standard, a norm, etc., the > requirements text could be like "The system shall be compliant to ISO 61508 > 'Functional Safety of Electrical/Electronic/Programmable Electronic > Safety-related Systems*'*" and its name is "ISO 61508 Compliancy".
> Don't use the name just for a requirements category. This should be done > by introducing new attributes with the help of the stereotype mechanism.
>> I am learning SySML. I am attempting to build a requirements diagram and >> then build relations between requirements and model elements.
>> Questions:
>> 1) What are some good practices for Naming requirements? >> 2) How is the "Name" of a requirement typically used by stakeholders?
>> Background: I am currently struggling with how detailed to make the >> name. Not too detailed and not too vague. I either end up with a detailed >> repeat of the requirement text or a simple two word phase that becomes a >> "category" for a collection of similar requirements. I have not been able >> to reach a just right name, just yet. If I have a better understanding of >> how the requirement name is used by stakehoders, I may be able to better >> identify naming standards.
>> Thanks for your help.
>> -- >> 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<javascript:> >> To unsubscribe from this group, send email to >> sysmlforum+...@googlegroups.com <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
On Sunday, September 23, 2012 11:15:38 AM UTC+2, Stephan Roth wrote:
> Hi MattS,
> a good practice is to choose a name for a requirement that is a kind of > summary or abstraction of the detailed description which is assigned to the > "text" attribute.
> For example: if you have a requirement "The system shall wipe the > windscreen automatically if waterdrops are detected on its surface.", a > good name could be "Rain detection".
I think, that giving an requirement a name is kind of hard, since e.g. "Rain Detection" already is somewhat vague or general, considering the fact, that there might be more requirements for rain detection. At least, when I compare that with the SW Requirements Spec I'm handling right now. Requirements should be small, simple, almost atomic. e.g There could be another requirement "The rain detection shall start after IG-ON and engine running and stop at IG-OFF." I wonder, if the "ID" wouldn't be a better "Name", but that would make one of it obsolete. The next question on that topic is, where does the ID come from? (Considering the Automotive world, requirements are usually handled within DOORS). But without an DOORS gateway, or being offline, who is giving unique IDs?
> If your system shall be compliant to a standard, a norm, etc., the > requirements text could be like "The system shall be compliant to ISO 61508 > 'Functional Safety of Electrical/Electronic/Programmable Electronic > Safety-related Systems*'*" and its name is "ISO 61508 Compliancy".
That makes me worry about the requirements quality. If I just reference compliance to the ISO spec. what are the actual requirements for your system, to fulfill that spec.?
> Don't use the name just for a requirements category. This should be done > by introducing new attributes with the help of the stereotype mechanism.
> On Sunday, September 23, 2012 11:15:38 AM UTC+2, Stephan Roth wrote:
> Hi MattS,
> a good practice is to choose a name for a requirement that is a kind of summary or abstraction of the detailed description which is assigned to the "text" attribute.
> For example: if you have a requirement "The system shall wipe the windscreen automatically if waterdrops are detected on its surface.", a good name could be "Rain detection".
> I think, that giving an requirement a name is kind of hard, since e.g. "Rain Detection" already is somewhat vague or general, considering the fact, that there might be more requirements for rain detection. At least, when I compare that with the SW Requirements Spec I'm handling right now.
> Requirements should be small, simple, almost atomic.
> e.g There could be another requirement "The rain detection shall start after IG-ON and engine running and stop at IG-OFF."
> I wonder, if the "ID" wouldn't be a better "Name", but that would make one of it obsolete.
> The next question on that topic is, where does the ID come from? (Considering the Automotive world, requirements are usually handled within DOORS).
> But without an DOORS gateway, or being offline, who is giving unique IDs?
> If your system shall be compliant to a standard, a norm, etc., the requirements text could be like "The system shall be compliant to ISO 61508 'Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems'" and its name is "ISO 61508 Compliancy".
> That makes me worry about the requirements quality. If I just reference compliance to the ISO spec. what are the actual requirements for your system, to fulfill that spec.?
> Don't use the name just for a requirements category. This should be done by introducing new attributes with the help of the stereotype mechanism.
> Hope that helps a bit.
> For me not really, sorry. :(
> Regards,
> kessel
> -- > 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 sysmlforum@googlegroups.com
> To unsubscribe from this group, send email to
> sysmlforum+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
On Sunday, September 23, 2012 11:15:38 AM UTC+2, Stephan Roth wrote:
>> Hi MattS,
>> a good practice is to choose a name for a requirement that is a kind of >> summary or abstraction of the detailed description which is assigned to the >> "text" attribute.
>> For example: if you have a requirement "The system shall wipe the >> windscreen automatically if waterdrops are detected on its surface.", a >> good name could be "Rain detection".
> I think, that giving an requirement a name is kind of hard, since e.g. > "Rain Detection" already is somewhat vague or general, considering the > fact, that there might be more requirements for rain detection. At least, > when I compare that with the SW Requirements Spec I'm handling right now.
> Requirements should be small, simple, almost atomic.
You're right, requirements should be small, simple, understandable, almost atomic, verifiable, free of solutions (ideally), etc. ..., but please keep in mind, that there are different levels of abstraction, and requirements typically constitute a hierarchy!
In many projects user-requirements (a.k.a stakeholder requirements) builds the top-level of the requirements hierarchy. They are mostly a kind of unspecific and often too big and heavy for developers to handle them. "The system shall be compliant to ISO 61508 'Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems*'"* is an good example for such kind of non-functional top-level requirement*.*
Over the projects lifetime, user requirements must be analyzed and refined. The next level of requirements are system requirements, followed by sub-system and component requirements (just an example hierarchy). On each step of refinement you should follow the "Single Level of Abstraction" principle, i.e. on each of those levels, you should avoid to mix requirements of different abstraction and granularity.
SysML provides several relationships to build a requirements hierarchy, like containment, trace, and derive («deriveReqt»).
e.g There could be another requirement "The rain detection shall start
> after IG-ON and engine running and stop at IG-OFF."
> I wonder, if the "ID" wouldn't be a better "Name", but that would make > one of it obsolete.
I don't think that the identifier makes the requirements name obsolete. An ID has no meaning, it is only a unique attribute, often just consecutively numbered.
> The next question on that topic is, where does the ID come from? > (Considering the Automotive world, requirements are usually handled within > DOORS).
> But without an DOORS gateway, or being offline, who is giving unique IDs?
This is a tool-specific problem. Many SysML modeling tools have a function for automatic ID assignment to requirements and other model elements. Of course, this topic is not trivial if you are working with different tools in an complex environment.
>> If your system shall be compliant to a standard, a norm, etc., the >> requirements text could be like "The system shall be compliant to ISO 61508 >> 'Functional Safety of Electrical/Electronic/Programmable Electronic >> Safety-related Systems*'*" and its name is "ISO 61508 Compliancy".
> That makes me worry about the requirements quality. If I just reference > compliance to the ISO spec. what are the actual requirements for your > system, to fulfill that spec.?
See above: hierarchical decomposition. Once you've started with the analysis of those top-level requirements you will come to a point, where requirements without a system design are not sufficient enough to go ahead. You feel the need of a first draft of the subsystem-structure of your system. After you've modeled this first level you'll get a better feeling for the next level of requirements. This procedure - a zig-zag pattern between requirements and system design - will continue until your system design is adequate and requirements are on a detailed level satisfying your and your engineers needs. It is an iterative-incremental process.
On Friday, November 2, 2012 11:55:20 AM UTC+1, Stephan Roth wrote:
> Hello kesselhaus,
> Am Donnerstag, 1. November 2012 18:24:32 UTC+1 kesselhaus wrote:
> On Sunday, September 23, 2012 11:15:38 AM UTC+2, Stephan Roth wrote:
>>> Hi MattS,
>>> a good practice is to choose a name for a requirement that is a kind of >>> summary or abstraction of the detailed description which is assigned to the >>> "text" attribute.
>>> For example: if you have a requirement "The system shall wipe the >>> windscreen automatically if waterdrops are detected on its surface.", a >>> good name could be "Rain detection".
>> I think, that giving an requirement a name is kind of hard, since e.g. >> "Rain Detection" already is somewhat vague or general, considering the >> fact, that there might be more requirements for rain detection. At least, >> when I compare that with the SW Requirements Spec I'm handling right now.
>> Requirements should be small, simple, almost atomic.
> You're right, requirements should be small, simple, understandable, almost > atomic, verifiable, free of solutions (ideally), etc. ..., but please keep > in mind, that there are different levels of abstraction, and requirements > typically constitute a hierarchy!
> In many projects user-requirements (a.k.a stakeholder requirements) builds > the top-level of the requirements hierarchy. They are mostly a kind of > unspecific and often too big and heavy for developers to handle them. "The > system shall be compliant to ISO 61508 'Functional Safety of > Electrical/Electronic/Programmable Electronic Safety-related Systems*'"*is an good example for such kind of non-functional top-level requirement
> *.*
> Over the projects lifetime, user requirements must be analyzed and > refined. The next level of requirements are system requirements, followed > by sub-system and component requirements (just an example hierarchy). On > each step of refinement you should follow the "Single Level of Abstraction" > principle, i.e. on each of those levels, you should avoid to mix > requirements of different abstraction and granularity.
> SysML provides several relationships to build a requirements hierarchy, > like containment, trace, and derive («deriveReqt»).
> I agree up to here, also to the levels of requirement analysis.
My concern about the "Name" like "Rain Detection" was actually that this "short name" is something to get harder and harder, once you get more and more detailed within your requirements spec.
Say, you start with the first requirement of "Rain Detection". Then, next hierarchy, you break them down to more specific ones. In DOORS you would make up an Heading1, Heading2 .. (comparable to chapter, section, subsection) to order them.
In SysML you would probably use the containment req_1 (+)--->req_1_1.
But what is with the name .. do you call them then RainDetection_1, RainDetection_2, RainDetection_1_1?
I mean, since a <<Requirement>> is specializing a class, you need to give them a name, but that should also be something useful and not too long, since you want to have them in a diagram, which you still want to look on without much scrolling and zooming.
e.g There could be another requirement "The rain detection shall start
>> after IG-ON and engine running and stop at IG-OFF."
>> I wonder, if the "ID" wouldn't be a better "Name", but that would make >> one of it obsolete.
> I don't think that the identifier makes the requirements name obsolete. An > ID has no meaning, it is only a unique attribute, often just consecutively > numbered.
So is the name attribute. It is unique, at least within a package. But with the full hierarchy (fully qualified name) it is unique too.
>> The next question on that topic is, where does the ID come from? >> (Considering the Automotive world, requirements are usually handled within >> DOORS).
>> But without an DOORS gateway, or being offline, who is giving unique IDs?
> This is a tool-specific problem. Many SysML modeling tools have a function > for automatic ID assignment to requirements and other model elements. Of > course, this topic is not trivial if you are working with different tools > in an complex environment.
>>> If your system shall be compliant to a standard, a norm, etc., the >>> requirements text could be like "The system shall be compliant to ISO 61508 >>> 'Functional Safety of Electrical/Electronic/Programmable Electronic >>> Safety-related Systems*'*" and its name is "ISO 61508 Compliancy".
>> That makes me worry about the requirements quality. If I just reference >> compliance to the ISO spec. what are the actual requirements for your >> system, to fulfill that spec.?
> See above: hierarchical decomposition. Once you've started with the > analysis of those top-level requirements you will come to a point, where > requirements without a system design are not sufficient enough to go ahead. > You feel the need of a first draft of the subsystem-structure of your > system. After you've modeled this first level you'll get a better feeling > for the next level of requirements. This procedure - a zig-zag pattern > between requirements and system design - will continue until your system > design is adequate and requirements are on a detailed level satisfying your > and your engineers needs. It is an iterative-incremental process.
Well, I had a project, where I had to go with the drafts of an system spec, several customer specs (for different topics), and my expertise of the previous generation system. The time schedule was so tight, that we could not do the ideal analysis, since the final system requirements spec was available half the project time to make up the analysis and linking of the SRS. That much to theoretical and practical work. :(
Also something that I like on tools like DOORS (even though, I do not like it very much), is the fact, that you can textual requirements, but also pictures.
E.g. customer has some timing diagram of signals, or some kind of state machine of the system states and their transitions. I wonder, how SysML tools can handle that, since the actual requirement is in the attribute "text" of type "String".
I still hope for better tools (e.g. I still wonder, why a lot of UML2 tools still do not support the Timing Diagram).
I also found the SysML flowports with their in/out/inout semantic and their representation as arrows quite nice and easy to see and wonder, why they are now made obsolete in SysML 1.3.
Also, I find the distinction of SysML to systems engineering and not for SW development strange. Especially when I see my field in the embedded world being something in between the field. I do not really like to jump between several "languages" (like, here you have to use SysML and here you have to use UML) and SysML is just an extension of UML. As far as I understand the introduction to SysML, it extends UML, and does not strip it down.
Not to mention all the Model to Model transformations, XXX model-based approach to YYY etc.
A lot of my colleagues find modelling in e.g. Rhapsody more of a burden and a pain in the ass. We don't find stuff that easy as we did with usual coding in an editor. It's harder to edit, since you click here to edit this, and click here, there and somewhere else, just to get some simple things done.
And that's also something I why wonder, how practical it really is, to enter requirements in an UML like tool.
Do you guys really enter your requirements in an SysML tool, or do you just import from something like DOORS, and use SysML just to link them?
On Saturday, September 22, 2012 8:08:07 AM UTC-7, MattS wrote:
> I am learning SySML. I am attempting to build a requirements diagram and > then build relations between requirements and model elements.
> Questions:
> 1) What are some good practices for Naming requirements? > 2) How is the "Name" of a requirement typically used by stakeholders?
> Background: I am currently struggling with how detailed to make the > name. Not too detailed and not too vague. I either end up with a detailed > repeat of the requirement text or a simple two word phase that becomes a > "category" for a collection of similar requirements. I have not been able > to reach a just right name, just yet. If I have a better understanding of > how the requirement name is used by stakehoders, I may be able to better > identify naming standards.
