User and Functional Requirements Specifications
[pic]
Company Name Here
Cary, North Carolina
User and Functional Requirements Specifications
System Name: System Name and Version Number
Prepared By:
Name: Date:
Author, Title
Department
/// 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 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 Manager/Leader |Name | | |
|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
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 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.
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, 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 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. ///
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). ///
3 Recommendations
/// Discuss any recommendations regarding the technology or applications to be used. Delete this section, if N/A. ///
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.
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.
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. ///
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 / Abbreviation |Acronym |Definition |
| | | |
| | | |
A more comprehensive list of applicable abbreviations and acronyms can be found in the Validation Strategy Document (VSD).
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 Number |Document Title |Issue Number |Effective Date |Document Type |
|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 |
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 |
1 Business Requirements
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 | |
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. ///
|Requirement # |Description |
|RS-FD-1 | |
|RS-FD-2 | |
1 Processing (Algorithms)
/// Describe any critical, essential calculations, which the system uses to process its data. ///
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 | |
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 ///
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: ///
|Requirement # |Description |
|RS-DA-1 |Logical entity relationship diagram |
|RS-DA-2 |Logical data flow diagram |
1 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 | |
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). ///
|Requirement # |Description |
|RS-DR-1 |Unique file names shall be utilized. |
|RS-DR-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 | |
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 |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. ///
4 Environmental Requirements
/// Identify, as they apply, or are known: ///
|Requirement # |Description |
|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 |
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: ///
|Requirement # |Description |
|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 |
2 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 |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. ///
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 # |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 |
4 Mechanical Requirements
/// Define the mechanical requirements for the system, such as:
|Requirement # |Description |
|RS-MR-1 |Special tools or fixtures (safety valves, etc.) |
|RS-MR-2 |Custom machinery |
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.) ///
5 Special Equipment Requirements
/// Identify: ///
|Requirement # |Description |
|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) |
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: ///
|Requirement # |Description |
|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 |
1 Passwords
|Requirement # |Description |
|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. |
2 User ID / Authentication Controls
|Requirement # |Description |
|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. ///
1 Auditing
|Requirement # |Description |
|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.. |
3 Internal Software Controls
|Requirement # |Description |
|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 |
4 Software COTS (Commercial Off the Shelf)
|Requirement # |Description |
|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 |
5 Hardware
|Requirement # |Description |
|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 Desktop / Laptop Dial-Up Controls
|Requirement # |Description |
|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 |
7 Physical Security
|Requirement # |Description |
|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 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. ///
|Requirement # |Description |
|RS-SR-1 |Audit Trails (System Level) |
|RS-SR-2 |Identify metadata requirements |
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. ///
|Requirement # |Description |
|RS-DR-1 |Training Manuals |
|RS-DR-2 |Foldout of keyboard shortcuts |
|RS-DR-3 |User Manuals |
8 Maintenance Requirements
|Requirement # |Description |
|RS-MN-1 |Contracts (External / Internal) |
|RS-MN-2 |Routine (Scheduled) |
9 Back-up, Restore and Archiving
1 Archiving
/// Provide detailed requirements of the system relating to:
|Requirement # |Description |
|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 |
2 System Backup & Contingency
|Requirement # |Description |
|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: |
3 Business Activities Interfaces
/// Describe the internal and external interfaces and the flow of the system for the typical user. Briefly outline: ///
|Requirement # |Description |
|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. ///
1 External Interfaces
/// Specify which external interfaces will control the performance of the system or the input/output data it manipulates or generates. ///
2 User Interfaces
/// Describe specific user interfaces required by the system, such as special function keys, web page/links, etc. ///
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. ///
4 Software Interfaces
/// List what other systems/applications will the System Name and Version Number interface with and provide details. ///
10 Other Requirements
/// List any other requirements which are needed, that were not mentioned anywhere else in this document. ///
|Requirement # |Description |
|RS-OR-1 | |
|RS-OR-2 | |
|RS-OR-3 | |
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 |Requirement |Test Script|Test Script Title |
| | |Number |ID | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
/// 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. ///
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- pkk funding operations and methods
- pre listing packet
- the listing packet
- clif bar co
- writing as an engineer or scientist writing as an
- outline for independent study project emse 298
- workplace diversity a global necessity
- oracle data warehouse
- a goal writer s companion
- user and functional requirements specifications
Related searches
- functional requirements document dod
- dod functional requirements document template
- functional requirements excel template
- sample functional requirements document
- functional requirements document dau
- free functional requirements template
- functional requirements format
- functional requirements document
- functional requirements list
- non functional requirements list
- functional requirements examples
- non functional requirements software examples