In Software validation, requirements can be checked against following conditions

The process of ensuring the specified requirements meet the customer needs.

This is a series of articles inspired by Software Engineering, 9th edition

Requirements Validation

It’s a process of ensuring the specified requirements meet the customer's needs. It’s concerned with finding problems with the requirements.

These problems can lead to extensive rework costs when they are discovered in the later stages, or after the system is in service.

The cost of fixing a requirements problem by making a system change is usually much greater than repairing design or code errors. Because a change to the requirements usually means the design and implementation must also be changed and re-tested.

During the requirements validation process, different types of checks should be carried out on the requirements. These checks include:

1. Validity checks: The functions proposed by stakeholders should be aligned with what the system needs to perform. You may find later that there are additional or different functions are required instead.
2. Consistency checks: Requirements in the document shouldn’t conflict or different descriptions of the same function
3. Completeness checks: The document should include all the requirements and constraints.
4. Realism checks: Ensure the requirements can actually be implemented using the knowledge of existing technology, the budget, schedule, etc.
5. Verifiability: Requirements should be written so that they can be tested. This means you should be able to write a set of tests that demonstrate that the system meets the specified requirements.

There are some techniques you can use to validate the requirements, and you may use one or more of them together, depending on your needs.

Requirements Reviews

A team of system customers; those who interact with the customer to gather requirements, and system developers start reading the requirements in the document and investigate in great detail to check for errors, inconsistency, conflicts, and any ambiguity.

Then they may negotiate with the customer on how to solve the problems and errors found.

Prototyping

We’ve discussed prototyping as one of the (non-standalone) software process methodologies which is used as part of a full methodology, and we’ve also mentioned it can be used in requirements engineering.

In this approach to validation, an executable model of the system is demonstrated to the customer and end-users to validate and ensure if it meets their needs.

Prototyping is usually used when the requirements aren’t clear. So, we make a quick design of the system to validate the requirements. If it fails, we then refine it, and check again, until it meets the customer's needs.

This definitely will decrease the cost as a result of having clear, understandable, consistent requirements.

Test-case Generation

As we’ve just mentioned, the requirements need to be testable. If the tests for the requirements are added as part of the validation process, this often reveals requirements problems.

If the test is difficult or impossible to design, this usually means that the requirements will be difficult to implement and should be reconsidered.

The term “tests” here doesn’t mean to write and run some code for every function. It means to write a textual description of the “inputs”, “expected value”, and “steps taken” to perform each function.

Here’s a template for a test case.

It’s difficult to show that a set of requirements does in fact meet a user’s need. Because users need to use the system in operation and imagine how that system would fit into their work. So, it’s inevitable that there will be further requirements changes.

If you’ve heard the terms “verification” and “validation” used interchangeably, you aren’t alone. However, this creates confusion during the testing process, and if you’re building products in highly regulated industries, it’s critical that products perform as expected and expensive errors are avoided.

Unclear and incomplete requirements can be frustrating for software developers, and if developers can’t get the required information up front, they must make interpretations, which aren’t always correct. The result is higher risk of errors and extra resources spent fixing issues further into the product development cycle.

Understanding the difference between verification and validation and how to use each during product development helps reduce cost, increase efficiency and deliver a product that better fits user requirements.

What is requirements verification?

If you’ve used verification and validation interchangeably in the past, one of the most important things to note is order. Software verification comes first, followed by validation. But what’s involved with each? Let’s dive into verification first.

Verification tests check to ensure the program is built according to the stated requirements. The verification process includes activities such as reviewing the code and doing walkthroughs and inspections.

Missing requirements or invalid requirements can be discovered during this phase, which can minimize risk of rework and the cost associated with overruns. It’s far more effective to fix a small bug up front than in the future when hundreds of lines of code must be identified and corrected.

For example, imagine that you’re driving to a new destination. You might plug that destination into your GPS, which provides directions and the freeway exit number. If you’re looking for exit 10 and just passed exit 1, you quickly know you have nine more exits to go. Using the GPS allows you to check your existing path against the directions, which is similar to the verification phase.

Another example is entering a formula into a spreadsheet. After entering a few rows of data, you might check the formula and make sure that it’s working. The process of verification is the same in that it allows you to do a quick check before getting too deep into the product development process.

RELATED POST: What is Requirements Traceability and Why Does it Matter for Product Teams?

What is requirement validation?

After you’ve completed verification, it’s time to complete validation testing, which confirms the accuracy of the requirements. It ensures that the requirements have achieved the business objectives, meet the needs of any relevant stakeholders and are clearly understood by developers. Validation is a critical step to finding missing requirements and ensuring that requirements have a variety of important characteristics. Software validation addresses the following:

