IEEE 1012-2024: IEEE 1012-2024 – Tutorial (about 60 minutes)

IEEE 1012 is the IEEE standard for verification and validation (V&V) of systems, software and hardware: the planned, evidence-based work that checks whether each stage of development produced what it was supposed to produce, and whether the finished item actually serves the people who need it. Systems engineers, software and hardware engineers, test and quality leads, safety and security specialists, independent assessors and the organisations that buy critical systems use it to agree how much V&V a product needs and what that work must deliver. After this tutorial you will be able to explain the difference between verification and validation, assign integrity levels, scale V&V tasks to risk, choose a suitable degree of independence and outline a V&V plan for a real project.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current edition is IEEE 1012-2024, IEEE Standard for System, Software, and Hardware Verification and Validation, developed by the 1012 working group under the Software and Systems Engineering Standards Committee (S2ESC) of the IEEE Computer Society. The IEEE SA Standards Board approved it on 2024-11-12 and IEEE published it on 2025-08-22; IEEE lists it as an active standard. It supersedes IEEE 1012-2016 (into which a 2017 corrigendum was incorporated), and earlier editions appeared in 1986, 1998, 2004 and 2012. IEEE 1012 is published by IEEE alone; it is not a joint ISO/IEC/IEEE number. On 2026-03-26 IEEE approved a new project authorisation (P1012) to revise the standard again, so a future edition is in preparation, but IEEE 1012-2024 remains the edition to use until a successor is published. The publicly available description of the 2024 edition keeps the approach of the 2016 edition: V&V processes organised around the life cycle process groups, with requirements that scale by integrity level. This tutorial explains that approach in our own words; check exact clause numbers, task names and table layouts in the copy you hold. Verified 2026-10-29 against the IEEE SA catalogue entries for 1012-2024, 1012-2016 and the P1012 project.

Who it is for: engineers and test leads who must plan or carry out V&V on a system with safety, security, financial or mission consequences; project and programme managers who must budget and schedule it; quality, safety and compliance staff who must judge whether the V&V evidence is good enough; and acquirers or independent assessors who need a shared vocabulary with their suppliers.

Prerequisites: none. A rough idea of how a product moves from idea to requirements, design, build, test and operation is enough. Every term is explained when it first appears.

How to use this tutorial: read the seven lessons in order (about 45 minutes), study the four diagrams, then spend the remaining time on the reflection questions before you take the 25-question knowledge check.

Learning objectives:

You will be able to explain the purpose and scope of IEEE 1012 and how the 2024 edition relates to earlier editions and to the revision now under way.
You will be able to distinguish verification from validation and both from testing, and use the core vocabulary correctly.
You will be able to assign integrity levels from consequence and likelihood and explain how they drive the minimum V&V tasks, their intensity and their rigor.
You will be able to describe how V&V runs alongside every life cycle process, from concept to disposal, and which reports it produces.
You will be able to compare the technical, managerial and financial dimensions of independence and choose a fitting form of independent V&V.
You will be able to explain how conformance with IEEE 1012 is demonstrated and assessed when no certificate for the standard exists.
You will be able to position IEEE 1012 next to ISO/IEC/IEEE 15288, ISO/IEC/IEEE 12207, ISO/IEC/IEEE 29119, IEEE 730 and sector safety standards.

Lesson 1 – Origins, purpose and scope

Why V&V needs a standard

Every development team checks its work in some way. The trouble is that "checking" means different things to different people. A developer may mean that the code compiles and the unit tests pass. A tester may mean that the scripted test cases in the release plan were executed. A customer may mean that the system did what they needed on its first busy day. All three can be satisfied while a serious problem slips through: a requirement that was wrong from the start, an interface two teams understood differently, or a hazard nobody analysed because it fell between disciplines.

