Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
add comment

5 Answers

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.

share|improve this answer
    
The thins is, is it the validation or verification? Validation should only apply against customer needs, so I would say that would be verification. –  user970696 Sep 12 '12 at 13:03
    
@user970696 - the internal inconsistency is often due to conflicting customer needs. –  Joris Timmermans Sep 12 '12 at 13:09
add comment

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
share|improve this answer
add comment

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.

share|improve this answer
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 Sep 12 '12 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 Sep 12 '12 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? –  user970696 Sep 12 '12 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 Sep 12 '12 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? –  user970696 Sep 12 '12 at 17:08
show 1 more comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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