User & Functional Requirements

Company Name Here
Cary, North Carolina
User and Functional Requirements

Specifications
System Name: System Name and Version Number
Prepared By:
Name: ____________________________________________________ Date: ______________

Issue Number: 1.1 CONFIDENTIAL Page 1 of 26
Author, Title
Department

User and Functional Requirements Specifications
System Name and Version Number Cary, North Carolina
/// THIS PAGE MUST BE DELETED BEFORE PUBLICATION
The purpose of this template is to assist in the interpretation, application, and preparation of the User
and Functional Requirements Specifications according to Schering-Plough Research Institute’s
(SPRI) standard operating procedures relating to validating software applications.
 Paragraphs in blue italics font style are meant to serve as instructions to the Author and should
be deleted in the final document.
 Paragraphs in black regular font style are sample wording that may be used as is or modified
as needed. Should a paragraph not be applicable, delete it from the document altogether.
 Text in GRAY shading contains a field code, and will NOT automatically update.
1. First, to assure that on your computer variable fields will display as gray in templates,
select Tools from the menu and then Options from the drop down list. On the View tab,
change the setting for Field Shading to display “Always”, by selecting it from the drop
down list. Click OK. (Note: these gray fields will not be shaded when printing the
document.)
2. To change values associated with fields, select File from the menu and then Properties
from the drop down list. Select the value in either the Summary tab or the Custom tab
and change the value. For the Custom tab, then press the Modify button.
3. To update the Table of Contents and all data displayed in field codes within the
completed document, click on Edit / Select All from the menu and then press F9; select
“Update Entire Table” and click OK.
 Text in <BRACKETS> should be replaced with the appropriate information by the Author. ///

Approvals
The individuals below agree that they have reviewed and approved the scope of the effort described in
this User and Functional Requirements Specifications (URS-FRS) for System Name and Version
Number, by signing this section. The User and Functional Requirements Specifications will be a
“living” document and will serve as the primary means of communicating project change with regard to
functionality. The signatures below represent the approval for the acceptance of the User and
Functional Requirements Specifications (URS-FRS) and acceptance by PHARMASYS?? management
representing both the user community and the implementation team.
Approval Signatures
APPROVED BY:
Function Name Signature Date
Title, Department Name
Compliance/VQC/Validation
Name
Manager/Leader
Title, System Owner Name

Revision History
Issue # Date Person Change

1.0 12/14/2006 Nicholas Ryan Document Creation

TABLE OF CONTENTS
1 Introduction..................................................................................................................................................7
1.1 Project Background.............................................................................................................................7
1.2 Summary of the User and Functional Requirements Specifications.....................................................7
1.2.1 Expected Benefits................................................................................................................................8
1.2.2 Consequences of Business Activities Failure.......................................................................................8
1.2.3 Recommendations...............................................................................................................................8
2 Purpose & Scope.........................................................................................................................................8
2.1 Goals & Objectives..............................................................................................................................8
3 Assumptions, Exclusions and Limitations.................................................................................................9
4 Abbreviations and Acronyms.....................................................................................................................9
5 Reference Documents...............................................................................................................................10
6 Requirements Specification......................................................................................................................11
6.1 Business Requirements......................................................................................................................11
6.1.1 Business Activities (Internal & External)...........................................................................................11
6.1.2 Functional Description.......................................................................................................................12
6.1.3 Outputs (Reports)..............................................................................................................................12
6.1.4 Implementation Constraints...............................................................................................................12
6.2 Data Requirements.............................................................................................................................13
6.2.1 Inputs ............................................................................................................................................13
6.2.2 Data Requirements (New or Existing System Integration)................................................................13
6.2.3 Data Migration...................................................................................................................................14
6.3 Performance Requirements................................................................................................................14
6.4 Environmental Requirements.............................................................................................................15
6.4.1 Facilities Requirements.....................................................................................................................15
6.4.2 Technology Requirements.................................................................................................................15
6.4.3 System Topology...............................................................................................................................16
6.4.4 Mechanical Requirements..................................................................................................................16
6.4.5 Special Equipment Requirements......................................................................................................17
6.5 Security Requirements.......................................................................................................................17
6.5.1 Passwords..........................................................................................................................................18
6.5.2 User ID / Authentication Controls.....................................................................................................19
6.5.3 Internal Software Controls.................................................................................................................20
6.5.4 Software COTS (Commercial Off the Shelf).....................................................................................21
6.5.5 Hardware...........................................................................................................................................21
6.5.6 Desktop / Laptop Dial-Up Controls...................................................................................................22
6.5.7 Physical Security...............................................................................................................................22
6.6 Audit Trail Requirements...................................................................................................................22
6.7 Documentation Requirements............................................................................................................22
6.8 Maintenance Requirements................................................................................................................23
6.9 Back-up, Restore and Archiving........................................................................................................23
6.9.1 Archiving...........................................................................................................................................23

