A User Requirement Specification (URS) is issued by the user to define the system requirements. Issuing a URS serves many purposes.

For example it:

  • Specifies the system’s parameters, regulations, and standards
  • Establishes the base for pricing the new system
  • Establishes the base for design, manufacturing, and validation
  • Specifies deliveries

Try to keep the system requirements as high level as possible. Avoid adding unnecessary detail or increasing the requirements, which can increase the cost.

URS Content

The requirements of a purified water treatment system are specified in the various regulations and standards, so don’t spend time repeating this information in the URS. To optimize your URS, focus on the parameters for the system and the regulations and standards that will be applicable.

Including contradicting requirements can lead to confusion, so develop clear concise requirements that are unambiguous.

It is not the amount of pages that decide the quality of your URS but how specific and easy to read and understand it is for the different groups involved in design, manufacturing, and validation.

Process Requirements

Process requirement should include:

  • How much water is needed
  • The required capacity of the system
  • How much water user point requires
  • What user points need to able to use water at the same time
  • Usage priorities if several user points need water at the same time (worst case scenario)
  • The water quality of the system (whether it should fulfil the USP or the Ph. Eur. monograph for PW. both, or any other pharmacopeia).

User Prerequisites

Include the following:

  • Maximum available utilities if there are limitations (incoming water, compressed air, black steam, electrical load, drain capacities, etc.) so engineering will design it properly
  • A water analysis report of the incoming water so engineering can design and size pre-treatment of the system for optimal operation. Attach water analysis reports from different seasons of the year so the changes in water quality can be considered
  • Room layout with measurements for where the system will be located
  • Interface points for each utility and the PW treatment system

Mechanical Requirements

Include the following:

  • Pipe standard, if applicable (for instance, DIN or ASME)
  • Use of sanitary components and valves on the product-wetted side (no threaded connections on the product wetted side)
  • Use of sanitary connections such as tri-clamp connections on the product-wetted side
  • Welding requirements according to current ASME BPE standard or European equivalent standards
  • Air break to floor drains to prevent back flow back up to the system
  • Dead-leg specifications according to ASME BPE or 3di (calculated as maximum length of the branch equal to 3 x the inner diameter of the branch)
  • Slope of purified water distribution piping (often 0.5%)
  • Drain-ability of the distribution piping, which must be sloped to low points where it’s possible to drain the water with a valve. Many times the distribution pump will represent a low point and would also need to be drainable and supplied with a valve to accommodate that

You should not need to specify drain-ability and slope requirements for the PW treatment system itself. Since you will never steam sterilize it you will not have to worry about any condensation in the lines. If the system won’t be used for a longer time or “stored”, it would be filled with preservation chemicals and not emptied. Note also that several components in this process are not drainable (for instance, RO vessels and CEDI modules). Many times pre-treatment vessels have both an inlet and outlet on the top.

Electrical Requirements

Applicable European Directives, NEMA Standards, and/or UL Standards are required depending on where the system will be installed.

Automation/Software Requirements

The system must be provided with design documents specifying how it will operate and the components and structure of the automation:

  • Functional Specification
  • Hardware Design Specification
  • Software Design Specification

The program must be logically structured and must be provided with clear comments and free of dead code.

Tests typically include:

  • A software review before implementation in the water system
  • Electrical inspections and tests of all inputs and outputs
  • Software testing according to the Functional Specification

The back-up of the software must be provided.

FDA Part 11 Compliance

FDA 21 CFR Part 11 requires that a water system’s software have an audit trail capability, data storage, individual passwords, and so on. Note that a PLC which is commonly used in water treatment systems will not have the feature of tracking changes, store them in a log and refer to the specific user who implemented the change and show at which time it happened.

For FDA Part 11 compliance there is special software available.

Quality Assurance

The following need to be specified:

  • Quality control activities
  • Design review
  • Required manufacturing inspections
  • Validation requirements
  • Responsibilities and supervision of contractors

Safety Requirements

If the system is going to be installed in the European Union it must comply with the Machinery Directive. Operator safety should be considered, especially for hot distribution systems and during hot water sanitizations. Requirements regarding insulation, automatically interlocked points of use (POU), sanitizations scheduled to times when production is not working, and warning signs/lamps can mitigate burning risks.

Site or Company Specific Requirements

Site- or company-specific requirements might include:

  • Preferred instruments list
  • Preferred components list
  • Equipment signs specification
  • Site specific tag numbering system
  • Special work procedures for contractors working on the site
  • Ergonomic requirements on design (for instance, height specifications for sample ports)

Suppliers normally have a “standard” design that fulfils most regulations. Site-specific requirements, in general, increase the cost of the system as custom requirements affect the
standard and imply change.