PT Hal 1 dari 13

Page of

< computerized system>

User Requirements Specification
DocID: <Doc ID>

User Requirements Specification

Date: Signature:
Author:

<name and surname>

System Owner

Approval:

<name and surname>

Department Head

<name and surname>

Engineering Head (If its related with equipment)

<name and surname>

e-Compliance Manager

<name and surname>

IT Head

<name and surname>

HSE representative (in case of HSE relevance)
Document history:

Version Date Author Comments

1.0 First version for approval
PT Hal 2 dari 13
Page of

< computerized system>

User Requirements Specification
DocID: <Doc ID>

Table of Contents

1 INTRODUCTION....................................................................................................................................... 3
2 OVERALL DESCRIPTION......................................................................................................................... 3
2.1 BUSINESS PROCESS <NAME>............................................................................................................... 3
2.1.1 Business Process Model............................................................................................................. 3
3 BUSINESS REQUIREMENTS................................................................................................................... 4
4 REGULATORY REQUIREMENTS............................................................................................................ 5
4.1 REGULATORY REQUIREMENTS FOR E-RECORD SYSTEMS.....................................................................5
4.2 REGULATORY REQUIREMENTS FOR E-SIGNATURE SYSTEMS..............................................................10
4.3 OVERVIEW OF REGULATED RECORDS.................................................ERROR! BOOKMARK NOT DEFINED.
5 DATA REQUIREMENTS..............................................................ERROR! BOOKMARK NOT DEFINED.
6 INTERFACE REQUIREMENTS....................................................ERROR! BOOKMARK NOT DEFINED.
7 USER ACCOUNT ROLE REQUIREMENTS.................................ERROR! BOOKMARK NOT DEFINED.
8 INFRASTRUCTURE REQUIREMENTS.......................................ERROR! BOOKMARK NOT DEFINED.
9 SERVICE LEVEL REQUIREMENTS............................................ERROR! BOOKMARK NOT DEFINED.
10 REFERENCES / GLOSSARY.......................................................ERROR! BOOKMARK NOT DEFINED.
11 APPENDIX....................................................................................ERROR! BOOKMARK NOT DEFINED.
PT Hal 3 dari 13
Page of

< computerized system>

User Requirements Specification
DocID: <Doc ID>

1 Introduction
The User Requirements Specification (URS) describes in lay terms what the system should do. It also
describes the data, interface, security, performance and hardware requirements, which provide a complete
and comprehensive description of the requirements for the system. This set of requirements will be used for
the vendor selection process. This set of requirements will be used as a foundation for the Functional and
Design Specifications.

2 Overall Description
This section of the User Requirements Specification describes the general factors that affect the system and
its requirements. This section does not state specific requirements. Instead, it provides a background for
those requirements, which are defined in detail in Section 3, and makes them easier to understand. Business
(sub) processes which are analyzed in more detail in the subsections bellow are identified in this section.

2.1 Business Process <Name>

This section defines the business process the system will support. This section can be as detailed as
needed, splitting business processes into individual sub processes, etc.

Business process participants:

Business process input:

Business process output:

Business process description:

2.1.1 Business Process Model

Modeling business processes is optional

Basic shapes that could be used in the activity diagram.

Example:
PT Hal 4 dari 13
Page of

< computerized system>

User Requirements Specification
DocID: <Doc ID>

3 Business Requirements
This section of the User Requirements Specification contains all of the business requirements of the system.
These requirements are written at a level of detail sufficient to enable designers to design a system that will
satisfy those requirements and testers to test that the system satisfies those requirements. When writing
requirements, remember to use clear and complete language and avoid ambiguity and jargon. Determine the
criticality of the requirements. Indicate which requirements have regulatory impact (e.g. GxP, SOX, Data
Privacy etc.). Optionally CTQ “Critical to Quality” could also be added as reference.

URS ID Requirements Business

Criticality*
URS-B-01

* E – Essential
I – Important
D – Desired
PT Hal 5 dari 13
Page of

< computerized system>

User Requirements Specification
DocID: <Doc ID>

4 Regulatory Requirements
Regulatory Requirements are to be identified and added. The requirements identified under these sections
must be comprehensive to address both system and regulatory needs. It is acceptable for requirements
identified in this section to be incorporated into other sections of User and Functional Requirements.

