Software Engineering

Software Requirements Specification

(SRS) Document
Russell Dixon
Simon Palenchar
Ryan Richardson
Erik Miller
Radford University Software Engineering
http://radfordwildcats.weebly.com/
3/14/2016

Wildcats

Review & Approval

Requirements Document Approval History
Approving Party
Project Manager

Version
Approved

Signature

Date
Ryan Richardson

2.0

3/15

Dr. T. L. Lewis

Requirements Document Review History

Reviewer

Version
Reviewed

Signature

Date

Group Member

2.0

Russell Dixon

3/15

Group Member

2.0

Eric Miller

3/15

Group Member

2.0

Ryan Richardson

3/15

Group Member

2.0

Simon Palenchar

3/15

Wildcats

Contents
1. Introduction........................................................................................................................3
1.1 Purpose of this document.............................................................................................3
1.2 Scope of this document................................................................................................3
1.3 Business Context..........................................................................................................3
2. General Description...........................................................................................................3
2.1 Product Functions.........................................................................................................3
2.2 Similar System Information.........................................................................................3
2.3 User Characteristics.....................................................................................................3
2.4 User Problem Statement...............................................................................................4
2.5 General Constraints......................................................................................................4
3. Functional Requirements...................................................................................................4
4. Interface Requirements....................................................................................................28
4.1 User Interfaces...........................................................................................................28
4.2 Communications Interfaces........................................................................................30
5. Performance Requirements..............................................................................................31
6. Other non-functional attributes........................................................................................31
6.1 Security......................................................................................................................31
6.2 Reliability...................................................................................................................31
6.3 Maintainability...........................................................................................................32
6.4 Reusability..................................................................................................................32
7. Operational Scenarios......................................................................................................32
8. Preliminary Use Case Models and Sequence Diagrams..................................................33
8.1 Use Case Model.........................................................................................................33
8.2 Sequence Diagrams....................................................................................................33
9. Updated Schedule.............................................................................................................34
10. Appendices.....................................................................................................................36
10.1 Definitions, Acronyms, Abbreviations.....................................................................36
10.2 References................................................................................................................36

Wildcats

1. Introduction
1.1 Purpose of this document
The purpose of this document is to define our product, its functional, interface, and
performance requirements, as well as its non-functional attributes and operational
scenarios. This document will also contain use case models, sequence diagrams, and
updated schedule. The document is intended for our software engineers.

1.2 Scope of this document

This projects requirements elicitation team, system engineers, and developers consist of
Erik Miller, Ryan Richardson, Simon Palenchar, and Russell Dixon. This projects
customer base will be businesses with delivery operations. The users will be the managers
of the delivery businesses and their delivery drivers. The constraint on the requirement
elicitation process is our schedules and our deadline, April 4th.

1.3 Business Context

Dominos (2016) business website describes themselves as Founded in 1960,
Domino's is the recognized world leader in pizza delivery operating a network of
company-owned and franchise-owned stores in the United States and international
markets. Domino's is a company of exceptional people on a mission to be the best pizza
delivery company in the world..

2. General Description
2.1 Product Functions
The product is a system comprising of a multi-route optimizing app as well as a
companion manager-side website that tracks multiple app users. The driver will have a
button on the app to return his location and timestamp to the managers companion
website.

2.2 Similar System Information

This system is similar to the existing apps Waze, Google Maps and MapQuest. Our
product will differ in that our product will have a companion manager-side website to
track multiple drivers. Waze, Google Maps, and MapQuest all have strength in their
ability to optimize multiple routes with a specific endpoint. Our app requires no endpoint
for route optimization and has a timestamp feature to show when drivers are returning.
Waze, Google Maps, and MapQuest are all tailored toward individuals and have no
manager side functionality.

2.3 User Characteristics

The users will not need very much training for our system due to its fairly intuitive
design.

Wildcats

2.4 User Problem Statement

The users need our system to increase the control that managers have over their drivers
while they are on the road, as well as to more accurately time food so that it is fresh when
the driver gets back to the store to deliver more.

2.5 General Constraints

Constraints upon the design team are our due date of April 6, 2016 for the requirements
document and April 22, 2016 for the final project.

3. Functional Requirements
1. The manager shall have a textbox to enter his username.
1. Description
The website must have a textbox for the manager to enter their unique
username in order to log into their account.
2. Criticality (4/5)
The website needs a login feature with usernames in order to differentiate
between users. Without this feature no matter who you are you would be able to see
all drivers anyone has connected to the site.
3. Technical Issues
Preconditions:The textbox must be editable. The textbox must be long enough
to support enough characters. Must be intuitive to write username in textbox.
Postconditions: Username will be in box.
4. Risks
It isnt intuitive to put username here.
Minimization: Have textbox filled with Username as default.
5. Dependencies with other requirements
Dependent on the login page being up.
2. The manager shall have a textbox to enter his password.
1. Description
The website must have a textbox for the manager to enter their password in
order to log into their account.
2. Criticality (4/5)
The website needs a login feature with passwords in order to differentiate
between users and keep the accounts safer. Without this feature no matter who you
are you would be able to see all drivers anyone has connected to the site.
3. Technical Issues
Preconditions:The textbox must be editable. The textbox must be long enough
to support enough characters. Must be intuitive to write password in textbox.
Postconditions: Password will be in box. Password will be in dots to add
security
4. Risks
It isnt intuitive to put password here.
Minimization: Have textbox filled with ******* as default.

Wildcats

5. Dependencies with other requirements

