How to Analyses / Verify the Design Against Functional AND Non-Functional Requirements?
This is a potential problem caused by the architecture of DOORS Next and Quality Manager and probably the OSLC.
The first part of the problem is that DOORS Next uses the incorrectly defined 'validates' link [it should be 'verifies' according to the use and definition] between the RM and Quality Manager tool. The built-in link constraints require that this link is only used between the tools.
The second part of the problem is that Quality Manager provides only a means to 'verify' functional requirements. This may be a reflection of an OSLC weakness or error.
What about non-functional requirements? Clearly these don't require testing -- but they do require verification. The forms of evidence are typically studies, simulation output i.e. links to documents with the results and analysis. This could be set up with the RM component.
This then leaves us with a situation where the verification is handled differently between functional and non-functional requirements. The 'validation' link error prevents us from using the relationship properly and being able to distinguish between validation (e.g. of a model or requirement collection) and verification of the design against that set of requirement.
The problem if verification is split across two tools using different relationships [the QM tool requires 'validates' and the intra-RM links would use 'verifies'] is that I'm not sure that it is possible to analyse/view the collection in a single report.
How / has anyone else tackled this? From some of the responses to the OSLC error wrt 'validates' it doesn't seem that there is any appetite to correct it so we're stuck with a link constrain that is semantically incorrect.
One answer
The OSLC RM spec defines the property validatedBy as:
Expresses a validation relationship between entities, where the object entity in some way validates the subject entity. For example, a requirement collection may be said to be validated by a test plan.
Regarding functional vs. nonfunctional requirements, the same applies. Nonfunctional requirements are often validated by test cases, especially performance and scale. Running these kinds of test cases can verify that the requirements are met through the validating test cases.
Comments
Thanks
1) The OSLC defining validation and something that validates ... doesn't define what the term 'validates' or 'validation' actually means.
2) Looking at ISO 9000 via Wikipedia gives us 'https://en.wikipedia.org/wiki/Verification_and_validation' -
Verification is intended to check that a product, service, or system (or portion thereof, or set thereof) meets a set of design specifications.
This is the sense it is used in Systems Engineering. When we validate a model or simulation we compare its output against reality to check that it is a correct (valid) representation. Validation is not therefore the proving of the design against requirements. You might, however, validate the build against something like a bill of materials or similar.