6.9.2 System Backup & Contingency.........................................................................................................23

6.9.3 Business Activities Interfaces............................................................................................................24
6.10 Other Requirements...........................................................................................................................25
7 Traceability Matrix.....................................................................................................................................25

1 Introduction
The User and Functional Requirements Specifications (URS-FRS) documents the business and
functional requirements of the System Name and Version Number system to be deployed. This is
intended to be a living document. The requirements detailed in this URS-FRS document provide the
definition of the System Name and Version Number from a user perspective: this includes the
functional, security, data integrity, and performance capabilities that the System Name and Version
Number must provide, in order to meet the business needs of users in the Department (Dept.)
department at Company Name Here. The URS-FRS will also provide additional information to expand
the project plan for realistic tasks, dates and resources.
1.1 Project Background

/// Briefly describe the system’s goals, objectives, and regulatory requirements.
Mention if this system is an upgrade of a previous version or a new installation. What is the
future status and effective date of the system / planned roll-out?
Describe if it is a purchased product, what customization has been added on.
Some of the words would be similar to those found in the beginning of the Validation Strategy
Document (VSD). ///
This System Name and Version Number is designed to /// qualify, quantify, collect, record…
what data? /// The complete system includes <_______>.
/// If applicable, include: /// The conceptual process flow of the system is found in section
<_____> below.
1.2 Summary of the User and Functional Requirements Specifications

The purpose of this URS-FRS document is to define the requirements of the System Name and
Version Number, <purchased and customized for and by/developed for use within> the Schering-
Plough Research Institute and to be utilized by the department(s)/division(s) of <_________> at
the following location(s): <_________>.
/// Summarize the contents of the document and provide a very brief description of the system’s
subsystems, their operations, and interaction. Highlight any major discrepancy or specific focus
that is specific to this system. ///

1.2.1 Expected Benefits

/// Discuss any relevant impact statements, management issues and
considerations, the applicable business unit service levels for technical support,
system uptime, etc. Provide all necessary information here that database
personnel may require. ///
1.2.2 Consequences of Business Activities Failure

/// Discuss any business activity problems. Document potential risks. Discuss
what would be the consequences to the business community or to the individual
user, should the application fail in part or in its entirety (temporary glitch or
catastrophic failure event). ///
1.2.3 Recommendations
/// Discuss any recommendations regarding the technology or applications to be
used. Delete this section, if N/A. ///
2 Purpose & Scope

This section addresses the objectives of the URS-FRS and its structure. Included in this section are the
scope of work, the users’ naming convention, applicable standards, and assumptions.
2.1 Goals & Objectives

The objectives of the URS-FRS are to collect and organize in writing a baseline of the user
(business) and functional requirements of the system. All testing which follows will relate back
to this URS-FRS to demonstrate that the completed design of the system does in fact consider
and is proven to meet and satisfy all such requirements, as specified by the business user and the
technical community that will be associated with it.
3 Assumptions, Exclusions and Limitations