Dependent on the login page being up.
3. The manager shall be able to log in to his account.
1. Description
The website must have login feature with usernames and passwords so that
different stores/managers can access their corresponding drivers.
2. Criticality (5/5)
The website needs a login feature with usernames and passwords in order to
differentiate between users and provide security to the system.
3. Technical Issues
Preconditions:Username must be correct. Password must correspond with
username. Log in button must be pressed.
Postconditions: Manager will be directed to the Management page.
4. Risks
Managers username or password is wrong.
Minimization: Send an error message.
Manager forgets username or password.
Minimization: Create a new account.
Database unavailable
Minimization: Send an error message and apology.
5. Dependencies with other requirements
Dependent on the login page being up as well as the username and password
textboxes being visible and editable.
4. The manager shall have a driver Management page
1. Description
The website must have a Management page separate from the other pages
for organization and ease of use.
2. Criticality (5/5)
This page will be the core page for managers to keep track of their drivers.
3. Technical Issues
Preconditions: Manager must have an account. Manager must have logged
on.
Postconditions: Management page will contain a list of active drivers, buttons
for editing and adding drivers, list of drivers their timestamps and their locations.
4. Risks
Page becomes out of date.
Minimization: Update features of page with current coding standards.
Page features are not visible on mobile.
Minimization: Test for scalability on different screen sizes during testing.
5. Dependencies with other requirements
This depends on the manager being able to log in.

Wildcats

5. The manager shall have a table with drivers, their last location, and their timestamps.
1. Description
The Management page of the website will contain a list of drivers, their
timestamps and their locations ordered from the newest at the top to the oldest at the
bottom.
2. Criticality (5/5)
This is arguably the most important part of the management section of our
system. This allows the manager to see what locations their active drivers have
visited and when. It will even allow the managers to see when drivers are coming
back.
3. Technical Issues
Preconditions: Manager must be logged on. Management page is up.
Postconditions: Manager will see all drivers timestamps, locations and
usernames from the time he's logged on until now.
4. Risks
Table becomes too large to display on web page.
Minimization: Have vertical and horizontal scrollbars.
5. Dependencies with other requirements
This requirement depends on the Management page being open.
6. The manager shall have a list of active drivers.
1. Description
The management page of the website will have a list of all drivers currently
logged on.
2. Criticality (2/5)
This is not a necessary attribute but having it helps the manager easily see
current drivers. Without this list we could still see drivers, their locations, and their
timestamps with the other list.
3. Technical Issues
Preconditions: Manager is logged on. Management page is up.
Postconditions: All and any active users are displayed in this list.
4. Risks
Driver doesnt log out properly.
Minimization: Ping driver device to see if they are still online.
List becomes too large for web page.
Minimization: Use scrollbars vertically to create extra room.
5. Dependencies with other requirements
This requirement depends on the Management page being open.
7. The manager shall have a Create User button.
1. Description
The management page of the website section of our system must have a
Create user button that links the management page to the New User Creation page.

Wildcats

2. Criticality (5/5)
Without the ability to make new users the manager would never be able to
add and keep track of their drivers.
3. Technical Issues
Preconditions: Manager must be logged on. Management page is up.
Postconditions: Create User button is located on top of management page.
4. Risks
Button does not intuitively tell user what it does.
Minimization: Clearly label button.
5. Dependencies with other requirements
This requirement depends on the Management page being open.
8. The manager shall be able to go to a separate Create User page.
1. Description
The website must a separate page to add new driver accounts. This page will
have a textbox for the new username and one for the new password of the driver
being added, as well as a submit button.
2. Criticality (5/5)
Without the ability to make new users the manager would never be able to
add and keep track of their drivers. By having this on a separate page we keep the
main management page from becoming cluttered.
3. Technical Issues
Preconditions: Manager must be logged in. Create User button must be
clicked.
Postconditions: Textbox for new Username and textbox for new Password will
be shown. Submit button will be showing.
4. Risks
Spacing between items on page make page confusing.
Minimization: Have page be scalable with size.
5. Dependencies with other requirements
This requirement depends on the Create User button being pressed.
9. The manager shall have a username textbox on the Create User page.
1. Description
On the Create User page the manager must have a textbox to enter the new
users username.
2. Criticality (5/5)
Without the ability to assign usernames to new Users it would be impossible
to tell which drivers are which.
3. Technical Issues
Preconditions: Manager must be logged in. Create User button must be
clicked.
Postconditions: The manager will have a textbox that will accept a certain
number of characters.

Wildcats

4. Risks
It isnt intuitive to put username here.
Minimization: Have textbox filled with Username as default.
5. Dependencies with other requirements
This requirement is dependent on the Create User page being up.
10. The manager shall have a password textbox on the Create User page.
1. Description
On the Create User page the manager must have a textbox to enter the new
users password.
2. Criticality (5/5)
Without the ability to assign passwords to new Users it would reduce the
security of our driver side app.
3. Technical Issues
Preconditions: Manager must be logged in. Create User button must be
clicked.
Postconditions: The manager will have a textbox that will accept a certain
number of characters.
4. Risks
It isnt intuitive to put new users password here.
Minimization: Have textbox filled with ******** as default.
5. Dependencies with other requirements
This requirement is dependent on the Create User page being up.
11. The manager shall have a submit button on the Create User page.
1. Description
On the Create User page the manager must have a button to activate the
action of adding the new user to his profile.
2. Criticality (5/5)
This button will be necessary to let the user tell the web page that he is done
entering the username and password.
3. Technical Issues
Preconditions: Manager must be logged in. Create User button must be
clicked.
Postconditions: The manager will have a textbox that will accept a certain
number of characters.
4. Risks
It isnt intuitive to put click this when wanting to submit username and
password.
Minimization: Have Button labeled as Submit.
5. Dependencies with other requirements
This requirement is dependent on the Create User page being up.

Wildcats

12. The driver shall have an Add Address button.

