Overview

Background

The IS Alerts system has acquired a more user-facing role as users are told to go to IS Alerts is a service is showing problems and also as an indicator of forthcoming outages and risk period.

However, as its origins lie in its being a tool for technicians to log and manage infrastructure and software upgrades, patches and other changes, there is now a need to enhancence the current screens and present the information in a more appropriate way to these different audiences.

Scope

The scope is to enhance the IS Alerts pages as much as possibleto provide a much improved interface for service users, within a contrained budget of 50 days effort from IS Applications.

This has meant some of the original proposal's deliverables cannot be achieved in this project, and the prioitisation reflects this.

As there is a cap on budget, then we cannot deliver any migration to a more enterprise database (nor move the Alerts DB and Application to an infrastructure outside the university's). Therefore, development will continue on the current Access database which carries the risk of not performing as the increased functionality is developed in the application.

Objectives

Offer more user-friendly pages to staff and students who are looking for service status updates and also service alerts.

Offer feeds and integrations with other websites so that the data can be consumed by other university channels.

Build upon existing code as much as possible to avoid effort in rewriting of code.

Deliverables

As a prioritised list, which will be delivered according to the budget.

1 Improved User Experience (Musts)

• Priority M1 Enhanced pages to 'separate' the technical views of the data to the non-technical.
• Priority M2 Content that is user-facing describing in non-technical terms the impact on a service
• Priority M3 A look and feel to the pages and navigation that is closer to the University Website to keep a consistent experience for the user.  

2 Enhancements that will improve the recording and management of changes for technicians and their managers, improve the approval process. (Shoulds)

• Priority S1 Remove of old fields and lists that no longer apply.
• Priority S2 Reduce the number of mandatory fields needed when setting up an Alert, have mroe fields that can be completed later.
• Priority S3 Provide areas where information that is recorded is not shown to the public.
• Priority S4 Consolidate the create/update Unplanned and Planned Alerts pages where possible
• Priority S5 Clarification between 'engineer' who does the work, 'alerter' who sets up the change, 'authoriser'  who approves the Alert
• Priority S6 Improve the visibility of the audit trail.
• Priority S7 Define the 'Risk' field better.

Out of Scope

A decent editor for text only fields, unless the number of such fields is reduced.

Feeds and Integration (Could)

• Provide RSS/Atom feeds so tha other websites can consume the alerts to show on their own pages.
• Integrate with the unviersity Twitter and SMS services so alerts and status can be communicated directly to users.
• Link 'Quick Alerts' to Tweets and SMS.

Host the Alerts on an infrastrtcure residing outside the university's so that in the event of a major failure the information is still accessible. (Will Not Do This)

Benefits

A better source of information to studentd and staff, providing confidence in IS.  

Success Criteria

A series of enhancements that are agreed by the wider group os stakeholders as significant improvements on what we currently have.