What Is Software Verification? What It Checks—and What It Doesn’t

Software verification is the set of checks used to determine whether a product or engineering result conforms to the requirements and specifications that apply to it. The practical question is: “Was it built according to what was defined?” In NASA’s systems engineering framework, verification compares a product with its requirements or specifications; the same distinction helps explain software programs, components, and deliverables. NASA: Product Verification

Verification is not a single activity that necessarily takes place at the end. It can be applied to different deliverables during development: a specification can be reviewed against previously agreed needs, a design against requirements, and an implementation against the design or technical criteria. The reference point must be explicit: without an identifiable requirement, it is not possible to state clearly which condition was checked. The specific sequence depends on the project and should not be mistaken for a universal recipe.

Nor does verification mean declaring that all software is correct, safe, or useful in every situation. A check provides evidence about a defined scope, against defined criteria and under defined conditions. For example, reviewing a particular calculation does not automatically demonstrate that every function, version, input, or environment behaves appropriately.

Verification objects can include requirements, design, executable code, integrated components, and associated documentation, provided there are applicable criteria against which to compare them. NASA’s page describes final product verification as a check of conformity with requirements or specifications and emphasizes the importance of maintaining a controlled baseline configuration. The same logic applies to scope: each claim should identify which item and version were examined. NASA: Product Verification

In a simple example, a requirement might state that an application must calculate a total from quantities and prices. Verification can check that the implemented formula matches the specified rule and that the result matches the expected outcome in the cases examined. If the rule itself is poorly framed—for example, if it leaves out a discount needed in actual use—the program could conform to the rule and still fail to meet the need. That distinction is why verification and validation should not be treated as synonyms.

Documentation matters too, because it defines what counts as conforming and records what activity took place. A verification and validation plan can record responsibilities, applicable documents, methods, and matrices linking requirements to evidence. NASA’s published outline has separate sections for verification and validation methods, implementation, and requirements matrices. Traceability helps reveal coverage and gaps, but a complete matrix is not, by itself, proof that every result is correct. NASA: Verification and Validation Plan Outline

Verification can bring together several forms of examination. A human review compares documents or changes with defined criteria; an analysis can look for properties or inconsistencies without running the program; and a test observes software behavior by running it under selected conditions. NIST information about its software verification and validation training highlights documenting evidence and using both kinds of techniques, although its examples focus on laboratory spreadsheets and do not establish an exhaustive list for every project. NIST: Software Verification and Validation Training

An example of checking against a specification

Suppose a specification requires a system to reject a request when a mandatory field is missing. A review could check that the requirement is defined and that the design accounts for the case; a test could submit an incomplete request and compare the observed response with the expected result. Each method answers a different question: a review examines artifacts and reasoning, while a test observes behavior under specific inputs and conditions.

Tests do not examine every possible input simply because they are run. The result depends on which cases were selected, which version was tested, and which environment was used. Accordingly, “passed the tests” means that no discrepancy was detected in the checks performed, not that the absence of defects has been proved. Evidence is easier to interpret when the relationship among the requirement, acceptance criterion, executed case, result, and product version is preserved.

A useful record-keeping practice

To help another person understand what was verified, it is useful to record the item and version examined, the associated requirement, the method used, relevant conditions, and the result. Where controls or audits matter, that record makes it possible to explain the scope and review later changes. NIST presents evidence documentation and ongoing software evaluation as objectives of its laboratory training resources; the specific record should be suited to the context. NIST: Software Verification and Validation Training

Verification asks whether a product conforms to defined requirements or specifications. Validation asks whether the product meets its intended use and relevant needs in its context of use. NASA expresses the difference through two questions: whether the product was correctly realized against what was specified, and whether it meets what the customer intended in the operating environment. NASA: Product Verification

The table summarizes the distinction of purpose described by NASA; it does not imply that each activity uses an exclusive method or that there is a rigid boundary between techniques. NASA: Product Verification

Consider an application that calculates shipping costs. If the specification says it must add a base fee and a surcharge, checking that calculation is verification. Asking whether the application accommodates real needs—for example, whether the workflow lets a user enter the destination and delivery type offered by the service—is validation. The first check may succeed while the second reveals that the solution was defined in a way that does not serve the expected use.

That is why it is not enough to say that a product “has been verified” without specifying the reference point and scope. Nor does validation replace every check against specifications: both perspectives may be necessary and complementary. The processes described by NASA separate their objectives, while acknowledging that some activities can look similar in practice. The label depends on the question being answered, not solely on whether an activity is called a test or a review.

Evidence may consist of test results, review observations, documented analyses, or matrices linking requirements to checks. These forms of evidence do not all prove the same thing: an execution result supports an observation for specific inputs and an environment, while a review can document that an artifact was evaluated against criteria. The conclusion must not exceed the evidence or be extended to versions or conditions that were not examined.

Traceability helps follow the link between a requirement and the activity intended to check it. NASA’s planning outline proposes both a requirements verification matrix and a validation matrix, as well as documentation of methods and activities. This offers a structure for organizing evidence, not an automatic guarantee that requirements are well phrased, complete, or representative of user needs. NASA: Verification and Validation Plan Outline

For example, if a calculation rule changes, knowing which requirements, components, and test cases are associated with it makes it possible to review the impact of the change. But a documentary link may be out of date or may not cover important behavior. Version management and evidence review remain necessary; a list of checked boxes is useful only if it describes real activities, interpretable results, and the correct artifact.

Verification is a bounded practice, not a mathematical proof of perfection. Defects may remain because certain cases were not examined, the criteria were incomplete, or the real environment differs from the one used. It is also possible to comply literally with a specification that does not represent the need well. A responsible statement therefore identifies what was reviewed, against which reference, and under what conditions, rather than claiming that the software is error-free.

In high-risk projects or those subject to control requirements, review independence may matter. NIST’s glossary describes independent verification and validation as review, analysis, and testing conducted by an objective third party to examine both requirements definition and implementation of functions and security requirements. This description refers to IV&V; it does not mean every project necessarily needs an external team or that independence eliminates coverage limits. NIST: Independent Verification and Validation Glossary

When reading a verification claim or planning a check, these questions help make its scope concrete:

• Which product, component, document, and version were examined?
• Against which requirement, specification, or criterion was it compared?
• Which method was applied, and under what conditions?
• What evidence was recorded, and which cases does it not cover?
• Was the question about conformity with what was specified or fitness for intended use?

ISO/IEC/IEEE 12207 provides a software life-cycle process framework, but the sources assembled for this article do not include the standard’s official text. Accordingly, this glossary does not attribute specific requirements to that standard and does not present a normative recipe. The guidance here relies primarily on NASA documentation about product verification and validation and NIST resources on evidence and IV&V; specific techniques should be selected according to the system, its risks, and applicable obligations. NASA: Product Verification NIST: IV&V