1. Description
On the address entry screen there will be a button that will make another text
field available for the driver to add another address to their queue.
2. Criticality (4/5)
The address entry screen needs this button so that drivers will be able to add
more than one address to their queue, and it allows the driver to see which addresses
they entered in what order.
3. Technical issues
Preconditions: The button must be enabled and there must be address text
fields that can be made visible.
Postconditions: The button is clicked and another address text field is made
visible.
4. Risks
The button could be clicked with the max amount of addresses text fields left
to
make visible.
Minimization: Make the button disabled when the max amount of address text
fields has been made visible.
The user could click the button without meaning to adding something they did
not mean to to the queue.
Minimization: Make the text fields still editable even after it has been clicked
and do not add the addresses to queue till they choose a G button.
5. Dependencies with other requirements
Dependent on the amount of address text fields and on the user logging in with
the
correct credentials.
13.The driver shall be able to add their address.
1. Description
The driver will have text fields where they can add a total of six address to
their
queue.
2. Criticality(5/5)
The application needs the drivers to be able to add addresses in text fields
because without the user input there are no addresses to route to.
3. Technical Issues
Preconditions: There will be a blank text field that is editable for the driver to
enter
an address.
Postconditions: The text field will contain the address the user entered.
4. Risks
The driver can enter an address incorrectly.
Minimization: The app can check address to see if they are valid before
adding them to the queue and if invalid display a error message.
5. Dependencies on other requirements
Dependent on the driver logging in correctly and the add address button
making
the other text fields visible and available of more than one address entry.
14. The driver shall have an error message appear when adding address fails.
1. Description

Wildcats

If the driver types in an address incorrectly there will be an error message that
will appear telling them they entered an address incorrectly.
2. Criticality(5/5)
This needs to be in place so there are no error when sending addresses to the
Google Maps and Directions APIs and the to make sure the driver goes to the correct
destination.
3. Technical Issues
Preconditions: The driver has entered an address into an address text field and
Presses a GO button.
Postconditions: The application has seen that an address entered is not a valid
address and sends the error message
4. Risks
The applications test to see if an address is valid causing the message to not
appear.
Minimization: Test the applications address validity test rigorously.
5. Dependencies on other requirements
Dependent on the applications address test and, and that the address text
fields are available and taking input correctly.
15. The driver shall have a list of every address added so far.
1. Description
The application will show the address already entered in their respective text
fields where they can see them and also edit them if need be.
2. Criticality(4/5)
The driver needs to see every address they have entered on the screen in the
text Fields so they know in what order they entered them and if they made an error in
entering them.
3. Technical Issues
Preconditions: There will be empty address text fields that are editable.
Postconditions: The address text fields will be full with an address in each and
they
Are still editable.
4. Risks
The driver enters an address in wrong
Minimization: Let the drive edit the addresses that they have already typed in.
5. Dependencies on other requirements
Dependent on the address text fields and the another address button.

16. The driver shall have a log out button on the Address entry page.
1. Description
On the address entry screen there will be a button labeled log out at the
bottom of the screen that will allow them to log out.
2. Criticality(4/5)
Drivers need to be able to log out on any screen including the address entry
screen so the drivers working list on the manager's website is not wrong because
someone wasnt able to log out because there was no button.
Wildcats

10

3. Technical Issues
Preconditions: There will be a button labeled Log Out on the bottom of the
screen.
Postconditions: The button will have been pressed and the driver will be
logged out.
4. Risks
The driver clicks the log out button on accident and doesnt want to log out.
Minimization:Show a message asking if they are sure they want to log out.
5. Dependencies on other requirements
Dependent on the address entry page and being able to log out.
17. The driver shall be able to log out from the Address page.
1. Description
The driver will be able to press the Log Out button and take them to the log
in
screen.
2. Criticality(4/5)
If there is a Log Out button on the address entry screen then drivers need to
be
able log out on that screen or that button does nothing or can confuse the
driver
3. Technical Issues.
Preconditions: The Log Out button will have been pressed.
Postconditions: The drivers device will be taken back to the login screen.
4. Risks
The log out operation does not work correctly
Minimization test the operation rigorously.
5. Dependencies on other requirements
Dependent on the log out button and the login screen. .
18. The driver shall have an GO Optimized button.
1. Description
On the address entry screen there will be a button labeled GO Optimized
near the bottom of the screen.that will navigate their routes optimized based on time.
2. Criticality(4/5)
Drivers need a Go Optimized button so they have the option to optimize their
route based on time which is one of the main premises of the application.
3. Technical Issues
Preconditions: There will be a clickable button labeled Go Optimized near
the
bottom of the screen with addresses in the tech fields.
Postconditions: The button will be pressed and the driver will be able to
navigate
an optimized route and addresses in the text fields.
4. Risks
The button does not take the driver to the navigation screen
Minimization: Test the button often.
5. Dependencies on other requirements
Dependent on the optimized route operation and the navigation screen.
19. The driver shall be able to choose an Optimized Route.
1. Description
The application will optimize the addresses order based on time and route the
driver.
2. Criticality(5/5)

Wildcats

11

Drivers have the option between an optimized route and an As Is route and to
make sure they have both options they need to be able to choose which type if
route they
would like like an optimized route.
3. Technical Issues
Preconditions: The Go Optimized button will be clicked with
addresses in
the text fields.
.
Postconditions: The list of addresses is reordered to get the driver through their
entire route with the best time and the navigation screen is shown.
4. Risks
The route is not optimized.
Minimization: Test the optimization operation often
5. Dependencies on other requirements
Dependent on the Go optimized button.
20. The driver shall be able to get a Cannot Connect to GPS error message.
1. Description
If the drivers phone is not able to connect to their location or has no service or
any other impairment the driver will receive a :Cannot Connect to GPS error
message.
2. Criticality(3/5)
If the driver's phone cannot connect to the GPS they will need a error message
them their route request cannot be handled at that moment.
3. Technical Issues
Preconditions: The drivers device cannot connect to GPS and the driver clicks
one of the GO options.
Postconditions: The application shows an error message saying the device
cannot connect to GPS at the moment.
4. Risks
The GPS connects while the message is still being displayed
Minimization: Add a retry button on the message.
5. Dependencies on other requirements
Dependent on the connection to internet and having the device location
available.
21. The driver shall have an GO As Is button.
1. Description
The address entry screen will have a GO As Is button that allows the drive to
set their route order.
2. Criticality(4/5)
If the driver wants to make the order of the addresses manually they will need
a
Go As Is button so their list does not get optimized.
3. Technical Issues
Preconditions:Near the bottom of the screen there will be a clickable button
labeled
GO As Is with addresses in the text fields..
Postconditions: The button is clicked and the application displays the
navigation screen with the addresses routed the way they were inputted.
4. Risks
The button does not take the driver to the navigation screen
Minimization: Test the button often.
5. Dependencies on other requirements
Dependent on the as is operation and the navigation screen.
Wildcats

