Non-Functional Requirements
Context
The Non-Functional Requirements illustrate the necessary information required to effectively define business and technical non-functional requirements. The intended audience is the project and programme teams, and any stakeholder whose input/approval into the requirements definitions process is needed.
These NFRs are specified to support the MVP implementation of TIS and will need to be updated to reflect new functionality rolled out post March.
Scope
These NFRs are intended to govern both the internal Admin application, the back end development and management of the app and the external facing Trainee application.
| Constraint | Description |
|---|---|
| Compliance |
|
| Application standards | |
| Assumptions |
|
Requirements
| REFERENCE | NAME | DESCRIPTION | COMMENTS |
|---|---|---|---|
| Hardware | |||
| TIS-NFR-H-1 | Internal Users (HEE & Trust Administrators) | System should support all devices used within HEE: PCs, iPads, iPhones | Validate with internal IT |
| TIS-NFR-H-2 | External Users (Trainees) | System should support all devices used by trainees: PCs, Macs, any mobile device | Check with Hicom to see if they know what devices trainees used to login; also check https://data.gov.uk/data/site-usage#totals (BW) Hicom do not have this data in an accessible format |
| Software | |||
| TIS-NFR-S-1 | Operating Systems (internal) | Sustem should support any desktop function (client or 3rd party plug-in) to work on a minimum of windows 7 desktops (Windows 10 upgrade path) (Mac OSX in limited numbers) | Validate with National IT and/or Ray |
| TIS-NFR-S-2 | Operating Systems (external) | Any public facing web application to be fully functional across a range of popular devices - touch screen and variable screen size (tablets and phone) | Dependent on devices |
| TIS-NFR-S-3 | Browsers (internal) | Any web application elements to be fully functional on the organisation standard browser - IE11 currently | Validate with National IT and/or Ray |
| TIS-NFR-S-4 | Browsers (external) | Any public facing web application to support a 'to be defined' range of common browsers & platforms | Dependent on devices |
| Interface | |||
| TIS-NFR-I-1 | Accessibility | All UI elements, public facing and back office to conform to industry accessibility standards - WCAG Double A | Ask Panos to run e2e test to capture reports |
| TIS-NFR-I-2 | ESR | The system needs to support the integration between TIS and ESR | |
| TIS-NFR-I-3 | Intrepid | The system needs to support the integration between TIS and Intrepid | |
| TIS-NFR-I-4 | Oriel | The system needs to support the integration between TIS and Oriel | |
| TIS-NFR-I-5 | GMC Connect | The system needs to support the integration between TIS and GMC Connect | |
| TIS-NFR-I-6 | GMC LRMP | The system needs to support the integration between TIS and GMC LRMP | |
| TIS-NFR-I-7 | Usability | The user experience of both public facing and back office UIs should be as streamlined, efficient and as intuative as possible to encourage usage and minimise training requirements | |
| TIS-NFR-I-8 | Printed outputs | Any printed output shall comply with HEE brand guidelines and stipulated formats | |
| TIS-NFR-I-9 | Language | All back office functions including any web and desktop functions, error and audit logs etc should be in English | |
| Performance | |||
| TIS-NFR-P-1 | Transaction load | TBC | Transactions per second, e.g. the software must support 80,000 customers which will on a busy day generate 4500 customer interactions |
| TIS-NFR-P-2 | Record load time | The system should load records within a reasonable amount of time | Exact timing tbc |
| TIS-NFR-P-3 | Reliability | 5% | Percentage tolerance of the system being down |
| TIS-NFR-P-4 | No internal users | The system should support at least 1800 users | No of intenal users (1767 current licenses issued) |
| TIS-NFR-P-5 | No external users (trainees) | The system does not need to support trainees for MVP | No of external users (54000 trainees; 21000 with self service; approx 6000 HCS) |
| TIS-NFR-P-6 | Accuracy | The data within the system must be accurate 100% of the time | |
| TIS-NFR-P-7 | Response times | TBC | e.g. In supporting 300,000 customers it shall ensure that performance shall not fall below the following level: 95% of ALL visible pages for “normal” customers respond in 8 seconds or less, including infrastructure, excluding backends. |
| Supportability | |||
| TIS-NFR-SU-1 | Times | TBC | Dependency on Support model - tbc with Naz |
| TIS-NFR-SU-2 | Days | TBC | Dependency on Support model - tbc with Naz |
| TIS-NFR-SU-3 | SLA - first line | TBC | Dependency on Support model - tbc with Naz |
| TIS-NFR-SU-4 | SLA - second line | TBC | Dependency on Support model - tbc with Naz |
| TIS-NFR-SU-5 | SLA - third line | TBC | Dependency on Support model - tbc with Naz |
| TIS-NFR-SU-6 | Out of hours support | TBC | Dependency on Support model - tbc with Naz |
| TIS-NFR-SU-7 | ESR support SLA | TBC | TBC with Ray |
| TIS-NFR-SU-8 | Intrepid support SLA | TBC | TBC with Ray |
| TIS-NFR-SU-9 | Oriel support SLA | TBC | TBC with Ray |
| TIS-NFR-SU-10 | GMC support SLA | TBC | TBC with Ray |
| Security | |||
| TIS-NFR-SE-1 | Login | User should not be able to access the site without being logged in | |
| TIS-NFR-SE-2 | Timeout | User should be logged out after 20 minutes period of inactivity | TIS Release 40.10 included an update to enforce this. |
| TIS-NFR-SE-3 | User deactivation | The system should not contain users who are no longer active as a trainee or within the HEE organisation | Regional Project Leads at present are responsible for identifying if a user should be removed. We are looking at the possibility of generating a report to identify if a user has not used the system for X period. |
| TIS-NFR-SE-4 | Profile management | User profile should be managed by specified users only, with TIS Admin role using customisable role based permission model | How /who should manage user profiles? |
| TIS-NFR-SE-5 | Access to UI | Restricted to users set up with an account | |
| TIS-NFR-SE-6 | Access to data | Restricted to those who are authorised to view them, according to permissions defined | Link to roles/perms table |
| TIS-NFR-SE-7 | Modifying data | information should only be modified by people who are authorised to do so | Link to roles/perms table |
| TIS-NFR-SE-8 | Fraud | The system should be protected against vulnerability due to penetration including SQL injection threats, denial of service, hacking and other attacks; Should pass 3rd party validation test (OWASP) | Speak to Chris |
| TIS-NFR-SE-9 | Locations | Users can login from any location globally | Should login be restricted by physical location of the user? BW comment - When trainees begin to use the system this may be undesirable. |
| TIS-NFR-SE-10 | Brute force | TBC | Confirm keyloak brute force requirements |
| TIS-NFR-SE-11 | Cookie policy | Publish a cookie policy that tells the user what cookies are used, what they do and how long they're stored | |
| TIS-NFR-SE-12 | Attacks | The system should be protected against hacking and other attack | |
| TIS-NFR-SE-13 | Password strength | User set passwords should conform to rules defined | See here: https://hee-tis.atlassian.net/wiki/spaces/TISDEV/pages/123404302/Admin+User+Management+-+Password+Management+Policy+TIS+Approach |
| Availability | |||
| TIS-NFR-A-1 | Peak times | System should be available between 09.00 and 17.00 | Periods of time when particularly important system does not go down |
| TIS-NFR-A-2 | Peak days | System should be available between Monday to Friday | Periods of time when particularly important system does not go down |
| TIS-NFR-A-3 | Peak Periods | May, June and July | |
| TIS-NFR-A-4 | The system should adequately support integration processing - Oriel (am, time tbc) and ESR (eve, time tbc), GMC (intraday), GMC LRMP (eve, time tbc) | ||
| TIS-NFR-A-5 | Availability (internal) | System should be available between 8am-6pm, Monday to Friday, year around | |
| TIS-NFR-A-6 | Availability (external) | System should be available 6am-10pm, 365/6 days a year | |
| TIS-NFR-A-7 | Traceability | Nothing should happen in a system that can’t be traced back to a responsible person | |
| Documentation | |||
| TIS-NFR-D-1 | Document types in use | Alll document file types should be supported | What version of Office, any other doc types typically in use? |
| TIS-NFR-D-2 | Document size | The system should not restrict file size | Limits on document sizes? |
| TIS-NFR-D-3 | Virus checking | Documentation should be virus checked before being uploaded into the System | |
| Archiving | |||
| TIS-NFR-AR-1 | Frequency | All records should be archived once they are over X years old | Speak to Joanne - maybe 7 years post trainee completion? |
| TIS-NFR-AR-2 | Access to archives | All archived records should be accessible only by X users | Speak to Joanne |
| TIS-NFR-AR-3 | Permanent deletion | TBC | Speak to Joanne |
| TIS-NFR-AR-4 | Notifications | TBC | Should any users/other be notified when records are archived - either for their own or others' records |
| Monitoring | |||
| TIS-NFR-M-1 | Alerts | Users with the role type TIS Admins should be alerted in the event that there is "unusual" activity tracked relating to logins | Who should be alerted, about what and when? |
| TIS-NFR-M-2 | Ongoing feedback | Feedback should be provided via MS Teams by internal users, trust feedback should be filtered through local offices and trainees by email to <TIS email address>? | Can/should an email address be provided for external users and Trusts? |
| TIS-NFR-M-3 | Performance metrics | To be agreed separately, via Google Analytics | Any other systems?? TBC with Chris |
| TIS-NFR-M-4 | Error tracking | All errors should be tracked by event, date,time, object, user(s) impacted | Where issues are found, how should they be tracked? |
| Maintenance | |||
| TIS-NFR-MA-1 | Functional updates | Functional updates shall be reviewed periodically and prioritised according to impact | |
| TIS-NFR-MA-2 | Scheduled downtime | Scheduled downtime should only happen outside of core working hours | When is it acceptable to have this? |
| TIS-NFR-MA-3 | Notifications (scheduled downtime) | All users should be notified of scheduled downtime via the site | How much notice to give users? |
| TIS-NFR-MA-4 | Notifications (unscheduled downtime) | All users should be notifie via email for unscheduled downtime | How much notice to give users? |
| TIS-NFR-MA-5 | Error tracking | Error tracking should be done according to categorisation of the errors | Linked to support model, speak to Naz |
| Audit | |||
| TIS-NFR-AU-1 | Record modification | All account/record modification shall be logged and displayed on UI; containing name of the person who made the change, date, time, object and change summary | |
| TIS-NFR-AU-2 | User actions | All user actions to be logged; containing name, date, time, object, change summary | |
| TIS-NFR-AU-3 | Login | All login attempts should be tracked - username, date, time, success rate | |
| TIS-NFR-AU-4 | Trainee email changes | All email change attempts should be tracked - username, date, time, success rate | |
| TIS-NFR-AU-5 | User password changes | All passowrd changes should be tracked - username, date, time, success rate | |
| TIS-NFR-AU-6 | System changes | Any change to asset or asset data should be through audited application interfaces (UI or API) or strictly controlled direct SQL access | |
| TIS-NFR-AU-7 | Reporting | Audit log data should be fully reportable from the data warehouse | NEW, added 02-feb (IO) |
| installation | |||
| Configuration | |||
| Backup & Recovery | |||
| Data Integrity | |||
| Operations | |||
Slack: https://hee-nhs-tis.slack.com/
Jira issues: https://hee-tis.atlassian.net/issues/?filter=14213