/// Describe the specific assumptions, limitation and exclusions applicable to the validation of this
system (for example, that all hardware and software was functioning correctly, that certain activities
occurred prior to testing (e.g. levels of access were correctly set up, etc.)).

List the software products, components, modules, interfaces, or functions that were excluded from
testing (e.g. functions not utilized by the users, etc.) Provide rationale for each, as to why testing was
not performed. ///
Assumptions governing the URS-FRS of the System Name and Version Number system are as follows:
/// Assumptions - Describe the specific assumptions that were applicable to the validation of this
system. Some examples of assumptions are:
 Users targeted to create requirements have an appropriate level of computer and functional
literacy ///
Exclusions that apply to the URS-FRS of the System Name and Version Number system are as follows:
/// Exclusions - List the software products, components, modules, interfaces, or functions that were
excluded from testing conducted within the confines of this study. Provide rationale for each, as to why
testing was not performed. An example of an exclusion is:
 Requirements designated for future releases are not included in this document. ///
Limitations that apply to the URS-FRS of the System Name and Version Number system are as
follows:
/// Limitations - Describe any limitations, which were applicable (perhaps relating to the platform,
versioning, etc.). Describe the risks that were inherent, if any. Describe the critical success factors
relating to the application, as applicable. Some examples of limitations are:
 Any errors that require manual workarounds identified in previous testing.
 List any workarounds that are known and required at this stage. ///
4 Abbreviations and Acronyms

Refer to Dept. SOP ///600.011 - Glossary/// and Standard SPRI-05 - Validation of Computer Systems for
standardized departmental terminology. Below is a list of terms and acronyms specific to this project.
/// Add other terms, abbreviations, acronyms and definitions as applicable to specific document being
prepared. Delete the table, if no terms are added. ///

Term /
Acronym Definition
Abbreviation
<TERM> <XXX> <DEFINITION>
A more comprehensive list of applicable abbreviations and acronyms can be found in the Validation
Strategy Document (VSD).
5 Reference Documents
The current revisions of the documents listed below have been consulted in the preparation of this
specification document or govern the content of this document.
/// Do not repeat documents already identified in the VSD. If the VSD is not written yet, then you may
reference them, such as:
 Internal SOPs which govern this URS-FRS or relate to the system
 List the applicable process flows/guidelines that relate to this system. IMPORTANT: Only
reference those that reflect current business practice.
 Vendor-supplied documentation
 RFP
 Other ///
/// For each listed reference, include the document number, full title, version/revision number, effective
date, issuing department, and type of document: ///
Document Issue
Document Title Effective Date Document Type
Number Number
SPRI-05 Validation of Computer Systems April 1, 2002 SPRI, Standard
Corporate Policy
Part 11 Electronic Records; Electronic Signatures August 27, 1997 US CFR, Regulation
6 Requirements Specification
/// In this Requirements section, define the business needs of the typical user in a clear and precise
way. Outline what major tasks the user expects the system to accomplish and any external interfaces

that are required of the system. Describe what legacy system, if any, is being replaced and what
method/phases would be required for phasing out the old, in the new. ///
/// The detailed requirements are uniquely identified with a Requirement Number (Requirement # or
Req. #, comprised of a sequential number prefaced by an alphanumeric identifier, which represents the
Description Category of the applicable business requirement, as suggested in the table below.)
NOTE: The numbering system is a suggestion and may be modified to suit the needs of the Author.
An alternative method may be 4.4.7.1, 4.4.7.2, 4.4.7.3, etc. ///
Requirement Description Category

Number
RS-1 Enhanced Business Processes

RS-2 Systems Interface
RS-3 Data Migration
RS-4 Systems Integration
RS-5 Data Management and Access
RS-6 Code Management
RS-7 Compliance (Predicate Rules and Part 11 Compliance)
RS-8 Application Performance
6.1 Business Requirements
6.1.1 Business Activities (Internal & External)