12

22. The driver shall be able to choose anAs Is Route

1. Description
The driver will be able to order their addresses the way they think best or they
order they need instead of it being computed and optimized based on time.
2. Criticality(4/5)
If the driver wants to make the order of the addresses manually they will need
a
Go As Is option which sets the order of the addresses as the order they were
inputted
in case the driver has priority addresses.
3. Technical Issues
Preconditions: The GO As Is button has been clicked and there are addresses
in
the text fields.
Postconditions: The application routes the driver to the addresses in the order
they
had inputted them.
4. Risks
The as is operation does not work.
Minimization: Test the as is operation often
5. Dependencies on other requirements
Dependent on the as is button and the connection to the internet and access to
the
device location
23. The manager shall be able to create a new user.
1. Description
The manager can create user accounts that will be saved to the database.
2. Criticality (5/5)
Users need accounts to log in and use the application.
3. Technical Issues
Pre-conditions: Must have access to a create user page. Website must be up and
working. Manager must be logged in with proper credentials. Database must be up.
Database must accept pushes from the website and save these accounts to the user
table.
Post-conditions: User information must be stored in database. User should be able to
log in with these credentials once created.
4. Risks
Database may not accept pushes from the website. We will seek help when needed
and do tutorials. Database may not save new users. Must run testing to fix any bugs.
Manager may not understand how to create a user or the guidelines for a user account.
Instruction will be provided in a manual.
5. Dependencies with other requirements

Wildcats

13

Must have database up and working. Website will be pushing new users to the
driver/user table. Database must save these new users to the table. Manager will
need a create page. Manager will need a link to get to the create page. Website must
be up and working properly. Manager must have logged in with valid credentials.
24. The manager shall be able to access an Edit page.
1. Description
Manager must be able to access edit page.
2. Criticality (3/5)
The Edit page is for convenience, it is not crucial.
3. Technical Issues
Pre-conditions: Must have internet. Manager must log-in. Manager must have
account stored on database. Database must be up and working. Credentials must be
validated. Link to edit page must be up and working. The link will be on the banner.
Post-conditions: Access to edit page grants the ability to edit and remove drivers.
Manager will also see a list of those drivers.
4. Risks
Manager might not have internet. Manager may not be able to log-in. This could be
because of incorrect credentials or a malfunction. We need to give manager the
ability to retrieve their username and password. We need to run tests on log-in to
make sure its working properly. Link to edit page may be broken. Need to test our
website links thoroughly.
5. Dependencies with other requirements
Edit page link must be up and working on the banner. The website must be up and
working. The manager can access this page once they have logged in. Need log-in
page. Need database up and working with stored manager credentials.
25. The manager shall have a list of his drivers and their passwords on the Edit page.
1. Description
The edit page will display a list of drivers and their passwords pulled from the
database
2. Criticality (3/5)
This list is to allow the manager to easily edit and remove drivers. It isnt crucial but
convenient. The manager can also view names and passwords in case log-ins are
forgotten.

Wildcats

14

3. Technical Issues
Pre-conditions: Must have an edit page to display the list. Must have a database up
with a driver table. Website must be able to pull information from the database. Must
be displayed in a list. The list will have two columns, one for name and one for
password.
Post-conditions: List will have remove buttons next to each driver. The list will be
editable by the manager.
4. Risks
Poor time management may lead us to not implement this function. We have to keep
following the schedule. We may not be able to have the website and database
interacting correctly, we will be seeking help when needed and consulting tutorials.
5. Dependencies with other requirements
Edit page must be up and working. Page must be accessible by manager. Database
must be up and working with a drivers table. Website must be able to pull table from
database and display the data in a list. Manager must be able to edit this list and
changes will be reflected in the database.
26. The manager shall have a remove button next to each driver name on the Edit page.
1. Description
A remove button will be displayed next to drivers in the drivers list on the Edit page.
2. Criticality (3/5)
Removing drivers from the database is not critical but very helpful to the manager.
3. Technical Issues
Pre-conditions: Must have a Edit page to place the button on. Must display the driver
list to remove from. Remove button should display next to individual drivers.
Website must be up and working and accessible by the manager.
Post-conditions: The remove button will have an action listener that will enable the
manager to delete a driver from the database and by that, the driver list.
4. Risks
Poor scheduling would be the only reason this is not implemented. Buttons are easy
to create. We will keep up to date with our schedule and communicate effectively. If
we fall behind we will have to put in extra time and work more efficiently.
5. Dependencies with other requirements

Wildcats

15

The remove button must be displayed by the page. It must be clickable. When
pressed, it should remove that driver from the database. The list should be updated
accordingly.
27. The manager shall be able to remove drivers.
1. Description
The manager will be able to remove drivers from the database on the edit page.
2. Criticality (3/5)
This function is not critical but very helpful to the manager.
3. Technical Issues
Pre-conditions: List of drivers must be displayed. There must be an option or button
to allow the manager to easily remove a driver from that list.
Post-conditions: The database must reflect these changes. The driver is removed from
the list.
4. Risks
Poor time management may lead us to not implement this function. We have to keep
following the schedule. We may not be able to have the website and database
interacting correctly, we will be seeking help when needed and consulting tutorials.
5. Dependencies with other requirements
The website, specifically the edit page, must be able to pull the driver list from the
database. The manager must be able to edit that list. The database must reflect those
edits.
28. The manager shall have a edit button at the bottom of the Edit page.
1. Description
An edit button at the bottom of the Edit page will enable the manager to edit user
account information.
2. Criticality (3/5)
Manager being able to edit users isnt critical but very helpful. Wed like the manager
to edit user accounts so we dont have to.
3. Technical Issues
Pre-conditions: Edit page must be up and working. Manager must be able to access
the page. Edit button must be clickable.
Post-conditions: Edit button should enable manager to edit user accounts,
Wildcats

