Tag Archives: URS

Specifications: How to Write Them

GAMP V Model

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!


WHO’s Draft Guidelines on Validation May 2016

Hello good people of the world! On May 15, 2016, the World Health Organization released its draft Guidelines on Validation. It is available on the WHO website for download here.

This post covers my review of the guidance. Continue reading WHO’s Draft Guidelines on Validation May 2016

Staying in Control: Alerts and Alarms


Hello good people of the world! If you work with a mix of process equipment and supervisory control or monitoring systems, you know the importance of alerts and alarms, but most companies do not take the necessary steps to ensure their alerts and alarms are well configured and meaningful. One of the enemies is so-called “nuisance-alarms,” but just as important is knowing that you have enough alerting/alarming so that critical events are not missed and appropriate actions are taken before harm is done.

And by the  way, alerts and alarms are something the FDA has historically shown to care about (e.g.  FDA had observation at Teva Irvine for lack of validation on alerts and alarms). So what considerations are at play?

What should alert/alarm? If you’ve clearly defined your Critical Process Parameters (CPPs) and know what your Critical Quality Attributes (CQAs) are, you know already what needs alerts/alarms: all CPPs.

What should the alert/alarm limits be? This part is tricky: you need limits that provide operators with sufficient information without becoming a nuisance. All too often I see the situation where alarm banners are flashing but no one is paying attention because “there’s always alarms” or whatever.

What action should occur based on alert/alarm conditions? This is another place I often see improvements needed: every alert and alarm should have a documented action associated with it, typically in the SOP, that operators are trained on. If there is no documented action required for an alert/alarm, why do you have it?

What do you find critical in configuring alerts/alarms and introducing them into a manufacturing process?

Like this MWV (Mike Williamson Validation) post? Be sure to like, share, and subscribe!