Executive Summary
This report provides a requirement specification for the creation of a new online system for the matching of clients and volunteers signed up to the service “Community Concern, run by the charity “Garden Partners”. The current system will be evaluated and a new one will be designed through the use of analysis elements such as requirements definitions, use case diagrams, use case descriptions, activity diagrams, and system life cycle approaches will allow us to create an efficient system for the charity.
Introduction
Garden Partners is a service created by the charity, Community Concern, that brings people in the community together through gardening. Volunteers who have free time and are knowledgeable in the field of gardening, are matched with elderly people to give them some assistance with their garden and to offer them the human interaction that is lacking in their lives.
Overview of the Current System
Problems with the Current System
The registration process is slow, the volunteers need to fill out three different forms. There is also some repetition of the forms, the first one asks for their details including gardening skills but the second form asks the volunteers to fill out information about their gardening skills.
The matching process is slow and requires the admin to do everything manually. It requires waiting on other people, and making multiple before they can progress.
There is a safety issue with the current system. Paper forms are kept in folders which can lead to security issues through theft and these documents are more difficult to back up.
The system is also going to be difficult to handle when more users are added. It is fine just now while there are six volunteers and twelve clients, but when they build the service up to where they want it to be, it is going to be complicated to sort through that much paper and make phone calls to that many people.
Objectives
- To modernise the current system
- Expanding the service through sustainability
- Build on their trustworthy reputation
- Provide governance reports
- To refine the matching process
- To scale the service up and offer it to all of Scotland
Scope
- Storing data
- Refined matching procedure
- Retrieving information
- Scalability
Requirements
Proposal for the New System
The new online system will allow volunteers to register by filling out their details in once section follows by another for the gardening skills, followed by another for health and safety which will then lead to a background check. Once the volunteer has registered they can login to an area where they can edit their profile, this will include the option to update their availability in case it changes and they will be able to update their postcode in case they relocate elsewhere. Another feature of the profile will be a status of their health and safety certificate, it will state how long they have before the current certification expires and once it says they have three months left a message will notify them as soon as they login so it is the first thing they see. The volunteers will also be able to leave feedback based on how the visit went.
The administrator will sign in using the login details that will be created for the admin. When they use the system they will create an event of a visit which will allow them to select a client and a volunteer. They will be able to view all of the saved users, but they will also be able to filter by the gardening skills and travel distance, from the client, of the volunteer. When selected, the visit’s details (date, time, volunteer, skills used and client) will be populated into the event. There will also be a section for feedback which will remain empty until the the volunteer and client provide it after the visit.
Clients will be able to register for an account. Once they have one they will be able to request a visit from the admin. Once they have been assigned to a visit and it has taken place, they will then be able to leave feedback on the visit.
The manager will be able to access information and statistics about users using the login details created specifically for use of the manager. This will be a database of all volunteers and clients on the system which will come with many different filters so the manager can create her reports.
The system must be secure as users will be using sensitive information when registering and logging into the system. The user experience (UX) of the system must match with the users’ capabilities, many older clients will be using the system so their skills in technology must be taken into consideration when developing it. One requirement was that the system should be compliant with GDPR data protection guidelines, however a requirement conflicts with that is that records should be kept for seven years. Under GDPR laws, data must be deleted as soon as it is no longer required (McElhill, 2019), and therefore if a user has left the service, then the records cannot be kept for this long.
Requirements Tables
| Functional Requirements | |||
|---|---|---|---|
| Code | Requirement | Description | MoSCoW |
| FR001 | Volunteer registration | Volunteers must be able to sign up for the project by entering their name, address, main area of gardening and transportation | M |
| FR002 | Enter gardening skills | Volunteers must enter their gardening skills | M |
| FR003 | Health and safety certificate | Volunteers must have an up to date health and safety certification | M |
| FR004 | Background check | Volunteers must take a background check on their criminal record | M |
| FR005 | Match client with volunteer | The admin must match volunteers and their gardening skills with clients | M |
| FR006 | Filtering information | The admin will be able to filter by travel distance and skill type to match pairs. The manager will also filter when she views all users of the system to create reports | M |
| FR007 | Store information about visits | The system should record information about the visit date, time, volunteer, skills used, client and feedback from the volunteer and client | S |
| FR008 | Leave feedback | The client and volunteer will leave feedback based on how they feel the visit went | S |
| FR009 | Trusted friends and family | The client can select certain volunteers that they have enjoyed spending time with which would then show them notifications of future visits. They can also access specific visits and view information from them like photos | C |
| FR010 | Keep track of application process | The system would track where about in the application process volunteers are | W |
| FR011 | Keep track of health and safety process | The system should track the status of the volunteer’s health and safety certificate | S |
| FR012 | Send notification for healthy and safety certification | The system should send a notification to a volunteer to tell them their certification needs to be renewed. This should be sent three months before the renewal date | S |
| FR013 | Keep track of safeguarding status | The system will track the status of a volunteer’s criminal background check as three different statuses (OK, awaiting result or rejected) | M |
| FR014 | Upload pictures | Clients could upload any photos from the visit | C |
| FR015 | List by postcode area | The system should list by postcode to see where the closest volunteers and clients are. This will allow the owners of the service to see where they need to recruit from | S |
| FR016 | Show clients/volunteers on a map | When the system filters, the clients and volunteers would be located on a map for a more visual representation | W |
| FR017 | Store user statistics | The system must store statistics about the users of the service like how many volunteers are part of it or how many clients they work with | M |
| FR018 | View profile | Volunteers must be able to view their profile | M |
| FR019 | Edit profile | Volunteers must be able to edit their profile | M |
| FR020 | Login (assumption) | Volunteers, clients, the admin and the manager must be able to login | M |
| FR021 | Edit availability (assumption) | Volunteers must be able to edit their availability of when they can be matched | M |
| FR022 | Edit postcode (assumption) | Volunteers must be able to edit their postcode incase they relocate | M |
| FR023 | Create a visit event (assumption) | The system must create a visit when a volunteer and client are matched | M |
| FR024 | Request visit (assumption) | The client must be able to request a visit to be scheduled | M |
| Non-Functional Requirements | |||
|---|---|---|---|
| Code | Requirement | Description | MoSCoW |
| NFR001 | GDPR compliant | The system needs to comply with the new GDPR data protection laws | M |
| NFR002 | Secure | Lots of sensitive information is going to be stored | M |
| NFR003 | Appropriate user experience | The UX of the website must meet the technological skills of their users | M |
Use Cases
Use Case Diagram
Use Case Descriptions
Use Case: Get information from the system
Actor(s): Manager
Goal: To find out how many volunteers the service has, the status of their health and safety/safeguarding certification and the different gardening skills they cater for
Overview: The manager logs in to the system and sees a table of all of the users. She filters out the registered clients so only the volunteers appear and at the bottom of the table is a total of how many volunteers are showing. To find out the health and safety status of volunteers, she filters between “OK”, “renewal within three months”, and “none” checkboxes and sees how many volunteers are in each category. To find out the safeguarding status of volunteers, she filters between “OK”, “awaiting results”, and “rejected” checkboxes and sees how many volunteers are in each category. To view the gardening skills the volunteers share she locates the set of checkboxes, selects the options she would like to select and sees how many skills the service offers.
Use Case: Get information from the system
Actor(s): Manager
Goal: To find out how many clients are registered to the service, and how many visits each week they organise
Overview: The manager logs into the system and sees a table of all the users. She filters out the volunteers so only clients appear and the number of clients displays at the bottom of the table. To find out how many visits take place, she filters the results by selecting a start date and an end date. The visits that happen between the dates she has selected then appear at the bottom of the table and display how many results are showing.
Use Case: List by postcode area of volunteers and clients
Actor(s): Manager, Administrator
Goal: To find out where they can recruit clients and volunteers
Overview: The manager and the administrator sit down together and log into the system. They would like to find out which postcode areas are lacking in volunteers and clients, so they sort the table by postcode, and this allows them to see where they are lacking. There is also the option of viewing it by map where circles with a number (of users) are displayed over parts of the country. The bigger the circle, the more users in that location.
Use Case: Setting a visit up
Actor(s): Administrator, Client, Volunteer
Goal: Explain how the administrator arranges a visit
Overview: The client requests a visit from the admin and they select a volunteer. If a volunteer is unavailable, the admin tries again. If none are available then the client needs to request a new time and date. When one is available the admin informs the client of the visit details. When the visit has taken place the admin requests feedback and updates the spreadsheet when they receive it.
Actor Descriptions
The Manager uses the system to retrieve data and write reports, and to sort the users by postcode to assist in recruiting new volunteers and clients. The role of the manager can only be carried out by the actual manager.
The Administrator uses the system to create visits by matching clients with volunteers, and also to sort users by postcode.
The Client uses the system to, sign in, request a visit and leave feedback on that visit.
The Volunteer uses the system to sign and leave feedback on the visit.
Activity Diagram
The manager requested that we model the current matching system in order for her to gain a better understanding of how the administrator currently organises a visit.