16

4. Risks
Easily satisfied condition. Only problem may be not getting to it, poor scheduling.
We have to keep progressing through our schedule and communicating what we have
accomplished.
5. Dependencies with other requirements
Edit button enables the list to be changed. The list is saved to the database.
29. The manager shall be able to edit existing drivers usernames and passwords.
1. Description
The manager will have access to an edit page where they can edit user information.
The edit page will be accessible via a banner hyperlink.
2. Criticality (3/5)
This allows the manager to change user account information. Helps with forgotten
usernames, passwords, and updating user accounts. Not very critical but very useful.
3. Technical Issues
Pre-conditions: Website must be up and working with a edit page. Manager must be
able to successfully log in and be identified as a manager. Edit page must have list of
users and an action button to enable editing of their information. Must have an edit
button to enable user list to be edited.
Post-conditions: Edits must be saved to the database.
4. Risks
The manager may not be able to find the edit page. A manual will be provided with
instruction. The website may not function. Extensive testing will be done.
5. Dependencies with other requirements
The edit page has to pull user accounts from the database and display them in a list
with a button to edit them. The database must be updated when the user submits
changes.
30. The drivers device shall have location services activated on their phone.
1. Description
Location services enables GPS, giving the users position in latitude and longitude.
2. Criticality (5/5)

Wildcats

17

The users location is needed to provide directions and display a map of where they
are.
3. Technical Issues
Pre-conditions: GPS capability and have the option to turn it on
4. Risks
Android smartphones should have GPS capabilities. We can not ensure they do.
5. Dependencies with other requirements
GPS coordinates are used by Google Maps to display current location and Google
Maps Directions to give directions from current location. The queue would be
ineffective because directions could not be provided.
31. The driver shall have Google Maps downloaded on their phone.
1. Description
The driver must have the Google Maps application downloaded.
2. Criticality (5/5)
Without Google Maps the driver will not see a map and the application can not
receive current street address.
3. Technical Issues
Pre-conditions: Must have internet to connection to download Google Maps.
No post-conditions.:
4. Risks
Driver may not have internet connection.
5. Dependencies with other requirements
Google Maps is used to display the map with the drivers location. Google Maps
passes locations to Google Maps Directions.
32. The drivers device shall have internet access.
1. Description
The driver must have internet access on their mobile device.
2. Criticality (5/5)
Wildcats

18

Without internet access, the user can not talk to the database and website. The user
will also not be able to get directions.
3. Technical Issues
Everything is a post-condition to having internet access. Nothing works without it.
4. Risks
We cant help it if a drivers phone can not access the Internet. However, if the driver
has access and loses signal, we will save the queue saved locally on their phone.
5. Dependencies with other requirements
The user needs internet access to log-in, so all features provided after log-in depend
on this. The users credentials are checked by the database, if valid, log-in is granted.
If the user is a manager, they are given the manager page. If a driver, the user is taken
to the address queue page.
33. The driver shall have an app button that launches Deliverable.
1. Description
The driver will need an icon that will be placed on the home screen or in the
applications menu that will launch Deliverable for use.
2. Criticality (3/5)
Without such an icon, the user will be unable to easily distinguish Deliverable
from other applications on the users device.
3. Technical Issues
Different users will have different screen resolutions. Therefore, the
Deliverable icon must be given in a variety of images that will be displayed on high
resolutions screens to low resolution screens.
4. Risks
While updating to future versions, the app icon becomes the default android
app icon and is unrecognizable to the user. Minimize: always deploy with an app
icon.
The app icon is not immediately recognizable to the user because of its design.
Minimize: Design the icon with enough distinction from competitors.
5. Dependencies with other requirements
independent.
34. Only the manager shall have access to the Deliverable website.
1. Description
The manager is the only user type that will be able to make changes to the
driver accounts and view the active drivers.
2. Criticality (3/5)
Wildcats

19

The manager user is the only person who directly benefits from the
information provided on the website. Driver users should not be able to change driver
accounts from a managers perspective.
3. Technical Issues
The manager should be the only user able to access and make changes to the
4. Risks
The driver is able to access the website from a managers computer while the
manager is away. Minimize: provide a timeout to the manager site so they have to log back
in.
The website crashes and the manager is unable to access it. Minimize: shop
around for web hosts and choose carefully.
5. Dependencies with other requirements
Independent.
35. The driver shall have a Title screen.
1. Description
The title screen will be the portal to the application for a driver.
2. Criticality (5/5)
The title screen will allow a user to log in and access the apps features.
3. Technical Issues
Preconditions: The driver is not currently logged in.
Postconditions: The driver will be logged in.
4. Risks
The driver is unable to launch the application. Minimize: support a variety of
different Android versions.
The application crashes. Minimize: implement the application in a resource
efficient manner.
5. Dependencies with other requirements
Dependent on the app being launched from the icon.(1)
36. The driver shall be able to enter a username into the Title screens username textbox.
1. Description
The user must be provided a textbox to enter in a username for access to the
application.
2. Criticality (5/5)
Without authentication, the user is unable to use the app. This is one piece of
the authentication.
3. Technical Issues
Preconditions: The driver is not currently logged in.
Postconditions: The driver will be logged in.
4. Risks
Wildcats

20

The driver is unable to launch the application.

The application crashes.
The device uses an old processor that makes it difficult to enter text
sometimes. Minimize: support a variety of Android versions.

5. Dependencies with other requirements

