...
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; also check https://data.gov.uk/data/site-usage#totals |
| 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 with Reuben for Emanuele's analysis on this also check https://data.gov.uk/data/site-usage#totals |
| 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 X period of inactivity | Discuss with Chris |
| 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 | What should the trigger be for user deactivation? |
| 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? |
| 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 | |
| installation | |||
| Configuration | |||
| Backup & Recovery | |||
| Data Integrity | |||
| Operations | |||
...