Académique Documents
Professionnel Documents
Culture Documents
Prepared By:
Name: ____________________________________________________
Author, Title
Department
Issue Number: 1.1
CONFIDENTIAL
Date: ______________
Page 1 of 26
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 Institutes
(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. ///
CONFIDENTIAL
Page 2 of 26
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
Title, Department
Name
Compliance/VQC/Validation
Manager/Leader
Name
Name
CONFIDENTIAL
Signature
Date
Page 3 of 26
Revision History
Issue #
Date
1.0
12/14/2006
Person
Nicholas Ryan
Change
Document Creation
CONFIDENTIAL
Page 4 of 26
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
Reference Documents...............................................................................................................................10
Requirements Specification......................................................................................................................11
6.1 Business Requirements......................................................................................................................11
6.1.1
6.1.2
6.1.3
6.1.4
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
6.4
Performance Requirements................................................................................................................14
Environmental Requirements.............................................................................................................15
6.4.1
6.4.2
6.4.3
6.4.4
6.4.5
6.5
Security Requirements.......................................................................................................................17
6.5.1
6.5.2
6.5.3
6.5.4
6.5.5
6.5.6
6.5.7
6.6
6.7
6.8
6.9
Facilities Requirements.....................................................................................................................15
Technology Requirements.................................................................................................................15
System Topology...............................................................................................................................16
Mechanical Requirements..................................................................................................................16
Special Equipment Requirements......................................................................................................17
Passwords..........................................................................................................................................18
User ID / Authentication Controls.....................................................................................................19
Internal Software Controls.................................................................................................................20
Software COTS (Commercial Off the Shelf).....................................................................................21
Hardware...........................................................................................................................................21
Desktop / Laptop Dial-Up Controls...................................................................................................22
Physical Security...............................................................................................................................22
CONFIDENTIAL
Page 5 of 26
Traceability Matrix...................................................................................................................................25
CONFIDENTIAL
Page 6 of 26
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 systems 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
CONFIDENTIAL
Page 7 of 26
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
1.2.3
Recommendations
/// Discuss any recommendations regarding the technology or applications to be
used. Delete this section, if N/A. ///
CONFIDENTIAL
Page 8 of 26
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:
List any workarounds that are known and required at this stage. ///
CONFIDENTIAL
Page 9 of 26
Term /
Abbreviation
<TERM>
Acronym
<XXX>
Definition
<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:
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
Number
SPRI-05
Document Title
Issue
Number
Effective Date
Document Type
April 1, 2002
SPRI, Standard
US CFR, Regulation
Corporate Policy
Part 11
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
CONFIDENTIAL
Page 10 of 26
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
Number
6.1
6.1.1
Description Category
RS-1
RS-2
Systems Interface
RS-3
Data Migration
RS-4
Systems Integration
RS-5
RS-6
Code Management
RS-7
RS-8
Application Performance
Business Requirements
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
CONFIDENTIAL
Page 11 of 26
Description
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. ///
Requirement #
Description
RS-OR-1
RS-OR-1
6.1.4
Implementation Constraints
/// Determine and discuss what system constraints would apply in implementation
of the system:
Cost constraints
Resource constraints
Any changes affecting the project scope, schedule, quality, or costs are
subject to the change management process and formal approval.
Page 12 of 26
6.2
Training issues
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 contextsensitive keys are required.
Develop and include, as applicable: ///
Requirement #
6.2.1
Description
RS-DA-1
RS-DA-2
Inputs
/// Describe the raw data and the format it is received in by the System Name and
Version Number. ///
Requirement #
Description
RS-IN-1
RS-IN-2
6.2.2
Description
Unique file names shall be utilized.
RS-DR-2
CONFIDENTIAL
Page 13 of 26
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. ///
Requirement #
Description
RS-DM-1
RS-DM-2
6.3
Performance Requirements
/// State what specific performance criteria exist, which are measurable and testable, such as: ///
Requirement #
Description
RS-PR-1
Response time (for example be downloaded via laptop in less than 3 minutes)
RS-PR-2
RS-PR-3
Availability
RS-PR-4
Processing Speed
RS-PR-5
Stress
RS-PR-6
RS-PR-7
Ease of use
RS-PR-5
Accuracy of calculations
RS-PR-8
/// NOTE: Ensure that all requirements listed are testable/measurable. ///
6.4
Environmental Requirements
/// Identify, as they apply, or are known: ///
Requirement #
Description
RS-ER-1
Hardware platform(s)
RS-ER-2
Server(s)
CONFIDENTIAL
Page 14 of 26
Requirement #
6.4.1
Description
RS-ER-3
Database(s)
RS-ER-4
Physical locations for all of the above (control room, city, building, etc.)
RS-ER-5
RS-ER-6
RS-ER-7
RS-ER-8
RS-ER-9
RS-ER-10
Facilities Requirements
/// List any special requirements that may be required to install and implement the
System Name and Version Number. Include items, such as: ///
Requirement #
6.4.2
Description
RS-FR-1
RS-FR-2
RS-FR-3
RS-FR-4
Technology Requirements
/// Define the technology required meeting the business and functional
requirements of the System Name and Version Number. Include: ///
Requirement #
Description
RS-TR-1
Technology architecture
RS-TR-2
I/O devices
RS-TR-3
RS-FR-4
Networking requirements
RS-FR-5
CONFIDENTIAL
Page 15 of 26
///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. ///
Requirement #
6.4.4
Description
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
Mechanical Requirements
/// Define the mechanical requirements for the system, such as:
Requirement #
Description
RS-MR-1
RS-MR-2
Custom machinery
6.4.4.1
6.4.5
CONFIDENTIAL
Page 16 of 26
Requirement #
6.5
Description
RS-SE-1
RS-SE-2
RS-SE-3
Security Requirements
The System Name and Version Number system must function under Schering-Plough Research
Institutes 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 platforms and applications security approach.
Address the logical and physical access to hardware. ///
/// Address the following, as they apply: ///
Requirement #
Description
RS-SR-1
Software access
RS-SR-2
File protection
RS-SR-3
RS-SR-4
RS-SR-5
RS-SR-6
RS-SR-7
CONFIDENTIAL
Page 17 of 26
6.5.1
Passwords
Requirement #
RS-PW-1
Description
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
RS -PW-3
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
RS -PW-7
RS -PW-8
RS -PW-9
RS -PW-10
RS -PW-11
CONFIDENTIAL
Page 18 of 26
6.5.2
Description
Multiple Logons Not Permitted:
System must restrict user to a single logon.
RS -ID-2
RS -ID-3
RS -ID-4
RS -ID-5
RS -ID-6
RS -ID-7
/// 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. ///
CONFIDENTIAL
Page 19 of 26
6.5.2.1
Auditing
Requirement #
RS -AU-1
Description
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
RS -AU-3
RS -AU-4
RS -AU-5
RS -AU-6
RS -AU-7
6.5.3
Description
User Menu Restrictions:
There must be the ability to restrict access to menu items by either
individual users and/or user groups.
CONFIDENTIAL
Page 20 of 26
Requirement #
RS -IC-2
Description
Fields that are not editable:
System must provide the ability designate certain fields as read-only.
RS -IC-3
RS -IC-4
Version Control:
The system and individual files must be version controlled.
6.5.4
RS -IC-5
RS -IC-6
Digital Certificates
Description
RS -SC-1
RS -SC-2
RS -SC-3
6.5.5
RS -SC-4
RS -SC-5
RS -SC-6
Hardware
Requirement #
Description
RS -HW-1
RS -HW-2
RS -HW-3
RS -HW-4
RS -HW-5
CONFIDENTIAL
Page 21 of 26
6.5.6
6.5.7
Description
RS -DC-1
RS -DC-2
RS -DC-3
RS -DC-4
Physical Security
Requirement #
Description
RS -PS-1
RS -PS-2
RS -PS-3
/// 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
6.7
Description
RS-SR-1
RS-SR-2
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. ///
CONFIDENTIAL
Page 22 of 26
Requirement #
6.8
Description
RS-DR-1
Training Manuals
RS-DR-2
RS-DR-3
User Manuals
Maintenance Requirements
Requirement #
6.9
6.9.1
Description
RS-MN-1
RS-MN-2
Routine (Scheduled)
6.9.2
Description
RS -AR-1
RS -AR-2
RS -AR-3
Restore procedures
Description
RS-BC-1
RS-BC-2
RS-BC-3
RS-BC-4
RS-BC-5
RS-BC-6
CONFIDENTIAL
Page 23 of 26
6.9.3
Description
RS-BI-1
RS-BI-2
Where the data will be coming from, via what input, what format, and
from what group
RS-BI-3
RS-BI-4
RS-BI-5
RS-BI-6
RS-BI-7
RS-BI-8
The nature of the support that is required (such as help desk: 24-hour
support or multilingual)
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. ///
CONFIDENTIAL
Page 24 of 26
6.9.3.4
Software Interfaces
/// List what other systems/applications will the System Name and
Version Number interface with and provide details. ///
Description
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. ///
#
Description
Test
Requirement
Script
Number
ID
1
2
3
4
5
6
CONFIDENTIAL
Page 25 of 26
/// 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. ///
CONFIDENTIAL
Page 26 of 26