The importance of having a solid user requirements specification (URS) prior to engaging equipment vendors cannot be overstated. While validation processes are commonplace in the pharmaceutical industry, we have found that many managers responsible for the purchase of a new purified water system have difficulty writing a high-quality URS.

Too often, the specifications accompanying requests for quotes (RFQ) focus on specifying system components rather than the needs the system should address. While it may be desirable to select certain technologies before launching an RFQ process, it is critical that a thorough URS be developed. Without a solid URS, a number of bad things can happen:

• The specification produced may needlessly limit the number of vendors who bid on your project
• The selected technologies may be unsuitable since important requirements or constraints have been overlooked
• Carrying out a meaningful performance qualification (PQ) will be impossible as there is no well-defined set of user requirements on which to base the final phase of qualification
• Lower-cost alternatives that would have met requirements may never be considered or be needlessly rejected
• The project may be delayed and costs increased due to changes required during design, construction or qualification

An Important Disclaimer

This is a controversial topic. If you’re reading this article, chances are good that you work for a company that already has templates you can or must use to write your URS. If that’s the case, we hope this article gives you some clarity that will help you think through your project even if your official documentation won’t look like what we describe.

What a URSIs and What It Isn't

Your user requirements specification document doesn’t exist in isolation. It is one of many documents that contribute to successful project execution and process validation. In short, a URS explains the purpose of the system and the non-negotiable criteria that will be used to determine whether it’s doing its job. Your URS will be the main document used to define your performance qualification (PQ) protocol. In fact, every single requirement in your URS should be verified during PQ. In contrast, your FRS and TRS will be used for your operational qualification (OQ) and installation qualification (IQ) respectively.

Prior to writing a URS, a project initiation phase should be completed. The project should have a title and defined purpose. A risk management plan should be written and various risk assessments should be completed. Finally, a validation plan should be developed and it should describe how requirements from the URS, functional requirements specification (FRS), and technical requirements specification (TRS) will be used for validation.

Since all these other documents exist, it makes sense to keep the URS as simple and focused as possible. It should contain nothing more than information on what good performance looks like over the long-term.

List of Requirements to Consider for a Purified Water System URS

The following sections describe the types of requirements we recommend you consider including in your URS. Every situation is different. Feel free to add or subtract elements as you see fit. Just keep in mind that your URS exists to describe desired outcomes rather than the means to achieve them.

Process Requirements

These should include:

• Quantification of water needs
• How much water will be used by downstream processes
• How often they will need water
• When the water will be needed
• Minimum and maximum water usage rates considering possible concurrent demands from different usage points
• Average water usage, typically expressed as daily usage
• Water quality requirements
• For multiple usage points, define requirements separately if they differ
• Include requirements from all applicable pharmacopeias. You will need to define your own requirements based on the recommendations of the applicable pharmacopeias and your specific uses for the purified water.
• Consider any water drawn for non-compendial uses (e.g. softened or dechlorinated water for steam generation, pure water for laboratory use)
• Include temperature requirements or preferences for each stream, if they exist

Usability Requirements

Usability requirements define how the system will be used by people. While we don’t recommend going into much detail here, some high-level elements can be included in the URS if they will be validated during performance qualification.

These may include :

• How users should be able to dispense water (e.g. “Filling the batch tank shall require only the single press of a button and require no further user attention or intervention.”)
• Requirements for visual, auditory or other signals (e.g. “The system shall provide personnel in the filling area with positive visual confirmation that purified water is of appropriate quality for use.”)
• How and from where users should be able to stop or start the system (e.g. “Users shall be able to stop the system locally, from the filling room and from the plant’s central control room.”)

It can be tough to draw the line between user requirements and functional requirements when describing these user interactions. A good rule of thumb is that if you’re getting into describing technology rather than results, you are probably getting into FRS territory. For example, the following would fit in an FRS, in contrast to the examples above.

A panel with one green light and one red light will be placed in the filling room so as to be visible when at any filling station. The system will maintain the green light lit when water quality is adequate. The red light will be lit when any water quality parameter has been measured as outside specifications. The system will wait for all parameters to be within specifications for 10 minutes prior to lighting the green light.

Example of a specification that would fit better in an FRS

System Availability Requirements

These may include:

• Water availability schedule (e.g. 16h/day, day & evening shift or 16 000 US gallons available every morning at 8:00AM)
• Acceptable frequency or schedule for shutdowns
• Expected behaviour during utility interruptions or instability, such as:
• Power outages
• Water outages
• Feed water quality upsets

Constraints

Constraints are limitations imposed by the situation, regulating bodies or other external forces. These should include:

