Non-Functional Requirements
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. |