Pace Tech – IMPULS3

Requirements Verification & Validation

IMPULS3 Requirements Verification and Validation
Stakeholder Stakeholders contribute to Requirements Validation by assessing whether requirements correctly express what is needed and are acceptable in their intended context. Participant in Requirements Validation
Requirements Baseline A controlled set of Requirements that can be reviewed as a coherent whole. V&V of a Baseline considers qualities such as completeness, consistency and absence of contradictions across the set. Input to Requirements V&V
Requirement A Requirement is assessed through both Verification and Validation. Verification checks whether it is specified correctly; Validation checks whether it correctly expresses what is needed. Information element being assessed
V&V criteria Agreed rules, standards, templates and checklists provide the criteria against which Requirements are assessed. They may address qualities such as ambiguity, atomicity, completeness, consistency, quantification, verifiability and traceability. Rules and standards applicable to Requirements V&V
People Requirements V&V requires human judgement. Requirements engineers, reviewers, domain experts and stakeholders may participate in assessing the quality and correctness of Requirements. People performing or supporting Requirements V&V
Requirements V&V activities Requirements are examined iteratively through Verification and Validation activities. Findings may lead to clarification, correction or renewed analysis before the Requirements can be released. Activities within the Requirements V&V process step
Assessment — no information transformation Requirements V&V assesses existing Requirements without transforming them into another type of engineering information. The Requirement retains its identity while its quality and correctness are assessed. Assessment rather than information transformation
Methods & tooling Reviews, walkthroughs, inspections, checklists, quality rules and supporting tools help engineers perform Requirements Verification & Validation systematically and consistently. Support for Requirements V&V
IMPULS3 principles Requirements V&V preserves the identity, meaning and traceability of the Requirement. Verification concerns the quality of its specification; Validation concerns the correctness of its intended meaning.
Review Record A Review Record captures the outcome of Requirements V&V, including findings, comments, decisions, status and required follow-up actions. Output of Requirements V&V
Review of Requirement The Review Record refers to the individual Requirement that was assessed and records the corresponding V&V outcome. Review Record → Requirement
Review of Baseline The Review Record may also refer to the Requirements Baseline that was assessed as a coherent set. Review Record → Requirements Baseline

Requirements Verification & Validation

Process

Requirements Verification & Validation is the process step in which specified Requirements are assessed before they are released for downstream use. The purpose is to determine whether the Requirements are specified correctly and whether they correctly express what is needed.

Requirements V&V is not System V&V

Within IMPULS3, Requirements Verification & Validation concerns the Requirements as engineering information. It does not verify or validate the realized system, a system element, a design solution or an implementation.

Requirements are verified and validated before they are released.

System-level Verification & Validation takes place later in the lifecycle and answers different questions. Requirements V&V instead acts as a quality gate within the Requirements Engineering process: before Requirements become an input to design, realization and testing, their quality and intended meaning are assessed.

Two complementary assessments

Requirements V&V combines two complementary forms of assessment: Verification and Validation. Although they are closely related, they address different questions.

1 Verify the Requirements

Verification assesses the intrinsic quality of the Requirement as an engineering artifact.

The central question is: “Are the Requirements written right?”

During Verification, the engineer or reviewer assesses whether a Requirement:

  • is unambiguous and atomic;
  • is complete and internally consistent;
  • is correctly structured and formulated;
  • is quantified where applicable;
  • is verifiable;
  • is traceable;
  • conforms to the agreed rules, standards, templates and quality criteria.

Verification is primarily rule-based: the Requirement is compared with agreed criteria for requirement quality.

2 Validate the Requirements

Validation assesses the Requirement in relation to the intended stakeholder need, system scope and engineering context.

The central question is: “Do the Requirements correctly express what is needed?”

During Validation, the engineer, stakeholder or other reviewer assesses whether a Requirement:

  • correctly reflects the analysed Stakeholder Needs;
  • is consistent with the relevant Analysis Statements and decisions;
  • fits the intended system scope and purpose;
  • is meaningful in its operational and stakeholder context;
  • is acceptable to the relevant stakeholders.

Validation is contextual and judgement-based. A Requirement can be perfectly written and still be the wrong Requirement.

IMPULS3 distinction: Verification checks the quality of the Requirement specification. Validation checks the correctness of the intended meaning behind that specification.

Perform the review

Requirements V&V is normally performed through one or more structured review activities. Depending on the project, these may include reviews, walkthroughs, inspections, checklist-based assessments and tool-supported quality checks.

