One of the most common problems seen today with validation studies is the lack of proper URS or specification documents detailing exactly what is required from a system/equipment/process.
Without proper planning of what is required it is very hard to have a successfully validation when no one really knows what actually needs to be tested…….without proper specifications forget about adopting a risk based approach!
If you don’t have the time to go back and write a URS from scratch retrospectively one of the most common methods to generate a robust specification would be using the vendor supplied user manual (you should have one of them at least)
Vendor User Manual
If you have a vendor-supplied User Manual for your system, you can quickly modify it to serve as both a reasonable Business Requirement document and a Functional/Design Specification. Generally, at the front of any chapter covering a specific function, there is an overview section. The overviews maybe called something else, or they might not be titled at all, but they are almost always there as an introduction to the rest of the Requirements. Next to each of these overviews, have your System Owner bracket that which applies, then single-line out, initial and date those statements or sections which are not applicable for your implementation. Next to the bracketed portions, the System Owner should write in, “Business Requirements #x.yz, where “x.yz” is the sequential number of this requirement. Once the System Owner had written this in, he/she should initial and date the entry, (and in fact, all entries/changes to the book).
Following the overview in each chapter is information on functional operation of the system. The screen prints here are the Design, and the description of their operation is the Functional Specification. Together, they comprise a decent Functional/Design Specification.
Usually, the fields and their functionality are discussed in this section as well. Quite often, other important design information such as Table/File structures, names, descriptions, and a Listing of Error and Warning messages is also included somewhere in these manuals.
Business and Design Specifications
Follow these steps to customise and formalise these manuals to serve as Business Requirements and Functional/Design Specifications for your implementation:
A. You need a dedicated set (or copy) of the manuals to use as a formal document.
B. You need to mark up each manual showing:
- What features are used in your implementation and what aren’t used.
- What is considered Business Requirements and what is considered Functional/Design Specifications.
C. Wherever your System Owner puts an ink mark, they must initial and date: They need to put a signature, initials and print their name and title just inside the front cover of the manuals, to show who is making these decisions.
D. There must be a formal review and approval of the finished document by the validation team. Have the team sign-off on a formal coversheet that will be permanently attached to the book. Include on the coversheet an introduction and background. The introduction should state that in lieu of generating business requirements and functional design specs for this legacy system from scratch, the decision was made to find a reasonable substitute. The user’s guide offered both business requirements and functional/design specifications. In the background section, detail how you became aware that updated specs were needed, usually via internal/external audit. This helps show an auditor that you are monitoring your own system compliance, and taking corrective actions when issues are identified.
E. After Review and Approval, keep this formal life cycle deliverable with all the other original validation documentation.
