[OSLC] Link types for requirements

[Ian Green1]

Hello Andy,

There has yet been no such discussion in our work group - your posting 
raises some good questions that will need to be addressed during the 
specification phase, which is ongoing.

As far as "vetting" across OSLC, I am not aware of any such activity, or 
that OSLC anywhere (currently) defines link semantics. or indeed defines 
the link type names which SHOULD/SHALL be supported.

In addition to a CR on a requirement, we can also ask about a defect 
against a requirement.  I recall you expressed that a defect against an 
artefact was tantamount to a request to resolve that defect, so perhaps 
the former is a generalization of the latter, in this case.

best wishes,
    -ian

ian.green at uk.ibm.com (Ian Green1/UK/IBM at IBMGB)
Chief Software Architect, Requirements Definition and Management
IBM Rational



From:
Andrew J Berner/Dallas/IBM at IBMUS
To:
community at open-services.net, Ian Green1/UK/IBM at IBMGB
Date:
10/08/2009 11:32
Subject:
Link types for requirements


Some questions about the Link Resource definitions in 
http://open-services.net/bin/view/Main/RmResourceDefinitions 

I missed a meeting of the RM workgroup, so please forgive me if these 
questions have been answered already.

Was there discussion about a third link type pair,  between a requirement 
and a defect?  Like the "implementation" links, it links a requirement to 
a change request that says "change the system to meet the requirement" but 
the difference is whether there is "reason to believe" the requirement was 
already implemented.  This affects "triage"---"should we implement this 
requirement and if so when" vs. "when should we fix this defect?", roughly 
the difference between "enhancement" and "defect".  It's hard to be 
precise about the difference---in both cases the software does not meet 
the requirement and the requester thinks it should.  And we also know in 
practice it gets a bit "dicey"---one person's defect is often another's 
enhancement, but that's due to imprecision in the definition and 
management of the requirement in the first place.  But if we start talking 
about the lifecycle of a requirement, there certainly is a difference 
between "we haven't decided it's a requirement yet" or "we have decided 
it's a requirement, but the work to implement it hasn't been done" on the 
one hand, vs. "we thought we did implement the requirement correctly but 
it turns out we didn't."  Perhaps the difference is that with a defect, 
there's a "qualification" as we call it linked to the requirement that was 
actually run and failed---or that there was an implementation request for 
the requirement that was already in a state that indicated "it should be 
met".

My second question is whether all these links, plus the kind of 
distinctions I'm making above, have been "vetted" with the other relevant 
OSLC workgroups?  The "implements" relationship needs to be part of a 
ChangeRequest resource, for example---does the CM workgroup agree with the 
definition?

Third, have we discussed another link from requirement to change 
request---a request to change the requirement?

Andy Berner
Lead Architect, ISV Technical Enablement and Strategy
IBM Rational Business Development
972 561-6599
ajberner at us.ibm.com

Ready for IBM Rational software partner program - 
http://www.ibm.com/isv/rational/readyfor.html







Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090810/14157d6b/attachment-0003.html>