The purpose of this question is for me to understand the concept, I am well aware in practice I just do these things, regardless of how I call them.

Also, the famous paper from B. Boehm (GUIDELINES FOR VERIFYING AND VALIDATING SOFTWARE REQUIREMENTS AND DESIGN SPECIFICATIONS) makes a super clear distinction between validation and verification:

By definition, verification involves the comparison between the requirements baseline and the successive refinements descending from it—the product design, detailed design, code, database, and documentation--in order to keep these refinements consistent with the requirements baseline. Thus, verification activities begin in the Product Design phase and conclude with the acceptance Test. They do not lead to changes in the requirements baseline; only to changes in the refinements descending from it.

On the other hand, validation identifies problems which must be resolved by a change of the requirements specification. For example, a simulation of the product design may establish not only that the design cannot meet the baseline performance requirements (verification), but also that the performance requirements are too stringent for any cost-effective product designs, and therefore need to be changed (validation).

So far, so good - whenever I check anything against the requirements specification, I verify.

Therefore, requirement specification itself cannot be verified (as it would be compared to itself), and it is only validated - this is explicitly mentioned in the paper too:

This refers to the requirements specification which is developed and validated during the Plans and Requirements Phase, accepted by the customer and developer at the Plans and Requirements Review as the basis for the software development contract, and formally change-controlled thereafter.

So I thought I had understood it well. In the next section, the paper presents V&V Criteria for requirements and design specs, with the first one being Completeness:

  1. No TBDs
  2. No references to non-existing functions, inputs or outputs
  3. No missing spec. items ...

Then it reads that the first two can be verified automatically, while the other need to be verified or validated with some human intuition.

And here comes my confusion: Say I have received a requirement spec to be validated. So I start working and notice a reference to a non-existent element and also a statement "to be determined". Now, the paper speaks about verification of these properties but req.spec is only validated (as there is nothing to be verified against). How should I interpret it?

EDIT: I start to think that probably the author just did not want to repeat "verify or validate" all the time, as the whole section is called "V&V Criteria" and he made it clear earlier that requirements are validated, while successive documents are verified.

  • 2
    I like that you've put so much thought in to this... but what's the question? – trashpanda Mar 14 '19 at 9:30
  • 1
    @trashpanda Well, I tried to put in the last paragraph. If requirement specifications are just validated (as they have nothing to be verified against), why checking for TBDs or references to non-existing items is explicitly called verifying when this is something that surely can be done with requirements specs too? – John V Mar 14 '19 at 9:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.