Non-Functional Requirements Clause Samples

Non-Functional Requirements. This section covers the mandatory non-functional requirements for the NDR. Any tender should reflect an understanding and demonstrate wherever appropriate how any proposed solutions will fulfil these requirements. Ref Requirement type Requirements Outline N01 Integrity The consumer must be able to trust the Register and have confidence in its integrity & authenticity. The Register will be the Database of Record for all Energy Assessments and in the event of dispute provides the definitive statement regarding the actual Energy Document that was produced and lodged along with the Model Data that was used to produce that Energy Document. Therefore the Operator must ensure that the Register: • maintains its internal integrity • be safeguarded from any unauthorised tampering. • protected from both internal and external threats. • reduce any risks of fraud and abuse that may take place across the end to end process. N02 Data Consistency Due to the highly distributed nature of the marketplace there is a significant issue with enforcing consistency across the entire marketplace. A particular area where consistency is essential is in the identification and addressing of each Property being reported on. A shared central database of Property & Address details is the most obvious way of achieving consistency both cost effectively and in the required timescales. Some scenarios where consistency is required are: • A Property may have a number of different addresses associated with it in addition to the primary or “official” address for example the street may have more than one name or the owner decided to give the house a name or a building has been sublet by units or floors. In order to maintain consistency it is essential that all Energy Documents relating to a property consistently have the same correct address shown • Over time the identifying characteristics of a Property can change e.g. a Royal Mail Postcode reorganization may result in a postcode change for the Property therefore the address of the Property is not sufficient • A Property in Wales has both an English and a Welsh Address and when producing Energy Documents in one of those languages the EA should consistently use the correct address in the relevant language. It is the up to NDR Operator to select appropriate data-sets or service providers – such as Ordnance Survey Addresspoint, Royal Mail Postal Address File (PAF), National Land & Property Gazetteer (NLPG) or National Land Information Service (NLIS)...

Non-Functional Requirements. ID NFR#1 Priority (MoSCoW) M Comment ID NFR#2 Priority (MoSCoW) M ID NFR#3 Priority (MoSCoW) M Comment ID NFR#4 Priority (MoSCoW) M Comment ID NFR#5 Priority (MoSCoW) M Comment ID NFR#6 Priority (MoSCoW) M

Non-Functional Requirements. The functional and non-functional requirements are discussed in D2. 1. For the sake of completeness and to avoid unnecessary switching between deliverables, the common non-functional requirements are summarized below. Note that D2.1 also contains non-functional requirements with respect to the text, audio and video processing tools. Adhering to these requirements is the concern of the developers of these tools, and will not be further discussed in this document.

Non-Functional Requirements. 2.2.1.4.1 The system must have an easy to use interface. 2.2.1.4.2 Performing a task on the system must be understandable by the user 2.2.1.4.3 The system interface must support accessibility to all users including users with impaired vision, hearing or loss of motor skills. 2.2.1.4.4 The system must be scalable to support additional stakeholders. 2.2.1.4.5 The system must be flexible to support current and future standards 2.2.1.4.6 The system must be compatible to work on common operating systems for mobile devices and tablets for availability everywhere 2.2.1.4.7 Response time speed for screen refresh must be 2 seconds on the average 2.2.1.4.8 The system must include on-line help. 2.2.1.4.9 The help desk specialists must be trained to use the applications to support the system. 2.2.1.4.10 Users must be able to recover or reset lost passwords on the system 2.2.1.4.11 The system must include standards for encryption to protect the confidentiality of a patient’s health information 2.2.1.4.12 The system must be operated on a secure hardware and software with back up storage that meets technology standards to protect personally identifiable information 2.2.1.4.13 Must provide login credentials and multi factor key authentication for authorized users at every access level 2.2.1.4.14 Must adhere to all written confidentiality and privacy to all written confidentiality and privacy practices applicable by law to protect patients’ privacy whereby the system contains their health information 2.2.1.4.15 The system must support providers to achieve the goal for CKD in Healthy People 2020

