Non-Functional Requirements
- Lewis Ford (Unlicensed)
- Gavin Start
Non-Functional Requirements (NFR) are a specification or constraints that describes how the software system should behave or perform. Unlike functional requirements, which define specific features or capabilities of the software, non-functional requirements relate to system qualities such as performance, scalability, reliability, security, and usability.
The NFR’s below are intended to be used as a reference for what to look for in a system outside of the functional requirements. The Universal / Overarching Non-functional Requirements apply to Acute, Mental Health, Community, Ambulance and Maternity care settings. These are then supplemented by Care Setting Specific Non-Functional Requirements.
Universal / Overarching Non-Functional Requirements
ID | Category | MOSCOW | Requirement | Definition |
|---|---|---|---|---|
NFR-001 | Availability and Resilience | Should | Planned Maintenance Period | A fully operational Electronic Patient Record (EPR) Application may have up to 8 hours offline during a planned application maintenance event. |
NFR-002 | Availability and Resilience | Must | Off-line viewing during planned downtime | The patient data held in the Electronic Patient Record (EPR) Application must be available to users whilst the fully operational application is unavailable. The data should be available read only, in an acceptable format, for the user to view easily. |
NFR-003 | Availability and Resilience | Must | Off-line viewing during incident / unplanned downtime | The patient data held in the Electronic Patient Record (EPR) Application must be available to users whilst the fully operational application is unavailable. The data should be available read only, in an acceptable format, for the user to view easily. |
NFR-004 | Availability and Resilience | Should | Click through access during downtime | Data held and managed in other clinical applications, which is usually accessed through the EPR application, must also be available without using the EPR application. |
NFR-005 | Availability and Resilience | Must | Communication of Planned Outages | No less than 6 weeks notice must be given to users when system unavailability is expected during a maintenance event |
NFR-006 | Availability and Resilience | Must | Data Retention Periods | Data collected and/or used by a critical clinical application should be retained according to the Trust data retention policy |
NFR-007 | Availability and Resilience | Must | Roll Back period | The application data storage solution must be configured to enable full restoration (roll back) to any point in the previous 90 days/15 weeks |
NFR-008 | Availability and Resilience | Could | Roll forward Replay | The EPR application data storage must be configured to enable replay from any point in the previous 90 days |
NFR-009 | Availability and Resilience | Must | Hardware Maintenance | Applications must be hosted on supported infrastructure, which is suitable for the availability requirements of the application |
NFR-010 | Availability and Resilience | Should | EPR - RTO 2 Hour | The EPR Application must be recovered to operational status according to the RTO specified in the "Critical (Essential) Systems" document. This is proposed to be set to "within 2 hours". |
NFR-011 | Availability and Resilience | Should | EPR - RPO 10 minutes | The EPR Application must be populated with data when it is returned to operational status according to the RPO specified in the "Critical (Essential) Systems" document. This is proposed to be set to "no more than 10 minutes lost". |
NFR-012 | Availability and Resilience | Could | Affected patient records | Patient records affected by planned and unplanned application downtime events must automatically record that a potential gap in data keeping has occurred (medicolegal perspective as well as usability). |
NFR-013 | Availability and Resilience | Could | Redundant Network | All EPR infrastructure components (diversity of routes, diversity of suppliers, diversity of points of presence) must have at least 2 separate and independent implementations which can be used interchangeably by the EPR application. |
NFR-014 | Connectivity | Must | CAP assurance | Applications which connect to PDS must assure that the Common Assurance Process has been completed |
NFR-015 | Infrastructure | Must | Supported Client Environment | The specification and implementation of the Supported Client Environment (SCE) must be warranted by the Supplier according to the support arrangements and warranted environment specification provided by the supplier |
NFR-016 | Infrastructure | Must | Warranted environment specification | Suppliers must warrant that the warranted environment specification (WES) is up to date and notify the Trust for any changes to the WES at least 3 months in advance of the change. |
NFR-017 | Infrastructure | Must | End user devices | End User devices (EUD) must meet the minimum specification as provided by the supplier |
NFR-018 | Infrastructure | Must | Local Infrastructure | Connectivity to local networks (for use by application client) and local network provision must meet the minimum specification as provided by the supplier |
NFR-021 | Infrastructure | Could | Continuous Operation | The deployed application components must have the ability to use high availability technology and technology patterns to maintain continuous operation. |
NFR-022 | Infrastructure | Could | Host in a Data Centre | All hardware components of the system not requiring direct access or not providing direct connectivity to the user must be hosted in a data centre. |
NFR-023 | Infrastructure | Should | Separate Cabinets | The hardware design should house servers which are used to provide resilience in separate chassis and cabinets. |
NFR-024 | Infrastructure | Should | Separate Data Centre | The hardware design should house servers which are used to provide DR in separate DC |
NFR-025 | Infrastructure | Should | Production Hardware Less Than 5 Years Old | Solutions must ensure that all production hardware for hosted components remains less than 5 years old. |
NFR-026 | Infrastructure | Must | Hardware Vendor Support | All hardware and firmware must have a support and maintenance agreement in place whilst it is in active use. |
NFR-027 | Infrastructure | Must | Operating System Vendor Support | All operating system software must have a valid and current support agreement in place whilst it is in use |
NFR-028 | Infrastructure | Must | Hypervisor and Virtualisation Service Vendor Support | All infrastructure software must have a valid and current support agreement in place whilst it is in use |
NFR-029 | Infrastructure | Should | Application gateway | Cloud hosted applications must use an approved application gateway in addition to firewalls monitoring network traffic at the Trust security boundary |
NFR-030 | Infrastructure | Must | Health and Social Care network | The solution design must show how applications will be able to interact with and access HSCN (Health and Social Care Network), to access services such as PDS, NEMS, NRL |
NFR-031 | Application Management | Could | Automated Deployment | EPR Application updates must be applied to all application clients at the same time (within a period of 1 hour / during down time?) |
NFR-032 | Application Management | Must | Verified Deployment | Verification that the update has been applied successfully must be obtained and available for audit |
NFR-033 | Performance and Scalability | Could | Network Traffic Prioritisation | The design of the solution must include Quality of Service (QoS) components and apply best practice to enable the management of data traffic (network prioritisation) to reduce packet loss, latency and jitter on a network |
NFR-034 | Performance and Scalability | Could | Network monitoring | Networks hosting the system must be actively monitored by automated systems to ensure correct operation and which must provide alarms where a device or group of devices has a fault. |
NFR-035 | Performance and Scalability | Must | Peak user volume | The EPR application must be able to support the expected peak number of concurrent users |
NFR-036 | Performance and Scalability | Mus | Sustained user volume | The EPR application must be able to sustain application performance for the typical number of concurrent users |
NFR-037 | Performance and Scalability | Must | Data volume | The EPR application must be able to effectively access and search the quantity of data expected to be stored in the system through its lifetime |
NFR-038 | Performance and Scalability | Should | User response time | System response to a user request must not be longer than 2 seconds in normal use |
NFR-039 | Performance and Scalability | Could | Application processing time | SCE processing time for activity in accessing data and image must be less than 1 second. |
NFR-040 | Performance and Scalability | Could | Action cancelation | Requests which will take longer than 5 seconds must provide the user with a cancel option |
NFR-041 | Performance and Scalability | Should | Increased Capacity | The design of the solution must support the future state architecture and enterprise growth considerations and apply best practice to enable the implementation of the EPR application |
NFR-042 | Performance and Scalability | Should | Increases in demand | The solution must provide timely response to changes in demand For on premises - this is set at maintaining a 20% capacity headroom which can be used within 24 hours |
NFR-043 | Regulations | Must | Regulatory/Legislative Conflicts | All variances between system specification and legal or professionally accepted best practice relating to cyber security and Information Governance must be fully documented and approved by the Trust before they are implemented. |
NFR-044 | Regulations | Must | Information Standards Compliance | ICT Applications must not prevent a trust complying with all relevant information standards as defined in the following:
|
NFR-045 | Regulations | Must | Information Standards Compliance | ICT Applications must comply with NHSD Clinical risk management standards as defined in the following: Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems Clinical Risk Management: its Application in the Manufacture of Health IT Systems |
NFR-046 | Regulations | Must | IG Assessments | A revised "DSP Assertions and Evidence Statement" as specified by the DSP Toolkit assessment process must be completed before the introduction of an application, or a change is made to an existing application, in the production environment. |
NFR-047 | Security | Must | Implement Authentication | All users of an ICT Application must be authenticated before they are permitted to use the application. User Authentication must use the highest security model available to the application and align with any single sign-on solution in place at the Trust. |
NFR-048 | Security | Must | End-User Authentication permitted methods | User authentication must use a permitted method from this list:
|
NFR-049 | Security | Must | Security Policy Compliance | All ICT applications must have a data protection impact assessment (DPIA) on record which is reviewed whenever a major change is made. New applications must submit a DPIA before implementation to any production environment |
NFR-050 | Security | Should | Asset Owner | Any new app must have an asset owner identified and they must provide a risk report to the SIRO at least once every 12 months. |
NFR-051 | Security | Must | Session Timeout | Applications must ensure that access to the system functionality is prevented when the authenticated user has stopped using the application. This rule is subject to consideration on a per area basis e.g. outpatient consultation vs. surgery/theatres. |
NFR-052 | Security | Must | End point to End Point Authentication | All connections between ICT applications must be configured to authenticate end points before data is shared. |
NFR-053 | Security | Should | Approved PEN Testing Provision | Penetration testing must be completed for both infrastructure and application by one of the Trust’s approved providers before the ICT application is implemented in the production environment. |
NFR-054 | Security | Must | Role Based Access Controls (RBACS) | All users of an ICT Application must be assigned an approved Role for that application. Configuration of the Role definition, and rules for role allocation, must be specified in detail and approved in accordance with defined security policies |
NFR-055 | Security | Should | Implement IG Baseline | Access to data held within ICT systems should be allowed for Informatics, supplier and trust operational users according to need. |
NFR-056 | Security | Must | Physical Location Hosting | All hosting infrastructure must be physically located in countries with applied UK Data Protection legislation |
NFR-057 | Security | Should | Appropriate Monitoring Functionality | All ICT applications used in the provision of Trust services must enable scheduled audit at least equal to the risk profile identified within the risk assessment. Where possible real time protective monitoring should be provided Monitoring must include:
|
NFR-058 | Security | Must | Secure Audit Trail | All ICT applications used in the provision of Trust services must secure the audit trail of data changes such that it is tamper proof, events are uniquely attributable to a user and non repudiable by both system and user. |
NFR-059 | Security | Should | Minimum Auditable Events | All ICT applications used in the provision of Trust services must include the following events in audit logs and other data stores as required to satisfy the secure audit trail requirement:
access.
multiple addresses.
|
NFR-060 | Security | Must | Malware Protection | The ICT production environment used to host any application must incorporate protection from malware. |
NFR-061 | Security | Should | User Input Minimal | The SCE application must be deployed in a consistent way for all Trust users and not require any user interaction with the update process itself |
NFR-062 | Security | Should | Patch Management Provision | ICT applications implemented in the production environment must be updated within 14 days of the release of any security patch by the vendor |
NFR-063 | Security | Should | Deployment of Critical Patch | ICT applications implemented in the production environment must be updated within 24 hours of the release of a critical security patch by the vendor |
NFR-064 | Security | Must | Security Updates Available | ICT applications implemented in the production environment must not use any subsystem, or rely on any component, which is no longer supported by the supplier |
NFR-065 | Security | Must | Trusted Applications | All applications and application add-ons must be certified for use and approved for implementation before they are installed in the ICT production environment |
NFR-066 | Security | Should | Minimum Functionality | Additional functionality without a verified business use, which is available from an authorised ICT application, should be made inoperable through configuration before the application is implemented in the production environment |
NFR-067 | Security | Should | Automated Deployment & Configuration | Trust environment owners should ensure that operating software for all devices providing the environment are deployed and configured automatically. |
NFR-068 | Security | Should | Data Management on external devices | Data required by Trust ICT applications operating on mobile devices where the device is not owned by the Trust must encrypt data to a standard not less than AES during the session and delete it at the end of the session. |
NFR-069 | Security | Should | Data Management on internal devices | Data required by Trust ICT applications operating on any device owned by the Trust must encrypt data to a standard not less than Triple DES or AES during the session. These devices can cache the encrypted data for offline use but must delete the data if it has not been refreshed within a 24 hours period. |
NFR-070 | Usability | Must | Training Strategy | No major application change should be implemented without a user training strategy |
NFR-071 | Usability | Should | Application monitoring | Application should enable the ability to monitor user interface failures, navigation failures and incomplete data management transactions. |
NFR-072 | Usability | Should | User feedback | Application should enable user reporting of user interface issues |
NFR-073 | Usability | Should | Applications Support notification | Applications should support the ability to configure alerts and enable notifications to the application support team accordingly |
NFR-074 | Usability | Could | Understanding User behaviour | Applications should provide the ability to monitor the time spent on the "In focus" screen object |
NFR-075 | Usability | Should | Monitoring applications | Applications should provide the ability to measure the performance of screen loading and screen content refresh (eg changing patient context) activities from the user experience perspective. |
NFR-076 | Usability | Must | Continuous Usability | Each application must have a usability review whenever a major upgrade or significant change occurs to the system |
NFR-077 | Accessibility | Must | Disabilities and impairments | Applications must make provision for all users' needs, which include (but not limited to) needs described by the GDS "understanding disabilities and impairments user profiles" |
NFR-078 | Accessibility | Must | Web browser content | Applications providing content via a web browser must ensure the presentation of the content is WCAG 2 compliant |
NFR-079 | Accessibility | Must | Clinical User Interface | Application user interfaces must be certified compliant with the NHS Digital Service Manual - Design - NHS digital service manual |
NFR-080 | Interoperability | Must | External data transfers | All internal and external data transfer must use agreed semantics as appropriate to the data destination |
Care setting specific Non-Functional Requirements
In addition to the Universal / Overarching Non-Functional Requirements the following care setting specific Non-Functional Requirements also apply.
Acute
The following additional Non-Functional Requirements are applicable for Acute care settings.
ID | Category | MOSCOW | Requirement | Definition |
|---|---|---|---|---|
NFR-019 | Infrastructure | Must | Permitted Types of Storage | The Supported Client Environment (SCE) solution requires a minimum of 10,000 IOPS to be available between the data store and application. |
NFR-020 | Infrastructure | Should | Bandwidth | The network capacity/bandwidth required for on-premises solution should be 1gbps from the client and at least 10gbps between data centres and within (latency < 5ms), or the minimum specification as provided by the supplier. |
Mental Health
There are no additional Non-Functional Requirements for Mental Health.
Community
There are no additional Non-Functional Requirements for Community.
Ambulance
There are no additional Non-Functional Requirements for Ambulance.
Maternity
There are no additional Non-Functional Requirements for Maternity.