Hello good people of the world! Today’s post is about the left side of GAMP’s V-model: specifications. Specifically, their purpose and how to write them.
Of course there are many variations of the V-model, and it is best to find what suits your organization and processes. For the purposes of this discussion, I’ll refer to the basic GAMP V-model, pictured above.
The specifications are: User Requirements Specification, Functional Specification, and Design Specification. In general each feeds in to the next. Also, Installation Qualification may test the details of the Design Specification, Operational Qualification may test the functional descriptions in the Functional Specification, and Performance Qualification may test the high-level requirement’s of the User Requirements Specification, although these boundaries are often blurred in practice.
Any new project should start with a User Requirements Specification which clearly defines the testable user requirements. It is important that requirements are testable, and often a SMART approach is applied: each user requirements should be Specific, Measurable, Achievable, Relevant, and Time-bound. It is also helpful to categorize user requirements upfront, since not all will be quality-related. This makes it easier to rationalize the requirements that are explicitly tested in qualification protocols versus commissioning or not at all. Typical categories include: business, safety, maintenance, and quality.
The Functional Specification is then a response to the User Requirements Specification, typically provided by the vendor, explaining in detail how automated components will function to fulfill the user requirements. Functional Specifications are often confused with Functional Requirements or Functional Requirements Specification, which may be another document defined by a process. GAMP’s V-model does not intend the Functional Specification to document new or further detail requirements, but to define the functionality employed to meet the requirements defined in the User Requirements Specification. The Functional Specification can describe sequence of operations, interlocks, alarms, etc.
The Design Specification should provide sufficient detail that an engineer could recreate the control system from scratch if need-be, to recreate the functionality described in the Functional Specification to meet the user requirements. The Design Specification is typically provided by the vendor and should contain such details as I/O list, alarm list, HMI security levels, sequence of operations details including device positions at each step and transition conditions. This should be a very detailed document, and if you’re working with 10-20 pages it is too light.
Documentation can be expensive and is maybe not fun to generate and review, but is critical to a highly effective validation program.
What do you like to see in specifications?
Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!
Mike Williamson Validation 