URS ID Requirements Regulatory

Reference
URS-R-01
URS-R-02

4.1 Regulatory Requirements for e-RECORD systems

URS ID 21CFR11 Requirement Description Y/N Ref. to Comment

Ref. other
URS ID
URS-ER- § 11.10 (a) The CS must be able to identify changes to
01 electronic records in order to detect invalid or
altered records. (If this requirement cannot be
satisfied by system functionality then a
procedure shall be defined, with a manual
process to track changes to records.)
URS-ER- § 11.10 (b) The CS must either support the viewing of e-
02 records or the generation of valid paper copies.
The CS should provide viewing & printing
capabilities for all relevant e-records. In certain
cases, controlled database queries or accurately
performed screen dumps may satisfy this
requirement.
URS-ER-03  § 11.10 (b) The CS should allow for the export of e-records     Recommende
               to portable file formats, preferably automatically. d formats are:
Common/
The file format(s) chosen is: _____ global XML
standards,
ANDI, PDF,
SGML.
URS-ER- § 11.10 (c) If the retention strategy does not include keeping     Recommende
04               the e-records in the originating system, the CS d formats are:
  should have implemented a mechanism to PDF,
archive e-records in a standard file format. Common/
global XML
The file format(s) for archiving is: ____ standards,
ANDI).
URS- ER - § 11.10 (c) Preferably e-records should be archived to write-      
05               protected media (Write-once Read-many media
            like WORM tape media or optical media) or
archiving solutions with WORM type safeguards
should be used.
URS-ER- § 11.10 (c) If automated archiving is put into practice,      
06               transaction safeguards should prevent the e-
            records in the source system from deletion until
confirmation that they have been successfully
archived.
URS-ER- § 11.10 (d) If the CS is accessed trough workstations which      
07               bear more than one application, the application
            must have its own security layer (e.g. application
specific User ID / password versus workstation
“power-up” User Id & password).
PT Hal 6 dari 13
Page of

< computerized system>

User Requirements Specification
DocID: <Doc ID>

URS ID 21CFR11 Requirement Description Y/N Ref. to Comment

Ref. other
URS ID
URS-ER- § 11.10 (d) Ensure that the CS has a security mechanism      
08               that uses at least two distinct identification
            components (e.g. User ID / password, PKI
mechanisms) or biometrics.

The applied security mechanism is: ____

URS-ER- § 11.10 (d) The CS must allow for the use of individual     Note:
09               accounts, shared accounts for access levels Password
            other than read are not acceptable. used in
conjunction
with individual
User IDs shall
not be shared.
URS-ER- § 11.10 (d) The CS should provide a mechanism to lock out/      
10               interrupt access of any user after a configurable
            period of non-attendance/ non-interaction with
the system (recommendation: 15 minutes at a
maximum). Password protected screensavers
are acceptable means to fulfil this requirement
provided that the security mechanisms of the
application are not compromised.
URS-ER- § 11.10 (d) The implementation of the lock out process     Recommendati
11               should be well investigated in regard to safety on: Purchase
         needs. Access to safety relevant functions & CS with safety
operations must always be possible and should relevant
be given priority. functions and
operations
detached from
general system
security
mechanisms.
URS-ER- § 11.10 (d) If technically possible passwords must be stored      
12               in the CS in encrypted form. In case were
         encryption of passwords is not possible, the
file(s) containing passwords and user-Ids must
be secured by technical means and their access
strictly controlled (no read option for any user,
SOP/strict instruction for administrators about
password file handling, password file not
accessible for users).
URS-ER- § 11.10 (d) When password entry fields are shown on the      
13               screen, password entries must be obscured (e.g.
         "*********").
URS-ER- § 11.10 (d) The system should allow for quality passwords     Refer to ISEC
14               (at least 8 alphanumeric characters) and enforce Key Directive
         their use. 02
URS-ER- § 11.10 (d) Transaction safeguards as specified in URS-ES-      
15               17, URS-ES-18 and URS-ES-19 should be
         implemented.
URS-ER- § 11.10 (e) If the CS provides for secured, computer-      
16               generated audit trails for e-records, they must be
         enabled.
PT Hal 7 dari 13
Page of

< computerized system>

