User Requirements Specification

For
Contained High Hazard Systems

[Enter System Name & Version # here]

Simple well designed systems work far better than complex over designed systems,
when stating the user requirements bear this in mind. Do not add features because
they would be nice to have (example temperature control to 2F in the range 60 -
65F). Only add features if they are essential to the operation. Features can be very
expensive and often do not work as expected.

There are two approaches outlined in the charts within the document; one is a vendor design approach
and the other is containment specialist design approach.
Vendor Design
In this approach the user prepares the User Requirement Specification (URS)so that competing vendors
know what the user wants in terms of process capability outline for the Functional Requirements (FRS)
for the vendor to complete. A procurement document is prepared to instruct the bidder on the Technical
and Financial Requirements for the bid. The vendor then has to undertake a preliminary design and
provide documentation in the bid document that in the vendors judgment is sufficient to illustrate the
scope of supply and a corresponding price. This will vary greatly from vendor to vendor.
The stakeholder team then has to assess the bids comparing the various designs to select the best
(design, specification and cost) solution or to negotiate with one or more bidders to leverage changes
prior to award. A vendor is selected and the project awarded.
The vendor then undertakes design development, builds an ergonomic model and completes the FRS.
Any changes as a result of this process may result in a change order due to scope change. Once these
are approved, the vendor commences detail design and submits drawings and documentation for
approval by the stakeholders.
The process then moves through FAT, SAT, Functional, Surrogate, IQ and OQ protocols. The vendor
prepares the FAT, SAT and Functional protocols and submits them for stakeholder approval. The
stakeholders typically prepare IQ, OQ, PQ and Surrogate test protocols. Training on operation of the
isolator is by the vendor.
Specialist Design
In this route the stakeholders engage the services of an independent specialist to assist the stakeholders
in one or more of the tasks described below. In some cases the specialist can be provided design and
mock up review and this is shown before the bid process. This allows bids to be on a like for like basis.
The specialist designer can be anyone who in the opinion of the owner has the necessary experience and
credentials to perform the role. The specialist may be:
A company employee who specializes in containment and has sufficient in depth knowledge to
perform the role
An independent consultant with out attachment to any interested party. This consultant should be
able to fully design and evaluate the isolator system so that vendors do not need to perform
preliminary engineering and ergonomic review
Part of an A/E team. Be careful most if not all A/Es derive their information from vendors and
rarely if ever have hands on experience of isolators
A Vendor. Vendors have virtually no feedback from end users and the design is being developed
once an order has been placed so the two drivers are to look for variation orders and design to
achieve the profit margin. A vendor pre-design will alter other vendors and may result in high
pricing with minimal input.
If the specialist consultant option is chosen the normal course would be for the stakeholder team to
appoint the specialist at the outset. The specialist would then become part of the stakeholder team and
participate in the stakeholder activities, bring detailed specialist support to the URS and FRS process as
well as the design development and mock up assessment.
The consultant design approach
As soon as possible the stakeholder team appoints a specialist who assists the stakeholders in
developing the URS using the outline illustrated here. The consultant will also have experience which
enables the FRS to be written to benefit the user requirements uninfluenced by vendor preferences for
ease of construction, cost, etc.
As the URS is developed concept designs are reviewed and when appropriate a mock up is made at full
size for the stakeholder review. This involves the use of the actual tools and equipment to fully explore all
the interventions, process steps, etc. The operators are a vital part of this process. After the review is
complete the consultant develops detail design drawings (general arrangement) and schematics showing
how the isolator is to function as well as product flow routes. The specialist will customize the protocols
that have been developed by the consultant for FAT, SAT and Functional testing (IQ and OQ can be
included) so that the vendor prices for the supply of calibrated test equipment and personnel for the
witnessed protocols (FAT, SAT, Functional and Surrogate Test, etc).
The packages described above are bid out so that the comparison is on a like for like basis on a design
that has already been scrutinized by the stakeholders and which represents their requirements.
On award the vendor moves directly to fabrication drawings. The specialist provides witnessing/ support
for FAT, SAT and Functional testing. Start up support and debugging can also be provided and the
specialist provides full training for operation technique and administration of the isolator.
This route minimizes scope changes and maximizes the operability and performance of the system.
Table of Contents

1.0 Introduction, Scope and Definitions.....................................................................................13

1.1 Introduction................................................................................................................ 13
1.2 Scope........................................................................................................................ 13
1.3 Definitions.................................................................................................................. 13
2.0 References.......................................................................................................................... 14
3.0 Operations Description........................................................................................................ 15
3.1 API and Excipients..................................................................................................... 15
3.1.1 API Hazard Assessment...............................................................................15
3.1.2 API and Excipient Characteristics.................................................................16
3.1.3 API/ Excipient Sensitivity..............................................................................16
3.1.4 API/ Excipient Fire and Explosion Risk (more to amplify).............................16
3.2 API Excipients and Process.......................................................................................16
3.2.1 Downstream Processes................................................................................17
3.2.2 The Process................................................................................................. 17
3.2.3 Pass-in.......................................................................................................... 18
3.2.4 Process Equipment.......................................................................................18
3.2.5 Sub-batches/ Campaigns.............................................................................19
3.2.6 Labeling........................................................................................................ 19
3.2.7 Sampling....................................................................................................... 19
3.2.8 Pass Out....................................................................................................... 20
3.2.9 Uptream Processing.....................................................................................20
4.0 User Requirement Specifications........................................................................................ 20
4.1 Ergonomics and Safety..............................................................................................21
4.2 Ergonomics and Safety..............................................................................................22
4.2.1 Ergonomics................................................................................................... 22
4.2.2 Safety........................................................................................................... 22
4.2.3 Guarding....................................................................................................... 23
4.3 Utility and Service Connections.................................................................................23
4.3.1 Process Connections....................................................................................23
4.3.2 Process Data Connections...........................................................................23
4.3.3 Process Equipment Interface with the System.............................................24
4.4 Cleaning Systems...................................................................................................... 24
4.4.1 Cleaning Materials........................................................................................ 24
4.4.2 Manual Clean............................................................................................... 24
4.4.3 WIP............................................................................................................... 25
4.4.3.1 Waste Disposal.............................................................................25
4.4.4 CIP Full cGMP clean in place....................................................................25
4.5 Select the Isolator System.........................................................................................26
4.5.1 Isolator Environment.....................................................................................26
4.5.2 User Requirements for the Isolator Control System......................................26
4.6 Business Functional Requirements...........................................................................27
4.7 Data Requirements.................................................................................................... 27
4.7.1 Data Input Requirements..............................................................................27
 4.7.2 Data Processing Requirements....................................................................27
4.7.3 Data Output Requirements...........................................................................27
4.8 Interface Requirements............................................................................................. 28
4.8.1 Hardware Interface Requirements................................................................28
4.8.2 Software interface Requirements..................................................................28
4.9 Control System Requirements...................................................................................28
4.10 Performance Requirements.......................................................................................28
4.10.1 Response Time Requirements.....................................................................28
4.10.2 Capacity Requirements................................................................................28
4.10.3 Scalability Requirements..............................................................................28
4.10.4 Support Requirements..................................................................................29
4.11 Environmental Requirements....................................................................................29
4.11.1 Technology Requirements............................................................................29
4.11.2 Mechanical Requirements............................................................................29
4.11.3 Facilities Requirements................................................................................29
5.0 Regulatory Requirements.................................................................................................... 30
5.1 Security Requirements..............................................................................................30
5.1.1 Logical Security Requirements.....................................................................30
5.1.1.1 Passwords....................................................................................30
5.1.1.2 User Ids........................................................................................31
5.1.1.3 Logical Security Other...............................................................32
5.1.2 Physical Security Requirements...................................................................32
5.1.2.1 Physical........................................................................................32
5.2 Electronic Records..................................................................................................... 32
5.3 Audit Trail Requirements...........................................................................................33
5.4 Handwritten Signature Requirements........................................................................34
5.5 Electronic Signatures Requirements..........................................................................34
5.5.1 Electronic Signatures - General....................................................................34
5.5.2 Non-Biometric E-signatures..........................................................................35
5.5.3 Non-Biometric E-signatures with Tokens......................................................36
5.5.4 Biometric E-signatures..................................................................................36
5.6 Backup, Recovery, Archive, Restore Requirements..................................................37
5.7 Training Requirements...............................................................................................37
5.8 Documentation Requirements...................................................................................38
6.0 Other Requirements............................................................................................................ 38
7.0 Assumptions, Expectations, Restrictions and Limitations....................................................38
General Instructions

The purpose of this template is to assist you in the preparation of the User Requirements Specification
URS) document for isolator systems. Please follow all applicable Pharmaceutical Sourcing Group
Americas (PSGA) standard operating procedures.

