I had to think about what a "defect against a requirement" would mean, since (in the way I'm using it) defect means "doesn't meet some requirement"....maybe instead there's a distinction between the "requirement intended" and the "description of the requirement"??
For example: If a requirement stated: "The user interface must be translated into English, French, German, and Chinese from its native Swedish" then a change request might be: "Add Japanese to the list of languages that the user interface must be translated into" and a defect might be: "Replace 'Chinese' with 'both Simplified Chinese and Traditional Chinese' " indicating that this was the intent of the original requirement as verified by the stakeholders, but there was a realization (maybe when a test case failed but was resolved as "works as designed") that the statement of the original requirement didn't properly capture the intent. Andy Berner Lead Architect, ISV Technical Enablement and Strategy IBM Rational Business Development 972 561-6599 [email protected] Ready for IBM Rational software partner program - http://www.ibm.com/isv/rational/readyfor.html Re: Link types for requirements Ian Green1 to: Andrew J Berner 08/10/2009 06:57 AM Cc: community 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 [email protected] (Ian Green1/UK/IBM@IBMGB) Chief Software Architect, Requirements Definition and Management IBM Rational From: Andrew J Berner/Dallas/IBM@IBMUS To: [email protected], Ian Green1/UK/IBM@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 [email protected] Ready for IBM Rational software partner program - http://www.ibm.com/isv/rational/readyfor.html