Dependent on the app being launched from the icon, and having a title screen.
(1, 3)
37. The driver shall be able to enter a password into the Title pages textbox.
1. Description
The user must be provided a textbox to enter in a password for access to the
application.
2. Criticality (5/5)
Without authentication, the user is unable to use the app. This is one piece of
the authentication.
3. Technical Issues
Preconditions: The driver is not currently logged in.
Postconditions: The driver will be logged in.
4. Risks
The driver is unable to launch the application.
The application crashes.
The device uses an old processor that makes it difficult to enter text
sometimes.
5. Dependencies with other requirements
Dependent on the app being launched from the icon, and having a title screen.
(1, 3)
38. The driver shall have a log in button at the bottom of the Title page.
1. Description
The user must be provided a control by which to submit their log in
credentials, to be granted access to the application.
2. Criticality (5/5)
Without authentication, the user is unable to use the app. This control is how
the user will submit their credentials to be validated by the backend.
3. Technical Issues
Preconditions: The driver is not currently logged in.
Postconditions: The driver will be logged in.
4. Risks
The driver is unable to launch the application.
The application crashes.

Wildcats

21

The submission could be intercepted by a third party. Minimize: sanitize

inputs and only allow certain characters as user names and passwords.
5. Dependencies with other requirements
Dependent on the app being launched from the icon, and having a title screen.
(1, 3)
39. The driver shall be able to log into their driver account.
1. Description
The driver, once he or she has entered in credentials and pressed the log in
button, must be given the ability to use the application on their mobile device, and be
tracked by the system.
2. Criticality (5/5)
Without authentication, the user is unable to use the app. The user must be
validated by the system to even be granted access, because other features of the
system depend on it, and data must be protected.
3. Technical Issues
Preconditions: The driver is not currently logged in.
Postconditions: The driver will be logged in.
4. Risks
The user forgets his or her password. Minimize: provide a way to reset the
password if forgotten.
The user forgets his or her username. Minimize: provide a way to remind the
user of their password.
The application crashes.
The device uses an old processor that makes it difficult to enter text
sometimes.
The user is an attacker attempting to gain access to the system. Minimize:
only allow certain characters, and sanitize the inputs.
5. Dependencies with other requirements
Dependent on the app being launched from the icon, having a title screen,
having a username textbox, a password textbox, and a log in button.(1, 3, 4, 5, 6)
40. The driver shall be able to get a Credentials Invalid error message.
1. Description
Should the driver attempt to use credentials that do not match to any record in
the system, the user should be notified that their attempt to log in was unsuccessful.
2. Criticality (4/5)
Without a notification of an unsuccessful log in, the user could be expecting to
gain access. It would not be immediately obvious that they are not logged into the
system.
3. Technical Issues
Preconditions: The driver is not currently logged in.

Wildcats

22

Postconditions: The driver will not be logged in, and will be given a message,
notifying them of the failure, on the title screen.
4. Risks
The driver is unable to launch the application.
The application crashes.
The request times out because of a bad internet connection. Minimize: provide
detailed messages to the user.
The user is an attacker attempting to gain access to the system.
5. Dependencies with other requirements
Dependent on the app being launched from the icon, having a title screen,
having a username textbox, having a password textbox, having a log in button, and to
be able to log in to their driver account.(1, 3, 4, 5, 6, 7)
41. The driver shall be able to get a Cannot Connect to System error message.
1. Description
If a users credentials are valid, and they are denied access to the system, they
must be notified that their attempt was unsuccessful.
2. Criticality (4/5)
A user may become confused that their request was denied, and may wonder if
it was because of their credentials, when in fact the system failed to make the request
for some other reason.
3. Technical Issues
Preconditions: The driver is not currently logged in.
Postconditions: The driver will not be logged in, and will receive a message
that their log in attempt was unsuccessful.
4. Risks
The driver is unable to launch the application.
The application crashes.
The device uses an old processor that makes it difficult to enter text
sometimes.
5. Dependencies with other requirements
Dependent on the app being launched from the icon, having a title screen,
having a username textbox, having a password textbox, having a log in button, being
able to log into their account.(1, 3, 4, 5, 6, 7)
42. The driver shall have an Address screen.
1. Description
To be able to navigate to an address, the user must first enter one in. They must
be provided a screen by which to do so.
2. Criticality (5/5)
Without a screen dedicated to entering in addresses, the user will be unable to
use the features of the application to assist them in their deliveries.

Wildcats

23

3. Technical Issues
Preconditions: The driver must be logged into the system.
Postconditions: The driver will have an address to navigate to entered into the
system.
4. Risks
The driver is unable to launch the application.
The application crashes.
The device uses an old processor that makes it difficult to enter text
sometimes.
The device loses internet connectivity and is unable to log in to the system
before this step. Minimize: provide a message to the user if their device is unable to gain
access to the system.
5. Dependencies with other requirements
Dependent on the app being launched from the icon, having a title screen,
having a username textbox, having a password textbox, being able to log into the
system.(1, 3, 4, 5, 6, 7)
43. The driver shall be able to enter an address into a textbox on the Address screen.
1. Description
To be routed to an address, the user must be able to enter it to be submitted to
the system.
2. Criticality (5/5)
Without a clear means by which to enter addresses, the user cannot use the
features of the application.
3. Technical Issues
Preconditions: The driver must be logged into the system.
4. Risks
The driver is unable to launch the application.
The application crashes.
The device uses an old processor that makes it difficult to enter text
sometimes.
5. Dependencies with other requirements
Dependent on the app having an address screen. (10)
44. The driver shall have a Directions screen.
1. Description
The driver will have a screen displaying a map and navigate button.
2. Criticality (5/5)
Driver needs this map to see where they are and navigate button to push
directions to Google Maps Directions.
3. Technical Issues

Wildcats

24

Preconditions: Address screen must be working properly to get to directions