Paragraphs in blue italics font style are meant to serve as instructions to the author of this
document and to be deleted in the final version.
Paragraphs in black regular font style are sample wording that may be used as is or modified as
required. Should a sentence or paragraph not be needed, simply delete it from your document
This template contains all the sections required for an Isolator URS.
Major requirement section(s) in black regular font must be populated or, if not applicable,
must be retained in the document and labeled as such. Sub-sections in blue regular font
are optional and can be modified or deleted to accommodate your system.
Text in [BRACKETS] should be replaced with the appropriate information by the author.
Shaded numeric and/or text fields (field codes) in Gray (including the Table of Contents) must be
updated before publication of your document (right click on field and select Update Field).

User Requirements Specification (URS) are based on business and user needs and define what the user
wants the isolator system to do in clear and specific terms. Upon completion of this document a
Functional Requirements Specification (FRS) will be developed and provide standard specifications for
materials, finishes, HVAC and control systems including process interfaces that will satisfy the
requirements stated in this URS document. The requirements in this document specify the business and
functional requirements of your system. This includes the functional, security, data integrity, and
performance capabilities that must be provided in order to meet the business needs of the users of this
system in PSGA. The URS will also provide additional information to expand the project plan for realistic
tasks, dates and resources.

Requirements must be written in a complete and unambiguous manner that defines the system
functionality and/or component. Most importantly, the requirement should be testable. It should not
contain words or phrases such as, timely, quick, or user friendly, etc. Descriptions must include words
and phrases that command the presence of some feature, function or deliverable, such as: shall, will,
must, is required to, responsible for, or are applicable.

Requirements must be uniquely identified with a requirement number. The following is a standard format
that contains the requirement number, prefaced by the user requirement indicator of U and an
abbreviation of the requirement category.

Present the requirements in a table form with the requirement ID number, the description and the
requirement type refer to the example table below. A legend for the possible Type field entries
appears further below. The most commonly used types will be T for technical and P for procedural.
Depending on the type of requirements incorporated into your finished URS, consider adding a specific
legend with definitions that will facilitate reader understanding.

DELETE THIS PAGE

Requirements example table:
ID Description Type

U-FR-01 The system shall allow the user to export raw data files from the ABC LIMS T
system in PDF format.
U-FR-02 A system specific SOP describing Backup & Restore procedures will be P
developed.

Type field legend

Term Definition
T Technical
P Procedural
CFG Configuration
CUST Customized
OBS Obsolete

The User Requirement Isolator Decision Matrix

The chart shows the user and functional requirements flowchart. The user is directed to follow this
flowchart in organizing the information that is incorporated in the User and Functional
Requirements Specification. Both should be used on all isolator projects. The User Requirements
Specification defines the user performance requirements while the Functional Requirements
Specification provides information on the required materials, finishes, process integration, etc
required to complete the project. If in doubt follow the flowchart.
The Isolator Decision Matrix
The matrix illustrates the sequence of events and actions required to fully describe the
requirements to the vendor. The diagrams illustrate two approaches; one with vendor design and
the other using an internal or external specialist to design the system.
Evaluation to review the best cost and method to mitigate the risk
The qualitative and quantitative risk assessment is undertaken using the RBEAP tool to provide risk
ranking. If this assessment shows that a closed process is required, such as an isolator and that
other controls cannot provide the required degree of exposure control then the process that follows
is used to develop the documentation required for successful project.
If the OEL cannot be achieved, then a decision to further investigate the issue is made. If the
outcome of this step is that an isolator is required to achieve exposure control, a stakeholder team
is formed and a project manager appointed.
Project Manager
The role of the project manager is to be the point person for the project, to set up review meetings
and to ensure that the key stakeholders make the appropriate commitment to the project. The key
stakeholders must represent the interests that have influence on the selection, funding, operation
and performance of the system.
Stakeholders
Stakeholders should represent the following interest groups:
EHS:
Set the hazard
Evaluate and assess exposure control
Assess and evaluate risk of injury and safety from the operations

Operations set the performance requirements to meet operational needs

Operators must buy into the system and have to make it operate successfully they should
contribute to the development of the process.

Engineering, have to procure, specify, install and evaluate the system.

Quality has to set acceptance criteria and ensure that the system complies with regulatory
requirements.

All stakeholders have to understand and appreciate the needs of others and understand that a
successful project stems from cooperation and collaboration. The project manager should
schedule and lead all stakeholder meetings and ensure that they are effective. The stakeholders
are responsible for developing the necessary data to allow the project to proceed in a timely cost
effective manner. In some cases the specialist consultant should be added to the stakeholder
team.

