Verifying Requirements (Cont)

Testers need to have guidelines to ensure quality measure for verifying requirement during requirement phase. Following is the checklist that can be used by testers during the requirement phase to verify the quality of requirement. Using this checklist is a first step toward trapping requirement-related defects as early as possible, so they do not propagate to subsequent phases, where they would be more difficult and expensive to find and correct. All stakeholders responsible for requirements should verify that requirements posses the following attributes:

• Correctness

Correctness of a requirement is judged based on what the user wants. Following is the questions that need to be concern: Are the rules and regulations stated correctly? Are the standard being followed? Does the requirement exactly reflect the user’s request? It is imperative that the end user, or a suitable representative, be involved during the requirements phase.

• Completeness

Completeness ensures that no necessary elements are missing from the requirement. The goal is to avoid omitting requirements simply because no one has asked the right question or examined all of the pertinent source documents. Testers should insists that associated Non Functional Requirements, such as performance, security, usability, compatibility, and accessibility are described along with each Functional Requirements usually documented in two steps:

1. A System-wide specification is created that defines the Nonfunctional Requirements that apply to the system.

2. Each requirement description should contain a section titled “Nonfunctional Requirements” documenting any specific nonfunctional needs of that particular requirement that deviate from the system-wide nonfunctional specification.

More details about Functional and Nonfunctional Requirements, I will explain in another posts.

• Consistency

Consistency verifies that there are no internal or external contradictions among the elements within the work products, or between works products. We should ask a question “Does the specification define every essential subject-matter term used within the specification?” We can determine whether the elements used in the requirement are clear and precise. Without clear and consistent definitions, determining whether a requirement is correct becomes a matter of opinion.

• Testability or Verifiability

Testability of the requirement confirms that it is possible to create a test for the Requirement, and that an expected result is known and can be programmatically or visually verified. If a requirement cannot be tested or otherwise verified, this fact and its associated risks must be stated, and the requirement must be adjusted if possible so that it can be tested.

• Feasibility

Feasibility of a requirement ensures that it can be implemented given the budget, schedules, technology, and other resources available.

• Necessity

Necessity verifies that every requirement in the specification is relevant to the system. To test for relevance or necessity, tester checks the requirement against the stated goals for the system. “Does this requirement contribute to those goals?”, “Would the excluding this requirement prevent the system from meeting those goals?”, “Are any other requirements dependent on this requirement?”. Some irrelevant requirements are not really requirements, but proposed solutions.

• Prioritization

Prioritization allows everyone to understand the relative value to stakeholders of the requirement. We use scale from 1 to 5 to specify the level of reward for good performance, and penalty for bad performance on a requirement. If a requirement is absolutely vital to the success of the system, then it has a penalty of 5 and reward of 5. A requirement that would be nice to have but is not really vital might have a penalty of 1 and reward of 3. This knowledge can be used to make prioritization and trade-off decision when the time comes to design the system. This approach needs to balance the perspective of the user against the cost and technical risk associated with a proposed requirement.

• Unambiguousness

Unambiguousness ensures that requirements are stated in a precise and measurable way.

• Traceability

This ensures that each requirement is identified in such a way that it can be associated with all parts of the system where it is used. For any change to requirements, is it possible to identify all parts of the system where this change has an effect