User Requirements Specification
DocID: <Doc ID>

URS ID 21CFR11 Requirement Description Y/N Ref. to Comment

Ref. other
URS ID
URS-ER- § 11.10 (e) Whenever traceability must be guaranteed for      
17               records which
         - are subject to frequent manipulations or
- could become modified and have a direct
impact on drug product quality and safety,
check that the CS has the ability to generate
secured audit trails.
URS-ER- § 11.10 (e) Computer generated audit trails should contain      
18               information about:
         - person/ equipment performing the activity
(WHO)
- date and time of its execution (WHEN)
- (WHAT) was changed/ done
URS-ER- § 11.10 (e) Computer generated audit trails should contain      
19               information about:
         - the reason for the activity (WHY) if appropriate

URS-ER- § 11.10 (e) Audit trails must be built using an unique      

20               identifier to trace “WHO did it” (preferably the
         unique User ID).
URS-ER- § 11.10 (e) Computer generated audit trails should at least      
21               record the hour and minute and must be as
         precise as required by the business process (e.g.
to verify correct sequencing of events).

Time stamps must record: _____

URS-ER- § 11.10 (e) The server time should be used for the      
22               generation of time stamps.
        
URS-ER- § 11.10 (e) Time & date settings should be subject to      
23               rigorous control to ensure the accuracy of time
         stamps, the CS should provide the ability to
restrict access to time settings. Users should not
be able to change time & date settings.
URS-ER- § 11.10 (e) CS spanning multiple time zones should be able      
24               to display & print the time zone used with the
         time stamp.
URS-ER- § 11.10 (e) The CS should have a mechanism to prevent      
25               that changes to e-records obscure or destroy the
         original recorded information. Secured
references/ pointers from computer generated
audit trails to the original recorded information
are acceptable.
URS-ER- § 11.10 (e) If audit trail information are not part of the record      
26               itself, the CS must implement mechanisms to
         establish a secured link between audit trail & the
respective record.
URS-ER- § 11.10 (e) The ability to change computer generated audit     Note: There
27               trails must be restricted to a minimum number of might be
         individuals and to duly authorized personal. exceptional
cases, where the
Audit trails should only be changeable by the
alteration of
following role: _____ computer
generated audit
trails is
unavoidable
(e.g. due to
technical issues
PT Hal 8 dari 13
Page of

< computerized system>

User Requirements Specification
DocID: <Doc ID>

URS ID 21CFR11 Requirement Description Y/N Ref. to Comment

Ref. other
URS ID
like database
corruptions). In
such cases,
modifications
must occur in a
controlled way,
according to
established
change control
procedures.
URS-ER- § 11.10 (e) The CS should provide viewing & printing      
28               capabilities for all relevant audit trails.
         It is recommended to purchase CS, which have
implemented search tools, data filter and / or
report functions for the audit trail to support its
review.
URS-ER- § 11.10 (f) If the adherence to certain sequences is critical     Note: The critical
29               to the proper conduct of the process, the CS sequences are
         should support operational system checks to defined in
sections 3 and 4.
enforce the execution of operations according to
the predefined order.
URS-ER- § 11.10 (g) The CS should apply authority checks to ensure     Note: If an
30               that only authorized individuals can appropriate role
         - make use of system functions & features and access
concept is
- electronically sign a record
already defined
- create, modify, inactivate/ logically delete, in another
delete records section of this
- access input and/ or output devices document,
- perform operations at hand. please
Authority checks should be implemented by role reference. If not,
based access. please specify
within this
requirement.

URS-ER- § 11.10 (g) Records may be linked to an authorization code     See remark to
31               that identifies the title or organizational unit of URS-E-29
         those individuals who are allowed to modify and/
or sign records. Based on this authorization
code, the CS should provide or reject access to
records/ e-signature functions.
URS-ER- § 11.10 (g) The CS should enforce record specific access     See remark to
32               rights (e.g. only the originator of a record is URS-E-29
         allowed to modify it) whenever the business
process asks for such controls.
This can be achieved by maintaining a list of
those records, an individual is allowed to modify/
sign. Before access to a record is provided for an
individual, the CS should check if this record is
part of the individual’s list.

URS-ER- § 11.10 (g) Records which are automatically captured by a      

