I am new to the DXL world and am wondering if I can set an attribute based on another attribute and the linking information of the object. This is what I would like to do: I have one attribute IsRequirement and one DXL attribute Derived that I am trying to set automatically. If the attribute IsRequirement is equal to Yes Then If the object has an outlink then Set the attribute Derived to No Else Set the attribute Derived to Yes End If Else Set the attribute Derived to NA End If Is this something easy to do through DXL? If so, I would appreciate an example DXL script. It's really hard to find the information through the DXL reference manual. Thank you so much! yhisella - Fri Oct 03 18:34:54 EDT 2014 |
Re: Setting a dynamic attribute *babble on-> Just some remarks beforehand: In our projects we noticed that it is not such a good idea to set Derived automatically. Introducing a requirement on a lower engineering level is something which should always be done on purpose. If you set the attribute automatically, how will you ever know whether a req has been introduced intentionally or whether the user just forgot to draw a link? If I remember correctly, there is even one regulation in Aerospace where you explicitly sign that all "Derived" requirements are introduced intentionally and are correctly marked as such. We even asked our users to add a Rationale, whenever they marked a req as Derived and set up two filters: a) which reqs are not marked as derived but do not have an out link, b) which reqs are marked as derived and do not have a Rationale. The result of the filters had to be empty before the module could be released to the customer. <-babble off* Having said this, if you really want to go this way, you should at least care for the name of the link module that the link is drawn with. Not every out link of a requirement denotes that the current req refines the target req. So, create a DXL attribute (e.g. isDerived) and use the following code for a start.
|
Re: Setting a dynamic attribute Mike.Scharnow - Sat Oct 04 05:45:57 EDT 2014 *babble on-> Just some remarks beforehand: In our projects we noticed that it is not such a good idea to set Derived automatically. Introducing a requirement on a lower engineering level is something which should always be done on purpose. If you set the attribute automatically, how will you ever know whether a req has been introduced intentionally or whether the user just forgot to draw a link? If I remember correctly, there is even one regulation in Aerospace where you explicitly sign that all "Derived" requirements are introduced intentionally and are correctly marked as such. We even asked our users to add a Rationale, whenever they marked a req as Derived and set up two filters: a) which reqs are not marked as derived but do not have an out link, b) which reqs are marked as derived and do not have a Rationale. The result of the filters had to be empty before the module could be released to the customer. <-babble off* Having said this, if you really want to go this way, you should at least care for the name of the link module that the link is drawn with. Not every out link of a requirement denotes that the current req refines the target req. So, create a DXL attribute (e.g. isDerived) and use the following code for a start.
I know I get black hole vision sometimes, but I've never understood the notion that lower-level specs can "derive" a requirement without suitable justification from parent specs. As far as I can see, ALL derived requirements exist to satisfy some higher level requirement. And if so all lower level requirements must be "justified" by one or more higher level requirements. If you cannot justify such a requirement then you shouldn't be doing it. -Louie |
Re: Setting a dynamic attribute Check out Mike's solution; which is typical for attr-DXL. What you may not grasp is:
Notice his code does not loop through all objects. -Louie I have a preference for this construct:
This way you keep track of the base names of your link modules (in this case "Refines Requirements") but don't have to keep track of exactly where they exist in the Project, since "name" gets the base name without any folder path inforamtion. -Louie |
Re: Setting a dynamic attribute llandale - Mon Oct 06 10:19:28 EDT 2014 I know I get black hole vision sometimes, but I've never understood the notion that lower-level specs can "derive" a requirement without suitable justification from parent specs. As far as I can see, ALL derived requirements exist to satisfy some higher level requirement. And if so all lower level requirements must be "justified" by one or more higher level requirements. If you cannot justify such a requirement then you shouldn't be doing it. -Louie Yes, it's a strange wording. As far as I understood it, it means "derived from somewhere else, not from the higher requirement". There are various sources for these requirements: legal regulations, design requirements or just knowledge of the hired company who brings in its expertise, as it "knows more of the device to be designed than the customer, since it's specialized in creating such devices". I'm sure there are others out there who can explain it better :-) |
Re: Setting a dynamic attribute Mike.Scharnow - Mon Oct 06 11:12:18 EDT 2014 Yes, it's a strange wording. As far as I understood it, it means "derived from somewhere else, not from the higher requirement". There are various sources for these requirements: legal regulations, design requirements or just knowledge of the hired company who brings in its expertise, as it "knows more of the device to be designed than the customer, since it's specialized in creating such devices". I'm sure there are others out there who can explain it better :-) Never-the-less it seems to me they need to be "justified", even if that justification is "Tribal Knowledge". And it seems to me that such tribal knowledge is in fact written down and a de-fact "requirements" document. I'm saying I've run into a lot of folks who routinely allow "derived" requirements to have no actual justification. "Justified" requirements are those that have direct relationship to the parent; such as "weight". |
Re: Setting a dynamic attribute Mike.Scharnow - Sat Oct 04 05:45:57 EDT 2014 *babble on-> Just some remarks beforehand: In our projects we noticed that it is not such a good idea to set Derived automatically. Introducing a requirement on a lower engineering level is something which should always be done on purpose. If you set the attribute automatically, how will you ever know whether a req has been introduced intentionally or whether the user just forgot to draw a link? If I remember correctly, there is even one regulation in Aerospace where you explicitly sign that all "Derived" requirements are introduced intentionally and are correctly marked as such. We even asked our users to add a Rationale, whenever they marked a req as Derived and set up two filters: a) which reqs are not marked as derived but do not have an out link, b) which reqs are marked as derived and do not have a Rationale. The result of the filters had to be empty before the module could be released to the customer. <-babble off* Having said this, if you really want to go this way, you should at least care for the name of the link module that the link is drawn with. Not every out link of a requirement denotes that the current req refines the target req. So, create a DXL attribute (e.g. isDerived) and use the following code for a start.
Thank you so much for your response, Mike. I totally understand your concern over setting the Derived attribute this way. For this particular project I am working on, the requirements were already written with links established and reviewed. The Derived attribute was introduced later. In order to reduce the work load, I am thinking of automatically filling the attribute. But maybe a better way is to pass the module once with a DXL script, rather than setting Derived as a DXL attribute. After all, for new requirements, I do want to have the attribute manually filled, rather than automatically generated. I will need to play with the DXL attribute to understand it better. But given the script you provided for the IsDerived DXL attribute, will the attribute automatically change its value whenever I add an outlink to the object (with no prior outlinks), or do I need to trigger the change some way? |
Re: Setting a dynamic attribute llandale - Mon Oct 06 10:27:04 EDT 2014 Check out Mike's solution; which is typical for attr-DXL. What you may not grasp is:
Notice his code does not loop through all objects. -Louie I have a preference for this construct:
This way you keep track of the base names of your link modules (in this case "Refines Requirements") but don't have to keep track of exactly where they exist in the Project, since "name" gets the base name without any folder path inforamtion. -Louie Thank you so much for filling in the blanks, Louie. Your notes on Mike's solution are very helpful! I also appreciate your additional script noting the need to track the module name only vs the path information. |
Re: Setting a dynamic attribute yhisella - Tue Oct 07 12:20:27 EDT 2014 Thank you so much for your response, Mike. I totally understand your concern over setting the Derived attribute this way. For this particular project I am working on, the requirements were already written with links established and reviewed. The Derived attribute was introduced later. In order to reduce the work load, I am thinking of automatically filling the attribute. But maybe a better way is to pass the module once with a DXL script, rather than setting Derived as a DXL attribute. After all, for new requirements, I do want to have the attribute manually filled, rather than automatically generated. I will need to play with the DXL attribute to understand it better. But given the script you provided for the IsDerived DXL attribute, will the attribute automatically change its value whenever I add an outlink to the object (with no prior outlinks), or do I need to trigger the change some way? As Louie pointed out and I forgot to mention: my solution shows the DXL code for an Attribute DXL. This means that this is a "dynamic" attribute in the sense that the calculated value (true/false) is never actually stored in the module, only the DXL code is stored in the value, and whenever someone opens a view where this attribute is shown, the attribute value is recalculated "on-the-fly". In your case where the module is already filled, you should definitely use a script which is executed only once, and after it is finished, you have a valid module. So, you will have to adopt the script: - a) surround it with a loop like this:
Object oCurrent
Module m = current
for oCurrrent in entire m do {
if (isDeleted(oCurrent)) then continue
<insert other code here>
}
- b) replace "obj" with "oCurrent", which now is a variable that you defined yourself, not the predefined variable - c) replace "obj.attrDXLName =" with "oCurrrent.isDerived = ", because attrDXLName is not predefined here. - d) only when you are satisfied with your code, add a "save m" as a last statement. But perhaps it is better to manually save the module
Note that this solution is not feasible for baselines.
But to answer your question in case you still want to go with a DXL Attribute: yes, the displayed attribute value will change when you create a new link. You might have to start "tools -> refresh DXL attributes" to see the result. |
Re: Setting a dynamic attribute llandale - Mon Oct 06 10:19:28 EDT 2014 I know I get black hole vision sometimes, but I've never understood the notion that lower-level specs can "derive" a requirement without suitable justification from parent specs. As far as I can see, ALL derived requirements exist to satisfy some higher level requirement. And if so all lower level requirements must be "justified" by one or more higher level requirements. If you cannot justify such a requirement then you shouldn't be doing it. -Louie I will try to provide my answer from an engineering perspective. In general, you are right, all requirements exist to satisfy the parent requirements. Derived requirements are not introduced to implement a new function/feature (if that's the case, the new function needs to be added as new parent requirements). Rather, derived requirements come from implementation details. The function specified in a parent requirement can be implemented in multiple ways. The choice of one particular implementation is considered "derived" or at least partially derived and will require additional justification to ensure it's valid, correct and does not introduce unintended consequences. All details associated with the implementation, for example, how to handle redundant inputs, failure monitoring, fail safe setting, initial setting, and etc, are derived and cannot be traced to parent requirements directly. "Derived requirement" is just a term. The way I understand the term should be used, when a requirement is marked as derived, it requires additional validation beyond traceability to parent requirements. On the other hand, the way traceability is used is mostly for impact analysis. If a requirement requires change when any part of a parent requirement changes, it requires a trace to that parent requirement. So derived is not completely equal to a requirement without outlinks to parent requirement documents. But the minimum requirement at least for aerospace applications is that requirements without parent requirements need to be justified. |
Re: Setting a dynamic attribute Mike.Scharnow - Tue Oct 07 12:49:11 EDT 2014 As Louie pointed out and I forgot to mention: my solution shows the DXL code for an Attribute DXL. This means that this is a "dynamic" attribute in the sense that the calculated value (true/false) is never actually stored in the module, only the DXL code is stored in the value, and whenever someone opens a view where this attribute is shown, the attribute value is recalculated "on-the-fly". In your case where the module is already filled, you should definitely use a script which is executed only once, and after it is finished, you have a valid module. So, you will have to adopt the script: - a) surround it with a loop like this:
Object oCurrent
Module m = current
for oCurrrent in entire m do {
if (isDeleted(oCurrent)) then continue
<insert other code here>
}
- b) replace "obj" with "oCurrent", which now is a variable that you defined yourself, not the predefined variable - c) replace "obj.attrDXLName =" with "oCurrrent.isDerived = ", because attrDXLName is not predefined here. - d) only when you are satisfied with your code, add a "save m" as a last statement. But perhaps it is better to manually save the module
Note that this solution is not feasible for baselines.
But to answer your question in case you still want to go with a DXL Attribute: yes, the displayed attribute value will change when you create a new link. You might have to start "tools -> refresh DXL attributes" to see the result. Thank you Mike for explaining the concept of DXL attributes so well! I will take your suggestion and adopt your script to run it once on the module. This is what I need now. It's fun to learn something new and to see a door opened in DOORS :) Thanks also for answering my question on the refresh of the DXL attribute.
|
Re: Setting a dynamic attribute llandale - Mon Oct 06 12:22:25 EDT 2014 Never-the-less it seems to me they need to be "justified", even if that justification is "Tribal Knowledge". And it seems to me that such tribal knowledge is in fact written down and a de-fact "requirements" document. I'm saying I've run into a lot of folks who routinely allow "derived" requirements to have no actual justification. "Justified" requirements are those that have direct relationship to the parent; such as "weight". Hi all, just thought I would put my two cents in, as I work in the aviation business where we build software to RTCA DO-178B development guidelines. There is confusion on what is meant by derived. In the normal sense, Louie is right where a lower level requirement is derived from a higher level requirement and so that is why it is needed, to implement the higher level requirement. A typical example of that around here, is low level requirements derived from safety needs and these are called derived software requirements. However, DO-178B defines the meaning of derived in a different way. These are requirements that are needed but NOT directly traceable to higher level requirements. So the meaning is almost the opposite. In simplistic terms, like yhisella is trying to do with the dxl, if a requirement doesn't have a link to a higher level requirement, then it would seem that it must be a derived requirement. This is not the definition of derived and inexperienced people get in trouble with this. As Mike noted, the derived requirement needs to be justified why it is needed and not just some additional functionality that the developer thought would be good to do. From a DO-178B perspective, this justification is needed for safety reasons. The additional functionality may inadvertently affect the safety of the system. yhisella mentioned that these derived requirements may be do to implementation decisions. This is true, but there are other reasons why there might need to be derived requirements. Two simple examples are 1) requirements for defining the software execution like the main program. This does not do any of the functionality a program needs to do, but is necessary for operating the software on the target computer. The second example would be error handling. This might be done by interrupt handling or other means. Some of our derived requirements are due to error handling due to the particular interface in the design. What happens when a bus providing data is missing? This type of error handling is generally not detailed in the higher level requirements, but is a product of the system design. In many dxl programs, we do similar things like checking for an attribute existence, or a module is there (not null) before using it. After some experience, we just automatically know we need to do these things without thinking as to why it is needed. Hope this helps some, Greg |
Re: Setting a dynamic attribute GregM_dxler - Fri Oct 10 09:55:59 EDT 2014 Hi all, just thought I would put my two cents in, as I work in the aviation business where we build software to RTCA DO-178B development guidelines. There is confusion on what is meant by derived. In the normal sense, Louie is right where a lower level requirement is derived from a higher level requirement and so that is why it is needed, to implement the higher level requirement. A typical example of that around here, is low level requirements derived from safety needs and these are called derived software requirements. However, DO-178B defines the meaning of derived in a different way. These are requirements that are needed but NOT directly traceable to higher level requirements. So the meaning is almost the opposite. In simplistic terms, like yhisella is trying to do with the dxl, if a requirement doesn't have a link to a higher level requirement, then it would seem that it must be a derived requirement. This is not the definition of derived and inexperienced people get in trouble with this. As Mike noted, the derived requirement needs to be justified why it is needed and not just some additional functionality that the developer thought would be good to do. From a DO-178B perspective, this justification is needed for safety reasons. The additional functionality may inadvertently affect the safety of the system. yhisella mentioned that these derived requirements may be do to implementation decisions. This is true, but there are other reasons why there might need to be derived requirements. Two simple examples are 1) requirements for defining the software execution like the main program. This does not do any of the functionality a program needs to do, but is necessary for operating the software on the target computer. The second example would be error handling. This might be done by interrupt handling or other means. Some of our derived requirements are due to error handling due to the particular interface in the design. What happens when a bus providing data is missing? This type of error handling is generally not detailed in the higher level requirements, but is a product of the system design. In many dxl programs, we do similar things like checking for an attribute existence, or a module is there (not null) before using it. After some experience, we just automatically know we need to do these things without thinking as to why it is needed. Hope this helps some, Greg A software requirement "shall be coded in language XYZ" is "justified" by the higher requirement that this software run on that computer; or that there will be software at all. Such software must have a language. XYZ may be a controversial design decision, but it is still justified. If there is tribal knowlege, then I suggest "Tribal Knowlege" be one of the Tier1 requirement documents; and detailed requirements are justified by that. The problem with Unjustified requirements is "gold plating" requirement's creep; folks will insert stuff because they feel like it. You cannot easily tell which of the unjustified low-level requirements are .. well.. Required; and which are just additional features. And if all else fails and you end up with unjustified requirements, then hey make a text "Justification" attribute and type it in there. -Louie |