V&V exists to close those gaps in a planned way. It asks two questions about every product of every stage of development. First, did this stage correctly turn its inputs into its outputs? Second, is what we are building going to meet the real needs and intended use of the people who depend on it? A standard for V&V makes those questions concrete: which tasks to perform, at which point in the life cycle, with what inputs and outputs, how deeply, by whom and with what records. That turns "we checked it" into evidence that someone else can examine.

A second reason is cost. A wrong requirement found during a requirements review costs a conversation and an edit. The same defect found during acceptance testing may cost a redesign, and found in operation it may cost an accident, a recall or a regulatory penalty. V&V that starts at the concept stage and continues through every stage finds problems where they are cheapest to fix. IEEE 1012 is built on that idea: V&V is not a phase at the end, it is a companion process that runs in parallel with development from the first day.

A short history

IEEE 1012 first appeared in 1986 as a standard for software V&V plans, drawing on experience from defence and space programmes where independent checking of critical software was already established practice. The 1998 and 2004 editions turned it into a process standard and introduced the idea that the amount of V&V should depend on the integrity level of the software. The 2012 edition, titled for system and software V&V, was the big widening: it added separate clauses for system, software and hardware V&V, organised the processes in the life cycle process groups of ISO/IEC/IEEE 15288 and ISO/IEC 12207, and mapped the outcomes of those two standards to V&V tasks in an annex. The 2016 edition put hardware into the title as well, giving the name the standard still carries. The 2024 edition continues that line; as with any revision, the detailed changes are documented in the standard itself.

Purpose and scope in plain words

The standard's purpose is to set out the V&V processes that determine whether the products of a development activity conform to the requirements of that activity, and whether the product satisfies its intended use and user needs. Its scope covers:

systems, software and hardware, and the interfaces between them;
items that are newly developed, maintained or modified, and items that are reused, including legacy items and commercial off-the-shelf (COTS) components;
the whole life cycle, from concept and agreement through development, operation, maintenance and disposal;
a range of V&V methods, including analysis, evaluation, review, inspection, assessment and testing.

The standard is deliberately independent of any particular life cycle model. A waterfall project, an iterative project and a continuous-delivery team can all apply it, although not every project uses every process. What it fixes is the set of V&V outcomes and the way they scale with risk, not the order in which a team works.

What IEEE 1012 is not

IEEE 1012 does not tell you how to design a product, which programming language to use or how to write a test case. It is not a product certification scheme, and it does not set the acceptable risk for your sector: a regulator or a safety standard does that. It is also not a replacement for development discipline. V&V checks the work; it does not do the work. A project with poor engineering and excellent V&V will simply have a very well documented list of problems.

Lesson 2 – Key concepts and vocabulary

The single most important idea in the standard is the difference between verification and validation. Barry Boehm's famous summary is still the best memory aid: verification asks "are we building the product right?", validation asks "are we building the right product?". Figure 1 shows how the two questions relate to the chain of development products.

Figure 1 – Verification checks each development product against the one it was derived from; validation checks the finished item against the needs it is meant to serve.

Notice that validation is not only a final acceptance test. Requirements can be validated early, by asking users, building prototypes or running simulations, long before anything is built. Likewise verification is not only testing: most verification of requirements and designs is done by review, inspection and analysis.