/// Briefly describe the daily activities of the business user. What is the role the
user is expected to fill? Define logical business activities. As applicable, develop
a process decomposition diagram. ///
Requirement # Description
RS-BA-1
RS-BA-2
6.1.2 Functional Description

/// Describe the functional role/purpose of the system as part of the overall daily
user activities. How does the system assist the user? Then provide a detailed

description of the functional requirements of the system from a technical

viewpoint. ///
RS-FD-1
RS-FD-2
6.1.2.1 Processing (Algorithms)

/// Describe any critical, essential calculations, which the system uses
to process its data. ///
6.1.3 Outputs (Reports)

/// List and describe all printout reports or export files generated by the System Name
and Version Number. ///
RS-OR-1
RS-OR-1
6.1.4 Implementation Constraints

/// Determine and discuss what system constraints would apply in implementation
of the system:
 Time constraints, deadline for rollout.
 Cost constraints
 IT/technology constraints (equipment, support, software readiness, etc.)
 Resource constraints
 Any changes affecting the project scope, schedule, quality, or costs are
subject to the change management process and formal approval.
 Constraints between existing systems.
 Number of users, their locations (spread out over wide-ranging locations)
 Users not having the correct operating system installed

 Speed of modem in dial-up and download
 Training issues
 Phase-in issues that would/could impact business activities ///
6.2 Data Requirements

/// Discuss the raw data that will comprise the input to the system and whether it is imported
from another application. Include approximate typical and worst case size of file, frequency,
delimiters, and any other limitations or constraints on the data format. State if any context-
sensitive keys are required.
Develop and include, as applicable: ///
RS-DA-1 Logical entity relationship diagram

RS-DA-2 Logical data flow diagram
6.2.1 Inputs
/// Describe the raw data and the format it is received in by the System Name and
Version Number. ///
RS-IN-1
RS-IN-2
6.2.2 Data Requirements (New or Existing System Integration)

/// Provide a description or diagram of the data flow between the System Name and
Version Number and other Schering-Plough databases (IN and OUT). ///
RS-DR-1 Unique file names shall be utilized.

RS-DR-2
6.2.3 Data Migration

/// Explain what data migration requirements exist or what problems may be expected.

Mention compatibility of databases/versions (if applicable), etc.

Identify any regulatory issues surrounding migration of data.
Define alternative methods for conversion, if any.
Estimate conversion cost. ///
RS-DM-1
RS-DM-2
6.3 Performance Requirements

/// State what specific performance criteria exist, which are measurable and testable, such as: ///
RS-PR-1 Response time (for example be downloaded via laptop in less than 3 minutes)
RS-PR-2 Logical data flow diagram
RS-PR-3 Availability
RS-PR-4 Processing Speed
RS-PR-5 Stress
RS-PR-6 Peak load/volume/number of users
RS-PR-7 Ease of use
RS-PR-5 Accuracy of calculations
RS-PR-8 Database size & replication constrains
/// NOTE: Ensure that all requirements listed are testable/measurable. ///
6.4 Environmental Requirements

/// Identify, as they apply, or are known: ///
RS-ER-1 Hardware platform(s)

RS-ER-2 Server(s)
RS-ER-3 Database(s)
RS-ER-4 Physical locations for all of the above (control room, city, building, etc.)

RS-ER-5 Platform(s) users will use

RS-ER-6 Physical location(s) of users (departments)
RS-ER-7 Compatibility of what other applications need be on the same platform
RS-ER-8 Required air conditioning power supply and rating
RS-ER-9 Effluent discharge into the environment
RS-ER-10 Special filters as needed
6.4.1 Facilities Requirements

/// List any special requirements that may be required to install and implement the
System Name and Version Number. Include items, such as: ///
RS-FR-1 Conditioned power supplies

