Verification against requirements and validation for intended use

Verification evaluates specified requirements

Verification gathers suitable evidence that a defined product satisfies specified requirements. Depending on the obligation, evidence can come from inspection, analysis, demonstration or test. Plan the method, conditions, configuration, acceptance criterion and records before treating a result as a decision. A requirement’s existence alone does not establish that its evidence method is adequate.

For our original R1, a timing check identifies the start and end events, the defined connected condition and how the interval is observed. The record retains observations, relevant measurement limitations and the decision rule. A single convenient time on an unrecorded version cannot establish all behaviour covered by a broad requirement.

Validation evaluates the service in context

Validation examines whether the realised system is suitable for its intended use and stakeholder expectations. The pickup service includes a visitor recognising the result and completing the task in the intended setting. Representative users, tasks, environments and exceptional situations matter to that evidence. Models or simulations need a justified relationship to the intended conditions.

In our constructed session, 10 of 12 visitors complete the task without staff help. Two select an incorrect shelf from an ambiguous message. The observed independent-completion fraction is 10/12≈83.3%. Retain the different outcomes and relevant session conditions. This small illustrative record is neither a population success probability nor a supplied acceptance threshold.

Plan both paths through development

Use operational scenarios and requirements to plan evidence early. A mock-up can reveal misunderstood messages before full assembly, while a model can check an allocation before implementation. Those useful early findings do not erase the need to examine the realised system at the appropriate level and conditions.

Trace each consequential claim to its supporting result and remaining limitation. Investigate anomalies rather than redefining success after seeing the data. Corrected software or messaging may change timing as well as usability, so identify which earlier evidence remains applicable. Verification and validation are complementary activities that can inform design repeatedly; they are not two labels for the same final demonstration.

Interpret two records together

A hypothetical controlled timing check reports 140 ms for the configured station under the stated connected condition. The separate visitor session records 10 independent completions and 2 incorrect-shelf outcomes. Subject to the timing method and decision rule, the first result supports a timing claim in its tested scope. It cannot explain away the task failures.

The team should investigate the misunderstood message, clarify the intended-use criteria with stakeholders and assess the proposed correction. Preserve the original outcomes, changed configuration and later observations. A successful repeat of the revised task would support that revised configuration within the new session’s scope; it would not retroactively change what happened in the first session.

Try the reasoning

1. Does passing every currently written requirement guarantee suitability for use?

   Show the answer and reasoning

   No. The set can omit or misrepresent a stakeholder need, and intended-use evidence remains necessary.

2. Why retain the two incorrect-shelf outcomes?

   Show the answer and reasoning

   They expose a service problem and the limits of the observed completion account.

3. Can a simulation contribute to validation?

   Show the answer and reasoning

   Yes, when its representation and limitations are suitable for the claim; a simulation label alone does not establish that relationship.

What to carry forward

Ask separately what the product must satisfy and what people need it to accomplish, then retain evidence for both claims in their actual scope.