Verification – confirming, with objective evidence, that the products of a development activity conform to the requirements and conditions set for that activity. It looks backwards along the development chain.
Validation – confirming, with objective evidence, that the product satisfies its intended use and the needs of its users in the intended environment. It looks outwards to the real world.
V&V effort – the whole body of V&V work on a project: its plan, people, tasks, tools, records and reports.
Integrity level – a value that expresses how important an item is, based on factors such as the consequences of its failure, its complexity, safety, security and reliability needs. In IEEE 1012 the integrity level decides which V&V tasks are mandatory and how thoroughly they are done.
Minimum V&V tasks – the tasks the standard requires for a given integrity level. Projects may add tasks; removing a required one needs a documented justification.
Intensity – the breadth of V&V coverage: how many items, scenarios, operating conditions or requirements the tasks cover.
Rigor – the formality and depth of the methods and records: for example, a structured inspection with checklists and logged results instead of an informal read-through, or formal analysis instead of a spot check.
Anomaly – anything observed in documentation, analysis or operation that deviates from what was expected based on requirements, design, standards or experience. An anomaly is not automatically a defect; it is something that must be evaluated.
Traceability analysis – checking that each requirement is linked to its source, to the design that implements it and to the tests or analyses that verify it, in both directions, so that nothing is missing and nothing is unexplained.
Criticality analysis – identifying which functions, items and requirements carry the highest consequences if they fail, so that integrity levels can be assigned and V&V attention focused.
Hazard analysis – identifying conditions that could lead to harm to people, property or the environment, and checking that the design removes or controls them.
Security analysis – identifying threats and vulnerabilities in requirements, design and implementation, and checking that security controls are specified and effective.
Independent verification and validation (IV&V) – V&V performed by an organisation that is separate from the developer in technical, managerial and financial terms. The degree of separation can vary, as Lesson 4 explains.
V&V plan – the document that records the scope, integrity levels, tasks, methods, schedule, resources, independence, reporting and administrative procedures for the V&V effort on a project.
Baseline – an approved version of a product, such as a requirements set or a software build, that changes only through a controlled change process. V&V assesses proposed changes against the baseline.

V&V, testing and quality assurance

Three terms are often confused. Testing is one V&V method: running an item under defined conditions and comparing results with expectations. It is important, but V&V also includes many methods that run nothing, such as requirements reviews and design analysis. Quality assurance, the subject of IEEE 730, gives confidence that the project's processes and products conform to their plans and requirements; it often audits the V&V effort itself. V&V, in turn, focuses on technical evidence about the product. The three overlap, and on a small project the same people may do all of them, but keeping the purposes distinct helps you avoid gaps.

Lesson 3 – Structure of the standard and integrity levels

How the content is organised

IEEE 1012 is a process standard. Without reproducing its contents, its organisation can be summarised in five blocks:

Overview and conformance. Scope, purpose, the V&V objectives, the intended audience, how to claim conformance and the limits of the standard.
Integrity levels. The concept, the example four-level scheme and how integrity levels select V&V tasks.
V&V processes by life cycle process group. The publicly available scope statement lists V&V for agreement processes, organisational project-enabling processes, project processes and technical processes, together with software implementation, software support and software reuse processes. These groups mirror the process structure of ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207, so a project that already maps its work to those standards can see where each V&V activity attaches.
System, software and hardware V&V activities. For each life cycle activity, the V&V tasks with their inputs, outputs and the integrity levels at which they are required. This content is largely tabular in the standard.
Reporting, administration and documentation. What the V&V effort must report, how anomalies are resolved, and the outline of a V&V plan. Informative annexes give guidance on topics such as independence, tailoring and the integrity level scheme.

The integrity level idea

Not every item deserves the same V&V effort. A function that calculates a radiation dose and the screen that lets an operator change the display language are both software in the same device, but a failure in the first could kill a patient while a failure in the second is an annoyance. Spending equal effort on both wastes money on the second and probably under-protects the first.

IEEE 1012 solves this with integrity levels. The project assigns an integrity level to the system and to its elements, and the standard then tells you the minimum V&V tasks for each level. Higher levels add tasks and demand greater intensity and rigor. Figure 2 shows the logic.

Figure 2 – Integrity levels are derived from consequence and likelihood and then decide which V&V tasks are required and how intensively and rigorously they are done.

The example scheme

The standard offers an example scheme with four integrity levels, numbered 1 to 4, where 4 is the highest. In outline:

Level 4 – the most dangerous combinations, such as an error with catastrophic consequences (loss of life, loss of the system or mission, or extensive financial or social loss) under conditions that are reasonably likely to occur. This level carries the most V&V tasks at the highest intensity and rigor.
Level 3 – serious combinations, such as critical consequences (major injury, major damage, partial loss of the mission) that are likely, or catastrophic ones that are rare.
Level 2 – moderate combinations, such as marginal consequences that the system or its operators can work around.
Level 1 – the least severe combinations, such as negligible consequences (minor inconvenience or a small effect on performance).