33               CS (e.g. process data …) must not be modified.
         The CS should provide mechanisms that prevent
users -except system administrators- from
having access other than “read” to such records.
If the CS lacks such controls, computer-
generated audit trails must be implemented.
PT Hal 9 dari 13
Page of

< computerized system>

User Requirements Specification
DocID: <Doc ID>

URS ID 21CFR11 Requirement Description Y/N Ref. to Comment

Ref. other
URS ID
URS-ER- § 11.10 (h) In cases where the physical identity of a HW      
34               item/ device/ equipment is relevant, the CS
         should check the identity of such devices.
The physical identity of the following HW items /
devices / equipments are relevant:

URS-ER- § 11.10 (h) When it is critical to the proper conduct of the      

35               process that specific HW items / devices /
         equipments (e.g. shop floor terminals, barcode
readers) create, submit or modify records, there
should be reporting & alarm features (prompts,
flags, or other help features) in place to ensure
consistency of records and to alert the user of
records being out of acceptable range.
URS-ER- § 11.10 (h) The CS should not have a mechanism to      
36               complete empty data fields within a record
         without the opportunity for the user to review
them. (i.e Features that enter automatically
information into a field when the field is by-
passed should not be used.)
URS-ER- § 11.10 (i) There must be a determination that persons who
37               develop, maintain, or use electronic
         record/electronic signature systems have the
education, training, and experience to perform
their assigned tasks. (All administrators and
users must have documented training for the
system).
URS-ER- § 11.10 (j) There must be the establishment of and
38               adherence to written policies that hold individuals
         accountable and responsible for actions initiated
under their electronic signatures in order to deter
record and signature falsification.
URS-ER- § 11.10 (k) There must be appropriate controls over the
39               system documentation including: 1) Adequate
        controls over the distribution of, access to and
use of documentation for system operation and
maintenance. 2) Revision and change control
procedures to maintain an audit trail that
documents time-sequenced development and
modification of systems documentation.
URS-ER- § 11.30 Where the CS is ‘open’, ensure that all required      
40               security measures as defined with the ISECO
         are employed (e.g. when emailing files ensure
that encryption technology is in use where
required). See also section 5.1.1”Security and
Privacy”. It is recommended to use PKI.
PT Hal 10 dari 13
Page of

< computerized system>

User Requirements Specification
DocID: <Doc ID>

4.2 Regulatory Requirements for e-SIGNATURE systems

URS ID 21CFR11 Requirement Description Y/N Ref. to Comment

Ref. other
URS ID
URS-ES-01  § 11.50 (a) Ensure that all users are uniquely identifiable in      
                  the CS. Where the User ID is not the user’s full
name, ensure it is traceable to the user’s full
name.
This does not impact the requirement that signed
records used for GxP purposes must display the
full name (at least name & surname) of the
signer.
URS-ES- § 11.50 (a) The CS must record/ link
02               - the unique identifier of the person executing the
  signature
- the date & time of the signature
- the meaning of a signature (e.g. approval;
review) for / to each signature event. Ideally, e-
signatures should be applied directly to records.
Alternatively, separate e-signature records are
allowable if they are unambiguously linked with
the record to which they apply.
URS-ES- § 11.50 (a) The CS should allow for pre-programming of      
03               signature meanings (e.g. via configurable
       picklists), if this makes a good business sense,
e.g. in case of predictable and/ or recurrent
signature meanings (e.g. approval / rejection of
documents).
URS-ES- § 11.50 (a) Where pre-programming of meanings for      
04               signatures appears to be not useful, implement
      free text comments associated with the
signature.
URS-ES- § 11.50 (b) Whenever a signed record is required to be used      
05               for GxP purposes, ensure that the full name (at
        least name & surname) of the signer, date and
time of the application of the signature and
meaning of the signature are displayed.
URS-ES-  N/A Whenever a signed record is required to be used      
06               for GxP purposes, ensure that the full name (at
         least name & surname) of the signer, date and
time of the application of the signature and
meaning of the signature are printed.
URS-ES- § 11.50 (b) E-Signature information, links to the signed     Note: There
07               records and the signed information must not be may be
          alterable for individuals involved in the business exceptional