screen. Queue must be transferred here as a parameter. Map must load properly.
4. Risks
Google Maps may not load map properly. We need to do tutorials provided by
Google. Driver may lose signal, displaying map incorrectly. Driver should be
notified of signal loss, queue should save to drivers phone.
5. Dependencies with other requirements
Address screen must be up and working. Hitting Navigate button opens
Google Maps Directions with queued addresses. Driver must have signal and location
services on.
45. The driver shall have Navigate button on the Direction screen.
1. Description
A button labeled Navigate will be provided on the direction page.
2. Criticality (5/5)
This button enables Google Maps Directions, which provides directions to the
destination.
3. Technical Issues
Preconditions: Direction screen must be working properly. User must have
gotten to this screen from Address screen.
Postconditions: The button must load Google Maps Directions and pass the
addresses as parameters.
4. Risks
User may not know what button does. A manual will be provided. Button
may not load properly. We will test it thoroughly.
5. Dependencies with other requirements
Current screen must load properly. Driver must have gotten to this screen
from Address screen.
46. The driver shall be able to go to the next address.
1. Description
Once the driver finishes a route, if he has another address in the queue he
should be able to go to it
2. Criticality (5/5)
Getting to the next route is the whole point of the queue.
3. Technical Issues
Preconditions: Driver has another address in the queue when he finishes an
address. Driver has a button to pass the next address to Google Maps Directions.
Postconditions: Current address is removed from queue once reached, next
address is passed to Google Maps Directions.
4. Risks
Wildcats

25

Queue may work improperly. We must do extensive testing on the queue.

Driver may not know queue is empty. Next address button should not be given unless
there is an address in the queue.
5. Dependencies with other requirements
Queue must be working. Queue must not be empty. Queue should pass
addresses properly to Google Maps Directions.
47. The driver shall have a Next button on the Direction page.
1. Description
The driver will have a button labeled Next on the Direction page
2. Criticality (5/5)
This button is important because it implements the cycle of addresses through
the queue.
3. Technical Issues
Preconditions: Direction page must be up and displayed properly.
Postconditions: Clicking the button removes the current address from the
queue, queue updates, next address is now the current address.
4. Risks
Button may not work properly. Button may not remove current address.
Queue may not update. Need to test thoroughly. Driver may not know what button
does, a manual will be provided but it should be intuitive.
5. Dependencies with other requirements
Directions page must be working properly. Next button cycles the queue.
Queue must function properly.
48. The driver shall be able to log out from the Direction page.
1. Description
The driver will have the ability to log out from the Direction page.
2. Criticality (2/5)
This isnt a crucial feature, but it is helpful for the driver.
3. Technical Issues
Preconditions: Need a log out button to enable the action. Directions page
must be working properly. Database must be functioning properly. Driver will have
an active attribute that records if the driver is logged in or out.
Postconditions: Logging out should take the driver to the log in screen. Driver
will be marked as inactive in the database.
4. Risks
Driver may log out accidently. Button must not be easily hit by mistake. Do
user testing to make sure the button is in an ideal location.
5. Dependencies with other requirements

Wildcats

26

Database must exist storing users. Logging out will set the driver to inactive.
The driver will not display on active drivers list once logged out.
49. The driver shall have a Log out button on the Direction page.
1. Description
A button labeled Log out will be provided on the Direction page.
2. Criticality (2/5)
This isnt a crucial feature, but it is helpful for the driver.
3. Technical Issues
Preconditions: Directions page must be working properly.
Postconditions: Pressing the button logs the driver out, taking them to the log
in screen. The database will update, marking the driver as inactive.
4. Risks
Driver may log out accidently. Button must not be easily hit by mistake. Do
user testing to make sure the button is in an ideal location.
5. Dependencies with other requirements
Screen must display properly. Database must exist storing users. Logging out
will set the driver to inactive. The driver will not display on active drivers list once
logged out. Log in page must be brought up correctly after button is pressed.
50. The driver shall have a Return button on the Direction page.
1. Description
A button labeled Return will be provided on the Direction page.
2. Criticality (5/5)
Return button tells the manager the driver is returning and will send the driver
to a directions page with his store address loaded
3. Technical Issues
Preconditions: Directions page must be working properly. Managers website
must function properly
Postconditions: Pressing the button sends the driver to a directions screen with
their store address. A timestamp and last address of the driver will be displayed to the
manager.
4. Risks
Driver may hit the button accidentally. Button must not be easily hit by
mistake. Do user testing to make sure the button is in an ideal location. Button may
not function correctly. Must run extensive tests.
5. Dependencies with other requirements
Screen must display properly. Database must exist storing users. Pressing the
button will display the drivers information, timestamp, and location to the manager.
New directions page must load with drivers store address, giving the driver
directions.

Wildcats

27

51. The driver shall be able to get directions to return to the store.
1. Description
The drivers store address is stored in the database. The driver will be able to
get directions from his location to that address.
2. Criticality (5/5)
Driver needs to get back to the store after a delivery.
3. Technical Issues
Preconditions: Driver must want to return to store. Store address must be
saved in the database. Phone must be able to pull that address. Address is sent to
Google Maps Directions. Directions are displayed properly.
4. Risks
Wrong store address may be stored. Manager needs to keep database updated
with correct information. Driver will be able to see where he is going.
5. Dependencies with other requirements
Database must store correct home address. Phone must pull this address for
the user and send to Google Maps Directions. Directions must be displayed properly.
52. The manager shall have a login page on the website.
1. Description
The first page available to the manager is a log in page
2. Criticality (5/5)
Without a log in page we can not authorize access to subsequent pages.
3. Technical Issues
Preconditions: Page must display properly. Text fields must be provided to
enter log in information. Database must have manager credentials stored.
Postconditions: Manager can access subsequent pages once logged in.
4. Risks
Input fields create security holes. Will need to whitelist or blacklist characters
to sanitize inputs.
5. Dependencies with other requirements
Subsequent pages must load properly. Database must have manager
credentials stored.

4. Interface Requirements
4.1 User Interfaces
Once application opens, the first screen the user is brought to will be the log in screen. From here, the
user or manager enters their username and password. Two input text fields will be provided with
labels for each. A log in button will be located below the text fields.

Wildcats

28

