Test model and requirement management

In prior posts, I have discussed test models as a package of test scenarios. Each scenario has specific requirements. The development of software for the telecommunications industry deals with large systems like OSS/BSS, and requirements creation is the initial phase of the project.

This phase is critical, as requirements errors can result in wasted time and increased cost. Analysis shows that the later readjustment phase can consume 30 to 40 percent of the total effort expended on a software development project.

Researchers have even indicated that about 50 percent of the bugs can be caused by requirements errors; thus, requirements errors may lead to between 70 to 85 percent of all project readjustment costs.

As you can see in Figure 1, the correction of requirements defects can cost up to 110 times more if found in operation than it would if the same defect had been discovered during the requirements definition phase.

We as QA consultants advise that two main parts of the requirements creation phase should be separated – into requirements development and requirements management.

The requirements development phase aims to collect information, make analysis, review and approve requirement. As a rule, it results in documents package creation. These are documents about image and product borders, software requirement specifications, data vocabulary and a corresponding analysis model.

The review and approval of this package defines the base requirements version (i.e. the agreement between developers and customers). The requirements management stage includes all actions supporting integrity, accuracy and timeliness of renovation of the agreement on requirements during the project.

Management of requirements includes:

• Management of changes for the base version of requirements;
• Maintenance of project plans actuality according to changing requirements;
• Management of versions of separate requirements and the documentation of requirements;
• Control of a condition of requirements in the base version; and
• Management of logic connections between separate requirements and other materials with the project.

The best practices and characteristics for requirements management are as follows:

• Completeness – Each requirement should completely describe the functionality that will be implemented in the software. In other words, it should contain all information necessary for developers to create the fragment of functionality.
• Correctness – Each requirement should describe the desirable functionality precisely. Connections (links) with sources of requirements is necessary for correctness.
• Practicability – Possibility to implement each requirement under certain conditions and restrictions imposed by the system and operating environment. Here it is needed to provide interaction of developers with experts in marketing and analysts the ability for extraction of all requirements.
• Necessity – Each requirement should reflect what is really necessary for users or necessary to meet external system requirements or standards.
• Setting of priorities – Setting of priorities is necessary to cope effectively with budget reduction, infringement of terms, loss of personnel, or the addition of new requirements in the course of development.
• Clarity – All readers of requirements should interpret them the same. All special and potentially confusing terms should be provided in a glossary.
• Verifiability – Requirement management helps to identify the incomplete, not agreed upon, impracticable or ambiguous requirements.