Tag Archive for: Verification and Validation

Tag Archive for: Verification and Validation

[Webinar Recap] The Costly Impact of Ineffective Requirements Management in the Medical Device Industry

In this post, we recap a recent webinar hosted by Jama Software on the topic of requirements management in the medical device industry

Requirements management solutions enable the unification of siloed processes and data that often reside in outdated, disparate, and disconnected legacy systems. However ineffective and inefficient, the industry still relies overwhelmingly on static documents housed in Excel/Word and relies on manual processes that add significant risk to the development process.

Axendia conducted a research study focusing on the medical device industry’s approach to requirements management with a goal to identify and analyze the drivers, barriers, trends, and value of requirements management across the product development lifecycle.

9 out of 10 (87%) Executives surveyed for this report admitted to having a ‘not effective or somewhat effective’ requirements management process.

In a recent webinar, Axendia’s Senior Industry Analyst, Sandra K. Rodriguez and Jama Software’s medical and life science principal solutions lead, Steven Meadows, shared the outcomes of the research including:

  • The impact of having an ineffective requirements management process
  • The critical importance of requirements management to achieve improved patient outcomes, product quality, and time to market
  • The negative impact on budgets, verification and validation activities when relying on manual processes

Watch the full webinar to learn more about The Costly Impact of Ineffective Requirements Management in the Medical Device Industry.

 

Excerpt from webinar:

Requirements Management in the Medical Device Industry

Sandra Rodriguez: Thank you for that introduction, Marie, and good morning, good afternoon, or good evening, depending on where you’re joining us from today. Really quickly about Axendia, we were founded in 2005. Our headquarters are in Philadelphia, Pennsylvania. I’m physically located in San Juan Puerto, Rico, it’s a balmy 84 degrees today. What’s unique about Axendia is that our analysts all have industry experience. And combined, we average about 25 years of experience. We work with startup companies as well as fortune 500 global clients. And we really focus on the intersection of the business regulatory and technology trends that impact the industry. So really looking forward to sharing the outcomes of our latest market research on the state of requirements management in the medical device industry.

Just really quickly too, for the folks of you on the webinar today, congratulations, you will be the first to receive a copy of the research report. I’m not going to cover the report in its entirety today because we don’t want to take away the thunder of it, but we do hope that you will find today’s information valuable and timely and that you get some great takeaways from the report. Before I go into that, though, just a quick acknowledgment that the content of today has been sourced from our quantitative and qualitative research, as well as our interaction with FDA’s officials and industry executives, and then some firsthand experiences from our clients as well.

All right, so let’s start with the demographics. We surveyed a multitude of companies from around the world, companies that perhaps make more than one type of medical device product, but here you can see that the majority do market and sell single-use disposable consumable devices followed by diagnostic devices that have both hardware and software components and software as a medical device.

So those were the top three. As a result of that, we wanted to look at the data in a little bit more kind of slice it and dice it. So we specifically picked out software as a medical device, and you’ll see in the report, and as well as in the presentation today, how the opinions vary based on the type of medical device company that we surveyed for this report.

In addition, we got a good mix of small companies and large companies. The majority of the companies that did respond to the survey were under 50 million. So they could be startups, they could be a little bit pre-market followed by the $1 billion to $5 billion size companies when it comes to their revenue. So another thing that we did was we went ahead and compared these survey responses based on those two different size companies. We also got a significant number of R&D and product development personnel to take the survey, which is important.

These are what I call the boots on the ground, the companies that really understand requirements management inside and out. They’re the ones who are working on the new products as well as quality assurance personnel. And then we had a 17% representation of executive management. So another thing that you’ll see in the report is that we went back to the data and did do some comparison and filtering based on these three personas. And we were really surprised to see how the attitude shifted.

RELATED READING: 2022 Predictions for Medical Device Development