If a user enters valid credentials, they are taken to the address queue screen. Here, the user will have a
text field labeled Enter First Address. At the bottom of the screen, there will be an Add Another
Address button. If a user selects this button, a text field will appear below the first address text box.
If they select it again, a text field will appear below the previous text field. A maximum of six
addresses will be able to be entered, so there will be enough room to fit six text fields before the Add
Address button. Two buttons will be provided below Add Another Address. One button labeled
Go Optimized and another labeled Go As Is. Hitting one of these advances you to the map
screen. Below these, buttons will be a Log Out button.
On the map screen, the top will be labeled with the current address. Below this, taking up most of the
screen, a map is displayed. This map shows where the driver is and directions to the current address.
Below the map, will be a Navigate bottom to provide turn-by-turn directions. At the bottom of the
screen will be three buttons: Next Address, Return To Store, and Log Out.
If a manager enters valid credentials, they are taken to a manager web page. The left side of the page
will be devoted to a table. The table will list drivers name, time stamp, and location of drivers who
have pressed the Return To Store button. A list of active drivers will be displayed to the right of the
table. A banner will be at the top of the page with four hyperlinks, Home, Create Driver, Edit
Driver, and Log Out.
Create Driver page will have two text fields, one on top. Top text field will be labeled Username:
and the bottom text field labeled Password: . A Submit button will be provided below these
fields. A banner will be at the top of the page with four hyperlinks, Home, Create Driver, Edit
Driver, and Log Out.
Edit Driver page will have a list of all drivers in the database. Next to each will be an X button
next to each driver to remove them. Edit and Update buttons will be provided at the top of the
page. A banner will be at the top of the page with four hyperlinks, Home, Create Driver, Edit
Driver, and Log Out.
Hitting Navigate opens Google Maps turn-by-turn on default settings.

4.1.1 GUI

Wildcats

29

4.1.2 CLI
No command line present.

4.2 Communications Interfaces

Device will send address to Google Maps Directions API. System is pulling map of current from
Google Maps API. System will communicate with a database to maintain user accounts and
information. Manager-side interface is provided by a website.

Wildcats

30

5. Performance Requirements
Response Time
.1 seconds: Add address, edit user, and remove user buttons.
< .5 seconds: Web page loads
< 1 second: Manager is authenticated through website
< 5 seconds: Users are authenticated on mobile device. Directions are displayed.
Map is displayed.
< 10 seconds: After navigate button is pressed, directions to address are displayed.
Driver returning data is sent to managers site after return button is pressed.
Workload
Deliverable will be capable of supporting 100 users in the current version, enough for a
whole store of employees. Only one user will have manager access. The website will be four
pages, three of which only viewable by the manager. The system will handle at least 3 pushes
per second.
Scalability
System is immensely scalable. After testing is conducted on first stores. More tables
and records can be added to the database. Database will need to be improved to increase
performance. System will be designed to handle entire franchises.
Platform
Deliverable will run on the Android and desktop computer platforms. Users will
access the app via a device running the Android operating system and through a web-browser
on a desktop computer. The web component of Deliverable will be built using the PHP
framework Laravel, and be run by an Apache server, using a MySQL database.

6. Other non-functional attributes

6.1 Security
Username/Password login, credentials must be verified. Inputs must be sanitized to prevent
injection. only managers can access manager page. Managers can edit/see/remove driver
information. Each user can have passcode on phone.

6.2 Reliability
Cell service for users can be in and out. System web interface and database should always be
up. Pushes can be resent if data loss or corruption occurs.

Wildcats

31

6.3 Maintainability
Manager will be creating, editing, and removing users. Database can expand. Users need to keep
mobile devices updated. Google Maps application must be up to date.

6.4 Reusability
Queue can be re-used for people who want to input addresses in a queue format. Log-in screen can be
re-used in many applications. Managers screen where users can be edited or removed can be
applicable. Pushing parameters from a mobile device to a website is the backbone of our code. We
can use this in any such interaction

7. Operational Scenarios
Scenario 1:
Initial assumption: The user has logged on, queue is empty. User enters three addresses into queue,
hits optimize Go button.
Normal: System optimizes addresses based on time. System places addresses into queue. First
address in queue is routed. Directions display.
What can go wrong: Addresses typed in wrong. Optimizer fails. GPS fails. Phone dies. Addresses
enter queue in wrong order. Addresses dont enter queue. Wrong address is routed. Address is not
routed. Directions dont display. Wrong directions display.
System state on completion: Directions to first location in queue are displayed.
Scenario 2:
Initial assumption: The user and manager have logged on. User presses Returning button because
he is on his way back.
Normal: The timestamp and the last address from the users queue are displayed under the users
name on the website to the manager. The last address is removed from the users queue. Users home
store address is entered. Directions to home store are displayed.
What can go wrong: Timestamp and address do not get pushed to the website. Driver GPS fails and
cant receive directions to store. Driver has wrong store entered as home store. System takes wrong
address from queue. Queue is already empty. Timestamp error. Website is down. Timestamp and
address show up under wrong user. More than home store address remain in queue.
System state on completion: Website is showing users last location and timestamp. The user has
directions back to the store.
Scenario 3:
Initial assumption: The user arrives at his destination in the queue. It is not his last address. User
clicks Next button.
Normal: Current address is removed from queue. Queue is updated, next address is pushed to front of
the queue. Address route loads and directions are displayed.
What can go wrong: Current address not removed. No more addresses in queue. Directions displayed
wrong. Next address not pushed to front of queue. Wrong address is pushed to the front of the queue.
Wrong address loads. GPS malfunction. Loss of cell reception.

Wildcats

32

System state on completion: Next address in users queue has been loaded and displayed. Queue is
updated, previous address has been removed.

8. Preliminary Use Case Models and Sequence Diagrams

8.1 Use Case Model

8.2 Sequence Diagrams

Wildcats

33

9. Updated Schedule
Wildcats

34

Wildcats

35

10. Appendices
10.1 Definitions, Acronyms, Abbreviations
App = Application
GUI = Graphical User Interface

10.2 References
The Worldwide Leader in Pizza Delivery. (n.d.). Retrieved April 05, 2016, from
https://biz.dominos.com/web/public/about#start

Wildcats

36