The review may address an individual Requirement or a complete Requirements Baseline. Reviewing a Baseline is important because several quality characteristics can only be assessed across a set of Requirements. Examples include consistency, completeness, duplication and contradictions between Requirements.

1. Prepare Select the Requirements and applicable criteria

Identify the Requirement or Baseline to be reviewed together with the applicable quality rules, standards, checklists, Stakeholder Needs, Analysis Statements and other relevant context.

2. Verify Assess specification quality

Check whether the Requirements are well-formed, clear, consistent, quantified where necessary, verifiable and traceable.

3. Validate Assess meaning and intent

Check whether the Requirements correctly express the analysed needs, decisions, scope and intended purpose of the system.

4. Record Document the V&V outcome

Record findings, comments, decisions, status and required follow-up actions in a Review Record.

Handle findings

Requirements V&V does not automatically change a Requirement. When a problem is identified, the finding is recorded and the appropriate corrective action is initiated. This may require clarification, correction, renewed analysis or consultation with stakeholders.

The Requirement itself retains its identity. Where its content must change, that change is handled in a controlled manner through Requirements Management. The Review Record provides the evidence of what was assessed, what was found and what decision was made.

Important: Requirements V&V is the last quality gate before Requirements are released. It is therefore the point at which defects in Requirements can still be detected and corrected before they propagate into design, realization and testing.

Outcome of the process step

At the end of Requirements V&V, each reviewed Requirement or Baseline has an explicit outcome. The result may be approval for release, or one or more findings that must be resolved before release.

Only after the required V&V activities have been completed and the resulting findings have been addressed should the Requirements proceed to controlled publication or release.

Requirements Engineering · Verification & Validation

Information Model

Requirements Verification & Validation assesses existing Requirements before they are released. The Requirement itself is not transformed into another type of engineering information. Instead, the outcome of the assessment is captured in a Review Record.

Within IMPULS3, the core information involved in Requirements V&V is represented through three connected Information Elements: Requirement, Baseline and Review Record. Together they make it possible to record what was reviewed, in which controlled context it was reviewed, and what the outcome of that review was.

Information Elements

Requirement

A Requirement is the engineering Information Element being assessed during Requirements Verification & Validation.

Verification assesses whether the Requirement is specified correctly. Validation assesses whether the Requirement correctly expresses what is needed in relation to its underlying Stakeholder Needs, Analysis Statements, scope and context.

Baseline

A Baseline is an immutable snapshot of a controlled set of Requirements and related engineering information at a defined point in time.

A Baseline provides the controlled context for reviewing Requirements as a coherent set. This enables qualities such as completeness, consistency, duplication and contradictions to be assessed across multiple Requirements.

Review Record

A Review Record captures the outcome of a Requirements V&V activity. It records the findings, comments, decisions, status and, where applicable, required follow-up actions resulting from the assessment.

The Review Record provides evidence of what was reviewed and what conclusion was reached, without changing the identity of the Requirement that was assessed.

Supporting Information

Requirements V&V does not operate on Requirements in isolation. Verification and Validation use different supporting information to determine whether a Requirement is of sufficient quality and correctly represents what is needed.

V&V Criteria

Verification uses agreed rules, standards, templates and checklists as reference information for assessing Requirement quality.

These criteria may address characteristics such as ambiguity, atomicity, completeness, consistency, quantification, verifiability and traceability.

Stakeholder and engineering context

Validation requires the meaning and rationale behind a Requirement to remain accessible. Relevant Stakeholder Needs, Analysis Statements, source information, scope and stakeholder context provide the basis for determining whether the Requirement correctly expresses what is needed.

Relevant stakeholders may participate directly in this assessment where their judgement or acceptance is required.

Semantic Relations

Requirements V&V adds assessment information to the existing Requirements information structure. The Review Record therefore points to the engineering information that was reviewed rather than replacing or transforming that information.

Review Record → Requirement

A Review Record points to the individual Requirement to which its finding, comment, decision or V&V outcome applies.

Relation: reviews

Review Record → Baseline

Where a review is performed against a controlled Requirements Baseline, the Review Record points to the Baseline that defines the reviewed set and its configuration.

Relation: reviews

Existing Traceability Supports Validation

Validation relies on traceability established during the preceding Requirements Engineering process steps. To determine whether a Requirement correctly expresses what is needed, the reviewer must be able to navigate from the Requirement back to the Analysis Statements, Stakeholder Needs and source information that explain its meaning and rationale.