The example combines the consequence of an error (graded in four categories: catastrophic, critical, marginal and negligible) with the likelihood of the operating conditions that would let the error cause that consequence. A table in the standard maps each combination to a level; the list above is a simplified reading of it, not a substitute for the table. You do not have to use this exact scheme. Organisations often already have a risk scheme from a safety standard, a regulator or their own risk management process. IEEE 1012 allows another scheme, provided the project documents how its levels map to the standard's levels so that the minimum tasks can still be selected.

Rules of thumb for assigning levels

Assign levels early, during concept and requirements work, using criticality and hazard analysis. Late assignment means early V&V was planned blind.
Assign at the right granularity. A whole system usually contains elements of different integrity; splitting it lets you focus effort, but only if the architecture genuinely isolates the elements from each other.
An element that can disrupt a higher-integrity element (for example by corrupting shared memory, flooding a shared network or supplying wrong data) generally needs to be treated at the higher level unless the design isolates it.
Integrity levels are not fixed. Revisit them when the design, the operating context or the threat picture changes, and record each change with its reasoning.
Reused, legacy and COTS items also get integrity levels. Being off the shelf changes how you verify the item (more analysis of evidence and behaviour, less inspection of source code you may not have), not whether you verify it.

Lesson 4 – How it works in practice

V&V runs alongside the whole life cycle

The defining feature of IEEE 1012 in practice is that V&V starts with the project and does not stop at delivery. Each life cycle activity has matching V&V tasks, and V&V management ties them together. Figure 3 shows the pattern.

Figure 3 – V&V management plans and coordinates V&V tasks that accompany every life cycle activity, from concept and agreement to disposal.

Typical V&V tasks by activity

The exact tasks depend on the integrity level, but a typical pattern looks like this (names paraphrased):

Management of the V&V effort. Write and maintain the V&V plan, assess proposed changes to baselines, review V&V progress and results with management, support technical reviews, coordinate with configuration management, quality assurance and risk management, and identify process improvements.
Agreement (acquisition and supply). Check that contracts, statements of work and supplier requirements include the V&V obligations, deliverables and access to evidence that the integrity levels require.
Concept. Evaluate concept documents and operational scenarios, perform the first criticality, hazard, security and risk analyses, propose integrity levels, and check that the concept is feasible and complete enough to proceed.
Requirements. Analyse requirements for correctness, completeness, consistency, accuracy, readability and testability; trace them to their sources; analyse interfaces; update hazard, security and risk analyses; and begin planning system and acceptance tests, so that test thinking shapes the requirements.
Design. Trace design to requirements, analyse interfaces and data, evaluate the design against hazards and threats, and plan integration and component tests.
Implementation. Inspect or review code and hardware implementations against the design, check use of standards, perform component testing, and trace implementation to design and tests.
Integration and test. Plan, run and evaluate integration, system and acceptance tests; for validation, involve users and realistic operating conditions.
Transition and installation. Check the installation configuration, confirm that the installed item matches the verified baseline, and support installation and checkout testing at the operational site.
Operation and maintenance. Evaluate proposed changes, decide which earlier V&V tasks to repeat (regression analysis), monitor operational anomalies, and keep the evidence current.
Disposal. Check that retirement is planned, that data is migrated or archived correctly, and that dependent systems are not left in an unsafe state.

Each task has defined inputs (for example, the requirements specification and the hazard log) and outputs (for example, a task report and anomaly reports). This makes the effort auditable: anyone can check that a task was done, on which version of which product, and what it found.

Reports and the anomaly process

V&V produces evidence, and the evidence must reach the people who decide. IEEE 1012 requires a set of reports. In outline:

