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.


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.


  • 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


  • Storing data
  • Refined matching procedure
  • Retrieving information
  • Scalability


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.