User Requirements Specifications–How Difficult Can It Be?

Q.  We are a well-established pharmaceutical company, and part of our procurement process requires us to prepare a ‘spec sheet’ (i.e., a document listing our requirements for either the service or the equipment we want to acquire). That has served its purpose well; however, we are finding it difficult to use when purchasing automated systems or software products. As we often have very little expertise or understanding of the software component, we struggle to write sensible specifications. We are tempted to simply accept the vendors’ system descriptions. Do you have any advice for us as to how we can overcome this challenge?

A. Your situation is not unusual, and the reason, as you already mentioned, often is a certain lack of expertise with software products. Whereas there is a lot of process and product expertise in companies, including processing equipment, the same cannot be said for automation. Let us first look at the parties/departments involved in preparing spec sheets for equipment. This will involve the operations group (e.g., manufacturing department, laboratories, utilities group), engineering, procurement, and the quality unit. When it comes to automated systems or pure software applications, the information technology (IT) department must be involved too. The IT terminology and the engineering and operations terminology are not necessarily the same or aligned, which can make communication more difficult, not only internally, but also with the suppliers. For example, what you refer to as a ‘spec sheet’ is a user requirements specification (URS) in computerized systems terms. The issue is further complicated as we as humans are used to being able to touch, smell, or hear equipment, none of which applies to software.

Can you simply adopt or accept the supplier’s description of the system or software, or do you need to prepare this yourself? The answer is that even if you were to accept the vendor’s description without any change, you still must confirm this in writing. In other words, the vendor’s description becomes your URS (aka spec sheet). With that, you also become responsible for the URS to be compliant with the applicable regulations.

In a few cases, you may be at the mercy of the supplier with regard to functionality and performance, but mostly you will have a choice. For example, if you are looking for software to support a quality management system, there are systems available that offer you everything you may wish for. But, you may only want to use certain functionalities (e.g., workflow) and specific modules (e.g., deviations and complaints management modules, but not the change management module). In this case, it would be wrong to merely copy/paste the full system description by the vendor into your URS; instead the URS has to be specific to your needs (i.e., requirements).

In computerized systems validation (CSV) terms, the URS forms the basis for user acceptance testing (also referred to as performance qualification). This is where it becomes essential that the URS is compliant with the regulations. To give an unacceptable example would be to write in the URS: ‘the screen refresh must be fast.’ This cannot be tested as it is a wholly ambiguous requirement. Another example would be to require ‘an easy-to-read screen.’ But how do you describe this in testable terms if you are not the software expert? This is where your IT team will have to support you and provide appropriate language. For example, they could suggest a refresh rate of 100 milliseconds or recommend a certain screen display quality that will meet your needs.

Despite its age, one of the best guidance documents for writing a URS is FDA’s General Principles of Software Validation; Final Guidance for Industryand FDA Staff from January 2002 (1). Other agency guidance documents and industry best practices are available online (e.g., European Directorate for the Quality of Medicines [EDQM] [2], the European Union [3], or GAMP [4], to name but a few). As the use of automated systems will surely increase in the future, it is sensible to build up relevant expertise in-house, so that in future you will be as comfortable writing spec sheets for a mechanical system as for a piece of software.

References

1. FDA,General Principles of Software Validation; Final Guidance for Industry and FDA Staff (CDRH, CBER, January 11, 2002).
2. EDQM, Revised: Validation of Computerised Systems Guideline. 
3. European Commission, EudraLex The Rules Governing Medicinal Products in the European Union Volume 4 Good Manufacturing Practice Medicinal Products for Human and Veterinary Use, Annex 11: Computerised Systems (EC, June 30, 2011).
4.  ISPE, GAMP 5 Guide: Compliant GxP Computerized Systems (ISPE, February 2008).

Article Details

Pharmaceutical Technology
Vol. 42, No. 11
November 2018
Page: 58

Citation

When referring to this article, please cite it as. S. Schmitt, "User Requirements Specifications–How Difficult Can It Be?," Pharmaceutical Technology 42 (11) November 2018.