Fork me on GitHub

Requirement Gathering


VERIFICATION CRITERIA

    1. Non-conjugated (Atomic): The requirement is atomic, i.e., it does not contain conjunctions. E.g., “The postal code field must validate American and Canadian postal codes” should be written as two separate requirements: (1) “The postal code field must validate American postal codes” and (2) “The postal code field must validate Canadian postal codes”.
    2. Traceable: The requirement meets all or part of a business need as stated by stakeholders and authoritatively documented.
    3. Current: The requirement has not been made obsolete by the passage of time.
    4. Unambiguous: The requirement is concisely stated without recourse to technical jargon, acronyms (unless defined elsewhere in the Requirements document), or other esoteric verbiage. It expresses objective facts, not subjective opinions. It is subject to one and only one interpretation. Vague subjects, adjectives, prepositions, verbs and subjective phrases are avoided. Negative statements and compound statements are avoided.
    5. Prioritised: Many requirements represent a stakeholder-defined characteristic the absence of which will result in a major or even fatal deficiency. Others represent features that may be implemented if time and budget permits. The requirement must specify a level of importance.
    6. Verifiable: The validity of the implementation of the requirement can be determined through basic possible methods. (The above was ‘borrowed’ from Wikipedia’s Requirement article: http://en. wikipedia.org/wiki/Requirement)
    Every requirement and component in a Requirement Gathering SHOULD have verification criteria detailing how to tell if the requirement is met or the component is working. Interfaces can also have verification criteria to detail how to test that the interface is implemented correctly. While there are a multiplicity of ways to verify the behaviour of components; requirements can be verified (in general) in one of four common ways:

    1. Analysis: Look at the Requirement Gathering – you can tell if the requirement is met. i.e. for parent requirements, do the child requirements cover all aspects of the parent requirement and are they themselves marked up with verification criteria?
    2. Inspection: Simply look at what has been done and decide if it meets the requirement. For example, a requirement that a project be implemented in Python can be verified by inspection at delivery time.
    3. Automation: Does the project pass tests defined to verify this requirement? These might be unit tests, black box tests, integration tests, scenario tests, system tests, etc. The tests must be defined elsewhere.
    4. Observation: Think of this as human-based testing. The result of the project is simply observed (used, deployed, whatever) and then its external behaviour is observed to see if it meets the requirement.
    Obviously the above is not 100% exhaustive. In each case the verification criterion should explain how and when verification should be done.

    Glossary

    • component: a physical or software part of the system being developed – large component: a component with sub components. The sub components break down the functionality of the large component and as such, shows how they work and interact together in order to fill some or all of the requirements of the project
    • interface: a part of a component via which other components, or users, may interact with it
    • work item: a set of tasks to implement some part of the project
    • requirement: something the customer wants or needs the project to do for them