SRS Documentation
- Anru Nel (u20646284)
- Joshua Young (u20442018)
- Leonardo Wessels (u17229457)
- Tshegofatsho Motlatle (u17066736)
- Thebe Kgaphola (u18371435)
The vision of this project is to provide a customer relationship manager for a citizen who would like to report and receive feedback on a municipal issue that they are experiencing in their area. The goal is to provide an easy to follow, consistently updated, system that will serve as a way for a customer to keep track of their issues and a management system for city officials and technician teams trying to resolve the issue.
The need for this application is seen daily. With multiple reports of hundreds of "check-up" calls happening daily on our municipal grid (2000 Calls Linked to Power Outages, Electrical Outage Results in 800 calls, Power Outage Results in 3000 Calls) the need for a system which can streamline this process is almost essential. We intend to provide a ticketing system which allows for this check-up system with some automated features.
-
Normal User
This would define a typical everyday user of the GridWatch System. This user would use the system to create an issue, edit an issue, check information about their issue and view issues in their area. -
City Official
This would be a member of a city municipality who would use the system to dispatch issues, sort through all issues based on their features and view all issues that are open -
Technician Team This would be the group of people that receive dispatched issues from the City Officials. The tech teams would use this system to update progress issues, accept or deny new requests and provide other basic information about issues.
- GS shall allow a user to register an account with the GS
1.1. GS shall provide a user the same issue registration functionality as a guest
1.2. GS shall register tickets that are created by a user to that user
1.3. GS shall allow a user to view updates on a user's issue
1.4. GS shall keep a hidden rating of a user to measure the validity of their issue reports - GS shall allow a guest to register an issue
2.1. GS shall allow a power failure to be registered
2.2. GS shall allow a water supply failure to be registered
2.3. GS shall allow a pothole to be registered
2.4. GS shall allow a sinkhole to be registered
2.5. GS shall provide a guest facility to provide more information about the issue being registered
2.5.1. GS shall require a user to pin the location of the issue being registered
2.5.2. GS shall require a user to take a picture of the issue being registered
2.5.3. GS shall require a user provide a description of the issue being registered - GS shall provide a web-based portal (referred to as GSWP) for authorized officials
3.1. GS shall display user created tickets to an authorized official
3.1.1. GS shall allow a user to sort displayed tickets
3.1.1.1. GS shall allow an official to sort tickets by upvotes
3.1.1.2. GS shall allow an official to sort tickets by ticket progress
3.1.1.3. GS shall allow an official to sort tickets by pending acceptance status
3.1.1.4. GS shall allow an official to sort tickets by ticket opened status
3.1.2. GS shall display average time to complete similar issues
3.1.3. GS shall allow a ticket to be explored
3.1.3.1. GS shall allow an official to request the dispatch of a technical team
3.1.3.2. GS shall allow an official to view details about a user created issue - GS shall communicate newly registered issues to authorized officials
4.1. GS shall create an entry for the registered issue on the GSWP - GS shall provide a cell phone application for technicians
5.1. GS shall create work requests ticket for issues brought forward by authorized officials
5.1.1. GS shall allow a technician to request or deny work requests
5.1.2. GS shall upon a work request acceptance, allow a technician to communicate work request details with the public
5.1.2.1. GS shall communicate to the public a work requests work start date
5.1.2.2. GS shall communicate to the public a work requests estimated repair cost
5.1.2.3. GS shall communicate to the public a work requests estimated repair time - GS shall provide a cell phone application for the public
6.1. GS shall facilitate a user viewing all reported outages in their area
6.1.1. GS shall provide information about specific outages in a user's area
6.1.1.1. GS shall provide the estimated progress of a ticket to the user
6.1.1.2. GS shall provide the estimated cost of a ticket to the user
6.1.1.3. GS shall provide the ticket start date to a user
6.1.2. GS shall allow users to up-vote tickets for a higher priority
- Scalability
1.1. The system must be able to handle a few million users.
1.2. The system must be available on multiple platforms including Windows, MacOs, Android and IOS. - Reliability
2.1. The system must have an aspect of redundancy to cater for outages and problems that may occur such that the system can recover from disasters.
2.2. The GS must be available 24/7 since users must have the ability to report faults at any moment. - Maintainability
3.1. The system must be designed in such a manner that all the features are isolated from one another for easy maintenance. - Security
4.1. The users' data and other sensitive information must be encrypted. - Data integrity
5.1. The integrity of the users' data must be upheld by only allowing administrative users to access sensitive information.
