Introduction to Requirement Driven Testing (RDT)

Software testing is a process of finding defects to ensure that the system being developed meet the requirements. In most cases it is likely that some of the requirements are changed or become obsolete. Therefore it is very important to always work from requirement to select which test to execute. Quite often not all test cases are up to date. Working from requirement will ensure that the they are reviewed regularly. Existing requirement and test cases might be updated, removed or added during each review. Requirement Driven Testing (RDT) is project methodology independent test approach that can be used in any project methodologies such as the Waterfall, Agile and SCRUM and focuses on the following:

  1. Building business requirement list;
  2. Requirement is used to select test case(s) and;
  3. Report pass/fail on business requirements.

The following diagram (click to enlarge image) illustrates testing and development activities are based on predefined requirements which encourage team member to review the requirement list on regular basis (even though no defect is found) to ensure maximum number of defect can be detected before releasing to production.

Building Requirement List

As the name suggests, RDT work is around building and refining requirements. The process continues throughout the project life cycle involving everyone in the team especially project owner, subject matter experts and/or application vendors.

RDT’s success is based on the fact that without well defined and testable requirements, test executions become subjective and are based on unsubstantiated assumptions

Having an up to date and testable list of requirements will make testing process much easier and productive. It is important to keep reviewing existing requirement especially during the following activities:

  1. Executing tests
  2. Creating defects
  3. Regression testing
  4. Reviewing business requirement documentation
  5. Retesting defects

Requirement is used to select test case(s) to execute

In most cases, the number of requirements will grow over time but it does not mean that the time required for testing will increase the same way. Priority classifications (High, Medium, Low) will be used to select what to test first and to manage time effectively. The priority classification also changes throughout the project life cycle as what is currently critical might not be so the same in the following iteration(s). The classification can also change when defects are detected during testing.

Although it is not mandatory, in general RDT follows the following guidelines:

  1. Each scenario should have at least one business requirement
  2. Each business requirement should have at least one test case
  3. A test case can be derived from business scenario
  4. Each defect should have one requirement and test case
  5. Each business requirement should have priority classification
  6. Each defect should have severity classification
  7. A separate test case should be created for each scenario

Report on Business Requirements

Closely coupled with the RDT approach is reporting on requirements. It focuses on providing up-to-date test results, test progress, test statistics in requirement term. The test reports can be as simple as manual update excel worksheet to a real-time online reports.

Imagine a business owner want to know the progress of the software being developed, it makes more sense if there are 10 out of 100 requirements still not tested than 10 out of 100 test cases not tested. In other words, RDT emphasis on the “what” factor rather than the “how” factor.

The quality of reports depends on the quality of inputs that have been provided. It is very important to plan what information is to be included to produce different reports. Some of the useful reports for monitoring and managing progress are:

  1. How many requirements without test case
  2. How many test cases without requirement
  3. How mane defects created without requirement and/or test case
  4. How many scenarios without requirement


RDT is a test approach that focuses on building requirement list, use the list to prioritize test execution to manage time efficiently and report on requirement status. RDT is project methodology independent and can be used in Waterfall, Agile or SCRUM project methodologies.

Next topic: Each scenario should have at least one business requirement

If you have any question, feel free to send email to

Related Posts Plugin for WordPress, Blogger...