COMMERCIAL-IN-CONFIDENCE. Electronic Duty of Care. Detailed Non-Functional Requirements. Project Reference 1262/002. Document Reference DNFR

Transcription

1 COMMERCIAL-IN-CONFIDENCE Detailed Non-Functional Requirements Project Reference 1262/002 Document Reference DNFR 25 May 2012 The edoc programme has been made possible with the support of LIFE+ funding from the European Community. intelligent business

2 Copyright Notice This document has been prepared by IPL Information Processing Limited ("IPL") on behalf of the Environment Agency, and the Environment Agency is the owner of the copyright and all other intellectual property rights of this document. No part of this document may be copied, reproduced, stored in a retrieval system, disclosed to a third party or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the prior written permission of the Environment Agency. Environment Agency 2012 Document History Date Issue Author Comments 11/05/ draft A 14/05/ draft B 25/05/ Owen Philpott Gareth Jones Owen Philpott Gareth Jones Owen Philpott Gareth Jones Initial draft for discussion. Updates following review Issued 25 May 2012 COMMERCIAL-IN-CONFIDENCE Page ii

3 Contents 1 Introduction Purpose Background Duty of Care (edoc) Document References System Security System Availability System Support System Capacity and Scalability System Performance Data Migration Back-up Configurability Extensibility Usability and Accessibility Interoperability User Support May 2012 COMMERCIAL-IN-CONFIDENCE Page iii

4 1 Introduction 1.1 Purpose This document, the edoc Detailed Non-Functional Specification, is a deliverable from the Requirements Gathering Phase of the edoc programme (IT Phase 1). It is one of a pair; the other being the edoc Detailed Functional Specification [1]. Together these detailed specifications will form the basis of a subsequent procurement exercise, within which a supplier for the development (and possible hosting) of the edoc system shall be selected. 1.2 Background Duty of Care Under UK waste legislation, all businesses have a Duty of Care to ensure they produce, store, transport and dispose of their waste safely. One of their responsibilities is to complete Waste Transfer Notes (WTN) and keep them as a record for at least two years. A transfer note must be completed, signed and kept by all parties involved in the transfer of the waste. WTNs ensure that there is an audit trail from when the waste is produced until it is disposed of. It must contain enough information about the waste for it to be handled safely and either recovered or disposed of legally. While all transfers of waste must be documented, the regulations do not require individual transfers to be separately documented. Where a series of transfers of waste of the same description is being made between the same parties at the same location, provision is made for the parties to agree a "Season Ticket" i.e. a single record covering a series of transfers over a future period up to 12 months. The use of a Season Ticket is, however, only permissible where the parties involved in the series of transfers do not change and where the description of the waste remains the same (edoc) The current transfer note process is paper-based. It results in 25 million transfer notes being produced a year with around 50 million pieces of paper being stored by business in filing cabinets, boxes, etc. at any one time. The goal of the electronic duty of care (edoc) programme is to modernise the way waste data is collected in the UK and greatly enhance the ability to extract good quality data for businesses, regulators and government. The programme aims to create a national, internet-based repository for the storage of transfer records. 1.3 Document References [1] edoc Detailed Functional Specification v1 Draft A, 4th May 2012 [2] edoc Programme Data Reassurance v1.0, 9th February 2012 [3] High Level Security NFR Template v2.00.xls [4] Protective Security policy 238_01, March 2011 [5] Information Security policy 453_05, March 2011 [6] Environment Agency Corporate standards for usability and accessibility 25 May 2012 COMMERCIAL-IN-CONFIDENCE Page 4 of 8

5 2 System Security.1 Use of the system is non-mandatory. To ensure adoption, businesses must be assured that the information they provide will be held securely..2 The Data Reassurance paper (see reference [2]) identifies that the system must be accredited to Business Impact Level 2 (IL2 Protected)..3 The system shall abide by the Data Protection Act for the capture and storage of personal information..4 All interfaces to the system must be secure with all transported data encrypted..5 All access to the system shall be logged including the username of failed attempts..6 Passwords for users must be delivered by a secure procedure..7 The system must enforce the use of complex passwords, as a minimum 8 characters including 1 digit..8 The system must store passwords and PIN codes in an encrypted form..9 The Web Portal must not display passwords or PIN codes..10 On first use of the Web Portal, the user shall be forced to change their password..11 The Web Portal shall force a user to change their password on a regular basis. The frequency will be configurable by the System Custodian..12 The system shall protect against brute force password attacks..13 On failed access the system shall not reveal which of the access credentials is incorrect..14 All updates to records will be audited and traceable to the user that performed the action..15 A procedure must be in place to allow the removal of a user s access..16 All input to the system must be validated before being processed further to prevent the injection of malicious code..17 Any feedback to the user must not reveal any details of the system s underlying implementation..18 The system shall be subject to approval by independent penetration testing commissioned by the Environment Agency..19 The supplier will provide sufficient information to scope the penetration test. For example: a) Hosting arrangements; b) Application architecture; c) Infrastructure security measures; d) Access by support staff, including their location..20 On decommissioning of any part of the system, any device containing data must be subject to approved techniques to make the data non-retrievable..21 The system must comply with all High Level Security non-functional requirements applicable to the application code developed for an IL2 system, as stated in the Agency s High Level Security NFR Template [3]..22 The system must comply with all relevant HMG legislation, guidance and standards relating to information and data security stated in the Agency s Protective Security policy [4] and Information Security policy [5]. 25 May 2012 COMMERCIAL-IN-CONFIDENCE Page 5 of 8

6 3 System Availability.1 Potential users of the system have identified its availability as business critical at all times of the day: a) A transfer cannot take place without validating against the information stored on the system; b) The bulk upload of transfer records may take place outside of business hours..2 The system shall be available, excluding scheduled downtime, for 99.9% over 24 hours 7 days a week..3 If the functionality of the system is impaired the user should be informed..4 If part of an action fails (e.g. an cannot be sent), the whole action should be rolled back. 4 System Support.1 Businesses must be confident that any faults will be resolved quickly and efficiently..2 An approved process should be used for incident, problem, change, release and service management..3 The schedule for any planned downtime shall be published at least 1 week in advance..4 Any disruption as a result of planned maintenance will be scheduled in non-core hours, with any one window of downtime restricted to a maximum of 4 hours..5 The system shall be restored to operational status within 4 hours of a complete loss of service..6 All changes to the system shall be controlled via a change control procedure..7 All changes to the system shall be reviewed, approved and tested prior to being undertaken..8 Following rollout of a change, all business critical areas of the system must be tested to ensure that there has been no adverse impact..9 For all changes there must be an approved back out strategy..10 To aid resolution of issues the system custodian shall be able to view error logs, traffic statistics, audit logs and system configuration. 5 System Capacity and Scalability.1 Use of the system is optional (transfers can continue to be recorded on paper). Therefore adoption of the system will be unpredictable..2 The largest 15 waste management companies create up to 80% of transfer notes. As each of these large companies adopts the system, there will be a significant increase in capacity requirements. The size of this jump will be linked to the policies of each company for types of signatures and data migration of historical records (see section 7)..3 The system must be flexible to accommodate revised growth projections..4 The outer bounds for the capacity of the system are: a) 25 million transfer records produced each year (external transfers); b) 5 million registered businesses..5 The following assumptions can be used in sizing calculations: a) 8.5 million internal transfers per year; b) There will be an equal distribution of types of signatures on transfer records; c) 20% of transfer records may be of interest to HMRC; 25 May 2012 COMMERCIAL-IN-CONFIDENCE Page 6 of 8

7 d) 5% of transfer records will have a Notes field. The length of the Notes field will be 512 characters; e) The example configuration values for Transfer Records can be used (see Detailed Functionality Specification [1]); f) 500 concurrent user sessions. 6 System Performance.1 To maintain the user experience the system must be responsive..2 Over a local network 95% of responses from the API for updates to individual records should be within 1 second, with no single response taking longer than 5 seconds..3 Over a local network 95% of responses from the API generic helper methods should be within 1 second, with no single response taking longer than 5 seconds..4 Over a local network 95% of responses from the Web Portal for updates to individual records should be within 2 second, with no single response taking longer than 10 seconds..5 3rd party software may perform bulk uploads of new transfers (e.g. at the end of every day). The system must support these spikes in traffic. 7 Data Migration.1 Transfer records are currently held on paper or by 3 rd party software. Registered businesses may wish to import these historical records into the system - the system shall support the bulk import of these records (see Detailed Functional Specification [1] - Lifecycle)..2 The system shall support a throttling mechanism to prevent bulk uploads impacting normal business. 8 Back-up.1 A back-up of the system s data and configuration shall be taken on a daily basis and held at a secure location..2 Procedures must be in place to check the integrity of these back-ups..3 The backup should minimise the impact on normal operation during backup the system shall be able to meet 75% of its agreed performance level..4 All application code and builds must be kept under revision control by the supplier. 9 Configurability.1 The Detailed Functional Specification [1] describes the minimum set of configuration the system shall support..2 It is anticipated that this configuration will change infrequently management at the database level may be more appropriate than the development of Web Portal screens. 10 Extensibility.1 edoc will be a national system. It will span several regulatory bodies the Environment Agency (for England and Wales), the Scottish Environment Protection Agency and the Northern Ireland Environment Agency..2 The system will have to comply with variations in regulations between these bodies, with the potential for the regulations to diverge further. 25 May 2012 COMMERCIAL-IN-CONFIDENCE Page 7 of 8

8 .3 In 2015 the NACE coding scheme will be introduced across the European Union to replace SIC codes NACE is the first 4 digits of a SIC code. At that time transfer records will be required to apply this coding scheme. The system must be capable of supporting this change..4 Defra, in response to the Government s Red Tape Challenge, has identified hazardous waste compliance as a candidate for simplification. The design of the system should consider the impact of an extension to include hazardous waste consignment notes. 11 Usability and Accessibility.1 The system must offer an improved experience over completing a transfer record by paper it must provide an intuitive interface to simplify this process..2 The Web Portal shall support standards-compliant browsers..3 The Web Portal shall comply with W3C Web Content Accessibility Guidelines v The Web Portal could use Java Script; however the site must provide a fall back for users without it enabled..5 The Web Portal shall be multilingual for this release supporting English and Welsh..6 The system shall meet the usability and accessibility standards as agreed between the regulatory bodies, e.g. [6]. 12 Interoperability.1 A number of waste management companies have existing software - either bespoke or off-the-shelf - that will need to be updated to interact with the system via its API..2 The supplier will provide documentation on how 3rd party software can access the system s functionality, including a FAQ section..3 The system shall provide a test area for 3rd party software to integrate against..4 The supplier will provide technical support to 3 rd party developers by ..5 The API should utilise Open API Standards..6 The API shall support versioning. There may be a window where an old and new version of the API must be supported..7 If any updates are made to the API, without increasing the version number, then existing functionality must be maintained, e.g. any new parameter must be optional and if absent must default to existing behaviour. 13 User Support.1 The system shall provide a training area for users of the Web Portal..2 The training area will mirror the functionality of the live system but will clear all data on a configurable schedule. For example, at the end of every day..3 The Web Portal shall provide context sensitive help..4 The supplier shall provide a user guide for the Web Portal including a FAQ section English and Welsh. - End of Document - 25 May 2012 COMMERCIAL-IN-CONFIDENCE Page 8 of 8