The 4 Types of Requirement Confirmation

Every user requirement must be a clearly stated expressions of a stakeholder need for an externally-observable characteristic of the system being developed. Therefore, it must be possible to check that the system we have built satisfies all of its user requirements. Since there are different ways to check things, it is helpful to identify the 4 types of requirement confirmation and to tag all requirements with one or more of these types as early as possible in their development.

the 4 types of requirement confirmation
Verification and Validation in the Systems Lifecycle

Verification and Validation

But first, we need to define some terminology. The terms verification, validation and the acronym V&V are often used for checking compliance with requirements. Sometimes they are used differently, which can be confusing. So, we will define them first:

  • Verification is the activity of checking that the implementation, build or construction of a component, and the system itself, has been done properly. It is the idea of checking that a power outlet has been wired correctly and that it is properly earthed. Verification means to answer the question “have we built it correctly?”.
  • This is a good question to ask, but it does not answer the question “have we built the correct thing?”. That is validation. So, validation means to check that the system conforms to what its stakeholders asked for.
  • V&V is the combination of these two. Depending on your preference, it could mean either Verification and Validation, or Validation and Verification. Most of us in 3SL prefer the second, as it is a little easier to say. The two are equivalent. As a result, V&V simply means to check everything, from the quality of the raw materials, and the fabrication or assembly of components, to the final inspection, configuration, alignment or calibration of the finished product.

The 4 Types of Requirement Confirmation

The 4 types of requirement confirmation are:

  • Inspection, or I
  • Analysis, or A
  • Demonstration, or D
  • Test, or T

We usually abbreviate these types to IADT. They are often called validation methods.

Most requirements will have one of these validation methods, but sometimes a requirement will have more than one.

The Requirements Confirmation Methods

We can describe the 4 types of requirement confirmation as follows.

Inspection

Inspection is the examination of the product or system using basic senses. This means to do one or more of look at it, touch it, smell it (rarely applicable), taste it (even more rarely applicable!). So, we would physically examine a product and check that all its physical characteristics are as required and that it has all of the controls that it is supposed to have. Similarly, for a software system, we would check that its UI is as required, that it has all of the data entry fields and buttons that it is supposed to have. For a web application, we would check its appearance on different screen sizes.

Analysis

Analysis is the validation of a product or system using calculations and models. We will use analysis to make predictions of the product or system’s performance based on some representative, actual, test results. We can use analysis to calculate failure points based on actual test results, without resorting to destructive testing (expensive as we can only do it once!).

Demonstration

Demonstration means that we use the product or system as it is intended to be used. So we can follow the functional user requirements and check that the product or system does what the user requirements say that it should do. We will press every button and use every control in a product to confirm that the product does what it is supposed to do. For software, we enter data as users will do and ensure that the software performs the actions that it is supposed to do and check that its reports are correct.

Test

Test is a more precise and controlled form of demonstration. We test a product to confirm that it behaves precisely as specified under a set of carefully specified test conditions. We repeat these operations using different sets of test conditions, following precisely-specified steps to complete the test. Therefore, this is often to verify performance requirements.

Use in the Process

It is good practice to specify the confirmation criteria for each requirement as it is written. This is because it helps reviewers to confirm that the requirement has been written clearly, by answering questions such as “could I inspect the product and confirm this requirement?”, or “could I demonstrate that this requirement has been met with the finished product?”, and so on.

Once the requirement and its confirmation method(s) are agreed, we can create its confirmation item(s). If a requirement is simple, then it will have one confirmation. If complex, we will create more than one confirmation.

Similarly, if the requirement has multiple confirmation methods, then we will need a confirmation item for each of them.

Therefore, the goal would be a single validation for each requirement, because an atomic requirement (one that says only one thing) should only need one validation.

Of course, both user requirements and system requirements will have a confirmation method. So we would normally talk about validations and verifications, and not the more general term, confirmations. Therefore, we would refer to:

  • The validation method of each user requirement
  • Writing validation items for user requirements
  • The verification method of each system requirement
  • Writing verification items for system requirements

Although it is impossible to generalise:

  • The confirmation methods of user requirements are predominately Inspection and Demonstration
  • The confirmation methods of system requirements are predominately Test and Analysis

Functional and Non-Functional Requirements

A Requirement that works and one that doesn’t?

Grammatically the difference between the types of requirement could be seen like that, but not so in RM (Requirements Management) parlance. Functional and Non-Functional Requirements are a what and how of engineering.

HID showing how functional and non-functional requirements link to form the overall set
Interlinked Functional and Non-Functional Requirements

Functional Requirement

These define what the features are. “The User Interface board shall send an enable signal when the user presses the On key”
or “The finance reporting mechanism shall produce a summary report automatically at the end of each month”. These requirements tell the designer/implementer what the systems need to do. They can be read and agreed by the customer and will align with their expectations of the system.

Functional requirements are not limited to actions. They can include regulatory or safety requirements, “The system shall be protected and able to be certified to IP44”, or internal rules “The output format shall be commensurate with detail explained in the operating procedures for the production line”. They can reference other external requirements or standards. “The electrical interface shall be compatible with USB 2.0 standards using type A connectors, verified by a third party.”

Non-Functional Requirement

These define how the system will operate. They will place constraints and capacities on the system that can be measured.  “The User Interface  enable signal shall be a TTL level present within 0.25 seconds of the user making contact with the physical interface” or “The finance reporting mechanism shall be capable of summarising 100K entries into the 10 specified categories”.

These limits and descriptions provide bounds within which the Functional Requirements can me met. “The system shall allow users to cross the road safely” is a wide Functional Requirement. “The user shall not need to interact directly with the facility”, “The design shall comprise of a fixed physical system requiring no power”. Looks like we’re building a bridge or subway rather than a pelican crossing then!

Lines are Drawn

There is always going to be a grey line between the two areas. Some will depend where the responsibilities end and so on one project what is deemed a functional requirement. “The interface must be USB 2.0”, is a main operating characteristic that our system can not change and is needed to interface to an external system. On another project the functional requirement may be “The main system should interface with up to three external input and output devices” and the design team may decide “All inter product interfaces shall use USB 2.0 standard communications”

In the ideal world everything should operate 100% of the time without failure and should be completely intuitive. Should occur without delay and should be fixable for ever. However, the world we live in is not ideal. System designers need to recognise that. Non-Functional Requirements can define these limits and manage expectations, from both a contractual and measurable quality point of view.

  • “To aid the user to perform the task consistently. The UI shall provide guidance in the form of fixed text and sequenced indicators.”,
  • The system shall have an availability no less than 99% of the time”, 
  • “Visual and audible feedback shall be provided within 0.2 seconds of any interaction”,
  • “Design components should have an availability before EoL of two years minimum”

For every system these user experience, reliability, performance criteria, and through lifecycle considerations should be made.