RS-FR-2 Additional bench/room space
RS-FR-3 Load on HVAC system, water or sewage
RS-FR-4 Special or additional electrical wiring required
6.4.2 Technology Requirements

/// Define the technology required meeting the business and functional
requirements of the System Name and Version Number. Include: ///
RS-TR-1 Technology architecture

RS-TR-2 I/O devices
RS-TR-3 Computer platform (required vs. desired)
RS-FR-4 Networking requirements
RS-FR-5 Environmental requirements (temperature-controlled room, etc.)
///If a vendor and specific software has already been selected, the technology
requirements would as specified by the vendor, with possible modifications, as
agreed to and allowed by the application. ///

6.4.3 System Topology

/// How many environments do you need. Identify all, which may include testing,
training, production, development, production support, security, or any others that
may be needed. ///
RS-ST-1 Testing Environment

RS-ST-2 Training Environment
RS-ST-3 Development Environment
RS-ST-4 Production Environment
RS-ST-5 Security Environment
6.4.4 Mechanical Requirements

/// Define the mechanical requirements for the system, such as:
RS-MR-1 Special tools or fixtures (safety valves, etc.)

RS-MR-2 Custom machinery
6.4.4.1 Control Software Requirements

/// Describe any requirements for control software (for example: control
modules or equipment which will be programmed for specific input or
output levels, user-programmable software to control special functions,
etc.) ///
6.4.5 Special Equipment Requirements

/// Identify: ///
RS-SE-1 Workstations (quantity, type), which are needed.

RS-SE-2 Custom machinery that is not commercially available but required as
part of the project.
RS-SE-3 Special equipment that may be needed (isolation booths for PC in
clean rooms)

6.5 Security Requirements

The System Name and Version Number system must function under Schering-Plough Research
Institute’s security associated with the system platform and incorporated application security, as
specified by the system administrator.
/// State how many secure accounts will be required, the CRUD types of user roles, and with
what level of access. Indicate which local or network security is required, if proxy servers are
used and, if software is installed locally, if a firewall or other protection is required.
Discuss the platform’s and application’s security approach.
Address the logical and physical access to hardware. ///
/// Address the following, as they apply: ///
RS-SR-1 Software access

RS-SR-2 File protection
RS-SR-3 Physical security requirements
RS-SR-4 System access control
RS-SR-5 Operator safety controls
RS-SR-6 Some screens are only read-only
RS-SR-7 Certain screens be accessible to only certain levels of security access
6.5.1 Passwords
RS-PW-1 Passwords have a Mix of Alpha and Numeric Characters:

Passwords should be required to contain a unique mixture of alpha
and numeric characters, such that passwords cannot be easily guessed
by another user.
RS -PW-2 Retained Password History:
Passwords can never be reused. (Verify against Corporate Policy)
RS -PW-3 Password entry cannot be Visible:
Password entry must be masked.

RS -PW-4 Inactivity of Password:

Passwords must be locked out after 90 days of inactivity.
RS -PW-5 Password Aging:
System must support the ability to force passwords to be changed
after a number of days, while also providing the ability to change the
password at will.
RS -PW-6 Discrete Distribution of User Passwords:
There must be a mechanism for discrete distribution of user
passwords.
RS -PW-7 Notification Process for Change User ID Status:
There must be a mechanism for deactivation of User ID upon change
in status, i.e. termination.
RS -PW-8 Restriction On Commonly Used Passwords:
The system must support a mechanism to disable use of commonly
used passwords, such that passwords cannot be easily guessed by
another user.
RS -PW-9 Blank Passwords Are Not Permitted:
Passwords must not be blank.
RS -PW-10 Enforced Minimum Password Length:
Passwords should be restricted to contain at least 5 characters.
RS -PW-11 Password Resets Verified by Application Security Administrator:
There must be a mechanism by which only the Application Security
Administrator has access to reset a password, i.e. employee forgot
their password.
6.5.2 User ID / Authentication Controls
RS -ID-1 Multiple Logons Not Permitted:

