Software Requirements: Verification vs Validation

Validation and Verification

The software requirements specification document is a written contract between the developer and client which explains the application domain and the system to be developed. This specification document is the bridge between the application domain and the machine domain, and it is therefore used as a baseline for evaluating the software. Making sure that these specifications are correct and complete is essential to building successful software.

There are three domains involved in this process. The application domain contains domain properties and requirements.

Domain Properties : Domain properties are things in the application domain that are true regardless of whether the proposed system is ever built.

Requirements : Requirements in the application domain are the things that we wish to be made true by deliverying the proposed system.

The machine domain, on the other hand, is the computer hardware and the programs it can run. The third domain is the specificaions which connects the application and machine domain (see diagram below). A specification is a description of the behaviours a computer program must have in order to meet the requirements, it is the glue that connects the application and machine domain and it is a critical part of the whole system.

Since software is built based off specifications, it is important that these specifications reflect the application domain as best as possible. For this reason there are completeness (validation) criteria and correctness (verification) criteria. The validation criteria tie the application domain (the real world) to the specifications, making sure they are complete:

  • We discovered all the important requirements.
  • We discovered all the relevant domain properties.

The verification criteria tie the machine domain to the specifications:

  • The program running on a particular computer satisfies the specifications.
  • The specifications, in the context of the given domain properties, must satisfy requirements in the application domain.

The way I remember it is that, before we can write specifications we must know the application domain and ensure that we have a complete picture of that domain. To ensure our specifications are comp*Lete, we use vaLidation criteria to make sure we discovered aLl the important and relevant requriements and domain properties. Once we have built a program according to our specifications we must make sure that we built the right program that satisfies all the specifications. To do this, we use the coRrectness criteria to veR*ify the system we built is the system described by the specifications.

To give a simple example of how these ideas actually work consider a university second hand book shop. At the start of a new semester (busy time) staff can not keep up with logging book inventory. This causes all kind of problems because invenotory figures are constantly out of date. The requirement would be that staff wish stock levels were up to date in their system. The domain property in this case is that stock levels change under two circumstances:

  • As a student wants I want to sell my book to the book store because I dont need it anymore.
  • As another student I want to buy that particular book from the book store because I am studying that sbuject next semester.

Knowing these characteristics of the application domain we can formulate the following specifications $$S$$:

  • When a new book is purchased, the system shall increment the inventory figure by one.
  • When a book is sold, the system shall decrement the inventory figure for that book by one.

These specifications define the behaviors of a program that would satisfy the requirements $$R$$ in context of the domain properties $$D$$. Developers use the specification document and come up with an inventory tracking system that they think meets the specifications. The program P, in this example, is simply the system the developers implemented. Similarly, the computers $$C$$ are simply the machines that run the inventory tracking system (these are pretty much the same in any example).

As always, I hope this creafully crafted post helped you understand the content better than reading your lecture notes. If there are any errors in this post, please point them out in the comments.

Related posts

Design Thinking: How to critically assess a solution in relation to the problem

Setting up basic motion activated Lighting with Home Assistant automation

Separation of concerns in Distributed Computing (Multi-tier architectures)

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Read More