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
C’est un sujet controversé. Si vous lisez cet article, il y a de fortes chances que vous travailliez pour une entreprise qui a déjà des modèles que vous pouvez ou devez utiliser pour écrire votre SEU. Si tel est le cas, nous espérons que cet article vous apportera une certaine clarté qui vous aidera à réfléchir sur votre projet même si votre documentation officielle ne ressemblera pas à ce que nous décrivons.
What a URSIs and What It Isn't
Votre document de spécification des exigences des utilisateurs n’existe pas isolément. C’est l’un des nombreux documents qui contribuent à la réussite de l’exécution du projet et de la validation des processus. En bref, un SEU explique le but du système et les critères non négociables qui seront utilisés pour déterminer s’il effectue son travail. Votre SEU sera le document principal utilisé pour définir votre protocole de qualification de performance (QP). En fait, chaque exigence de votre SEU doit être vérifiée pendant le QP. En revanche, vos FRS et TRS seront respectivement utilisés pour votre qualification opérationnelle (QO) et votre qualification d’installation (QI).
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 des besoins en eau :
- 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
Contraintes
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 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.
Nous ne disons pas que votre package RFQ ne doit pas contenir les détails techniques spécifiques que vous auriez pu prévoir d’inclure. Nous vous recommandons simplement de garder votre SEU propre, simple et rationalisé et d’inclure ces éléments ailleurs. Incluez-les dans votre FRS ou TRS si vous comptez-les valider, ou incluez-les simplement dans un autre document de votre RFQ s’ils se rapportent à une autre exigence que vous souhaitez imposer aux fournisseurs.
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?
S’il vous plaît, ne tombez pas dans le piège de définir comment le système ouvrira et fermera les vannes, démarrera et arrêtera les radiateurs ou les moteurs, déclenchera des alarmes, enregistrera les données et fera beaucoup de choses à ce stade précoce. Éloignez-vous du <comment>. Cela viendra plus tard.
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.
Nous espérons sincèrement que cet article vous aidera à réduire les coûts et à obtenir le meilleur système possible pour répondre à vos besoins. Comme toujours, veuillez vous joindre à la conversation en laissant un commentaire ci-dessous. Si vous avez des questions ou si vous n’êtes pas d’accord avec tout ce que nous avons écrit ci-dessus, nous aimerions avoir de vos nouvelles.