System must restrict user to a single logon.
RS -ID-2 User Accounts Disabled after 3 Consecutive Tries:
System must disable password after 3 consecutive invalid attempts at
logging on.
RS -ID-3 Inactivity Timeout on User ID After X Number of Minutes:

The system must support the ability to lock the User ID after x
number of minutes of inactivity, by requiring that the user re-enter
their password to continue operation.
RS -ID-4 Guest Account Protected or Deleted:
Guest accounts must be protected from use or deleted.
RS -ID-5 Written Authorization for the Creation of User ID’s:
There must be a mechanism in place that requires written
authorization prior to the creation of a User ID.
RS -ID-6 Notification Process for Change User ID Status:
There must be a mechanism in place to notify the Application
Security Administer of terminations of employment or changes in
access.
RS -ID-7 Unique User ID/Account Supplied:
System must require User ID’s to be unique; User ID’s may never be
reused.
/// If none were generated specifically for this system/project, be sure to reference the
SPRI internal document/departmental SOP that govern such changes. Internal audits
shall verify that such policies are followed. ///
6.5.2.1 Auditing
RS -AU-1 Invalid Attempts are logged and maintained &

Reviewed:
The system must keep a log of invalid attempts at access
to the system, and this log must be reviewed on a regular
basis.
RS -AU-2 Audit Trail on Password History:
System must keep a log of used and in use passwords.
RS -AU-3 Audit Trail of Backend Changes & Review:
There must be a log of backend changes, and this log must
be reviewed.
RS -AU-4 Audit Trail for Failed Attempts:
The system must keep a log of failed attempts at access to

the system..
RS -AU-5 Audit Trail for Tracking Attempts to Access
Unauthorized System resources or Sensitive
Information:
The system must keep a log of attempts to access
unauthorized system resources or sensitive information.
RS -AU-6 Monitoring of Operating System or Application
Changes:
There must be a mechanism for monitoring the operating
system and/or application changes made to the system.
RS -AU-7 Change Control Process Documented and in Place:
There must be a documented Change Control Process in
place for changes to hardware, system software, and/or
application software..
6.5.3 Internal Software Controls
RS -IC-1 User Menu Restrictions:

There must be the ability to restrict access to menu items by either
individual users and/or user groups.
RS -IC-2 Fields that are not editable:
System must provide the ability designate certain fields as read-only.
RS -IC-3 Time Restrictions for Access:
System must provide the ability to restrict access to the system based
on time either hourly, daily, or monthly.
RS -IC-4 Version Control:
The system and individual files must be version controlled.
RS -IC-5 User Classification of Data
RS -IC-6 Digital Certificates
6.5.4 Software COTS (Commercial Off the Shelf)
RS -SC-1 Contractor/Vendor Familiar with SP Security Policy

RS -SC-2 Vendor Updates/Installations Documented

RS -SC-3 Source Code Provided:

Source Code must be provided or an escrow agreement must be in
place.
RS -SC-4 Vendor Software Security Changed from Defaults & Configured to
Operate Securely in SP Environment
RS -SC-5 Configured to Operate Securely in SP Environment
RS -SC-6 Contractor/Vendor Read and Signed Non-Disclosure Agreement
6.5.5 Hardware
RS -HW-1 Power On Password Enabled – Desktop/Laptop

RS -HW-2 Screen Saver Password Enabled
RS -HW-3 Laptop Encryption – HDD Data Encrypted
RS -HW-4 Data of Greatest Sensitivity must be Encrypted
RS -HW-5 Desktop Acting as a Server
6.5.6 Desktop / Laptop Dial-Up Controls
RS -DC-1 Data Transfer Encrypted Over Phone Lines

