Requirement Breakdown

Uploaded by

aarif.ctinfotech

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

5 views

Requirement Breakdown

Uploaded by

aarif.ctinfotech

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 3

Requirement Breakdown

There are two, or possibly three user groups:

● Super Admin
● Admin
● Drivers

We need a web application, that is accessible from desktop and mobile devices. The design must
be modern and clean, and doesn’t necessarily have to be a fully bespoke design. We’ve found
lots of different Laravel admin dashboard themes that we could use, just ask, and we can work
together to find one that we like, and one that you’re happy to work with.

1) Drivers
Users should be able to visit the website / web app and apply to become a driver. Clicking the
apply button should trigger a multi-step form. Here is a demonstration of the Driver Registration
Form: https://mkd.chaosinternet.co.uk/driver-application-pack

Please note, the vast majority of the fields will be required and are disabled for demonstration
purposes, and validation will be required.

Once a driver has completed the registration form, we need to display a success message, and
details on what they need to do next (they will need to physically visit our office, we can provide
the wording for this message).

At this stage, a Driver user should be created, in a ‘pending state’. An email confirming the
application must be sent to the driver. The driver can login with their email address, so we need
to check it is unique. The best way for them to set a password, I don’t know.

Another email notifying the admins of a new registration must also be sent.

The admin will then be able to follow a link from the email, taking them to the newly registered
user, where they can either confirm or deny the user. If denied, an email should be sent to the
driver confirming they have been denied. We can provide the wording for this.

If approved, an email should be sent to the driver confirming they have been approved, including
a link to complete their PPE Form.
An approved user can either click the link in their approval email to be taken to the web app, or
they can visit the web app directly and upon logging in, they must be presented with a form that
needs to be filled out before they can progress any further.

We also require some further fields in the driver profile that were not present in the initial sign up
forms. Initially, admins will go to the driver profile and upload photos/pdf files for relevant
documents like licences, certifications, or any other required documents. O

PPE Form
Once the driver has applied and have been approved, they must complete another short form.
Here is a demo: https://mkd.chaosinternet.co.uk/ppe-record/

Please note, the vast majority of the fields will be required and are disabled for demonstration
purposes, and validation will be required.

Once a driver is logged in and has completed the PPE form, an email should be sent to the
admins to state the drivers PPE form is complete.

The driver should be able to edit their sizes from their profile.
The driver should also be able to submit the form again at any point to send in a new request for
more equipment. This should be logged in the admin panel, and the admins should be notified.

Admin Panel
All of the drivers must be shown, probably best in a table. We want to be able to search and sort
our drivers based on the information they have provided in the forms. For example, we may want
to search for a driver without any convictions and has forklift and flatbed driving experience. We
can achieve this with a range of facets/filters and maybe AJAX for instant results.

On the admin panel homepage, it would be good to see a list of recently approved or denied
applications, latest PPE form requests and upcoming driver licence expiry dates, upcoming tacho
expiry dates, etc.

Incident Reporting

It should be possible that the driver can log in and report incidents/accidents. We call them
incidents (because damage to the vehicle isn’t always caused by an accident). Here is a demo of
the incident reporting form: https://mkd.chaosinternet.co.uk/driver-incident-report/

Please note, the vast majority of the fields will be required and are disabled for demonstration
purposes, and validation will be required.

2
Admins must be able to see a record of all driver incident reports. Drivers must be able to see
previous incident reports that they have submitted.

Staff can add internal notes/comments to incident reports for tracking purposes.

Logging & Auditing

This is where I feel we made need the Super Admin role, for one specific user. This user must be
able to access and view complete logs of everything on the system. Here are some examples:

● The Super Admin can see the date/time an admin approved a drivers application
● The Super Admin can see the time a driver submitted an incident report
● The Super Admin can see when a driver updates their profile

We literally need to log as much information as possible. This is very important, as it covers us
from the drivers, and also normal admins who like to say “I didn’t do that”. The super admin
should have concrete evidence of all actions completed. I expect this to grow quite larges, so
maybe make this searchable (eg: I want to search for all actions involving Admin Member A &
Driver Member C.