Task reports record the results of individual tasks such as a traceability analysis or a hazard analysis update.
Activity summary reports pull together the results for a life cycle activity, often as input to a stage gate or milestone review.
Anomaly reports record each anomaly with its description, location, impact, severity, cause where known and proposed resolution.
A V&V final report summarises the whole effort at the end of a project or release: what was done, what was found, how anomalies were resolved and any recommendations.

Projects may also produce special study reports, for example on a particular risk. Anomalies are tracked to closure through the project's problem resolution process: the developer fixes or justifies, V&V checks the fix, and unresolved anomalies are visible to management before key decisions. A healthy anomaly process is fast, factual and blameless; its aim is a better product, not a scorecard.

Independence

The value of V&V depends heavily on how independent it is. A developer reviewing their own design tends to see what they meant rather than what they wrote. A V&V team that reports to the project manager may be pressured to soften findings before a deadline. A V&V budget controlled by the developer can be cut when money is tight. These three risks correspond to the three dimensions of independence used in IEEE 1012 and by organisations such as NASA's IV&V programme:

Technical independence – V&V staff were not involved in developing the item, and they use their own methods, tools and analyses.
Managerial independence – V&V is managed separately from the development organisation, chooses its own focus and schedule within the plan, and reports its findings without them being altered or suppressed.
Financial independence – the V&V budget is controlled outside the development organisation so that schedule or cost pressure cannot quietly shrink it.

Figure 4 – The three dimensions of independence combine into a range of V&V forms, chosen according to the integrity level and risk of the item.

The informative guidance in the standard describes several forms along this range; the main ones are explained here. In classical IV&V an outside organisation has all three kinds of independence, which is typical for the highest integrity levels and for public programmes such as space missions. In modified forms, for example where the prime contractor or system integrator selects and directs the V&V organisation, some managerial independence is lost. Internal V&V is done by a separate group in the same organisation. In embedded V&V the work is done inside the development organisation, with the least independence. None of these is wrong in itself; the point is to choose deliberately, record the choice in the V&V plan and make the remaining conflicts of interest visible.

Agile and continuous delivery

Because the standard does not prescribe a life cycle model, it works with iterative and continuous delivery. In practice, requirement and design V&V happen per increment, automated tests and static analysis in the pipeline produce much of the routine verification evidence, and V&V staff focus on the analyses automation cannot do well: hazard and security analysis, traceability for high-integrity features, interface analysis between teams and validation with real users. The V&V plan then describes cadence ("each release" or "each sprint") rather than fixed phase dates, and pipeline records become part of the V&V evidence. What does not change is that high-integrity items still get the tasks, intensity, rigor and independence their level requires, however fast the team ships.

Lesson 5 – Assessment, conformance and compliance

There is no IEEE 1012 certificate

IEEE publishes the standard; it does not certify organisations, products or people against it, and there is no accredited certification scheme for IEEE 1012 comparable to ISO 9001 certification. Be wary of any offer of an "IEEE 1012 certificate" for an organisation. What exists instead is conformance: a project claims that its V&V effort meets the requirements of the standard, and others check that claim.

What a conformance claim rests on

A credible claim of conformance usually rests on these pieces of evidence:

a V&V plan that states the integrity scheme used, the integrity level of each item and the reasoning behind it;
evidence that at least the minimum V&V tasks for each level were planned and performed, with documented and justified tailoring where a task was changed or replaced;
task inputs and outputs tied to identified versions of the products (configuration control);
task reports, activity summary reports, anomaly reports and a final report;
a record of how anomalies were resolved and verified;
a statement of the independence arrangements and how they were maintained.

Who checks

Conformance can be examined in three ways. A first-party check is done by the organisation itself, for example by its quality assurance function under IEEE 730. A second-party check is done by the acquirer, who may write IEEE 1012 conformance, specific integrity levels or IV&V into the contract and then audit the supplier's V&V records. A third-party check is done by an independent assessor, a notified body or an IV&V contractor, often because a regulator or safety standard requires an independent opinion.

Where IEEE 1012 meets regulation

