Functional Requirements Specification (FRS).
Software Validation.
The functional requirements specification is a description of the product to be supplied in terms of the functions it will perform and facilities required to meet the user requirements (often defined in a prior URS – User Requirements Specification) document.The functional specification should be written in such a way that it is understood by both supplier and customer.
This document is the controlling specification, against which the system will be tested.
Functional Requirements Specification. (FRS). Best Practice in Software Validation.
Functional versus the User Requirements Specification.
The URS (user requirements specification) tends to be a higher level document which describes what the final software output will be, or describes how an item of equipment controlled by software will perform. The FRS will get into a greater level of detail in defining customer requirements.
The functional requirements need to be defined to a level which is both “complete” and “consistent”. Completeness refers to an ability to clearly and fully define all required functional outputs which will be provided via the software development process. Consistency refers to a necessary absence of any inconsistencies in the defined requirements of the FRS.
Functional and Non-functional user requirements.
In practice an FRS will often define both the functional and non-functional requirements. The functional requirements will describe the behavior of a software or related system, whereas the non-functional requirements will describe the performance characteristics of the software. Depending on the magnitude and complexity of the software development project, and the criticality a customer places on particular attributes of the software performance, there may be crossover between functional and non-functional requirements.
Examples of functional requirements may be:
Requirements for auditability and audit trails.
Certification requirements.
The necessary levels of authorization.
Output reports to be provided.
Ability and easy of interfacing with external users.
Ability of make corrections, updates to inputted data.
Regulatory requirements (also potential non-functional requirements).
Ability to generate and retain user and performance histories.
Ability to restrict users to functional performance levels.
If there is an ordering element, then the system may be required to generate an order i.d. which will carry through to all related activities and allow full historical and status search based on the specific i.d. number.
Examples of non-functional requirements may be:
Capacity of the system.
Associated documentation.
Regulatory requirements.
Requirements for disaster recovery.
Requirements for future extension of the software.
Portability of the software.
Quality expectations.
Response times to user inputs and system outputs.
Level and integrity of security.
Associated with security may be privacy requirements.
How efficiently will the process perform under the control of the software.
Current Best Practices.
Software Validation.
- Agile Development. Extreme Programming. Spiral Validation. Etc..
- Software Validation explained in an easy to understand, visual, format.
- Use to inform yourself on the Validation of Software.
- Information, Understanding, Best Practice >>>
General Principles of Software Validation FDA
EU Commission guidance on stand alone software