Non-Functional Requirements. The Portal must be cloud hosted, in line with the government's Cloud-First technology principle to technology solutions. See ▇▇▇▇▇://▇▇▇.▇▇▇.▇▇/guidance/government-cloud-first-policy The Portal must adhere to cloud security principles. See ▇▇▇▇▇://▇▇▇.▇▇▇▇.▇▇▇.▇▇/collection/cloud/the-cloud-security-principles The Portal must be accessible to all users, including people with disabilities. The design will incorporate and meet WCAG 2.1 AA Accessibility Standards. See All of the data within the Portal will be classified as OFFICIAL. The Supplier’s staff assigned to the Contract shall have Baseline Personnel Security Standard (BPSS) clearance as a minimum. For further details of how to handle OFFICIAL data, see ▇▇▇▇▇://▇▇▇▇▇▇.▇▇▇▇▇▇▇▇▇▇.▇▇▇▇▇▇▇.▇▇▇.▇▇/government/uploads/system The Portal must include rights based access and segmentation of data, allowing users to see only the data which they have a right to see, following the principle of Least privilege. The Portal should comply with the General Data Protection Regulation (GDPR) regarding any personal data in the system. The location of servers where data is stored must be in the UK or Europe, unless otherwise agreed with the Authority. The Portal must support secure access in read only mode for the Authority’s users. The Portal must support secure login technologies, such as single sign on or multi factor authentication. The Portal must provide audit tracking features that identify the specific changes made to a record, the individual who made the changes and a date/time stamp. The Authority should have sight of audit logs at all times, ensuring any changes to data are visible. The Portal must support seamless maintenance, upgrades, version releases, bug fixes, enhancements, to minimise downtime. The Portal and any support services, such as the helpdesk, must be available during working hours, defined as the hours between 09:00 and 17:00, Monday to Friday, excluding British public and bank holidays. All data stored within the Portal must be maintained for a minimum of seven years. All data in the Portal must be backed up on at least a monthly basis, with the capability to restore data to the previous backup within 1 hour. The Supplier must have and be able to share with the Authority, Business Continuity Management (BCM) and Disaster Recovery (DM) plans. The Portal must be compatible with all major web browsers such as Microsoft Edge, Mozilla Firefox and Google Chrome.

Non-Functional Requirements. 7.1 [Performance, availability, capacity, characteristics, etc.] 7.2 Ex: [***]

Non-Functional Requirements. The ISO/IEC 25010 standard offers us a product quality evaluation system with a reasonably rigorous classification for NFR’s. A non-functional requirement (NFR) specifies how a component should perform. NFRs define the desired qualities and rules of conduct in the ecosystem, whereas functional requirements define the vehicles for functional delivery. They are used to describe key operational characteristics of the components and services that make up the CCT’s RM&DM&CM platform, rather than specific behaviours. The requirements listed below will either be provided by the RM&DM&CM solution or controlled and provided by another service within the IT landscape, for example, single sign-on logically fits within the access provisioning of ICT whilst a single user-GUI to access all the modules of the RM&DM&CM system is a non-functional requirement that usually is fulfilled by the RM&DM&CM solution. The solution should be easily scaled up to work for a Multi-location environment that might require replicating Image Servers and load-balancing Web Servers. A required document management system should have easy to use XML API's and Web- Services interfaces to facilitate integration with other business systems like Workflow, Records Management, and Image Enabling of ERP & CRM applications, Core Insurance & Banking applications. For clarity, the NFRs are used to describe qualities that are observable during execution such as performance, accessibility, and usability characteristics; and qualities that describe how the ecosystem develops, such as testability, maintainability, extensibility and scalability, which are vital for a platform to be dynamic, and evolve.

Non-Functional Requirements. 6.6.1 These requirements are supported by the Service Level requirements in the Contract (Schedule Part 5 – Service Levels) . The Service Provider must agree availability requirements of the Online Collection Instrument, prior to, and after the Rehearsal and Census Operational Periods, with the Authority. These periods will include Authority tests, Operational Readiness and Authority evaluation. The Service Provider must work with the Authority to refine the Non Functional Requirements during the Mobilise and Design stages, and after Rehearsal 2019. This should include but is not limited to the following: System Quality Attributes: Service Perspectives: - Accessibility - Performance - Availability - Scalability - Capacity - Availability - Compatibility - Evolution - Efficiency - Interaction - Elasticity - Security - Extensibility - Localisability - Modifiability - Performance - Recoverability - Resilience - Robustness - Scalability - Security - Serviceability - Testability - Usability Appendix C states the current baseline Non Functional Requirements including descriptions for each. Please refer to the following SLs for section 6.6.1: - SL 1 to 9 covering Availability and Performance

Non-Functional Requirements all other requirements. 1.2 The Contractor shall, and shall ensure that the Services and Deliverables shall, deliver and comply with the requirements set out in this Schedule 3.