At all times remember that the devil is in the detail.

The core stakeholders commence writing the URS using the blank format. The process starts with
reviewing the issues of the API (3.1.1) and excipients (3.1.2) including any sensitivity to oxygen,
light (3.1.3) and continues through the details of the process (3.2) including:
3.2.1 Deals with downstream processes; where do the materials come from? How are they packed
and the risk of external contamination? What processes were performed?
3.2.2 Deals with the process to be contained
3.2.3 Deals with what passes into the isolator
3.2.4 Deals with the process equipment
3.2.5 Deals with batches
3.2.6 Deals with the required labeling which is often ignored
3.2.7 Deals with sampling requirements
3.2.8 Deals with pass out
3.2.9 Deals with upstream processes
In addition 4.1 Performance and 4.2 Ergonomics and Safety (this has a direct link to the ergonomic
evaluation by either of the two routes described), 4.3 Utilities and Services and 4,4 Cleaning
Systems and 4.5 Isolator Systems all comprise the user requirements where the user has a distinct
requirement. This results in the production of the URS. If a specialist (internal/external) is used
this person normally develops the URS in consultation with the critical stakeholders.
The stakeholders decide whether they want to go a vendor design route or a consultant design
route. The advantages and disadvantages are summarized below.
Consultant Design in this format the URS is used to produce a design that satisfies the
URS, this is then challenged by an ergonomic evaluation of a mock-up. The specialist then
develops a bid package including the URS, FRS, general arrangement drawings as well as
FAT, SAT, IQ, OQ, Surrogate and Functional Testing Protocols. This means a full bid
package is produced so that the bids are like for like and the risk of change orders is greatly
reduced. The responsibility for the designs ability to meet the objectives rests with the
consultant. The process also eliminates many of the quirky elements that are incorporated in
containment designs caused by people with limited experience subjectively deciding what is
important.
Vendor Design in this format the bid package comprises the URS, an outline FRS and
Procurement Package. The bid period has to be extended to allow vendor preliminary
design. An order has to be placed before detail design and ergonomic evaluation takes
place. The Vendor receives the URS prior to award of a purchase order and then develops
the FRS once a purchase order has been awarded. This results in a bid evaluation by the
owner that has to make a cost and design evaluation between different designs. This
process often leads to cost escalation as the user comprehends what he has contracted for
and as a result of undertaking the ergonomic review after the contract is awarded. The
vendor is asked to write the protocols for testing and this can be very variable in quality and
bias towards the vendor.
The rest of the chart follows the creation of drawings for review and approval. The process
includes FAT, SAT, training and documentation.
Procurement produces a document that encompasses the details of the bid process, terms and
conditions, instructions to bidders, etc.
The Functional Specification is an outline document which is used by either the vendor or the
specialist to prepare an FRS that is part of the bid process.
DELETE THIS PAGE
1.0 Introduction, Scope and Definitions

1.1 Introduction

[This section describes the isolator system by depicting its functionality, location and intended use
or purpose. The purpose of this document is for the users to clearly state what they intend to do in
the system and what features are necessary to perform the operations successfully. A user
requirement document will not specify materials and workmanship unless it has a direct process
impact. Most projects fail because there is no clear statement of the use of the system.]
The purpose of the User Requirements Specification (URS) is to define the business user needs
of the [System name and version number]. The User Requirements Specification will be the basis
of Qualification testing to ensure that user requirements are met.

The [Name] System is an isolator system that will be utilized by the [department/group and
location] to [purpose/intended use of the system]

1.2 Scope

[Describe the scope of the system being defined including site locations and major
components and / or interfaces to be included as a part of the system.]

1.3 Definitions

This section presents acronyms and definitions of terms specific to this document.

Term Definition

API Active Pharmaceutical Ingredient as opposed to excipients,

also called Bulk

Characterization A method to make preliminary hazard assessment and to help

in risk communication

Excipient Non-active ingredient of a pharmaceutical compound

HEPA High efficiency particulate filter

Inert Typically using a nitrogen environment to prevent vapor and

dust explosions

OEL Occupational exposure limit based on an 8 hour day and 10

m3 air consumption per operator.
 Term Definition

UID User Requirement Identification Number used to identify and

reference each specific user requirement related to the
system.
Electronic Record Means any combination of text, graphics, data, audio, pictorial,
or other information representation in a digital form that is
created, modified, maintained, archived, retrieved, or
distributed by a computer system.
Electronic Signature Means computer data compilation of any symbol or series of
symbols executed, adopted, or authorized by an individual to
be the legally binding equivalent of the individuals handwritten
signature.
T Technical requirement type This term indicates that the
capabilities of the system will meet the specific requirement.
P Procedural requirement type This term indicates that the
capabilities of the system cannot sufficiently meet the
requirement and therefore necessitates the use of a written
procedure, e.g., SOP.
CFG Configuration requirement type This term indicates that the
requirement is met through a specific configuration of the
system.
CUST Customized requirement type This term indicates that the
requirement is met through a customization of the system.
OBS Obsolete requirement type This term indicates that the
requirement is obsolete.
SUPAC Scale Up and Post Approval Changes FDA Guidance on
allowable changes that do not require a resubmission for
approval
IOM Institute of Occupational Medicine Standard used for
samplers
RBEAP Risk Based Exposure Assessment Process

2.0 References
[This section should include all appropriate references for the project, including change approval
numbers, project management plan, validation plan, etc.]

Document Title Version

