The development of a product requirements

document. This is a statement of need. Why is the product being developed, what markets are being served, gross functionality, target hardware platforms, constraints imposed by external factors, and how it relates to other products/system. The support requirements should also be detailed: who is going to support it, plans for upgrades, how will they be phased in, and how many versions will be supported.

New Computer System Existing Computer System

New Computer System Existing Computer System

Figure 12.4

Computerized systems life-cycle diagram developed by PMA [8], showing the stages in the development and validation of new and existing computerized systems

Figure 12.4

Computerized systems life-cycle diagram developed by PMA [8], showing the stages in the development and validation of new and existing computerized systems

• Based on the requirements, a functional specification is produced. The purpose of this document is to provide in detail, what the product is going to do, how it will work, what capabilities will exist in the initial release, what capabilities will be planned for future versions, and what documentation will be created to support the product (in large systems this should require a separate documentation plan).

• In response to the functional specification, two documents are produced. One is the engineering design specification. This is how the functions described above will be implemented, specifying tools to be used, operating systems required, hardware required, algorithms used, constraints. The second is the test plan. The test plan is an independent document, preferably drafted by someone other than the development engineers, that describes the testing procedures to be used, how each module will be examined, how code reviews will be conducted, and the procedures for documenting bugs, resolving issues and determining the criteria to be met in order for the software to be deemed ready for release into production.

• A project plan provides the management details of the project including the provisional schedule (to be refined and updated as the project progress), the people required to do the work, trade-offs between people and schedule, and any contingencies for problems that may be encountered (at as far as they can be foreseen). It should also include the requirements for acceptance testing and completing validation if it is an in-house project or identification of internal testers of the completed product, beta-testers, and the process used to determine when and how each stage of product development is to be reviewed before moving on to the next.

All of these stages are part of the validation plan for in-house projects. When evaluating commercial software, these are the items that should be considered for review during a vendor audit. In the latter case, special arrangements and legal documents may be required; vendors are not likely to expose their inner-most secrets without very good cause and protection. The engineering process may vary from site to site and company to company, but they should have a process and follow it which is part of the ISO 9000 program.

An FDA report [3] notes two types of tests that can be used in evaluating software: functional (black box) and structural (white box). Functional testing treats software as a module and examines the inputs and outputs to determine if it is working properly. Structural testing is a detailed evaluation the source code, examining the logic and flow of control. Every path is examined. Among the points to be evaluated are the quality of the code, its internal documentation, correctness of algorithm implementation, and, looking for dead code (code that is never executed).

This brings us to an interesting point: source code. The FDA requires that users of software systems have the source code available to them for all applications software. Note that at this time, this does not include commercial software in wide-spread use. However, any code that acquires, manipulates, or manages laboratory data should be available for examination. The point of this is to give the users a means of demonstrating that something in the code is not biasing or altering data without it being a conscious decision and part of a Standard Operating Procedure for which they are accountable. Vendors of laboratory software are aware of this requirement, and may either sell a source code license, or, put the source code in an escrow account, giving the right of access under a given set of conditions. The details of these agreements need to be worked out between you and the vendor. Certainly any code that you develop or that is developed for you under contract should have this requirement as part of your engineering practices.

There are tools available to assist developers in maintaining software: code management systems. These are useful since they keep track of current versions of modules as well as the components that went into earlier versions of the software. The use of these systems helps provide a "developer's audit trail" of programming changes and ensure that the product is built from only the appropriate files.

12.6 Vendors and Regulatory Compliance

The marketing potential of the word "validation" has not been lost on laboratory systems vendors. The use of "GLP certified" labels is declining as vendors are realizing that the term is meaningless; they can test components, but since validation requires a context (a user-defined need with product requirements) they can not be "pre-validated".

What a vendor can do is significant. They can show that products are well designed, well tested, provide product performance information, and show where they are applicable. They can also train users in product use, provide SOPs for maintenance and maintenance schedules, describe normal operating procedures, provide qualification tests to show that a product is operating as designed (Installation Qualification, Operational Qualification, and Performance Qualification).

Systems that require customization and upgrades, particularly Laboratory Information Management Systems (LIMS) can benefit from the services provided by some vendors. In addition to the points in the previous paragraph, some vendors provide validation test suites. They range from a simple set of instructions of what a person should do in front of a screen to test managers that can do some testing automatically.

One vendor has a program that, during the initial testing phases of a system, "learns" the keystrokes needed to carryout a function and records the results. Repeated testing of that function can be automated by having the computer execute the function and compare the response to what is expected. Deviations are noted and provide a flag to the tester to check that point in more detail. When looking at hundreds of functions and keystrokes, this is a significant benefit. Automated audit trails, software control of revisions to systems, and automated security also provide assistance in meeting regulatory requirements.

Some vendors provide a very useful service to their customers through on-line bulletin boards. These systems allow vendors to provide up-to-date information about systems, software, and an opportunity for users to exchange information about products (including problems). Services like this can be an important part of programs to maintain software.

Was this article helpful?

0 0

Post a comment