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

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.

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.

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.

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.