Verification of Requirements:
In this type of verification, all the requirements gathered from the users viewpoint sre verified. For
this purpose, an acceptance criterion is preprared. An acceptance criterion defines the goals and
requirments of the proposed system and acceptance limits for each of the goals and requirements.
The testers works in parallel by performing the following two tasks:
1. The tester reviews the acceptance criteria in terms of its completeness, clarity and testability.
2. The tester prepares the Acceptance Test Plan which is refered at the time of Acceptance Testing.
Verification of Objectives: After gathering of objectives specific objectives are prepared
consedering every specification. These objectives are prpepared in a document called SRS. In this
activity the tester performs two parallel activities:
1. The tester verifies all the objectives mentioned in SRS.
2. The tester also prepares the System Test Plan which is based on SRS.
How to verify Requirements and Objectives:
An SRS is verifiable if, and only if, every requirement stated therein is verifiable. A requirement is
verifiable if, and only if, there exists some finite cost-effective process with which a person or
machine can check that the software product meets the requirement. In general any ambiguous
requirement is not verifiable. Nonverifiable requirements include statements such as “works well",
“good human interface", and “shall usually happen". These requirements cannot be verified because
it is impossible to define the terms “good", “well", or “usually". An example of a verifiable
statement is “Output of the program shall be produced within 20 s of event x 60% of the time;
and shall be produced within 30 s of event x 100% of the time". This statement can be verified
because it uses concrete terms and measurable quantities. If a method cannot be devised to
determine whether the software meets a particular requirement, then that requirement should be
removed or revised. Following are the points against which every requirement in SRS should be
Correctness: An SRS is correct if, and only if, every requirement stated therein is one that the
software shall meet. However, generally speaking there is no tool or procedure to ensure
correctness. That’s why the SRS should be compared to superior documents (including the System
Requirements Specification, if exists) during a review process in order to filter out possible
contradictions and inconsistencies. Reviews should also be used to get a feedback from the
customer side on whether the SRS correctly reflects the actual needs. This process can be made
easier and less error-prone by traceability.
Unambiguity. An SRS is unambiguous if, and only if, every requirement stated therein has only one
interpretation. As a minimum, this requires that each characteristic of the final product be described
using a single unique term. In cases where a term used in a particular context could have multiple
meanings, the term should be included in a glossary where its meaning is made more specific.
Completeness. An SRS is complete if, and only if, it includes the following elements:
--All significant requirements imposed by a system specification should be acknowledged and
--Full labels and references to all figures, tables, and diagrams in the SRS and definition of all terms
and units of measure.
However, completeness is very hard to achieve, especially when talking about business systems
where the requirements always change and new requirements raise.
Consistency: Consistency refers to internal consistency. If an SRS does not agree with some higher-