To get a trial key
fill out the form below
Team License (a basic version)
Enterprise License (an extended version)
* By clicking this button you agree to our Privacy Policy statement

Request our prices
New License
License Renewal
--Select currency--
* By clicking this button you agree to our Privacy Policy statement

Free PVS-Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

Message submitted.

Your message has been sent. We will email you at

If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

Verification and validation

Verification and validation

Jan 12 2010

The terms verification and validation are related to software quality checking. We use these terms in our articles and reports. Very often we have heard various comments and debates concerning the question if static analysis of program source code should be referred to verification and validation and in what way these notions differ. On a whole, it seems that everyone means something different by these terms and it leads to a mutual misunderstanding.

We decided to make it clear in order to stick to the most proper understanding of these notions. During the investigation we came across a work by V.V. Kulyamin "Software verification methods" [1]. It gives a thorough description of the terms and we decided to further rely upon the definitions provided in this work. Here are some extracts from it related to verification and validation.

Verification and validation are the types of activity intended for checking the quality of software and detecting errors in it. Having the same goal, they differ in the origin of the properties, rules and limitations (whose violation is considered an error) being tested during these processes.

Before going on we must introduce the term "an artefact of software life-cycle". By artefacts of software life-cycle we understand various information entities, documents and models created or used during the process of software development and maintenance. Thus, requirements specification, architecture description, domain model in some graphics language, source code, user documentation etc. are artefacts. Various models used by single developers during software creation and analysis but not fixed in the form of documents available to other people are not considered artefacts.

Verification checks if some artefacts being created while developing and maintaining software correspond to some other artefacts created earlier or being used as source data and also if these artefacts and processes of their development correspond to the rules and standards. In particular, verification checks if standards, software requirements specification, design decisions, source code, user documentation and operation of the software itself correspond to each other. Besides, it checks if the requirements, design decisions, documentation and the code are arranged in correspondence with the software development rules and standards accepted in a particular country, branch and organization, and also if all the operations stated in the standards are executed and in the appropriate sequence. Defects and errors detected during verification are divergences between some of the listed documents, between documents and actual program operation or between standards and actual processes of software development and maintenance. Making a decision what document must be corrected (if not both of them) is a separate task.

Validation checks if any artefacts being created or used in the process of software development and maintenance correspond to the needs of the users and customers of this software, with taking into account the laws of the domain and limitations of software usage context. These needs are usually not fixed in the form of a document - when they are, they turn into a requirements specification, i.e. one of the artefacts of the software development process. That is why validation is a less formal activity than verification. It is always carried out in the presence of customers', users', business-analysts' or domain experts' representatives - those whose opinion can be considered a rather good expression of the needs of users, customers and other persons concerned. The methods of its execution often involve specific techniques of discovering knowledge and actual needs of the participants.

The difference between verification and validation is illustrated in Figure 1.


Figure 1 - Relation between verification and validation

The definitions given above are drawn through some extension of the definitions of IEEE 1012 standard on the processes of verification and validation [2]. In the standard software engineering glossary IEEE 610.12 of 1990 [3], the definition of verification is nearly the same but the definition of validation is different - it is said there that validation must check if the result software corresponds to the requirements set to it in the beginning of the development process. In this case, validation would be an instance of verification but it is not mentioned anywhere in literature on software engineering, and this is the reason, together with the fact that this definition was corrected in IEEE 1012 of 2004, that it should be considered incorrect. This phrase by B. Boehm which is used very frequently [4]:

Verification answers the question "Are we making the product properly?" while validation - "Are we making a proper product?"

also contributes to the confusion because its aphoristic character, unfortunately, combines with ambiguity. But multiple works of this author allow us to think that he meant by verification and validation nearly the same notions that were defined above. The described discrepancies can be traced in the content of software engineering standards. Thus, ISO 12207 standard [5] considers testing a kind of validation but not verification and it seems to result from sticking to the incorrect definition of the standard glossary [3].

In conclusion, I would like to note that according to the definitions given above static source code analysis corresponds to software verification being the method of checking correspondence between program code and various coding standards. Static analysis checks if the results of the stage of designing a program system correspond to the requirements and limitations stated before.


  • IEEE 1012-2004 Standard for Software Verification and Validation. IEEE, 2005.
  • IEEE 610.12-1990 Standard Glossary of Software Engineering Terminology, Corrected Edition. IEEE, February 1991.
  • B. W. Boehm. Software Engineering; R&D Trends and Defense Needs. In R. Wegner, ed. Research. Directions in Software Technology. Cambridge, MA:MIT Press, 1979.
  • ISO/IEC 12207 Systems and software engineering - Software life cycle processes. Geneva, Switzerland: ISO, 2008.
Popular related articles
Four reasons to check what the malloc function returned

Date: Apr 20 2022

Author: Andrey Karpov

Some developers may be dismissive of checks: they deliberately do not check whether the malloc function allocated memory or not. Their reasoning is simple — they think that there will be enough memor…
Trojan Source: Invisible Vulnerabilities

Date: Apr 15 2022

Author: Guest

We present a new type of attack in which source code is maliciously encoded so that it appears different to a compiler and to the human eye. This attack exploits subtleties in text-encoding standards…
Vulnerabilities due to XML files processing: XXE in C# applications in theory and in practice

Date: Feb 11 2022

Author: Sergey Vasiliev

How can simple XML files processing turn into a security weakness? How can a blog deployed on your machine cause a data leak? Today we'll find answers to these questions, learn what XXE is and how it…
Design and evolution of constexpr in C++

Date: Jan 13 2022

Author: Guest

constexpr is one of the magic keywords in modern C++. You can use it to create code, that is then executed before the compilation process ends. This is the absolute upper limit for software performan…
The first static analysis report: the key problems and how to address them

Date: Dec 09 2021

Author: Nikolay Mironov

The main purpose of the static analyzer is to detect and report errors in code - so that you can fix them afterwards. However, reporting errors is not as simple as it may seem. Those just starting ou…

Comments (0)

Next comments
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →