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. 1. The system shall be scalable to accommodate additional users and modules as needed.
Non Functional Requirements all other requirements.
Non Functional Requirements. 10.1 Navigation
Non Functional Requirements. In order to be more precise, this section is divided into three points: Common non-functional requirements. These requirements relate to the whole system. Online processing requirements. These are special requirements for the online processing service. This service will be used to process input in the journalist use case, where the system will recommend content based on user input. Background processing requirements: These are special requirements for the background processing service. This service will be used to process items that may be recommended or searched for in the future.
Non Functional Requirements. 1.The system shall comply with local, state and federal regulations. 2.The system shall be web-based and platform agnostic. County of Orange MA-042-20012181 Health Care Agency Page 29 of 65 Folder No. C025988
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. A non-functional requirement is a statement of how a system must behave, it is a constraint upon the system’s behavior. It specifies all the remaining requirements not covered by the user and functional requirements. They specify criteria that judge the operation of a system, rather than specific behaviors. Non- functional requirements specify the system’s ‘quality characteristics’ or ‘quality attributes’ (OGC, 2000)
Non Functional Requirements. A non-functional requirement is more concerned with specific criteria that can be used to judge the operation of a system. In the eDIANA context, this includes requirements such as performance, reliability, safety, power consumption, as well as other more generic aspects such as design constraints (e.g., technology, architecture) and compliance with standards. Most of the requirement attributes are quite self-defined and others were originated from deliverable D1.2-B (Requirements Support Ontology). However some of them are somehow vague and need some clarifications: Priority • High: Must be implemented no later than in the first iteration of the Construction phase. • Medium: Must be implemented no later than by the end of Construction. • Low: May be implemented if time permits. (Functional) Category • COM – Communication: functionality related to communication between separated nodes. • FUN - Functions/Operations: functionality covering computation/processing operations. • IS - Information Storage/Flow: functionality related to information storage or transmission. • UI - User Interface: functionality associated to user interfaces. • DI - Device Interface: functionality related to interfaces of devices. • MOD - Operational Mode: description of required operational modes. An operational mode identifies a segment within the system execution that is characterized by a given configuration. Information Direction: Only applicable if the functional category is Information Storage/Flow. • Required: the information is required by the component defined in the attribute eDIANA Component. • Provided: the information is offered by the component defined in the attribute eDIANA Component. • Shared: the information is shared (read/write) by multiple eDIANA components. • Undefined: the information direction exists, but it is not defined at this stage of the requirement elicitation.
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