Sandra Rodriguez: From a geographic standpoint, we had a really good representation. Overall, the majority of survey respondents do work for companies that sell in market products in North America, so Canada, the United States, and Mexico followed by Europe and all the EU member states. And then, of course, Asia, South America, Africa, and Australia. So again, a really great representation of the medical device industry.

So this was our first question. And following the demographics, I think it’s really important to point out that this was the first question that it came when it came to requirements management processes. We wanted to understand from the market standpoint if people felt that their organization’s requirement management process was either effective or I’m sorry, not effective, somewhat effective, very effective or ideal. We were really surprised that when you combine not effective and somewhat effective, straight out the gate, we have a 68% of the market saying that there is a lot of room for improvement here. This is what I call aiming for average. And it’s definitely time for this to change because the complexity of the devices is changing. The regulatory landscape is changing. We have a lot more software as a medical device coming out there into the marketplace. And there’s a lot of hardware and software components that are going into these products, whether you’re doing remote monitoring of the products once they’re out in the field or in the patient.

So because of the complexity alone, you really need to have… You would want to see the very effective and ideal numbers go up because when we combine them, we’re only at 31%. And what’s really shocking is that only 2% of those companies that we surveyed for this research project believe that they have an ideal process. So we wanted to take a look at those numbers from the different personas. The quality personnel were of a little bit more positive. They believe that their requirements management process is very effective or ideal. So they account for about 53% of that. But when you look at the executive management, to have 87%, so almost 9 out of 10 executives indicating that their organization’s requirement process is not effective or only somewhat effective, that’s pretty shocking. Keep in mind that these are the folks that own the budgets.

So if you know that there’s a problem, we really need to do something to incentivize these folks to make the necessary change and get to that very effective or ideal state, even on the R&D and product development side, the same holds true with 68% of those professionals saying that their organization’s process is somewhat effective or not effective.

So we also asked the closed-loop system question. And we define a closed-loop system as one in which the desired output depends on the input signal and the feedback elements that are going to enable end-to-end traceability. So when you’re looking at a typical product development cycle, you have the finished product here in the middle. So you’re going from concept to prototype. Clinical, if you need to have a clinical trial for the type of medical device that you’re looking to bring to the market, going into manufacturing, marketing, commercial, and then obsolescence.

RELATED READING: Axendia Report: The Costly Impact of Ineffective Requirements Management

Sandra Rodriguez: So having that continuous feedback loop, really closing loop around that system, and having the necessary traceability that’s going to be required from a quality and from a regulatory standpoint. So we ask them, how effective is your organization at closing the loop across the product development cycle. Now, mind you, this was question number two. And we see here that 68% of the market, again, admitted that that process is not effective or only somewhat effective.

So again, really need to make the necessary changes there, and probably invest in the solutions so that you can close the gap and get that traceability and close the loop across the product life cycle. It’s interesting as an analyst because we don’t sell or implement software, but we stay really close to the market. And we follow these trends and we see significant investment in the life sciences when it comes to digital transformation or investing in business systems.

But it’s important to point out that without a product you wouldn’t be in business. So the solutions and the systems, the tools that you have in place when it comes to your product should be as important as the systems and tools that you give your salespeople, or your ERP, or however, you’re investing in those systems. You really need to make the necessary investments in order to make sure that your product is of the highest quality and that you can get to market sooner and on time and on budget because we’re going to learn in this presentation that the industry is really struggling with that.

Watch the full webinar to learn more about The Costly Impact of Ineffective Requirements Management in the Medical Device Industry.

READ MORE


Five Key Design Control Practices that Improve Compliance and Help Develop Better Products

Design Controls have been an FDA Quality System Regulation since 1997. Having worked on developing products in the regulated medical device industry for over 35 years, I have compiled a list of the five key takeaways for implementing design controls and achieving success in commercializing medical devices:

  1. Design Controls not only help achieve regulatory compliance, they help develop better products
  2. Design Inputs lay the foundation for product development, building a good foundation
  3. Don’t underestimate the power of Bidirectional Traceability
  4. Know the difference between Verification and Validation
  5. Risk Management is a vital part of Design Controls

