In this type of verification, all the requirements gathered from the user's viewpoint are verified. For this purpose, an acceptance criterion is prepared. An acceptance criterion defines the goals and requirements of the proposed system and acceptance limits for each of the goals and requirements. The acceptance criteria matter the most in case of real-time systems where performance is a critical

issue in certain events. For example, if a real-time system has to process and take decision for a weapon within x seconds, then any performance below this. would lead to rejection of the system. Therefore, it can be concluded that acceptance criteria for a requirement must be defined by the designers of the system and should not be overlooked, as they can create problems while testing the system.

The tester works in parallel by performing the following two tasks:

1. The tester reviews the acceptance criteria in terms of its completeness, clarity, and testability. Moreover, the tester understands the proposed system well in advance so that necessary resources can be planned for the project..
2. The tester prepares the Acceptance Test Plan which is referred at the time of Acceptance Testing

Verification of Objectives

After gathering requirements, specific objectives are prepared considering every specification. These objectives are prepared in a document called software requirement specification (SRS). In this activity also, two parallel activities are performed by the tester:

1. The tester verifies all the objectives mentioned in SRS. The purpose of this verification is to ensure that the user's needs are properly understood before proceeding with the project.
2. The tester also prepares the System Test Plan which is based on SRS. This plan will be referenced at the time of System testing.

In verifying the requirements and objectives, the tester must consider both functional and non- functional requirements. Functional requirements may be easy to comprehend, whereas non-functional requirements pose a challenge to testers in terms of understanding, quantifying, test planning, and test execution.

How to Verify Requirements and Objectives

Requirement and objectives verification has a high potential of detecting bugs. Therefore, requirements must be verified. As stated above, the testers use the SRS for verification of objectives. One characteristic of a good SRS is that it can be verified. An SRS can be verified, if and only if, every requirement stated herein can be verified. A requirement can be verified, if, and only if, there is some procedure to check that the software meets its requirement. It is a good idea to specify the requirements in a quantification manner. It means that ambiguous statements or terms such as 'good quality', "usually" and 'may happen' should be avoided. Instead of this, quantified specifications should be provided. An example of a verifiable statement is

'Module x will produce output within 15 sec of its execution.'
The output should be displayed like this: TRACK A's speed is x

It is clear now that verification starts from the requirement phase and every requirement specified in the SRS must be verified. However, what are the points against which verification of requirement will be done? The following are the points against which every requirement in SRS is verified:

Correctriess: There are no tools or procedures to measure the correctness of a specification. The tester uses his or her intelligence to verify the correctness of requirements. The following are some points which can be adopted (these points can change according to the situation):

(a) Testers should refer to other documentations or applicable standards and compare the specified requirement with them.

(b) Testers can interact with customers or users, if requirements are not well understood.

(c) Testers should check the correctness in the sense of realistic requirement. If the tester feels that a requirement cannot be realized using existing hardware and software technology, it means that it is unrealistic. In that case, the requirement should either be updated or removed from SRS.

Unambiguous: A requirement should be verified such that it does not provide too many meanings or interpretations. It should not create redundancy in specifications. Each characteristic should be described using a a single term, otherwise ambiguity or redundancy may cause bugs in the design phase. The following must be verified:

(a) Every requirement has only one interpretation.

(b) Each characteristic of the final product is described using a single unique term.

Consistent: No specification should contradict or conflict with another. Conflicts produce bugs in the next stages Therefore they must be checked for the following:

(a) Real-world objects conflict, for example, one specification recommends a mouse for input, another recommends a joystick.

(b) Logical conflict between two specified actions, for example, one specification requires the function to perform square root, whereas another specification requires the same function to perform square operation.

(c) Conflicts in terminology should also be verified. For example, at one place, the term process is used, whereas at another place, it has been termed as task or module.

Completeness: The requirements specified in the SRS must be verified for completeness. We must do the following:

(a) Verify that all significant requirements such as functionality, performance, design constraints, attribute, or external interfaces are complete input

(b) Check whether responses of every possible input (valid and invalid) to the software have been defined

(c) Check whether figures and tables have been labelled and referenced completely

Updation:

Requirement specifications are not stable; they may be modified or another requirement may be added later. Therefore, if any updation is there in the SRS, then the updated specifications must be verified.

(a) If the specification is a new one, then all the aforementioned steps and their feasibility should be verified.

(b) If the specification is a change in an already mentioned, then we must verify that this change can be implemented in the current design.

Traceability: The traceability of requirements must also be verified such that the origin of each requirement is clear and also whether it facilitates referencing in future development or enhancement documentation. The following two types of traceability must be verified:

(a) Backward traceability: Check that each requirement references its source in previous documents.

(b) Forward traceability: Check that each requirement has a unique name or reference number in all the documents. Forward traceability assumes more meaning than this, but for the sake of clarity, here it should be understood in the sense that every requirement has been recognized in other documents.