IEEE 1012 is referenced in several regulated sectors, typically through contracts or regulatory guidance rather than as a law in its own right. A well-known example is the US Nuclear Regulatory Commission, whose regulatory guidance on V&V for safety-system software in nuclear power plants has endorsed an earlier edition of IEEE 1012, with conditions. Defence and space acquirers have long used it to define IV&V on critical programmes. In other sectors (rail, automotive, aviation, medical devices) the sector's own safety standard is primary, and teams use IEEE 1012 as a detailed reference for planning and documenting V&V that the sector standard requires in more general terms. In every case, check which edition the regulator or contract names and whether any exceptions apply.

Assessing the quality of a V&V effort

Beyond a yes-or-no conformance check, an assessor should ask whether the V&V effort was effective. Useful signs are: anomalies found early (in requirements and design) rather than mostly in system test; integrity levels that were revisited when the design changed; traceability that is complete for the highest-integrity items; hazard and security analyses that changed the design; and V&V findings that management acted on. A thick file of reports that never changed a decision is a warning sign.

Lesson 6 – Worked example: a water treatment dosing system

The situation

A regional water utility is replacing the control system that adds chlorine to drinking water at its main treatment plant. The new system has four elements: a dosing controller (programmable logic controller hardware with control software) that adjusts the chlorine pump from sensor readings; an operator workstation for monitoring and set-point changes; a reused legacy alarm module from the old system; and a commercial data historian that stores readings for regulatory reports. The utility's engineering team will integrate the system with help from a supplier. Under-dosing could allow pathogens into the supply; over-dosing could make water unsafe to drink. The board asks the engineering manager to "show that the system is safe before it goes live". She decides to plan V&V according to IEEE 1012-2024.

Step 1 – Criticality and integrity levels

In the concept phase, a small team of process, control, safety and security engineers runs a criticality and hazard analysis. They use the standard's example four-level scheme, mapped to the utility's existing risk matrix:

Dosing controller (software and hardware): level 4. A wrong dose could harm thousands of people (a catastrophic consequence), a control error is credible over years of continuous operation, and no other automatic barrier fully prevents it.
Legacy alarm module: level 3. It alerts operators to abnormal chlorine levels, a key mitigation, but a separate hand-held testing regime offers partial backup.
Operator workstation: level 3. An operator could enter a wrong set-point; the team decides to add range limits in the controller so that the workstation cannot command an unsafe dose; without those limits the workstation would have to be treated at level 4 like the controller.
Data historian (COTS): level 2. Lost data would breach reporting obligations but would not affect water safety, provided it is isolated from the control network.

The team records the reasoning for each level, including the isolation assumptions, in the draft V&V plan. They note that if the historian is ever allowed to send commands to the controller, its level must be reassessed.

Step 2 – Independence and the V&V plan

For the level-4 controller the manager hires an IV&V firm that has no link to the supplier, reports directly to the utility's operations director and is paid from a separate budget line: classical independence. For the level-3 and level-2 elements, the utility's own quality and test group, which is outside the project team, performs internal V&V. The V&V plan lists items and levels, the minimum tasks per level, methods, schedule linked to project milestones, resources, the independence arrangement, the anomaly process, the reports and the configuration items each task will use. The contract with the supplier is updated so that the IV&V firm has access to design documents, source code and test results.

Step 3 – Requirements V&V

The IV&V firm traces each controller requirement back to the process design and the drinking-water regulations, and forward to planned tests. It finds three anomalies: no requirement states what the controller must do if a chlorine sensor fails; two documents give different maximum dose rates; and the response time for a dosing correction is not testable as written. The anomaly reports go to the project, the requirements are corrected, and the IV&V firm verifies the corrections. A security analysis adds requirements for authenticated set-point changes and for network separation between the historian and the controller.

Step 4 – Design and implementation V&V

