What?
Designing tests based on objectives derived from requirements for the software component (e.g.[] tests that exercise specific functions or probe the non-functional constraints such as performance or security). See functional test case design.
BS 7925-1.British Computer Society Specialist Interest Group in Software Testing (BCS SIGIST)

The above definition only mentions components. However requirements-based testing can

Why?
If you read the rest of this site, or indeed any testing literature, requirements-based testing is axiomatic. I believe this because of the very nature of testing. We are ensuring that the software meets the needs of the people we have developed it for, i.e the customer. The representation of the customers needs are captured in "requirements". It does not matter if those requirements turn out to be functional or non-functional, they still need to be tested.

When we look at the various other types of testing ( for a full listing) we find that test cases are almost invariably involve requirements to a lesser or greater degree. So even if we state up front that we are going to use requirements based testing, we will pretty quickly drill down to say we are for instance, black box or stress testing.

Who?
Virtually everybody in the organisation needs to be involved if requirements testing is to be a success. Not just the testers. The project management needs to build a culture of accurately capturing requirements and ensuring they are met. Analysts have to be accurate in the capturing of requirements. Additionally they need to have an awareness of the risk and other issues related to individual or groups of requirements. If there are separate designers, then testability becomes an issue, which should be built in to the system, and act as a guide to the requirements.

Where?
The culture of testing against requirements, should also be pervasive, throughout the organisation. So every physical site which is involved in developing the software should be used to help the testing.

When?
Throughout the whole length of the software development lifecycle. No matter which model or framework is being used.

How?
Successful development of software that is bug free (to a level satisfactory in a business sense), is dependant on good requirement capture and representation of those requirements. How that occurs is outside the scope of this article. However we as testers are reliant on them.

Analysis is then needed, to ensure that the risk associated with each requirement will be mitigated following the testing cycle.

An individual test case, I suggest requires:-

  The requirement to be satisfied
  The state of the software before any input
  data setup
  inputs
  predicted outcome.