What is Functional Requirements Specifications (FRS) & Checklist that should followed while finalizing FRS
In Earlier post we understand User Requirement Specification & Its Guidelines should be kept in mind while finalizing URS in computer system validation.
The
purpose of a functional specification is to define the requirements to be
implemented by the software solution.
Functional Requirements should include:
•
Descriptions of data to be entered into the system
•
Descriptions of operations performed by each screen
•
Descriptions of work-flows performed by the system
•
Descriptions of system reports or other outputs
•
Who can enter the data into the system
•
How the system meets applicable regulatory requirements
Requirements outlined in the Functional Requirements
Specification are tested in the Operational Qualification.
The Functional Requirements Specification should be signed by the
System Owner & Quality Assurance. If key end-users, developers, or
engineers were involved with developing the requirements, it may be appropriate
to have them sign and approve the document as well.
Depending on the size and complexity of the program, the
Functional Requirements Specification document can be combined with either the
user requirements specification or the design specification.
Functional Specifications (FS); Vendor or Implementation
partner shall develop & provide the FS to Project team for review &
Approval. Wherever required Project team
shall developed FS
FS defined what the system should do, and what functions and facilities
are to be provided.
•
FS must state essential business needs from a
functional & technical perspective.
•
Each requirement specified in the URS document
for the system shall be addressed in the FRS document. In case any specific
requirement defined in the URS cannot be implemented as a part of the system
then reason for the same shall be addressed.
•
Each functional requirement must be uniquely
numbered for each traceability
•
Requirement must be unambiguous
•
Each requirement must be verifiable and /or
testable
FRS document serve as the foundation to implement the functionality
Examples of Functional Requirements
Functional requirements should include functions performed by
specific screens, outlines of work-flows performed by the system, and other
business or compliance requirements the system must meet.
Interface Requirements
•
Field 1 accepts numeric data entry.
•
Field 2 only accepts dates before the current date.
•
Screen 1 can print on-screen data to the printer.
Business Requirements
•
Data must be entered before a request can be approved.
•
Clicking the Approve button moves the request to the
Approval Workflow.
•
All personnel using the system will be trained
according to internal SOP AA-101.
Regulatory/Compliance
Requirements
•
The database will have a functional audit trail.
•
The system will limit access to authorized users.
•
The spreadsheet can secure data with electronic
signatures.
Security Requirements
•
Members of the Data Entry group can enter requests but
can not approve or delete requests.
•
Members of the Managers group can enter or approve a
request but can not delete requests.
•
Members of the Administrators group cannot enter or
approve requests but can delete requests.
Functional Requirements
Specification Checklist
•
Is there a genuine business need and benefit outcome planned from the
specification?
•
Is there an approved budget for providing and spending time on the
specification?
•
Does specification include a version history?
•
If there is an assumptions section where those assumptions have been
verified?
•
Have all functional solutions been considered?
•
Is it confirmed there are no questions left to answer?
•
Does specification include layouts of proposed screens?
•
Does specification include details of validation to be imposed on any
inputs?
•
Does specification include detailed logic for any workflow required?
•
Does specification include details of any messages that will be
output?
•
Are any help facility requirements present?
•
Does specification outline/exclude any performance requirements?
•
Is it mentioned how exception handling will be handled?
•
Is it clear what documents will be delivered as part of the work?
•
Is each of requirements mentioned and appropriate based on the
business requirements specification?
•
Have all dependencies been identified?
•
Have all ambiguities been replaced with exact requirements?
“Trust but Verify “ Ronald Reagan
Across the internet, there are millions of resources are available which provide information about Everything.
If you found all content under one roof then it will save your time, effort & you will more concentrated on your important activity.
 |
| Data Integrity App |
Our Data integrity app will helpful for understanding what Data integrity & CSV really means & How 21 CFR Part 11, EU Annex 11 & other regulatory guidelines affects in pharmaceutical Industry.
- Basic Data Integrity Concepts
- ERES & Its Requirement
- CSV & Its best practices
- Mock Inspection and General Q&A
- Checklist for inspection
- Inspection Readiness
- Useful SOP’s
- Stay Regulatory Compliant.
“Stay One Step Ahead in Pharma IT Compliance”
https://play.google.com/store/apps/details?id=com.innovativeapps.dataintegrity
Try our "Data Integrity" app which helps you to better understand current regulatory agencies thinking on Data Integrity & CSV.
Comments
Post a Comment