Number
CR-nnnnn Change Request for the [System name & version #]
 PSGA-DOC- Project Management Plan for the [System name & version #]
nnnnn

PSGA-DOC- Vendor Assessment for the [System name & version #]

nnnnn

PSGA-DOC- GxP Assessment for the [System name & version #]

nnnnn
PSGA-DOC- Validation Plan for the [System name & version #]
nnnnn
PSGA-DOC- Traceability Matrix for the [System name & version #]
nnnnn

3.0 Operations Description

[Include Applicable Flow Diagrams]

[This section describes an overview of the manufacturing operations that will be covered by the
system. The description in this section sets the scope or boundaries of the functionality of the
system. Reference to operational procedures, product specifications and other documents impact
within the scope of the system may be identified in this section.]

3.1 API and Excipients

3.1.1 API Hazard Assessment

This section states all the APIs the system is expected to handle and should list its OEL, the
occupational exposure limit, ADI, the allowable daily intake (protective of the patient
population) and list other characteristics that require consideration such as carcinogenicity,
sensitizer, genotoxicity, etc.

When the compounds are unknown then a default should be used that is protective of the
occupational workforce. This default should be based on the worst characteristics that will be
expected.

The system is expected to handle the following APIs:

Compound OEL ADI Considerations

Sensitizer
Mutagen
Carcinogen
Teratogen
Other phrases

3.1.2 API and Excipient Characteristics

 In designing containment systems understanding how the compound behaves and its density
are key considerations. Volume is often the most important factor in designing containment
systems. Inspired guesses are better than no data, but if a guesses please state as a guess.

Particle Shape*

Electrostatic Properties
Bulk Density*

Explosivity

Comments*
Particle Size
API/ Excipient Name

*Sphere *Free flowing

Feathery Sticky
Amorphous etc
* expressed in comparison to the same unit volume of water

3.1.3 API/ Excipient Sensitivity

Is the API/ Excipient sensitive or degraded by light, heat, oxygen, etc?

The comments column should indicate safe ranges such as oxygen >5%, heat 20 - 30C, etc.
Where the user has a required mitigation regimen it should be stated, so for oxygen the
required mitigation is inerting with nitrogen or the use of an amber light where there is not
prescribe mitigation it should be left to the functional specification or the vendor.

API/ Excipient Sensitivity Comments Mitigation

Humidity

Others
Light

Heat
Oxygen

3.1.4 API/ Excipient Fire and Explosion Risk (more to amplify)

The data on the fire and explosion propagation characteristics should be clearly stated.
Where risk of explosion by solvent or powder concentration exists it should be clearly stated.

All powders and liquids (solvents) are to be listed and the vendor is to evaluate materials of
construction in accordance with these materials an those listed in 4.4.1.

3.2 API Excipients and Process

This section describes the processes to which the API and excipients are subjected

Process / Start of Process End of Process

Material Weight Volume Pack No./ Weight Volume Pack No./ Batch
Type Batch Type
Process Step: (Sampling)
API 1 kg 10 L Fiber 1 1 kg
drums
21 x 24
Excipient 10 kg 100 L Fiber 10 10 kg
drums
21 x 24

3.2.1 Downstream Processes

Processes that occur before the API and excipients enter the system described in this URS.
This helps the designer understand how the system fits into the whole process. An example
would be:
The API is manufactured in China and is packed in liners in liners in fiber drums 12
diameter by 24 tall in random weights. On receipt the drum is opened in the warehouse
sample area and a sample is extracted for analysis. The drum is re-sealed and wiped down.

It is important to understand if significant external contamination of the packaging has

occurred in an upstream process.

Representative samples may be received as part of the bulk fiber drum which will help to
minimize exposure but this may not be applicable to all sites. The team should verify
applicability with the local site.

ID Description Type

U-DP-1
U-DP-2

3.2.2 The Process

This section describes in detail the processes that are undertaken within the system
described in this document. A process flow diagram should be inserted showing the flow of
materials through the process(es) so that the reader can understand the detail that follows.

The process should be described in detail highlighting all interventions expected and
unexpected, for instance The Jet Mill suffers cold fusion every 5 10 minutes and has to be
solvent dissolved. Provision for a spare mill and solvent bath, cleaning is required. As
opposed to The material is mircronized.

Typical processes are:

o Sampling
o Weighing
o Formulation of a liquid or slurry
o Milling
o Granulation
o Drying
o Blending
 o Compression
o Filling
o Encapsulation
o Extrusion, etc

Frequency: How often is the system likely to be used for the processes required?
Multiple times a day? How many times a day?
Daily?
Weekly?
Monthly?
Less frequently?

It is essential to fully describe these processes using the headings below.

ID Description Type

U-PR-1
U-PR-2

3.2.3 Pass-in

What passes into the system? What are the sizes and weights of the API(s)? Excipient(s)?
Equipment that passes in? Material that passes in? Do they pass in in a particular order?
Are there any special procedures required on pass in? For instance is a liner removed?
What is the container type? How many pass in, how often does this occur?

ID Description Type

U-PI-1
U-PI-2

3.2.4 Process Equipment

What equipment is to be reused or ordered? Is it subject to regulatory filing or can it be

changed or modified? Can more containment friendly options be considered and can
substations be made under SUPAC?

What accuracies are required? What are the feed and discharge rates?

Does the process produce

Pressure?
Vacuum?
Heat?
Dust?
Noise?
And if so, how much?
 Will these issues affect the product or operator? (Note processes that create pressure
outside the design parameters must be capable of being closed down. The volumes and flow
rates are essential to allow a correct design.

Provide cut sheets of the equipment and add as an appendix.

ID Description Type

U-PE-1
U-PE-2

3.2.5 Sub-batches/ Campaigns

This section describes how the process is performed.
o Are sub-batches necessary to make the full batch? If so, how many? Describe
and estimate the time a sub-batch will take
o How many batches are made and the frequency? Are they staged and if so how
long?
o How many batches make a campaign?

ID Description Type

U-SB-1
U-SB-2

3.2.6 Labeling
At what stages is labeling required? What information is required and how will it be
generated? Will it be applied within the contained system? If so, how will the label get
there? State the parameters and not the solution unless a solution has already been
evaluated for instance sacrificial printer mounted in the isolator. Where are the labels
created? Where are they placed?

ID Description Type

U-LA-1
U-LA-2

3.2.7 Sampling
Clearly state all the points at which samples are taken, how they are taken, how much is
taken and from where it is taken. What happens to the sample once it is taken?
Failure to fully define sampling processes causes more isolator failures than any other factor.
Better to provide too much information than too little.
How long do results take? What happens to the sample materials while waiting for results?
 Consider non-invasive real time verification (PAT) to perform tasks required.

ID Description Type

U-SA-1
U-SA-2

3.2.8 Pass Out

How do the product, wastes, and equipment pass out? Provide size, packaging, weight and
frequency of all items to be passed out.

ID Description Type

U-PO-1
U-PO-2

3.2.9 Uptream Processing

Briefly describe what happens to product when it leaves the system described in this
document.
ID Description Type

U-UP-1
U-UP-2

4.0 User Requirement Specifications

[Suggestion: When writing User Requirements, try to begin with The user shall . . . with regards to
user needs. If a requirement needs to be written as The system shall . . . , chances are this is a
Functional Requirement because it identifies a system function. Such requirements should be
moved to the Functional Requirements Specification (FRS) document.]

NOTE: As stated above, user requirements need to focus on the user needs with the
exception of the Regulatory Section (21 CFR Part 11) that traces the regulation to system
functionality normally found in the FRS. However, since a GAMP category 1, 2, or 3
system does not require creation of an FRS, consider this document as a combined User &
Functional requirements Specification (UFRS) document. GAMP category 4 or 5 systems
may either combine requirement specifications in a similar fashion (UFRS), or if the user
and functional specifications are in separate documents, refer the FRS regulatory section
back to the URS regulatory section.
For each of the component requirement sections shown below please provide a high level
description for that section as it pertains to the busy process requirement the system will be
expected to meet or resolve. Complex systems may also include a process flow diagram. The
diagram may be placed in the respective section it is illustrating or placed as an appendix at the
end of this document. Specific descriptions for each sub category are given below.
 Requirement sections appearing in black regular font must be populated or, if not
applicable, should be retained in the document and labeled as such (N/A). Requirement
sections or subsection appearing in blue regular font are optional and can be modified or
deleted to accommodate your system.

4.1 Ergonomics and Safety

The hazard has been stated in 3.1. Hazard is the ability of the compound to produce harm in the
occupational and patient populations. This section states the requirements for safety and ergonomics.

Summarized below are the suggested criteria for performing the air sampling to validate the effectiveness
of the engineering and work practice controls.

The criteria below will be used as part of a separate PO requisition for which IH air sampling will be
performed independently to validate the effectiveness of the vendors systems.

The objective of the sampling is to verify that the system / controls maintains operators exposures below
{insert OEL} g / m3 for {insert API} during normal routine operations at {insert site} handling JNJ
compounds for the following {insert controls}.

The sampling criteria includes:

Media - 25 mm filters consistent with the validated sampling protocol

Flow Rate - 2 liters / minute

Sampler - IOM sampling head

Approved JNJ Analytical Lab

Analysis - The use of the validated analytical method for the active ingredient(s) being
assessed.

Type - Personnel breathing zone samples. For some processes and equipment area
samples may be appropriate in conjunction with the personal breathing zone samples.

Duration (sampling time) - For the duration of the task being performed under routine
situations.

Sample Quantity - At least 6 samples per task.

Investigator - The sampling will be performed under the direction of a Certified Industrial
Hygienist or a by a Qualified IH.

Sampling Documentation - The activities performed during the sampling needs to be

sufficiently documented to understand and interpret the results, preferably using the
RBEAP form.

Report - A draft report with the sampling results / conclusions needs to be prepared for
review by JNJ personnel before the report is finalized.
 Activity description A brief description of the task, activities and the controls should be
provided.

4.2 Ergonomics and Safety

4.2.1 Ergonomics
What is the occupational population characteristics, population type and size range?
Example: US Adults 5 95 percentile
If the occupational workforce includes any individuals with varying needs such as:
o Height outside the 5 95 percentile range
o Arm reach outside the 5 95 percentile range
o Frontal features (maximum weight and reach permitted) that limit arm insertion
into gloves
o Other factors affecting ergonomic performance

These should be stated in a respectful manner. A copy of any EH&S guides on weight,
reach, lift should be attached. A clause requiring an ergonomic model is required to allow
review by the stakeholders.
The vendor/ specialist (delete what does not apply) will be responsible for the construction of
a mock-up at full size and providing where possible the transfer system. The owner will
provide typical equipment to allow a full evaluation of all the operations listed in 3.2.2. The
ergonomic evaluation is to be at a location agreed by the owner.

ID Description Type

U-ER-1
U-ER-2

4.2.2 Safety
Occupational Exposure to:
o Moving parts
o Heat
o Cold
o Corrosives
o Radiation
o Etc
Describe and limited if the risk is not present in the processes there is no need to state the
limits.

ID Description Type

U-SF-1
U-SF-2
 4.2.3 Guarding
User preferences for mitigations should be stated.
o E-stops (not the isolator)
o Guards
o Light fences
o Barriers, etc

ID Description Type

U-GA-1
U-GA-2

4.3 Utility and Service Connections

4.3.1 Process Connections

User required utilities and service connections should be listed. If cut sheets of the
equipment are available a statement that all utilities shown on the data sheets are required is
sufficient. Repetition of data in more than one place can lead to errors and confusion. The
user should state the requirements needed for the user required equipment such as:
o Water(s)
o Gasses
o Vacuum
o Power
The pressures, volumes, flow rates, voltage and amperage, etc must be clearly stated.

ID Description Type

U-PCC-1
U-PCC-2

4.3.2 Process Data Connections

The user is to state what data connections are required to pass data into and out of the
system. The user is also to specify what data, if any, is required from the containment
system (such as pressure alarm, temperature, humidity, etc). Consider carefully the impact
of such data, what the parameters should be and what will be done if the parameters are
outside the limits. Resist the temptation to gather as much data as possible.

ID Description Type

U-PDC-1
U-PDC-2
 4.3.3 Process Equipment Interface with the System
The user is to state what processes should be controlled from a combined man machine
interface, if any. Certain parameters are essential to communicate to the system controller;
for instance over pressure caused by the process equipment must be addressed by the
containment system or the source shut down to prevent a failure of the containment
boundary (glove and glazing failure).

4.4 Cleaning Systems

The objectives of the cleaning regimen should be stated by the user.
ID Description Type

U-CLN-1
U-CLN-2

4.4.1 Cleaning Materials

List all cleaning materials that are likely to be used in the system. This is vital because some
cleaning materials are corrosive and will impact the selection of materials of construction.
Others represent an explosive and exposure risk.
If cleaning materials are not known then a reasonable and informed guess is required with a
statement that the cleaning materials are indicative only.

ID Description Type

U-CMA-1
U-CMA-2

4.4.2 Manual Clean

The user is to state if this is a preference and if so the key features the user wishes to be
incorporated such as:
o Drains
o Filter caps/ monofilament screens to prevent filter wetting during cleaning
o Spray wands, with manifold? Valving? Wash? Rinse? Air knife drying?

ID Description Type

U-MAC-1
U-MAC-2

4.4.3 WIP
 User feature required for a repeatable cycle for wet in place or wash in place. Features to
consider: (select appropriate equipment)
o Spray nozzles
o Spray wands
o Manifold
o Drains
o WIP skid

4.4.3.1 Waste Disposal

Where WIP, hoses and spray nozzles are used or where significant liquid waste is
generated the isolator can be equipped with a drain and valve. Tank bottom valves
are often used to allow cleaning down to the diaphragm. Liquid wastes can then be
collected in a drum or carbouy for treatment or disposal. Care is required it make
sure cross contamination does not occur and the connection to the isolator should
be cleaned and flushed. Liquid wastes can be peristatically pumped to collection.
Liquid wastes can:
Be analyzed for release to process waste treatment
Be neutralized where possible and then dumped after release into the
process waste treatment/ sewer
Be incinerated.
The best route has to be selected on a case by case basis

ID Description Type

U-WIP-1
U-WIP-2

4.4.4 CIP Full cGMP clean in place

Not readily achievable and very costly

ID Description Type

U-CIP-1
U-CIP-2

4.5 Select the Isolator System

Where the user has a definite requirement as to the type of system this should be stated in the user
requirements.

4.5.1 Isolator Environment

What pressure regimen is required? Typically negative for high hazard compounds and
positive for aseptic processes. Making systems more negative or positive does not make a
 system more secure instead it increases operator fatigue and creates high turbulence at any
penetration. Isolators have to be in control and overcome pressure transients caused by
glove movement.

ID Description Type

U-IEN-1 The isolator will be negative pressure to ambient to be protective of

the operator when handling hazardous compounds
U-IEN-2 The isolator will be positive pressure to ambient to be protective of
the product from environmental contamination
U-IEN-3 Glove inrush protection is required in the event of a breech due to
the failure of a glove.

For negative pressure applications a feature that allows the blower to ramp to full capacity
when a breach occurs can be incorporated, is often referred to as Glove Inrush. Typically
velocities in the 60 -90 fpm range are required to minimize exposure to the operator.

4.5.2 User Requirements for the Isolator Control System

The user should state the type of control required for the isolator. At their simplest, isolators
are controlled by photohelics with a simple on/off for the blowers with an adjustable set point.
This causes a continually fluctuating pressure within the isolator. Other systems have the
blower at a fixed output, as manipulations occur and filters achieve a higher and higher
pressure differential so the pressure will vary. Such control systems are only appropriate for
very simple isolators performing occasional tasks or for use with disposable flexible film
isolators.
A control system run by a dedicated logic control allows for isolator performance with a
constant set point pressure and very small deviation caused by glove manipulation. The
power to the blower varies to control pressure. The set points can be input via a pass code
and button manipulator or the parameters can be downloaded from a PC. The logic of the
controller is factory installed and is not configurable (other than setting parameters).
The final option is a PLC driven controller. PLCs can be configured and software written.
The PLC can also control or integrate with processes. The more complex the control system
the greater the risk that it will be incorrectly programmed. The controller can perform these
control functions:
o Manage the isolator to control pressure
o Manage inertization
o Manage alarm functions and indicate, record, alarm and instigate maintenance or
replacement of critical components such as filters
o Instigate, control and record pressure hold or other parametric tests

ID Description Type

U-ICS-1
 ID Description Type

U-ICS-2

4.6 Business Functional Requirements

Insert a high level description here and all Business functional requirements.

ID Description Type

U-BR-1
U-BR-2

4.7 Data Requirements

Insert a high level description here and all data requirements for the following categories.

4.7.1 Data Input Requirements

Include the specific data input requirement, which would include raw data, search and
retrieval requirements. Also, include specific requirements concerning any data import files.

4.7.2 Data Processing Requirements

Include data processing requirements and any requirements for calculations, algorithms, data
definitions and data conversions. Include mandatory, optional, user and system supplied
data field requirements. Data storage requirements shall be defined in terms of requirements
for a specific database type, data access method, retention time and archival needs.

4.7.3 Data Output Requirements

Include the data output requirements for all printout reports, export files, or raw data. Also
include names of all reports and samples. Provide requirements for data formats, calculation
results, signatory approval, sorting and filtering.

ID Description Type

U-DR-1
U-DR-2

4.8 Interface Requirements

Include a high level description and all interface requirements for the following categories.

4.8.1 Hardware Interface Requirements

 Include any hardware interface requirements. Include instruments, laboratory equipment,
network connections, external interfaces with other hardware, printers, fax machines and
other devices or peripherals.

4.8.2 Software interface Requirements

Include any software interface requirements, and include all system interfaces, such as, data
repositories.

ID Description Type

U-IR-1
U-IR-2

4.9 Control System Requirements

This section describes the user requirements associated to the system whenever controlling an
equipment operation, normally found in PLC based systems. Within this section user
requirements should address description of the sequence of operation for all operating modes,
safety and security interlocks, requirements for system operation after recovery from a power
failure or other abnormal condition, interface to other systems, etc.]

ID Description Type

U-CS-1
U-CS-2

4.10 Performance Requirements

Include a high level description here and all performance related requirements for the
following categories, which should be quantitative and unambiguous.

4.10.1 Response Time Requirements

Include the response time required by the users for all critical functions. Testable response
times are usually express as times greater than or less than a quantifiable parameter.

4.10.2 Capacity Requirements

State what the specific capacity requirements are for the system, such as, number of
customers, transactions, etc.

4.10.3 Scalability Requirements

Include the requirements for system limitations, expandability, and availability.

4.10.4 Support Requirements

Include the requirements for maintenance, level of support, local and /or remote support,
international support, support hours, and long term support.
 ID Description Type

F-PR-1
F-PR-2

4.11 Environmental Requirements

Include a high level description and all system level requirements that will be needed to
support the application for the following categories.

4.11.1 Technology Requirements

Include the requirements that specify the chosen technology architecture to be implemented.
Include the expansion and enhancement possibilities, spare capacity that the system will
require over its lifetime.

4.11.2 Mechanical Requirements

Include any mechanical requirements, such as safety valves, and custom instrumentation or
machinery.

4.11.3 Facilities Requirements

Include the environmental, facilities, and system topology requirements. Include specific
requirements that describe facilities needed, such as quantity and type of workstations and
other peripherals. Include specific requirements for each of the Development, Validation,
Production and Training environments. If there are any special needs, make sure to include
such things as requirements to maintain sterility, humidity, temperature, pressure, or storage.

Items to consider:
o Exhaust of air stream from isolator
o User material air lock (MAL) requirements and features
o User personnel air lock (PAL) pass in and pass out
o User access to equipment

ID Description Type

F-EnR-1
F-EnR-2
5.0 Regulatory Requirements
Include regulatory requirements. Include security, data integrity, validation, predicate rules and 21
CFR Part 11 requirements. Include requirements for user roles and levels of access, network
security, and system access control, logical and physical access. Data Integrity and Part 11
requirements include interface security, error handling, audit trails, data migration and change
control. In addition, both technical and procedural control requirements for Part 11 validation shall
be included. The sample requirements provided below cover all aspects of the Part 11 regulation.
Some of the requirements may not be applicable to this system, such as, electronic signatures. For
all other part 11 requirements that cannot be met from a technological standpoint by the systems
capabilities, a procedural solution will be required. Requirements in black regular font should be
considered boiler plate and must appear in your requirements document. Requirements in blue
italics can be considered optional depending on your system.
.

5.1 Security Requirements

5.1.1 Logical Security Requirements

Include any safety and security related requirements, such as access restrictions, role-based
security, time-out, and input value checking. The password requirements provided below
cover both the Part 11 regulation and J&J policy requirements.

5.1.1.1 Passwords
ID Description Type

U-PW-1 Passwords in the system must not consist of easily guessed or

commonly used words found in dictionaries (English and Non-
English), such as user ids or names easily associated with the
individual user (dates, nicknames and family names).
U-PW-2 Passwords/PINs must not consist of easily guessed words
preceded and/or followed by one or more numbers or a special
character. (For example, Daniel!, $Robert, $$stew, 1walt2,
ivy123, 321bob, and 4shannon are not acceptable).
U-PW-3 Passwords and PINs must comply with the complexity
requirements. Passwords/PINS must contain characters from
least three (3) of the following four classes:
Class Description

1. English Upper Case Letters: A B C Z

2. English Lower Case Letters: a b c z

3. Westernized Arabic Numerals: 0 1 2 9

4. Non-alphanumeric
(special characters, punctuation, symbols):
{}[],.<>;:?/\!@#$%^*()-_=+
 ID Description Type
The system will require the user to change their password
U-PW-4
every 90 days and allow the user to change passwords at will.
The system will set a minimum time between user-initiated
U-PW-5
password/PIN changes must be at least 1 day.
Passwords must be locked out after 45 days of inactivity.
U-PW-6
The system will prevent the last 5 passwords from being
U-PW-7
reused.
The system shall require passwords to have at least 8
U-PW-8
characters, including at least one numeric and one alpha.
The system shall prevent a duplicate user ID from being
U-PW-9
created.
U-PW-10 The system shall hide the password in order to maintain
confidentiality while the user is entering his/her password in the
system.
U-PW-11 Passwords must not be blank
U-PW-12 There must be a mechanism by which only the Application
Security Administrator has access to reset a password, i.e.
employee forgot their password.
U-PW-13 The system shall utilize password protected screen savers to
prevent access when the system is unattended for a specified
length of time.
U-PW-14 The system shall enforce that the user will be logged out after
15 minutes of inactivity.

5.1.1.2 User Ids

ID Description Type
System must restrict user to a single logon.
U-ID-1
The System must not allow the use of Guest accounts.
U-ID-2
There must be a mechanism in place that requires written
U-ID-3
authorization prior to the creation of a User ID.
There must be a mechanism in place to notify the Application
U-ID-4
Security Administer of terminations of employment or changes in
access.
System must require User IDs to be unique; User IDs may never
U-ID-5
be reused.
At time of production, an SOP shall be in place describing the
U-ID-6
system security, including: Procedure for granting access to new
users.

The system should allow automatic detection of security

U-ID-7
violations and production of an alarm or warning message.

The system must log a user off after a defined period of inactivity.
U-ID-8
 5.1.1.3 Logical Security Other
ID Description Type
The system shall be placed behind the corporate firewall or
U-SO-1
incorporate firewall software or other methods for protection from
the internet.
Before production, the System Owner will ensure that a Security
U-SO-2
SOP is developed and made effective. The SOP will include
physical and logical security (as applicable: application security,
network security, access authorization, creating new accounts,
modifying accounts, deleting/disabling accounts, periodic
checking of access and approval by the System Owner or
designee).
The system shall utilize anti-virus software that is updated
U-SO-3
regularly to prevent viruses corrupting data.
The system shall have the capability to only accept input data or
U-SO-4
instructions from specified input devices.

5.1.2 Physical Security Requirements

5.1.2.1 Physical
ID Description Type
The Server room must be secured.
U-PS-1
Access to the computer room must be restricted to authorized
U-PS-2
personnel and controlled by card access.
The workstation must have an anti-theft device.
U-PS-3

5.2 Electronic Records

Include Part 11 Electronic Record requirements for the system not covered in previous
sections.

ID Description Type
The system shall be able to detect invalid records that contain
U-ER-1
invalid field entries.
The system shall be able to detect invalid records that contain
U-ER-2
blank fields that should contain data.
The system shall be able to detect invalid records that contain
U-ER-3
out-of-bound values.
The system shall display the entire contents of the electronic
U-ER-4
 ID Description Type
record.
The system shall have the ability to print the entire contents of the
U-ER-5
electronic record.
The system shall retain the meaning and content of electronic,
U-ER-6
printed, or copied records.
The system shall have the capability to extract electronic records
U-ER-7
in an electronic format that can be read by a regulatory agency.
The system shall have the capability to exclude confidential
U-ER-8
annotations attached to an electronic record before supplying an
electronic copy to the regulatory agency.
The system will not allow steps to be bypassed.
U-ER-9
If applicable, the system will enforce a sequence of steps or
U-ER-10
events.
If applicable, the system will only allow data input from specified
U-ER-11
terminals or instruments at specified locations.

5.3 Audit Trail Requirements

Include any addition audit trail requirements.

ID Description Type
The system must have a secure, computer generated, time
U-AT-1
stamped, audit trail that independently records the date and time
of operator entries, actions that create, modify, and delete
electronic records and the reason for the change.
The system must have an audit trail that is protected from
U-AT-2
intentional or accidental modifications.
The system will be able to record a change to an electronic
U-AT-3
record, and the previously recorded information is not obscured
by the change.
The electronic records audit trail is retrievable throughout the
U-AT-4
records retention period.
The system must be able to produce the audit trail in read only
U-AT-5
electronic format and can be printed in human readable format.
Any one individual user or administrator, must not have the
U-AT-6
capability to disable the systems audit trail.
The systems audit trail must be impossible to disable without
U-AT-7
detection.
Before going into production the system must have clearly
U-AT-8
defined retention periods for electronic and meta data.
The systems audit trail will capture e-signatures and associated
U-AT-9
time, date and meaning of change.
5.4 Handwritten Signature Requirements
If this is a hybrid system, include any requirements in addition to those stated below in the
table.

ID Description Type
The system shall link handwritten signatures to their electronic
U-HS-1
record counterpart via a unique version numbering schema.
Prior to production deployment, procedures will indicate how the
U-HS-2
paper copy is assured to be a complete and accurate copy of the
electronic record, the process for signing and maintaining the
paper copy, and the method for protecting the electronic record
from any future modification.
The system shall prompt for re-signatures for new versions of the
U-HS-3
changed electronic record.
The system shall not obscure any information in a signed or
U-HS-4
previously signed version of an electronic record.

5.5 Electronic Signatures Requirements

If this system has e-signature capability incorporate the requirements from the table below.
Specific e-signature technologies will be covered in subsequent tables.

5.5.1 Electronic Signatures - General

ID Description Type
System users shall be responsible for understanding the meaning
U-ES-1
and significance of electronic signatures in the system, for
certifying that their electronic signature is equivalent to their
handwritten signature, and for understanding and complying with
the security mechanisms designed into the system procedures
related to Electronic Signatures.
The system shall automatically insert the electronic signature
U-ES-2
information, including full user name, date, time, and reason for
signature after each electronic signature event.
The system shall ensure that the source and format of the date
U-ES-3
and time are defined, controlled, unambiguous, and protected
from unauthorized change.
The system shall ensure the user selects the reason for the
U-ES-4
signature as approve or reject.

The system shall display the electronic signature information (full

U-ES-5
printed name, date, time, and signature meaning) related to the
report on-screen and on the printout of the report.
 ID Description Type
The system shall ensure that the electronic signatures are linked
U-ES-6
via technology, not procedures, to their corresponding electronic
records to ensure that the signature cannot be excised, copied, or
otherwise transferred to falsify an electronic record by ordinary
means.
The system shall detect a modification made to a previously
U-ES-7
signed electronic record and prompt the user to resign the record.

The system shall retain electronic signatures in the report for as

U-ES-8
long as the report to which the signature applies is maintained.

Procedures shall be established to control the issuance,

U-ES-9
replacement, and termination of electronic signature privileges
including the verification of the users identity and to ensure that
only its genuine owner knows the password component of the
electronic signature.
The system shall prevent unauthorized individuals from signing
U-ES-10
electronically on behalf of another.
The system shall ensure that a reason for signing is designated.
U-ES-11
The system shall lockout a user account after five failed
U-ES-12
password electronic signature attempts within a 770 minute (12
hour) time period.
If applicable, the system will enforce a specified sequence of
U-ES-13
steps or events before allowing the insertion of an electronic
signature.
If applicable, the system must require specified data to be
U-ES-14
entered before allowing approval via an electronic signature.

5.5.2 Non-Biometric E-signatures

If this system employs non-biometric (commonly: user id & password) e-signature
technology, incorporate the following requirements into your document.

ID Description Type
The electronic signature component for each user of the system
U-ES-15
will be made up of the unique user identification code and
password.
Single continuous e-signature session signings will utilize both
U-ES-16
components of the users e-signature for the initial session and
the users private password component for subsequent signings
[please define the period of continuous use here or as a separate
requirement in this section].
 ID Description Type
The system shall not allow an electronic signatures combination
U-ES-17
of a user ID and password components to be duplicated for use
by another individual.
The systems password file must be encrypted so that passwords
U-ES-18
cannot be viewed by ordinary means.

5.5.3 Non-Biometric E-signatures with Tokens

In addition to the previous table of requirements, if this system employs non-biometric e-
signature with token technology, incorporate the following requirements into your document.

ID Description Type
Prior to production, procedures will be implemented directing
U-ES-19
action to be taken to electronically deactivate lost, stolen,
missing, or otherwise potentially compromised tokens, cards, and
other devices used to carry or generate electronic signature
components.
Prior to production, procedures will be implemented for managing
U-ES-20
and controlling temporary or permanent token / card
replacements.
Prior to production, procedures will be implemented covering the
U-ES-21
initial and periodic testing of devices, such as tokens or cards,
that bear or generate identification code or password information.
Prior to production, procedures will be implemented to conduct
U-ES-22
testing on devices to include checks for proper functioning,
performance degradation, and detection of unauthorized
alterations.

5.5.4 Biometric E-signatures

Explanation: The characteristics of a persons hand-written signature. The pen pressure and duration of
the signing process, which is done on a digital-based pen tablet, is recorded as an algorithm that is
compared against future signatures.

If this system employs biometric e-signature technology, incorporate the following

requirement from the table below.

ID Description Type
The system shall be designed to ensure that electronic signatures
U-ES-23
based on biometrics can only be used by their genuine owners.
5.6 Backup, Recovery, Archive, Restore Requirements
Include all backup, recovery, archive, and restore requirements, such as, data recovery,
redundancy, and recovery from system failures.

ID Description Type
Prior to production, an SOP shall be developed to establish
U-BR-1
procedures for Backup, Recovery, Archive and Restore.
The system shall be backed up on a regular basis, including full
U-BR-2
system backup, incremental backup, weekly, and monthly of all
electronic records including meta data (audit trail records).
A copy of all system backups shall be stored off site.
U-BR-3
The system shall have the capability to archive electronic data,
U-BR-4
including meta data (audit trails).
The system shall have the capability to restore electronic data,
U-BR-5
including meta data (audit trail) within a 24-hour period.
Prior to production, a system contingency plan will be in place.
U-BR-6
The contingency plan shall be reviewed on a regular basis.
U-BR-7
The contingency plan will be tested.
U-BR-8

5.7 Training Requirements

Include specific training and qualification requirements. Specify what requirements exist
relating to training of users: how many users, length of training, availability of users,
language in which conducted, geared to what level(s) of users and user roles, and any
additional related training that may be required.

ID Description Type
The training department shall maintain records for system training
U-TR-1
of all business areas involved in systems development,
maintenance, administration, or use.
Documentation will be maintained to show that persons
U-TR-2
(employees, temporary and contractors) who develop the system
have the education, training, and experience to perform their
assigned tasks.
Documentation will be maintained to show that persons
U-TR-3
(employees, temporary and contractors) who maintain the system
have the education, training, and experience to perform their
assigned tasks.
Documentation will be maintained to show that persons
U-TR-4
(employees, temporary and contractors) who use the system
have the education, training, and experience to perform their
assigned tasks.
Training manuals will be developed.
U-TR-5
 5.8 Documentation Requirements
Include the system specific documentation requirements here.

ID Description Type
The distribution of, access to, and use of the systems operation
U-DR-1
and maintenance documentation will be controlled.
The systems old documentation will be retrieved or withdrawn
U-DR-2
when new versions are issued.
One copy of each of the systems superceded documentation will
U-DR-3
be maintained for future reference.
Access to all system documentation deemed sensitive in nature
U-DR-4
will be restricted to authorized persons in accordance with their
job duties.
System documentation will be under formal revision and change
U-DR-5
control procedures to maintain an audit trail that documents time-
sequenced development and modification of systems
documentation.
All systems documentation will contain revision history and be
U-DR-6
version controlled.
System documentation will be maintained in One Source, which
U-DR-7
maintains an audit trail of changes.

6.0 Other Requirements

Include any other requirements not included in any of the previous categories.

ID Description Type

U-OR-1
U-OR-2

7.0 Assumptions, Expectations, Restrictions and Limitations

[This section describes any assumptions, expectations, restrictions, and limitations of the system.
Non-testable expectations should be listed here. Assumptions such as other activities to be
performed or use of any special tools should be mentioned here.]

END OF CONTENT
 History of Change

Version Change Control Section Reason for Revision

Number Number (Description of Change)
 Template History of Change

Version Change Control Section Reason for Revision

Number Number (Description of Change)

1.0 N/A All New template

2.0 CR-3774 All Change of authorship and a complete revision of
all sections.

Delete this page