process. cases, where
the alteration
of signature
information,
the links to the
signed record
or the signed
information is
unavoidable
(e.g. technical
data migration
issues). In
such cases,
modifications
must occur in a
PT Hal 11 dari 13
Page of

< computerized system>

User Requirements Specification
DocID: <Doc ID>

URS ID 21CFR11 Requirement Description Y/N Ref. to Comment

Ref. other
URS ID
controlled way,
according to
established
change control
procedures.
URS-ES- § 11.70 The system must be designed such that e-      
08 signature information including links are saved
as read-only data and cannot be excised, copied
or transferred to falsify e-records.
It is recommended to purchase CS, which have
implemented or have plans to implement
technical link mechanisms such as hash
functions.
URS-ES- § 11.100 (a) The CS must not accept duplicate user accounts.      
09              
 
URS-ES- § 11.200 (a) CS must be designed to require two components      
10               for the execution of the first e- signature within a
  session (e.g. User ID & password). One of these
components must be private and shall not be
shared with other individuals.
URS-ES- § 11.200 (a) The CS should be designed to require the private      
11 component for the execution of subsequent
signings within a session.
URS-ES- § 11.200 (a) To facilitate work, it is allowed that the CS pre-      
12 populates automatically the user identification
information (also for the first signature).
URS-ES- § 11.200 (b) CS using electronic signatures based on      
13              biometrics must provide mechanisms that
prevent from bypassing the biometric controls.
URS-ES- § 11.300 (b) The CS should support password-aging      
14              processes (prompts for password renewal after
60 calendar days).
URS-ES- § 11.300 (b) The CS should allow for configuration of the      
15        password aging parameter.
URS-ES- § 11.300 (b) The setting of the password aging parameter      
16 should be limited to duly authorized personnel
only.
URS-ES- § 11.300 (d) Check that the system is able to lock an user  Y  NA  NA
17  account after a specified number of failed access
attempts (preferred option: 3 unsuccessful
attempts until log out).
URS-ES- § 11.300 (d) The CS should be able to log unauthorized  Y  NA  NA
18        access attempts.
URS-ES- § 11.300 (d) Preferably the CS should be able to detect      
19        potential misuse (e.g. log out of users) and notify
the responsible individual.
PT Hal 12 dari 13
Page of

< computerized system>

User Requirements Specification
DocID: <Doc ID>

4.3 Overview of Regulated Records

Identify the regulated records.

Record Regulation Retention Period

Example: batch records GxP 7 years

5 Data Requirements
This section captures data requirements such as source/target databases, transformational rules, extent of
conversion/migration, data integrity, and archive requirements. Determine the criticality of the requirements.
Indicate which requirements have regulatory impact (e.g. GxP, SOX, Data Privacy etc.). Optionally CTQ
“Critical to Quality” could also be added as reference..

URS ID Requirements Business

Criticality*
URS-D-01
URS-D-02
* E – Essential
I – Important
D – Desired

6 Interface Requirements
This section captures interface requirements such as user interfaces, application interfaces, database
interfaces, and equipment interfaces. Determine the criticality of the requirements. Indicate which
requirements have regulatory impact (e.g. GxP, SOX, Data Privacy etc.). Optionally CTQ “Critical to Quality”
could also be added as reference.

URS ID Requirements Business

Criticality*
URS-I-01
URS-I-02
* E – Essential
I – Important
D – Desired

7 User Account Role Requirements

This section captures requirements related to user roles and access rights. Determine the criticality of the
requirements. Indicate which requirements have regulatory impact (e.g. GxP, SOX, Data Privacy etc.).
Optionally CTQ “Critical to Quality” could also be added as reference.

URS ID Requirements Business

Criticality*
URS-A-01
URS-A-02
* E – Essential
I – Important
D – Desired
PT Hal 13 dari 13
Page of

< computerized system>

User Requirements Specification
DocID: <Doc ID>

8 Infrastructure Requirements
This section captures infrastructure requirements such as memory storage, performance requirements,
backup requirements, installation requirements etc. Determine the criticality of the requirements. Optionally
CTQ “Critical to Quality” could also be added as reference.

URS ID Requirements Business

Criticality*
URS-H-01
URS-H-02
* E – Essential
I – Important
D – Desired

9 References / Glossary
Define references and terms used in the document.

10 Appendix.