Requirements Analysis - Procedure

Requirements Review

This is a cross-functional or peer review of requirements. Requirements will be reviewed with an aim towards completeness, testability, and eliminating ambiguity and conflicts.

Creating Test Objectives

Each Requirement will generate one or more Test Objectives. A Test Objective is very high-level description of a condition to create and the expected result. Since the software may not be completed at this point, Test Objectives are vague in that they prescribe conditions to produce, but contain little or no information on how to produce them.

Creating test objectives is where the testing thought process comes into play. Test objectives focus on the various types of testing, such as boundary testing, exception handling, fault insertion, branch testing, and range testing.

Creating and reviewing test objectives must involve someone other than the original developer. It is preferred but not required for test objectives to be created as soon as requirements are stable and before code is written (knowing how the system will be tested can often improve the design of the software).

To create test objectives, take each requirement in turn and devise the set of test conditions for that requirement. Each test objective describes a condition to create and the expected result.

Example: Functional Requirement – The software will save the data in the XYZ format.

Test Objective 1 – Save the data. Verify that it is in XYZ format.

Test Objective 2 – Save the data to a full disk. Verify that an error is displayed.

Test Objective 3 – Save the data to a write-protected disk. Verify that an error is displayed.

Unit and Integration Testing (UIT)

Unit and Integration testing is an aid in finding defects as well as in refining test objectives. For this reason, a UIT is both a verification activity and a requirements analysis activity.

Unit and integration testing can be done directly from test objectives, with the test data providing details about the program’s actual behavior. This can be done to help refine the Test Objectives, as well as to add additional test objectives based on the software implementation. For this reason, it is preferred but not required that unit and integration testing be performed by software development personnel.

Written Test Steps

A Test Step is a more detailed description of how to produce the test condition and how to verify the result. A Test Step will cover one or more test objectives. A Test Step will produce one or more Test Results. At this point, there should be enough detail that a trained operator can run the tests.

The more detailed the test steps, the more likely that the testing is actually descriptive testing, not prescriptive testing. At this point in the process, more detail only reduces the number of defects in the test protocol – not in the software itself.