Improving Computerized System Quality Through Design Verification

Unverified Design – An Example

For those of us who travel routinely, one of the most sought-after treasures in the typical airport terminal is an electrical outlet. With our dependency on mobile devices and technology, access to a continuous power supply while on the move is a necessity. This is all too often realized when you get that annoying message on your smartphone that your battery is critically low and you need to connect your charger … and all available outlets in your immediate vicinity are taken by fellow travelers.

Fortunately, some airlines are recognizing this growing need and providing multi-outlet charging stations for their flying customers. I was fortunate enough to locate an unoccupied charging station on a recent trip only to discover that it was inoperable. I checked behind the unit and found that it was unplugged, as the outlet could not accept a fourth plug due to outlet and cord configurations (see photo … yes my phone had enough battery left to snap a picture!):

This situation could have been avoided with a simple design/specification verification of outlets and plugs before deploying the units to the terminals. So what does this have to do with software quality/system validation? This example hardly impacts any pharmaceutical product quality or patient safety. The fact is, similar situations often arise when reviewing validation plans and auditing system life cycle documentation.

Impacts of Unverified Designs

While User Requirements and Functional/Design Specifications are usually included as formal deliverables in typical system validation approaches, allocating adequate project time to formally review requirement and design documentation is not a common practice. All too often projects move from a very cursory development of requirements and design directly into build and configuration activities.

Original project plans which have minimal time allotted to design verification result in expanded build and configuration time during project execution, which typically takes away from time originally scheduled for testing activities.  Heaven forbid that we should move an established implementation due date!   It has been repeatedly documented that the cost of correcting software defects increases with each passing phase of the development life cycle.

While documented cost estimates may vary for correcting software/system defects in early versus late phases of the life cycle (10-100 times) the fact remains that formalized design verifications can be an effective tool in improving software quality. In regulated environments this can translate into improved compliance, enhanced data integrity and ultimately patient safety.

Practical Design Verification

Formal design verifications should

1. Review individual requirements to ensure that they are clear, concise, consistent, and verifiable.
2. Identify initial traceability between individual requirements and documented functional/design specifications.
3. Evaluate and enhance any preliminary test and verification plans for suitable confirmation of intended system use, reliability, and regulatory compliance.
4. Provide an opportunity to update functional risks of the software/system and develop additional mitigation strategies.

While it might be natural to assume Design Verifications would be more applicable to custom software development, e.g., embedded software for medical devices, formal verification of requirements and design may be equally applicable to commercially available configurable software packages.  Many Commercial Off-The-Shelf (COTS) packages today, such as process control solutions and Enterprise Resource Management (ERP) systems are highly configurable to fit client manufacturing and business processes.  In such cases a Configuration Specification has as much influence over system functionality and performance as a detailed Design Specification for a custom software module.  The same attention should be provided in formally verifying the documented software configuration.

Within a standard life cycle approach, a formal Design Verification could be viewed as a toll gate or check point activity.  While logically placed at the end of the requirements/design phase, prior to build/configuration, the use of a formalized Design Verification doesn’t mean the design may not be re-visited during subsequent life cycle phases.  It also doesn’t eliminate the incorporation of iterative design/development processes within the system life cycle.  It’s intent is to ensure that we take a good look at documented requirements/design before moving into final build, configuration, and formal testing activities.

In a regulated pharmaceutical/biotechnology/medical device environment, our primary system validation goals focus on verifying suitability for use and protection of patient safety, product quality, and data integrity.  In addition to these aspects, formal Design Verification can also have added business benefit in helping to deliver a solution that is more supportive of the end user’s work process, and actually enhances rather than hinders their day to day activities.  Without proper attention to the relationship between requirements and design specifications, it is possible to deliver a system that functionally meets its intended use, but fails to meet end user operational demands.

So by verifying our system design and identifying possible system defects earlier in the life cycle we can:

1. Enhance overall system quality
2. Ensure system regulatory compliance
3. Improve system end user satisfaction
4. Deliver critical systems in a more cost effective manner

The bottom line is to engage validation and quality subject matter experts as early in the system life cycle as possible, not only to ensure system compliance, but also to enhance overall project quality practices and continuous improvement of the life cycle approach.