Interface analysis between the workstation and the controller reveals that set-points are sent in different units in two message types. The fix is cheap at this point. The IV&V firm inspects the controller logic against the design, using checklists for numeric handling and fail-safe behaviour, and reviews the supplier's component tests for coverage of boundary conditions. For the legacy alarm module, the internal V&V group cannot rely on the old documentation, so it analyses the module's behaviour, runs focused tests on the alarm thresholds and checks its operating history for recorded faults.

Step 5 – Integration, system and acceptance testing

System tests run on a test rig with simulated sensors, including sensor failure, power loss and communication loss. Validation goes further: experienced plant operators run realistic shift scenarios on the rig, including a sudden change in raw water quality, and confirm that alarms, displays and procedures let them respond in time. One finding is that an important alarm is hard to see among routine messages; the display is redesigned before acceptance.

Step 6 – Installation, operation and change

At installation, V&V checks that the controller software running at the plant matches the verified baseline and repeats a defined set of checkout tests on site. Six months later, the supplier proposes a firmware update for the controller hardware. V&V evaluates the change, decides which earlier tasks must be repeated for a level-4 item, and the IV&V firm reviews the regression results before approval. When the old system is decommissioned, V&V confirms that historical data was archived and that no live connection to the old equipment remains.

Step 7 – Reporting

Each milestone review receives an activity summary report. Before go-live, the board receives the V&V final report for the release: the integrity levels and their reasons, tasks performed, 41 anomalies found (most in requirements and design), how each was resolved, two accepted residual risks with their owners, and a recommendation to proceed. That is what "show that it is safe" looks like in IEEE 1012 terms: a traceable, independent and proportionate body of evidence, not a single test run.

Lesson 7 – Relationship to other standards and frameworks

IEEE 1012 sits in a family of system and software engineering standards and is often used together with sector safety standards. The table summarises the most common relationships.

Standard or framework	Main focus	Relationship to IEEE 1012
ISO/IEC/IEEE 15288 (system life cycle processes)	Defines the full set of system life cycle processes, including verification and validation processes	Provides the process framework; IEEE 1012 adds detailed, integrity-scaled V&V tasks attached to those processes
ISO/IEC/IEEE 12207 (software life cycle processes)	The software counterpart of 15288	IEEE 1012's software implementation, support and reuse process groups follow the software-specific process structure of 12207
ISO/IEC/IEEE 29119 series (software testing)	Test processes, documentation and test design techniques	Gives detailed guidance for the testing part of V&V; IEEE 1012 decides which testing is needed and how it fits with reviews and analyses
IEEE 730 (software quality assurance)	Assurance that processes and products conform to plans and requirements	Complementary; SQA often audits the V&V effort, and V&V results feed SQA evidence
IEEE 1028 (software reviews and audits)	Procedures for management reviews, technical reviews, inspections, walk-throughs and audits	Supplies methods for the review and inspection tasks that IEEE 1012 requires
ISO/IEC/IEEE 29148 (requirements engineering)	Processes and characteristics of good requirements	Defines what good requirements look like; IEEE 1012 requirements V&V checks them against such criteria
Sector safety standards (IEC 61508, ISO 26262, DO-178C, IEC 62304)	Safety life cycles with their own integrity schemes (SIL, ASIL, DAL, safety classes)	The sector standard is primary; IEEE 1012 can structure V&V planning, with the sector's scheme mapped to its integrity levels
NASA and ESA IV&V practice	Agency programmes and guides for independent V&V of mission-critical software	Apply the same independence dimensions and risk-based scoping that IEEE 1012 describes

How to combine them

A practical rule is to let the life cycle standard (15288 or 12207) define which processes exist, let IEEE 1012 define what V&V must be done in each and how much, and let the specialist standards (29119 for testing, 1028 for reviews, 29148 for requirements) define how each method is performed. Where a sector safety standard applies, it sets the required integrity and the evidence a regulator expects; IEEE 1012 then helps organise and document V&V without contradicting it. Where an organisation already follows a capability model or an ISO 9001 quality system, the V&V plan becomes one of the controlled project documents and V&V records become quality records.

Neighbours that are easy to confuse