• Correctly outlines the end user’s need.
• Has only one exact meaning.
• Can be modified as necessary.
• Documents the attributes that customers truly need.
• Easily linked to system requirements, such as designs, codes and tests.
• The ability to implement can be verified through testing, inspection, analysis and demonstration.

Validation isn’t focused on the path that you traveled to arrive at the destination but is instead focused on whether you’ve hit the mark. For example, consider the last example of a person traveling in a car and tracking landmarks, such as exit numbers. Let’s say the goal is to arrive at a hiking trail. A few questions might be asked when you arrive.

• Does the hiking trail look as expected?
• Can I see a marked trail and trailhead sign?
• Does the location meet my expectations?

Verification validation is focused on the same types of questions. It’s not concerned with how you got there, but that you arrived at the correct location.

If you’re designing a spreadsheet, as we discussed before, you checked that the formula worked during the verification process. During validation, you’re making sure the end product (the spreadsheet) meets the needs of the user.

RELATED POST: Requirements Management Tools and Software

Verification and validation: What’s the difference?

As you consider validation vs. verification, you might feel unsure about the differences. What activities fall under the category of validation and which fall under verification, and when should you perform each?

Let’s say that you’re working to create a product and it’s time for verification testing, since verification always comes first. During this process, you check documents, design, code and the program to make sure the software is built according to requirements. The goal is to ensure the quality of the application or design. You might conduct activities such as reviews, walkthroughs or inspections.

Now, it’s time to move on to validation verification. During this process, you’re testing and validating whether the product meets the needs of your customer. Tasks in this process may include unit testing, integration testing or user testing. Here are more differences between verification and validation.

• The verification process does not include code. In contrast, validation includes executing relevant code.
• Methods used during each process are different. Verification might include reviews, walkthroughs and inspections. Validation might include white-box testing, black-box testing and nonfunctional testing.
• The verification process ensures that software meets specifications. Validation focuses on whether the software meets the expectations and requirements of the end user.
• Verification finds potential issues early in the product development process. Validation finds any issues that verification missed.
• Validation focuses on the actual software product, whereas verification is focused on the software architecture, database and design.

Let’s look at another example of verification and validation in software testing. Imagine that you’re working on creating a clickable website button with the text “click here,” but the existing text actually reads “click her.” The verification process would check the document design and fix the spelling mistake. Once fixed, validation would occur, which would check the functionality of the button. Does it work how a user expects it to work? If not, the functionality would be remedied during this phase.

RELATED POST: Nonfunctional Requirements vs. Functional Requirements – What’s the difference? 

Streamlining Collaboration During Verification and Validation with Software

For system engineers, being able to trace relationships between data types is essential. However, there can be a problem with multiple levels of requirements, specification and verification artifacts all having their own set of stakeholders who are performing a variety of tasks.

The right software solution can simplify complicated situations and enable you to add traceability of the data. You can analyze the “who, what, where and why” of potential changes and make sure that essential data doesn’t get overlooked. Look for a software solution that does the following:

• Connects test cases from a problem statement to your requirements and design. If you don’t have the ability to do this, you can’t be sure that you haven’t overlooked something critical.
• Connects system requirements to business and stakeholder requirements. If you miss a critical connection, you risk unplanned expenses that may have a ripple effect and create slowdowns in product launches, weaken stakeholder confidence and adversely affect the bottom line.
• Improves decomposition. It’s critical to relate lower-level requirements to higher-level requirements to ensure that components and subcomponents all come together into a functional system. Mistakes in this area may lead to extra costs as you work hard to put the pieces back together and implement changes later in the product development process.

A software solution is a critical tool in helping you manage the verification and validation process and ensure that every engineering activity is connected throughout the entire system life cycle. It’s critical to capture all communication in context and bring stakeholders together in one place for a real-time and comprehensive look into what teams are building and why.

Moving Into the Future

Testing can be one of the most expensive parts of product development, without proper planning. It’s important to incorporate verification and validation to ensure cost savings and a high-quality product. In the end, if the product doesn’t meet the original objectives, then time, money and effort are wasted.

Fortunately, companies can get products to market faster when people and data stay in sync with product development activities and deliverables. Using innovative software tools can easily shorten the time from ideation to value creation and performance.

See how Jama Connect streamlines requirements verification and validation. 

LEARN MORE

• Author
• Recent Posts

What are the measures to validate the requirements of software system?

What checks should be applied during requirements validation?

What is called validating requirements explain?

What is the need of requirement validation in software engineering?