#1 – Design Controls not only help achieve regulatory compliance, they help develop better products

Many companies think that design controls are a burden to development organizations imposed by the FDA, and it’s the price to pay for playing in the medical device field. However, what is often overlooked is that design controls only define the basic minimum requirements necessary to develop a product that can…

  • …meet the needs of the user.
  • …be designed to be safe and effective.
  • …be reliably manufactured.
  • …be verified and validated.
  • …maintained and updated throughout the product lifecycle.

These are all things that any development organization should do to successfully deliver products to market. I like to say that if you are doing the right things in product development, compliance comes for free!

#2 Design Inputs lay the foundation for product development, building a good foundation

The FDA defines design inputs as the physical and performance requirements of a device

that are used as a basis for device design. To generate adequate design inputs, the foundation upon which product development is built, the user needs must first be well understood. These needs, ideally written with the voice of the user, must then be translated into design requirements. In contrast to the user needs, these design requirements should be written using the voice of the engineer, and as such should be measurable and testable. Furthermore, design requirements should be traceable to a specific user need, risk control, or standard that necessitates the existence of said design requirement.

Research has shown that, on average, companies that are successful at developing products spend about 25% of the product development time on the generation of user needs and the subsequent design requirements. The return on this investment of time and resources reduces the need for rework and redesign, and ultimately leads to higher customer satisfaction. Failing to make the investment ensures that design inputs are complete and correct is analogous to building a house on quicksand, where the flaws in the foundation can cause issues throughout the construction and subsequent (likely short) lifetime of the house. Issues with requirements will impact development, verification, validation, and user acceptance of the product, so spending the time to get requirements right will be well worth the effort.

RELATED: Three Ways to Proactively (vs Reactively) Incorporate Design Controls in Medical Device Product Development

#3 Don’t underestimate the power of Bidirectional Traceability

In an audit, the trace matrix should be valued as a friend! Having and maintaining bi-directional traceability throughout the product lifecycle provides a number of benefits:

  • Effecting project tracking
  • Thorough change impact analysis
  • Ease of making future changes
  • Re-use of elements of the design
  • More effective issue resolution

To derive these benefits, the relationship between the following entities should be established:

  1. User Needs and Design Requirements
  2. User Needs and Validation
  3. Design Requirements and lower-level requirements
  4. Design Requirements and Verification
  5. Lower-level requirements and verification
  6. Lower-level requirements and Design Outputs
  7. Risk Controls and Design Requirements

In creating a trace matrix that has views to show all the bi-directional relationships of each of the elements described above can help answer most questions from an auditor.  With this level of traceability, I can trace from a user need all the way through implementation and test.

#4 Know the difference between Verification and Validation

The terms “Verification” and “Validation” often get combined and abbreviated to V&V; however, these activities are vastly different.

Verification is confirmation by examination and provision of objective evidence that specified requirements have been fulfilled. It is design-centric and answers the question “Did I build the product right?” Verification also entails gathering objective evidence that the design behaves as intended through the use of observation (visual inspection), measurement (values and tolerances), testing (function) or analysis (reviews).

Validation is confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use can be consistently fulfilled. Unlike Verification, this is a user-centric term, and answers the questions “Did I build the right product?” and “For whom is this the right product?” Validation entails gathering objective evidence that the design satisfies the user needs through the use of Usability Studies/Human Factors Studies, Clinical Evaluation/Clinical Studies, Customer Surveys, and through Analysis of Verification Data.

Knowing the difference between Verification and Validation is of quintessential importance for ensuring customer satisfaction and regulatory acceptance of the product.

#5 Risk Management is a vital part of Design Controls

The elements of design controls are Planning, Design Inputs, Design Outputs, Design Reviews, Design Verification, Design Validation, Design Changes and the Design History File. So, what happened to Risk Management? Risk is mentioned in Design Control Regulation (QSR 820.30) all of one time, under Design Validation. The statement simply reads “Design validation shall include software validation and risk analysis, where appropriate.”

Fortunately, the FDA Design Control Guidance elaborates on requirements for risk management. The guidance includes this paragraph:

Risk management begins with the development of the design input requirements. As the design evolves, new risks may become evident. To systematically identify and, when necessary, reduce these risks, the risk management process is integrated into the design

process. In this way, unacceptable risks can be identified and managed earlier in the

design process when changes are easier to make and less costly.

The takeaway from this is that although risk management is just cursively mentioned in the QSR Design Control regulation, the intent of the regulation is that Risk Management be practiced starting from the point where design inputs are known and practiced throughout the product life cycle.  You cannot be compliant to the design control regulation without having an adequate risk management file.

Conclusion:

Design Control regulations have been around since 1997, but many manufacturers still have problems complying with design controls. Focusing on the best practices outlined above will derive the most benefit from implementing Design Controls, will lead to a more predictable development cycle, and ultimately result in higher-quality products that can be enhanced and maintained throughout their lifecycle.


What is Requirements Engineering? An Overview and Intro into Requirements Engineering

Requirements management (RM) is a challenge for many companies, partly due to the ambiguity involved in software development. First, you must understand the client’s requirements. Second, you must match those requirements to critical processes.

RM is a component of requirements engineering (RE), which bridges the divide between a client’s needs and what developers create. When done well, RE has the ability to create a solid framework for software development, which is critical since poor software engineering requirements management is a root of many project failures.

A CIO magazine study found that “Analysts report that as many as 71% of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure.”

In 1999, NASA built the $125 million Mars Climate Orbiter probe. The probe failed because it entered orbit 100 kilometers too close to Mars. The source of the error was incompatible specifications; an important component of RE.

Understanding the details involved in requirements engineering and best practices can set you on the path to successfully meeting client expectations.

What is requirements engineering?

Clients have a long list of goals when creating new software, and RE provides a framework for meeting those goals. Important needs are inventoried and transformed into a detailed set of requirements. Requirements development dictates future development activities and creates a blueprint for success.

The terms requirements management and requirements engineering are often used interchangeably, but they are different. RM is one piece of requirements engineering, and getting it right makes all the difference.

RE ensures that the problem a client wants solved is clearly defined and the solution is both accurate and effective. Essentially, RE transforms a real-world problem into a highly functional software solution.

RELATED POST: Requirements Management Tools and Software

The 4 steps of the requirements engineering process

The requirements engineering process has many potential pitfalls. Strengthening your RE process enables you to avoid many common challenges. The process serves as a compass, guiding you in determining the exact deliverables and doing so with greater accuracy. All important parties are on the same page about what steps need to be taken to achieve the desired outcome. Strengthen your RE process by considering the following:

Elicit requirements. Elicitation is about becoming familiar with all the important details involved with the project. The customer will provide details about their needs and furnish critical background information. You will study those details and also become familiar with similar types of software solutions. This step provides important context for development.

Requirements specification. During the specification phase, you gather functional and nonfunctional project requirements. A variety of tools are used during this stage, including data flow diagrams, to add more clarity to the project goals.

Requirements verification and validation. Verification ensures the software is implementing the right functions. In contrast, validation ensures the software is built to the customer’s requirements. If the requirements don’t go through the validation stage, there is the potential for time-consuming and expensive reworks.

Requirements management. During RM, you’re matching all the relevant processes to their requirements. You will analyze, document and prioritize the requirements – and communicate with relevant stakeholders. Any requirements that need modification are handled in an efficient and systematic manner.

As you implement the different components of RE, it also helps you get a sense of what should be excluded from requirements. Understanding this will help you focus more accurately on developing requirements and better meeting client expectations.

What information should be excluded from the requirements?

Requirements should be viewed as addressing a problem, but not necessarily as providing a solution. A requirement should clearly state what you want to solve, not how you want to solve it. Let’s take a look at guidelines for good requirements:

  • The requirement accurately defines the need of the stakeholder.
  • The requirement is testable.

A requirement needs to be clear and understandable, without the risk of ambiguity. An important step in developing good requirements is the review process. Does the requirement accurately express the needs of the stakeholders? Make sure to build in enough client reviews so that you can get early feedback and adjust as needed.

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

Common mistakes to avoid

There are many challenges that may occur as you develop your RE framework. Understanding potential issues can help you avoid them. Consider the following as you develop your processes:

  • Avoid scope creep. There is a temptation to add “just one tiny new requirement” to make the client happy. But these little changes add up and may have an impact on future activities, such as testing, documentation and more.
  • Resist the urge to “over-engineer.” Over-engineering can be tempting, especially when you want to make sure everything is just right for the client. But this overzealousness can backfire. Adding a little extra code because “I’m doing this, I may as well do that” might seem logical, these changes can create a ripple effect, putting requirements at risk in the future.
  • Build in enough feedback and reviews. Early feedback is essential to a project’s success. Build in frequent reviews and solid traceability to get feedback often and early.
  • Search for all the important stakeholders. You might think you’ve included all the important stakeholders, only to learn you missed one later on. Invest time early in the process to find any and all important stakeholders in order to avoid expensive reworks later in the process.
  • Identify potential resistance early in the process. Resistance can be an invisible but serious project problem. Learn to identify resistance early in the process so that you can work through it efficiently and early, getting everyone on the same page.

Awareness about these potential pitfalls can save you time, money and resources during the RE process. Also, look at your existing processes and whether they include enough traceability. Ensuring that deliverables meet requirements, for example, is much easier if every requirement is linked to at least one test. And traceability is an essential part of this process.

Engineers can then invest their energy into requirements that are failing the test and get the project back on track quickly.

Leveraging the right tools for success

Requirements engineering is critical to the success of a project because it tells everyone involved with the project what needs to be done. A project manager, who schedules tasks, can do so based on more accurate requirements. A requirements management software tool can greatly support successful RE, as it enables more efficient and optimized product and system development.

This type of tool can provide:

  • Clarity and visibility. Get broader visibility into what you’re building and why.
  • Live traceability. Ensure product quality and improve change management with complete traceability.
  • Decision tracking and fast reviews. Conduct virtual reviews of requirements, test cases, user needs and more.
  • Real-time collaboration. Immediately note and prioritize important decisions, pull in the required stakeholders and reference historical context to eliminate communication errors.

The right tool can help you transform RM as you easily track, review, sign off on and truly understand how and why you did certain things. As a result, you can streamline your product development process and increase efficiency, understand and respond to change, and establish a higher level of clarity and visibility.

See how Jama Connect can help with requirements engineering by downloading our solution overview.


Software as a Medical Device (SaMD): Four Key Development Best Practices

This post on Software as a Medical Device (SaMD) development is written by Mercedes Massana, the Principal Consultant of MDM Engineering Consultants. 

SaMD software is software intended to be used for one or more medical purposes that do not require embedding in a medical device. These purposes can range anywhere from helping to diagnose or treat disease, helping in the clinical management of a disease, or providing information to help with the clinical management of a disease. SaMD differs from other medical device software in that it will operate on different platforms and will interconnect with other devices, carrying with it an increased cybersecurity risk and a commensurate increase in the use of off-the-shelf software. 

On the surface it may appear that the development of SaMD software is no more difficult than the development of Medical Device embedded software, but appearances can be deceiving, and the development of SaMD products can be quite challenging. In order to deal with these challenges, there are four key best practices that should be followed for SaMD software development.  

These practices are:  

  1. Make use of standards and guidance documents  
  2. Apply the right level of rigor 
  3. Understand the difference between Verification and Validation  
  4. Implement a post-market monitoring program

Best Practice #1– Making Use of Standards and Guidance Documents 

Although standards development organizations and regulatory bodies have only started to scratch the surface in the creation of standards and guidance documents to help SaMD development organizations, there is a sufficiently detailed body of work available to help development organizations succeed. The most relevant of these are the documents generated by the International Medical Device Regulators Forum (IMDRF) related to SaMD and IEC 82304 Safety and Security of Health Software Products. The IEC standard points to other well-known standards, such as IEC 62304 Software Development Lifecycle, IEC 62336 Usability Engineering and ISO 14971. Additionally, several FDA guidance documents are available that apply to all medical device software and are useful for the development of SaMD, these include General Principles of Software Validation, Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, Off-The-Shelf Software Use in Medical Devices and the FDA pre and post market cybersecurity guidance, as well as other guidance documents 

Best Practice #2 –Applying the Right Level of Rigor  

Within the development of SaMD, a clear understanding of the scope and intended use of the product is necessary, and to that end, it is necessary to have a method to gauge the risks associated with SaMD use. The IMDRF “Software as a Medical Device” Possible Framework for Risk Categorization and Corresponding Considerations, IEC 62304 , and FDA Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices all provide a method for risk based classification of SaMD. The rigor applied to the development of SaMD should be commensurate with the level of risk. IEC 62304 uses the Safety Classification to define the level of rigor of activities to be performed in the software lifecycle based on the level of risk. Ideally, the development process is sufficiently flexible to avoid the over-engineering or under-engineering of the SaMD in question. A development process that is adaptable requires organizational maturity and experience, in order to perform the right set of activities and understand the value provided by those activities.

RELATED: Regulatory Shift for Machine Learning in Software as a Medical Device (SaMD)

Best Practice #3 – Understanding the Differences Between Verification and Validation  

SaMD is a medical product, a system in and of itself. Therefore, SaMD system requirements must be verified to have been implemented correctly, and  SaMD user’s needs must be validated to ensure that the product satisfies the user’s need and that the right product was built for the customer. Validation typically includes human factors testing, clinical evaluation to determine the efficacy of the software for its intended use, and a demonstration that risk controls are effective. This requires more than just your standard set of software testing, which typically consists of code reviews, unit testing, static analysis, integration testing and requirements-based testing. 

Best Practice #4 – You Are Not Done When the Software is Released  

Your SaMD software has successfully completed verification and validation, has been cleared by regulatory agencies, and is now ready to go live. Time to breathe a sigh of relief and congratulate the team for a job well done. Pop the champagne and throw a party, you have all earned it. Enjoy the festivities, but afterwards turn your attention promptly to monitoring the performance of the SaMD post launch. Rigorous and exhaustive as your testing was, you can never anticipate every possibility. Be ready to respond to identified software defects and emerging cyber threats and deploy patches or software fixes as issues are identified.  The nature of cybersecurity risks is ever-changing, and no system, regardless of how well-designed, or rigorously-tested, is free of software defects. Additionally, customer input can provide opportunities for enhancements and improvement.  However, be aware that proposed changes can impact the intended use of the device, the classification of the SaMD, and can ultimately result in additional regulatory submissions. It is paramount that prospective SaMD developers evaluate changes thoroughly and plan actions related to these changes to avoid surprises that can delay, or outright derail, SaMD implementation. 

In summary, SaMD can provide great benefits to the user; however, to successfully launch SaMD that meets the user’s needs, several best practices should be utilized in their development. These best practices, making use of standards and guidance documents, applying the appropriate level of rigor in the development of SaMD, understanding the difference between Verification and Validation, managing change appropriately, and implementing a good post-market monitoring program.  These best practices are indispensable in ensuring a safe and effective SaMD product. 


Requirements Verification and Validation for Product Teams

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