2

Doing a lot of reading about V&V, I would need to clarify the following. A lot of definitions (less formal ones found in books) define verification like that:
Verification: The software should conform to its specification.
But then they speak about requirement verification, design verification etc. If I say that these items are "software" in terms of applying the definitions, what should I checked them against? What specification should requirements, which is the basic information, conform to?

And one more thing: shouldn't requirements also be validated? To make sure they meet the customer needs? All texts I have, speak only about SW validation on the end of the development process!

EDIT: Just to make it clearer, my main question is how the definition of verification apply to requirements. The bookss or e.g. ISO 12207:2008 mention that verification is a process that the product reflect the requirements. One of the process is requirements spec review. But how can requirements conform to requirements?

Improve this question

5 Answers 5

Reset to default
4

It depends how are the terms defined in the book you are using. In wikipedia there is an interesting text about SW Verification.

For me validation of requirements basically means that requirements are clear enough for the customer and the organisation that is going to deliver SW so that they can make a formal deal. Of course the validation process is not so simple. I know projects where QA teams read requirements to validate their correctness. Here you have example of checklist for requirements I use:

  • clarity
  • unambiguity
  • feasibility
  • provability
  • consistency
  • necessity
  • free of redundancy
Improve this answer
2

Requirements can be validated for consistency. It's perfectly possible (and unfortunately even common) for a longer requirements document to contradict itself in places. This would make it impossible for any of the next steps in the sequence to conform to the requirements, so validating the requirements themselves is the obvious and important first step.

Improve this answer
2
  • The thins is, is it the validation or verification? Validation should only apply against customer needs, so I would say that would be verification.
    – John V
    Commented Sep 12, 2012 at 13:03
  • @user970696 - the internal inconsistency is often due to conflicting customer needs.
    – Joris Timmermans
    Commented Sep 12, 2012 at 13:09
0

One of the best validations for a requirement, if you're going to do verification, is that it can be verified. How would you verify these:

  • The system will be responsive and fluid
  • The user interface will be intuitive
  • The system will be easily adaptable in the case of future changes

I see these sorts of things in requirements all the time. If you actually intend to have a pass through all the requirements one by one and say "yes, I confirm that requirement 124 has been met" then the statements above don't get to be requirements (and I'm not just talking about shall/will issues.) They're not testable.

What is testable? This sort of thing:

  • There will be a menu to enable users to choose a report
  • There will be a screen to enter a new customer. It will have the following fields: blah, blah, blah, blah for pages and pages
  • Only managers will be able to set an order's priority (this one needs two tests: one that a manager can, and one that non-managers can't)
  • Sales tax will be calculated as follows: [half page thing about in/out of state/province and all the other complicated stuff for sales taxes)

Each requirement should lead to at least one test that you would use to verify the software against it.

The only problem with writing requirements this way is that they become enormously long and repetitive. Ordinary users will refuse to read them after a few iterations, and the risks increase that your developers will produce something that meets all the requirements, but that nobody wants. Somthing to be aware of.

Improve this answer
6
  • 1
    "the risks increase that your developers will produce something that meets all the requirements, but that nobody wants," is a great example of why the difference between verification and validation is important. Also, just to elaborate on your explanation of how to test quality and/or non-functional requirements, the original poster can see House of Quality for an example on how to map non-functional requirements to functional requirements.
    – David Kaczynski
    Commented Sep 12, 2012 at 11:43
  • Re The only problem with writing requirements this way, that's far from the "only" problem. Another is that the requirements as originally written are oftentimes wrong, but the problem is only found during design or development. At some point in the process, people tend to stop going back to fix those faulty requirements. Waterfall would work great if only we could foresee the design and development processes perfectly. But we can't.
    – David Hammen
    Commented Sep 12, 2012 at 12:31
  • Thanks, however, I mainly asked about the difference between verification and validation for requirements. If verification process means "The software should conform to its specification", what should the spec conform to?
    – John V
    Commented Sep 12, 2012 at 13:05
  • @user970696 My understanding is that there are no rigid specifications for requirements in general. As Marcin Sanecki points out, verifying requirements (and validating, for what it's worth) can be done through checklists and auditing. It largely depends on how your organization defines requirements. You may be able to generalize specifications for certain types of requirements, for example, a functional requirement should be testable. To validate a functional requirement, an auditor may check to see that it is directly traceable to the customer's needs.
    – David Kaczynski
    Commented Sep 12, 2012 at 13:34
  • @David Kaczynski: Thanks, but I have troubles with the general understanding: if I should verify whether the requirements conforms to the specification, what does it mean?
    – John V
    Commented Sep 12, 2012 at 17:08
0

My understanding:

Verification: Software should conform to its specification.

I would say, according to ISO, that it applies to product of any development phase. That would match to the activities described in the ISO (Code review, Design review). i.e:

  • Code should conform to design and standards
  • Design should conform to requirements
  • Requirements should conform to "documents from users describing their needs". I do not know the name for this document.

But I must admit, I am not sure about the last one and how applying standards fits to the definiton of "Verification" in the ISO. I would be happy for comments claryfiing that.

Improve this answer
0

It means that you need to define your own specifications and verify requirements against those. There are many types of requirements:

  • customer requirements
  • operational requirements
  • architecture requirements
  • quality requirements
  • interface requirements
  • functional/non-functional requirements
  • product/product component requirements

The list goes on, and as reality would have it, each of these types are open to interpretation. I believe that what the ISO standard is trying to say is that there should be some effort to create specifications for your requirements (like an audit checklist, as Marcin Sanecki points out), but how you do that is up to you.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.