• Full feed water quality analysis
• Maximum available utilities (electricity, steam, water, drains)
• Space constraints (room layout drawings are excellent here)
• Connection points for utilities and downstream processes, if set in stone
• Water quality standards imposed by regulations (e.g. USP Purified Water)
• Applicable pressure vessel design standards and any exclusions (e.g. ASME stamp or required CRN stamp on all pressure vessels)
• Applicable electrical standards (e.g. UL, cUL, CSA)
• Applicable data integrity standards (e.g. FDA 21 CFR Part 11)
• Other applicable safety standards

Restraints

Restraints are limitations imposed by the client. This is where many a URS goes awry and delves deeply into the FRS territory. Any project-specific decisions related to how the system’s aims are to be achieved should be in the FRS. Most true restraints are plant- or company-wide policies.

Restraints may include:

• Applicable industry-specific design standards the client has chosen to apply (e.g. ASME-BPE)
• Plant or company standard instruments list
• Plant or company standard valves list
• Plant or company standard PLC architecture
• Other plant or company standard components lists
• Documentation standards
• Any plant or company policies around purified water system or distribution system design (e.g. dead leg specifications, drainability requirements, pipe finish requirements). DO NOT include these if they’re just project-specific design choices; you’ll do that in your FRS and TRS.

What Not to Include in Your URS

As we’ve worked to help clients define their requirements we’ve found that recommendations for writing requirements specifications vary wildly. This is unfortunate and not at all helpful since it creates confusion at the earliest stage of buying critical systems. Our key observation about the various URS documents we’ve seen, especially those included in RFQ packages, is that they confuse defining requirements with specifying the means for achieving them.

We know this section is going to draw fire from certain domain experts because we rarely if ever see a user requirements specification that contains no “out of scope” information. So be it.

In short, we are basing our recommendations on one simple fact: your URS is used to define your PQ protocol. IQ and OQ are already complete by the time you undertake PQ. If you’re going to be validating a requirement you’ve written in your URS during IQ or OQ, it’s in the wrong place.

We’re not saying your RFQ package shouldn’t contain whatever specific technical details you might have been planning to include. We just recommend that you keep your URS clean, simple and streamlined and instead include these elements elsewhere. Include them in your FRS or TRS if you’ll be validating them, or simply include them in another your RFQ document if they relate to some other requirement you wish to impose on vendors.

Technology Selections

A URS should not contain, in our not-so-humble opinion, a description of the actual treatment process that will be used to achieve the desired results. This type of content is more appropriate for the technical specification or, in some cases, for the functional requirements specification.

You may decide to request bids based on a specific system design. That’s your prerogative. In that case, you should be going to bid after having written your URS, FRS and TRS and other validation documentation. In this situation, you wouldn’t expect your equipment vendor to participate in validation other than by providing the documentation laid out in your quality plan.

In all likelihood, though, you don’t have the in-house expertise to fully design and validate a purified water system. Most clients rely on specialized vendors and consultants to do this work. If this sounds like your situation, we’d recommend you stop after writing a true URS and engage a large number of vendors so that they can propose the solutions they think will be the best fit for your requirements. You may then want to hire a consultant to help sort through all the options and decide which proposals will meet your requirements.

Full Functional Specifications

We’re not sure why some sources recommend including a functional specification as part of a URS. These sources go on to include hardware and software design specifications in the list of URS inclusions. How can you specify these details when you haven’t even selected technologies that will make up your treatment train?

Please, don’t fall into the trap of defining how the system will open and close valves, start and stop heaters or motors, trigger alarms, log data or do much of anything at this early stage. Stay away from the “how”. That will come later.

Equipment Sizing

It’s no use specifying how big your distribution tank will be unless you already own a tank that will be used for this system. It’s also useless, at this early stage, to specify the physical size of a softener or the number of cubic feet of resin it should contain. Similarly, please leave out the sizing of the pumps and UV sterilizers. These are all items that either belong in the FRS or TRS, but not in the URS. Think about it: once you’ve completed your installation qualification (IQ) and operation qualification (OQ), are you going to need to make sure that you have an 8″ diameter softener with 0.8 cubic feet of cation resin with a minimum capacity of 25,000 grains per cubic foot? No!

In Conclusion

Maybe you can tell from the tone of this article that we can get a little heated when discussing this subject. That’s because we know how important it is to get the URS right before moving on to the subsequent design stages. It’s also because we’ve seen so many cases where a poor URS lead to completely preventable cost increases, project delays and production losses, not to mention 20+ years of complaining about a system that just doesn’t quite do what it should have been designed to do.

We sincerely hope this article will help you reduce costs and get the best system possible to meet your needs. As always, please join the conversation by leaving a comment below. If you’ve got questions or if you disagree with anything we’ve written above, we’d love to hear from you. Nothing helps us all move forward more than a healthy debate!