Requirement What has been specified?

The Requirement is the Information Element being validated.

Analysis Statement Why was it specified this way?

Analysis Statements preserve the reasoning and interpretation that led to the Requirement.

Stakeholder Need What is actually needed?

Stakeholder Needs provide the needs against which the meaning of the Requirement can be assessed.

Source Information Where did the information originate?

Source Information provides the original evidence and context where further substantiation is required.

IMPULS3 information structure.

Requirements V&V does not create a second, “verified” or “validated” version of a Requirement as a different Information Element. The Requirement retains its identity. The result of its assessment is represented separately by the Review Record.

This separation preserves both the engineering information and the evidence of its assessment. It becomes possible to determine which Requirement or Baseline was reviewed, what was found, what decision was made and which follow-up action was required.

IMPULS3 principle Requirements V&V assesses Requirements as engineering information before release. It does not verify or validate the realized system. Preserve the Requirement and record the evidence and outcome of its assessment separately.

Requirements Engineering · Verification & Validation

Tools & Techniques

Requirements Verification & Validation can be supported by a combination of review techniques, quality criteria, checklists and automated tools. Different techniques help reviewers assess whether Requirements are specified correctly and whether they correctly express what is needed.

The techniques below form the initial IMPULS3 Requirements V&V toolbox. They are not intended as a prescriptive sequence. The appropriate combination depends on the type and maturity of the Requirements, the size of the Baseline, the applicable standards and quality rules, the system context, and the stakeholders and domain experts involved.

Requirements V&V assesses the Requirements before they are released. These techniques do not verify or validate the realized system.

Prepare the review

Effective V&V starts by establishing what will be reviewed, against which criteria it will be assessed, and which people and supporting information are needed to perform the assessment. [GilbGraham1993]

Review Planning

Define the scope of the review, identify the Requirement or Baseline to be assessed, select the participants and determine the applicable Verification and Validation criteria.

Checklist Preparation

Select or prepare checklists containing the agreed Requirement quality rules and review criteria. Checklists help reviewers apply the same criteria systematically and consistently.

Standards & Rules Selection

Identify the standards, conventions, requirement patterns, templates and project-specific rules against which the Requirements must be verified.

Traceability Preparation

Ensure that the relevant Analysis Statements, Stakeholder Needs and other supporting information can be reached from the Requirements. This context is particularly important for Validation.

Verify the Requirements

Verification focuses on the intrinsic quality of the Requirements as engineering information. The techniques in this group help answer the question: Are the Requirements written right?

Checklist-based Review

Assess each Requirement systematically against agreed quality criteria, such as clarity, atomicity, completeness, consistency, quantification, verifiability and traceability.

Peer Review

Have one or more engineers independently examine Requirements for formulation problems, ambiguity, omissions, inconsistencies and other quality defects that may have been overlooked by the author.

Inspection

Perform a structured and systematic examination of Requirements using predefined roles, criteria and defect categories. Inspections are particularly useful where a formal and repeatable review process is required.

Walkthrough

Step through the Requirements with other participants while explaining their intended formulation and structure. Questions and discussion can expose ambiguities, inconsistencies and missing information.

Consistency Analysis

Compare Requirements with one another to identify contradictions, incompatible values, inconsistent terminology, duplication and other conflicts within the Requirements Baseline.

Completeness Analysis

Examine the Requirements set for missing information, uncovered aspects, incomplete conditions or gaps that prevent the Baseline from adequately specifying its intended scope.

Terminology & Ambiguity Analysis

Examine the language used in Requirements for undefined terms, vague expressions, subjective wording and terminology that can be interpreted in more than one way.

Verifiability Assessment

Determine whether objective evidence could later demonstrate that the realized system satisfies the Requirement. A Requirement that cannot be objectively assessed is not sufficiently verifiable.

Automated Verification support

Some aspects of Requirement quality can be checked automatically or semi-automatically. Tool support is especially useful for large Baselines, where manual inspection alone makes systematic checking difficult.

Requirement Quality Analysis

Automated rules can identify potentially ambiguous terms, weak wording, passive constructions, missing quantities, compound statements and other patterns that may indicate a Requirement quality problem.

Traceability Analysis

Tools can identify missing or incomplete trace links and help determine whether Requirements remain connected to the Analysis Statements and Stakeholder Needs from which their meaning originates.

