Issue 12751: use of derived in Requirements (sysml-rtf)
Source: NIST (Mr. Peter Denno, peter.denno(at)nist.gov)
Nature: Bug
Severity: Minor
Summary: 16.3.2.3:


(2) /derived: Requirement [0..1]
Derived from all requirements that are the client of a «deriveReqt» 
relationship for which this requirement is a supplier.


I don't think we can write OCL to derive this value, at least not 
without knowledge of the population of Requirements in which this 
instance is situated. How would we navigate from this object, a 
Requirement, to that population? I note that the version of the 
profile XMI I am using doesn't declare this property as derived. It 
appears that at least one SysML tool provider didn't derive it, but 
maintains it in their tool and XMI. 


I think something like the above criticism can be leveled against all 
of the 
attributes /satisfiedBy, /verifiedBy, /tracedTo, /derived, /derivedFrom, /refinedBy, /master 
that are declared derived in the spec 08-05-16. Perhaps we ought to 
remove the '/' and use a word other than "derived" in describing 
these attributes. 


Likewise 16.3.2.4 RequirementRelated attributes should not be declared 
derived.


It may be the case that the OMG needs to be clearer regarding what it 
means by "derived." There are attributes whose *definition* can be 
expressed in OCL and there are attributes whose value can only be 
found by some (perhaps vaguely specified) analysis of the Model (if 
Model is the correct context!). The latter notion is, I think, what 
you intend throughout Clause 16. That's fine, except I don't think 
the attributes for which this notion applies should be annotated with 
the slash. Further, it may be useful to identify what population is 
being considered when using terms like "all requirements."

Resolution: 
Revised Text: 
Actions taken:
August 7, 2008: received issue
Discussion: 
This issue is being deferred because no proposed resolution was voted on during
the schedule of the SysML 1.3 RTF.
Disposition: Deferred
End of Annotations:=====
te: Thu, 7 Aug 2008 14:14:35 -0400
From: nobody@omg.org
To: juergen@omg.org
SUBJECT: New Issue Submitted 


FIRST_NAME Peter 
LAST_NAME Denno 
LIST_NAME sysml-rtf 
ISSUE_NAME use of derived in Requirements 
NATURE Bug 
SEVERITY Minor 
ISSUE_STATUS Unresolved 
UPDATED_SPEC  
PROBLEM_DESCRIP 16323: 
 
 
(2) /derived: Requirement [01] 
Derived from all requirements that are the client of a «deriveReqt»  
relationship for which this requirement is a supplier 
 
 
I don't think we can write OCL to derive this value, at least not  
without knowledge of the population of Requirements in which this  
instance is situated How would we navigate from this object, a  
Requirement, to that population? I note that the version of the  
profile XMI I am using doesn't declare this property as derived It  
appears that at least one SysML tool provider didn't derive it, but  
maintains it in their tool and XMI  
 
 
I think something like the above criticism can be leveled against all  
of the  
attributes /satisfiedBy, /verifiedBy, /tracedTo, /derived, /derivedFrom, /refinedBy, /master  
that are declared derived in the spec 08-05-16 Perhaps we ought to  
remove the '/' and use a word other than "derived" in describing  
these attributes  
 
 
Likewise 16324 RequirementRelated attributes should not be declared  
derived 
 
 
It may be the case that the OMG needs to be clearer regarding what it  
means by "derived" There are attributes whose *definition* can be  
expressed in OCL and there are attributes whose value can only be  
found by some (perhaps vaguely specified) analysis of the Model (if  
Model is the correct context!) The latter notion is, I think, what  
you intend throughout Clause 16 That's fine, except I don't think  
the attributes for which this notion applies should be annotated with  
the slash Further, it may be useful to identify what population is  
being considered when using terms like "all requirements" 
 
DISCUSSION  
RESOLUTION  
REVISED_TEXT  
CODE 3TMw8