Requirements Validation

Updated 06 Sep 2026

•
def
- •
  the process of checking that the defined requirements accurately specify the system the customer actually wants
- •
  ensures requirements have been correctly stated, are not contradictory, are complete, and are implementable
- •
  "The aim of validation is to check that the requirements define the system that the customer really wants." — Sommerville (2015)
•
importance
- •
  requirements errors are extremely costly — fixing an error after delivery can cost up to 100 times the cost of fixing the same error during development (Sommerville, 2015)
- •
  building the right system from the start is far less expensive than correcting misaligned systems post-deployment
•
verification vs validation
- •
  verification — "Is the requirement written correctly?" (Correctly specified)
  - •
    evaluates whether the product meets the stated specifications
  - •
    done internally by the analyst or QA team during quality control
  - •
    done before the deliverable is handed to the user
- •
  validation — "Is this requirement actually needed?" (Appropriate to the real need)
  - •
    evaluates whether the product truly meets user needs
  - •
    done by the customer or end user
  - •
    done after verification, before the next development phase begins
- •
  a requirement can be verified but not valid — correctly written but not reflecting what users actually need
  - •
    e.g., "The system must handle 10,000 transactions per second" — correctly specified, but actual user base is only 500 per day (over-engineered)
  - •
    e.g., "The system must store a log of every user click" — not needed by users and may cause overload
- •
  a requirement can be valid but not yet verified — genuinely needed but not yet formally documented or technically analyzed
  - •
    e.g., "Users want all notifications sent as video to WhatsApp" — genuinely desired, but API, bandwidth, and technical constraints have not been evaluated
  - •
    e.g., "The application must work offline" — valid user need, but synchronization and caching mechanisms are undefined
•
types of checks in the validation process
- •
  validity checks — does the requirement reflect current user needs? (requirements that were once valid may become outdated)
- •
  consistency checks — are there conflicting requirements? requirements should not contradict each other
  - •
    e.g., one requirement states a customer can cancel a reservation any time; another states cancellations are only allowed up to 1 hour before the reservation
- •
  completeness checks — have all key features and constraints been described? nothing important should be missing
  - •
    e.g., a reservation system specifies booking and cancellation but omits how confirmation is delivered (email, SMS, or in-app notification)
- •
  realism checks — can the requirement be implemented within budget, time, and technology constraints?
  - •
    e.g., requiring 10,000 reservations per second for a restaurant with 20 tables and 200 daily users is unrealistic
- •
  verifiability checks — can the requirement be tested? requirements must be testable through objective observation or measurement
  - •
    e.g., "the system must respond quickly" is not verifiable; "the system must respond within 2 seconds" is verifiable
•
techniques
- •
  requirements reviews
  - •
    systematic manual analysis by a team of developers, analysts, and stakeholders
  - •
    identifies errors, inconsistencies, or unclear requirements
  - •
    may be formal (with completed documents and formal sign-off) or informal
  - •
    review checks — verifiability, comprehensibility, traceability, adaptability
- •
  prototyping
  - •
    using an executable model or visual mockup to check whether requirements match expectations
  - •
    users interact with the prototype and provide feedback used to refine requirements
  - •
    e.g., a reservation page mockup is shown to users; they request that a confirmation screen be added
- •
  test-case generation
  - •
    developing test cases for requirements to verify testability
  - •
    if a test case is difficult to write, the requirement is likely unclear or too vague
  - •
    e.g., "the system must be fast" → no test case possible; "the system must process a reservation in max. 2 seconds" → testable
•
related
•
Cards
- •
  Distinguish verification from validation.
  - •
    verification: was it built correctly (does it match the written requirements)? validation: was the correct thing built (does it match what users actually need)?

Linked references 11

◌ Explore connections in Graph view

Requirements Validation

Cards

Linked references 11