RS -DC-2 3rd Party Software (PC Anywhere Secured)
RS -DC-3 Personal Firewall or Security Software Enabled
RS -DC-4 Workstation Activity Auditing – NT Security Auditing
6.5.7 Physical Security
RS -PS-1 Server Room Secured

RS -PS-2 Workstation has Anti-Theft Devices
RS -PS-3 Controlled Access to Computer Room
/// Refer to existing departmental, RIS and SPRI SOPs, and work instructions,
which define the procedures for controlling accounts and passwords (relating to

uniqueness, deactivation when a person leaves the company, procedures for

reactivation upon rehire, etc.) ///
6.6 Audit Trail Requirements

An audit trail will be required, to satisfy the regulatory requirements defined in 21 CFR Part 11.
Each change and deletion should be traceable to the responsible individual, as well as a date and
time stamp.
/// Describe which ones are required and how they will be verified. ///
RS-SR-1 Audit Trails (System Level)

RS-SR-2 Identify metadata requirements
6.7 Documentation Requirements

/// List what user documentation is required. Discuss vendor documents vs. customized in-house
documentation, specific to each user, explanation of business flow, etc. ///
RS-DR-1 Training Manuals

RS-DR-2 Foldout of keyboard shortcuts
RS-DR-3 User Manuals
6.8 Maintenance Requirements
RS-MN-1 Contracts (External / Internal)

RS-MN-2 Routine (Scheduled)
6.9 Back-up, Restore and Archiving
6.9.1 Archiving
/// Provide detailed requirements of the system relating to:

RS -AR-1 Archiving of files (procedure and frequency)

RS -AR-2 Back-up of the database (procedure and frequency)
RS -AR-3 Restore procedures
6.9.2 System Backup & Contingency
RS-BC-1 Backups are Completed Regularly:

RS-BC-2 Backup Frequency includes Full System Backup, Incremental
Backup, Weekly, and Monthly:
RS-BC-3 Backups Stored Securely Off Site:
RS-BC-4 Contingency Plan in Place:
RS-BC-5 Contingency Plan Updated Regularly:
RS-BC-6 Contingency Plan Tested:
6.9.3 Business Activities Interfaces

/// Describe the internal and external interfaces and the flow of the system for the
typical user. Briefly outline: ///
RS-BI-1 What platform the user will be using (laptop dial-up or desktop,
PC/Macintosh, Windows 95, Win NT, etc.)
RS-BI-2 Where the data will be coming from, via what input, what format, and
from what group
RS-BI-3 Frequency of use (daily, monthly, etc.) and how long of a download
expected
RS-BI-4 What data would be transferred/exported and to where
RS-BI-5 What files require being stored
RS-BI-6 What reports will be generated
RS-BI-7 What compatibility issues are expected
RS-BI-8 The nature of the support that is required (such as help desk: 24-hour
support or multilingual)
/// Provide a diagram describing process dependency.

As feasible, include diagrams that detail internal and external activity

interfaces. ///
6.9.3.1 External Interfaces

/// Specify which external interfaces will control the performance of the
system or the input/output data it manipulates or generates. ///
6.9.3.2 User Interfaces

/// Describe specific user interfaces required by the system, such as
special function keys, web page/links, etc. ///
6.9.3.3 Hardware Interfaces

/// List in detail what hardware interfaces will the System Name and
Version Number require, such as printers, fax machine, bar code
scanner, etc. ///
6.9.3.4 Software Interfaces

/// List what other systems/applications will the System Name and
Version Number interface with and provide details. ///
6.10 Other Requirements

/// List any other requirements which are needed, that were not mentioned anywhere else in this
document. ///
RS-OR-1
RS-OR-2
RS-OR-3
7 Traceability Matrix
As part of the SPRI validation effort, a Traceability Matrix will be compiled. The purpose of the
matrix, in the format of the table displayed below, is to provide testing coverage for the system being
validated, by cross-referencing the requirements (Requirement Number from the URS-FRS) to the test
steps executed as part of IQ/OQ or PQ/UAT (Test Script ID).