Two confusions are common. First, the verification and validation processes in ISO/IEC/IEEE 15288 are short process descriptions with purposes and outcomes; they do not scale tasks by integrity level or define reports and independence in the detail IEEE 1012 does. Second, the integrity levels of IEEE 1012 are not the same as the safety integrity levels of IEC 61508 or the assurance levels of DO-178C, even though the ideas are related. Always document the mapping; never assume that "level 4" in one scheme equals "level 4" in another.

Common pitfalls and best practices

Pitfalls to avoid:

Treating V&V as the final test phase. Starting V&V at system test means requirement and design defects are found when they are most expensive, or not found at all.
Everything at the same integrity level. Rating every item at the top level makes V&V unaffordable and tends to dilute effort; rating everything low hides real risk. Both avoid the hard thinking the standard asks for.
Assigning integrity levels once and never again. Designs, interfaces and threats change; a level that was right at concept may be wrong after a new connection is added.
Calling self-review independent. A team checking its own work, or a V&V group whose budget and reporting line belong to the project manager, does not provide the independence a high-integrity item needs.
Equating V&V with testing. Skipping reviews, traceability, interface, hazard and security analysis leaves whole classes of defect undetected.
Ignoring COTS, reused and legacy items. Off-the-shelf does not mean verified for your use; these items need integrity levels and suitable V&V.
Reports nobody reads. Anomaly reports that never reach decision makers, or a final report written after the go-live decision, turn V&V into paperwork.

Best practices:

Plan V&V at project start and write V&V obligations, access to evidence and independence into supplier contracts.
Base integrity levels on documented criticality and hazard analysis, record the reasoning and isolation assumptions, and review the levels at every major design change.
Match independence to integrity: classical IV&V or a clearly separate group for the highest levels, lighter arrangements where consequences are small.
Maintain bidirectional traceability from needs to requirements, design, implementation and verification results, at least for high-integrity items.
Validate early and with real users, using prototypes and realistic scenarios, not only at acceptance.
Automate routine verification in the build pipeline and keep its records, so that V&V experts can spend their time on analysis.
Run a fast, blameless anomaly process and present open anomalies at every milestone decision.
Use the V&V results to improve the process, for example by tightening a review checklist when the same class of defect keeps appearing.

Summary and key takeaways

IEEE 1012-2024 is the current, active IEEE standard for verification and validation of systems, software and hardware; a revision project was authorised in 2026, but no successor has been published.
Verification checks that each development product conforms to the requirements of its activity; validation checks that the product meets its intended use and users' needs. Both use reviews, analyses and tests.
Integrity levels, derived from consequence and likelihood, decide the minimum V&V tasks and their intensity and rigor; another scheme may be used if it is mapped.
V&V runs in parallel with every life cycle activity, from concept and agreement to disposal, under V&V management and a V&V plan.
V&V produces task reports, activity summary reports, anomaly reports and a final report, and anomalies are tracked to verified closure.
Independence has technical, managerial and financial dimensions; the degree chosen should match the integrity level and be documented.
There is no certificate for IEEE 1012; conformance is shown with evidence and checked by first, second or third parties, often because a contract or regulator requires it.
IEEE 1012 complements ISO/IEC/IEEE 15288, 12207, 29119, IEEE 730 and sector safety standards rather than replacing them.

Reflection questions

Pick a system you work on. Which of its elements would you place at the highest integrity level, which at the lowest, and what evidence would you use to justify the difference?
Think of a defect that reached production in a project you know. Which V&V task, at which life cycle stage, would most likely have caught it earlier, and why was it not done?
How independent is the checking in your organisation today? Assess it against the technical, managerial and financial dimensions and name one change that would strengthen the weakest one.
Your team moves to releasing every week. How would you rewrite a phase-based V&V plan so that high-integrity items still receive the required intensity and rigor?
A supplier delivers a commercial component with no source code. How would you decide its integrity level, and what V&V evidence could you still obtain or create?