Duplicate & Similarity Detection

Text and semantic comparison can help identify Requirements that may express the same or strongly overlapping obligations and therefore deserve closer human examination.

Baseline Quality Checks

Automated checks can examine larger Requirement sets for missing attributes, invalid states, broken relations, inconsistent units, duplicate identifiers and other structural quality issues.

Automation supports Verification; it does not replace engineering judgement. Automated tools are particularly effective at identifying possible defects and deviations from explicit rules. Whether a Requirement is correct and meaningful in its engineering context still requires human assessment.

Validate the Requirements

Validation focuses on the meaning and intent of the Requirements. These techniques help answer the question: Do the Requirements correctly express what is needed?

Stakeholder Review

Review Requirements with relevant stakeholders to determine whether they correctly represent their needs, concerns, expectations and intended outcomes.

Domain Expert Review

Involve people with relevant operational, technical or domain knowledge to assess whether Requirements are meaningful and correct within the context in which the system will be used.

Trace-back Analysis

Navigate from a Requirement through its Analysis Statements to the underlying Stakeholder Needs and, where necessary, Source Information. This allows the reviewer to compare the Requirement with the rationale and meaning from which it originated.

Scenario-based Validation

Examine Requirements in representative operational scenarios or use situations to determine whether they remain meaningful, sufficient and appropriate when considered in context.

Walkthrough with Stakeholders

Step through Requirements together with stakeholders or domain experts, discussing their meaning and consequences to uncover misunderstandings, incorrect assumptions or missing needs.

Rationale Review

Examine the reasoning behind a Requirement and determine whether the assumptions, Analysis Statements and decisions that support it still justify the Requirement as specified.

Consolidate and record the outcome

V&V findings need to become controlled engineering information. The outcome of the review is therefore documented rather than being left as informal comments or undocumented agreement.

Finding Classification

Classify findings according to their nature and significance, for example as Verification defects, Validation concerns, questions, required corrections or items requiring renewed analysis.

Review Record

Record findings, comments, decisions, V&V status and required follow-up actions, while maintaining the relation to the Requirement or Baseline that was reviewed.

Finding Resolution

Determine the appropriate response to each finding. Resolution may require correction of the Requirement, clarification, stakeholder consultation or renewed Requirements Analysis.

Release Readiness Assessment

Determine whether the applicable Requirements V&V activities have been completed and whether unresolved findings prevent the Requirement or Baseline from being released.

Keep Requirements V&V and System V&V separate

Some terminology used during Requirements V&V also appears later in the system lifecycle. Reviews, inspections, scenarios and verification activities can all be used in other engineering processes. Their object of assessment is what distinguishes them here.

In Requirements V&V, the object being verified and validated is the Requirement or Requirements Baseline — not the realized system.

Asking whether a Requirement is verifiable is part of Requirements Verification. Actually demonstrating that a realized system satisfies that Requirement belongs to system-level Verification and takes place later in the lifecycle.

IMPULS3 perspective. Tools and techniques support Requirements Verification & Validation; they do not define the process themselves. Their purpose is to provide confidence that Requirements are correctly specified, correctly express what is needed, and are ready for controlled release.

IMPULS3 Principles

The following IMPULS3 principles are particularly relevant during Requirements Verification & Validation:

  • Verify and validate Requirements before release. Treat Requirements V&V as a quality gate within Requirements Engineering. Requirements should only be released for downstream use when their quality and intended meaning have been adequately assessed.
  • Distinguish Verification from Validation. Verification determines whether Requirements are specified correctly; Validation determines whether they correctly express what is needed. A Requirement can be well written and still be the wrong Requirement.
  • Do not confuse Requirements V&V with System V&V. Requirements V&V assesses Requirements as engineering information. It does not demonstrate that the realized system satisfies its Requirements or that the realized system fulfils stakeholder needs.
  • Validate against meaning, not only against text. Use the underlying Analysis Statements, Stakeholder Needs, rationale and context to determine whether a Requirement preserves and correctly expresses the intended meaning.
  • Use traceability as an engineering instrument. Navigate the traceability chain from Requirement to Analysis Statement, Stakeholder Need and Source Information when evidence of meaning, rationale or origin is needed during Validation.
  • Preserve the Requirement; record the assessment separately. Requirements V&V does not transform a Requirement into another type of engineering information. Preserve the identity of the Requirement and capture findings, decisions, status and follow-up actions in a Review Record.