/// Fill in the table below, including all detailed functions that are required of the specific system:
input, output, processing, intricate details, screens, relating to the flow of the application, etc. ///
Test
Requirement
# Description Script Test Script Title
Number
ID
1
2
3
4
5
6
/// NOTES:
The Requirement Number column indicates the unique identifier for the specific requirement described
in the Description column.
The Requirement Number and Test Script ID columns are required. ///
/// This matrix may be included either here, as part of the Test Plan/UAT Test Scripts, the Validation
Summary Report (VSR), or just referenced in any of these documents and saved as a separate
document as part of the validation package. Mention here, which is the case for the validation of this
system. ///

User & Functional Requirements

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

User & Functional Requirements

Diunggah oleh

Hak Cipta:

Format Tersedia

Company Name Here

Cary, North Carolina

User and Functional Requirements

System Name: System Name and Version Number

Name: ____________________________________________________ Date: ______________

Issue Number: 1.1 CONFIDENTIAL Page 2 of 26

/// THIS PAGE MUST BE DELETED BEFORE PUBLICATION

Issue Number: 1.1 CONFIDENTIAL Page 3 of 26

Title, Department Name

Title, System Owner Name

Issue Number: 1.1 CONFIDENTIAL Page 4 of 26

Issue # Date Person Change

Issue Number: 1.1 CONFIDENTIAL Page 5 of 26

Issue Number: 1.1 CONFIDENTIAL Page 6 of 26

6.9.2 System Backup & Contingency.........................................................................................................23

Issue Number: 1.1 CONFIDENTIAL Page 7 of 26

1.1 Project Background

1.2 Summary of the User and Functional Requirements Specifications

Issue Number: 1.1 CONFIDENTIAL Page 8 of 26

1.2.1 Expected Benefits

1.2.2 Consequences of Business Activities Failure

2 Purpose & Scope

2.1 Goals & Objectives

3 Assumptions, Exclusions and Limitations

Issue Number: 1.1 CONFIDENTIAL Page 9 of 26

 Any errors that require manual workarounds identified in previous testing.

4 Abbreviations and Acronyms

Issue Number: 1.1 CONFIDENTIAL Page 10 of 26

 Internal SOPs which govern this URS-FRS or relate to the system

Issue Number: 1.1 CONFIDENTIAL Page 11 of 26

Requirement Description Category

RS-1 Enhanced Business Processes

6.1 Business Requirements

6.1.1 Business Activities (Internal & External)

6.1.2 Functional Description

Issue Number: 1.1 CONFIDENTIAL Page 12 of 26

description of the functional requirements of the system from a technical

6.1.2.1 Processing (Algorithms)

6.1.3 Outputs (Reports)

6.1.4 Implementation Constraints

 Time constraints, deadline for rollout.

 IT/technology constraints (equipment, support, software readiness, etc.)

 Constraints between existing systems.

 Number of users, their locations (spread out over wide-ranging locations)

 Users not having the correct operating system installed

Issue Number: 1.1 CONFIDENTIAL Page 13 of 26

 Speed of modem in dial-up and download

 Phase-in issues that would/could impact business activities ///

6.2 Data Requirements

RS-DA-1 Logical entity relationship diagram

6.2.2 Data Requirements (New or Existing System Integration)

RS-DR-1 Unique file names shall be utilized.

6.2.3 Data Migration

Issue Number: 1.1 CONFIDENTIAL Page 14 of 26

Mention compatibility of databases/versions (if applicable), etc.

6.3 Performance Requirements

6.4 Environmental Requirements

RS-ER-1 Hardware platform(s)

Issue Number: 1.1 CONFIDENTIAL Page 15 of 26

RS-ER-5 Platform(s) users will use

6.4.1 Facilities Requirements

RS-FR-1 Conditioned power supplies

6.4.2 Technology Requirements

Name: ______________________________________ Date: