Managing requirements, software item specifications, and Verification and Validation (V&V) tests is a critical aspect of software development in the medical device industry. Compliance with regulatory standards and producing a comprehensive requirements traceability matrix (RTM) is one of the largest hurdles that a company may face when developing their medical device. Ketryx is a software platform designed for regulated medical devices, simplifying, and streamlining the development and post market processes.

The V Model

To understand how to develop configuration items that may show up in your RTM, it’s important to first understand the V model.

The V model is a framework that outlines the intersecting paths of development and validation. For each development activity, there is a corresponding validation activity. As we define our requirements, there are, or will be, accompanying validation test cases and executions. Similarly, as we define our software item specifications, there are, or will be, accompanying verification test cases and executions.

The V model maps to the different configuration items that are defined in the Ketryx Platform.

When we break down the V model into its simplest form, we are left with two questions that need to be answered. What? and How?

When planning your product, a requirement provides the answer to the question “What does it do?” and a specification provides the answer to the question “How does it do it?”

Once we know the answers to those questions, we develop the product to meet the “what” and “how”.

Finally, we perform verification and validation to ensure that we are able to provide proof that the product meets the “what” and “how”.

Defining Requirements and Specifications:

The easiest starting point is defining your user needs and intended use. 21 CFR 820.30g states: 

"Design validation shall ensure that devices conform to defined user needs and intended uses..."

Additionally, IEC 62304 states:
"The manufacturer shall document the intended use of the particular medical device being considered. The intended use should take into account information such as the intended medical indication, patient population, part of the body or type of tissue interacted with, user profile, use environment, and operating principle".

User needs, use cases, and intended uses, at the highest level, are configuration items of type requirement that describe how users interact with a medical device to achieve a particular goal, what the end users expect in the final product, and identify what the users want or require from the product or system. 

For your user needs, it may be helpful to break down the requirement further in to “child requirements”. Child requirements are specific, detailed requirements that are derived from a higher-level or parent requirement. These requirements help to break down a general user need or intended use into more detailed, actionable requirements that can be designed, implemented, and tested.  

Software item specifications aka “the how” fulfill requirements. They do so by providing detailed descriptions of the functionality, behavior and characteristics that are necessary to meet the stated requirements. They act as a bridge between the high-level requirements and the actual implementation of the software.

When requirements are defined, they describe what the product needs to do, but they do not describe how the product needs to do it. Software item specification take these requirements and translate them into detailed technical descriptions that can be used by developers to design and build the software. They should have enough detail such that the developer has a vision of what the final product should look like and how it should act.

Both requirements and specification should be developed with verification and validation in mind. They provide a basis for verification and validation activities.

• Ensure that both requirements and specifications are written in clear, unambiguous language. Each requirement and spec should be precise and specific, avoiding vague terms that could lead to multiple interpretations.
• Make sure that each requirement and specification is testable. This means that it should be possible to design a test case that can objectively determine whether the software meets the requirement or specification.
• If possible, break down complex requirements and specifications into further, into smaller, more manageable components. Ketryx allows the user to define children of children. The traceability tree can go as deep or shallow as you make it. This modular approach makes it easier to develop focused test cases for each component and simplifies the V&V process.
• Incorporate acceptance criteria as part of the requirement and specifications. Specific wording like “shall” or “should” can be used to define the conditions under which a requirement is considered satisfied. This provides a clear basis for creating test cases and evaluating test results.

Consider risk in the development of both software item specifications and requirements. Ketryx allows the user to perform risk management at any stage of the planning, development, and post market release process. While thinking of requirements and specs, you should also try to identify potential risks associated with them. At some stage during the planning phase, you should perform some method of risk identification such as a failure mode and effects analysis (FMEA) or fault tree analysis (FTA).

Defining Verification and Validation Tests

When considering verification and validation during the development of requirements and specifications, it's crucial to ensure that test cases directly relate to the predetermined acceptance criteria. A trained quality tester should follow clearly defined steps, which should be written in clear, unambiguous language. One aspect that is often overlooked during the creation of test cases is the tendency to focus solely on the "happy path," where everything works as expected. It's important to also consider foreseeable misuse, which should be defined during the risk management process.

Additionally, tests should not only assess whether a requirement or specification is met under normal conditions but also explore the limits of what is being tested. This includes scenarios where the user goes beyond the specified limits to understand how the system behaves under stress or in unexpected situations. By including these considerations in the test cases, you can ensure a more comprehensive validation of the software, leading to a more robust and reliable product.

In summary, when developing requirements and specifications with verification and validation in mind, it's essential to:

1. Relate test cases to predetermined acceptance criteria.
2. Provide clear, unambiguous instructions for quality testers.
3. Include tests for both the "happy path" and foreseeable misuse.
4. Explore the limits of the requirements and specifications in the tests.
5. Consider scenarios where the user goes beyond the specified limits.

By following these guidelines, you can enhance the effectiveness of your testing process and ensure that your software meets the necessary quality and safety standards.

For more information on this topic, you can refer to resources such as the International Electrotechnical Commission's standard IEC 62304 on medical device software lifecycle processes, which provides guidelines for software development and testing in the context of medical devices.

How the V model maps to your requirement traceability matrix:

In the default Requirements Traceability Matrix (RTM), you may encounter five columns. At Ketryx, we have simplified the "Intended Use" and "User Needs" into a single category called "Use Cases." Furthermore, the child requirements that emerge from the "Intended Use" and "User Needs" are categorized as "Design Inputs." These requirements are further elaborated in "Software Item Specifications," which are referred to as "Design Outputs." Tests are classified into verification and validation depending on the type of configuration item they are assessing. A verification test must be explicitly linked to a corresponding specification (Design Output), while a validation test must be directly tied to a corresponding requirement (Design Input). Refer to the diagram below to understand the relationships between these elements.