Functional Specification Contents
0. Table of contents
A table of contents with pages numbers indicated for all sections / headings should be included.
1. Introduction
1.1 Overview
UniPool is a cross-platform carpooling application that will cater for attendees of colleges in Ireland.
A user will register and select the college they’re attending. The app will be based around a map and will focus on linking users together to organise carpools to college. Based on location pinpoints drivers will be able to select users who are looking for a lift and add them to their ride. Users will also be able to request lifts. The map will show the driver the shortest route to get to college, and will adapt to different stops a driver may have to make to collect fellow passengers. It will include a messaging service that will be available to users once they’ve been linked and approved by one another. There will be a petrol pot feature where a driver can advertise how much money they’d like towards the lift.
The idea is to stop people driving to college on their own everyday with several empty seats in their cars, and reduce the number of cars on the road. Carpooling is a great way to save the environment, save money, reduce traffic, and gives people an opportunity to make friends.
There will be a simulator that will showcase, demo and test the app.
1.2 Business Context
This will be a free to use app, but there will be a ‘Petrol Pot’ feature where users offering lifts to college will have the ability to advertise how much money they’d like towards the lift. This feature will be completely optional.
1.3 Glossary
MEAN: The MEAN Stack is the technology stack I’ll be using which consists of MongoDB, ExpressJs, Angular6, and NodeJs.
API: API is an Application Program Interface.
REST API: A RESTful API that uses HTTP requests to GET, PUT, POST and DELETE data.
UI: User Interface
2. General Description
2.1 Product / System Functions
A list of functions follows:
User Registration: User’s will sign up to the app and create a profile which will include the college that they are attending.
Request Lifts: Users will be able to request lifts during a selected time frame in order for their location to be shown on the map so drivers can choose them.
Offer Lifts: Users will be able to choose requesting users on the map to offer them a lift.
Shortest Route: The map will show users the best route to take to college, and will adapt when a lift is accepted, the map will then show the best route to the location of the person they’re picking up and then the best route from there to college.
Location Services: The map will show the exact location of users requesting lifts. The map will also show the location of the driver to the passenger, once the driver has added them to their ride, so that they know his whereabouts in order for them to be ready when he/she arrives.
View Profiles: Users will be able to view another person’s profile, which will include their reliability rating before accepting them to their ride, or before accepting to take a lift off another user.
Accept Users: Two users will accept each other before they can communicate further.
Messaging: There will be a messaging service so that users can interact with each other and organise the lifts in greater detail.
Petrol Pot: There will be a ‘petrol pot’ feature where a driver can optionally advertise the amount of money they would like towards the lift.
Notifications: A user will receive push notifications when a user accepts their request and is willing to add them to their ride.
2.2 User Characteristics and Objectives
Due to the fact that this app will focus on college students, it is fair to assume that most people using it will be somewhat comfortable with technology. The target audience will for the most part be in the 18-25 age bracket but I will also have mature and postgraduate students in mind when designing the UI. I will be sure to make this application accessible to everyone.
The app will be very easy on the eye with an attractive UI and will be simple to navigate. The app will also need to be reliable and quick response times are necessary due to the busy lifestyle that most students live…….
Describes the features of the user community, including their expected expertise with software systems and the application domain. Explain the objectives and requirements for the system from the user's perspective. It may include a "wish list" of desirable characteristics, along with more feasible solutions that are in line with the business objectives.
2.3 Operational Scenarios
Use cases:
Use Case
1
Goal in Context
User registration
Success End Condition
User registers successfully
Failed End Condition
User does not register successfully
Primary,
Secondary Actors
User,
Database
Trigger
User clicks the register button
Description
Step
Action
1
User opens app
2
User clicks on register button to navigate to registration page
3
User enters required information e.g. name, college, course, year
4
User creates password
5
User clicks register
6
User is redirected to Login page
Use Case
2
Goal in Context
User login
Success End Condition
User logs in successfully
Failed End Condition
User does not log in successfully
Primary,
Secondary Actors
User,
Database
Trigger
User opens app
Description
Step
Action
1
App opens on login page
2
User enters required information – username and password.
3
User is redirected to home page of the app
Use Case
3
Goal in Context
User offers a lift
Success End Condition
User offers a lift successfully
Failed End Condition
User doesn’t offer a lift successfully
Primary,
Secondary Actors
User, map,
Database
Trigger
User chooses a day and enters a time frame clicks the offer lift button
Description
Step
Action
1
Map opens showing location pinpoints of all people looking for lifts
2
User chooses a pinpoint which suits their journey
3
Profile of user requesting a lift opens
4
User clicks the offer carpool button
5
Requesting user is notified
Use Case
4
Goal in Context
User requests a lift
Success End Condition
User requests a lift successfully
Failed End Condition
User doesn’t request a lift successfully
Primary,
Secondary Actors
User, map,
Database
Trigger
User chooses a day and enters a time frame and clicks the request lift button
Description
Step
Action
1
User is notified that someone has offered them a lift
2
User is given the ability to see the other user’s profile
3
User accepts offer
4
Offering user is notified
5
Both users are given the ability to message each other
Use Case
5
Goal in Context
User messages another user to organise carpool in further detail
Success End Condition
Users can message each other
Failed End Condition
User cannot message each other
Primary,
Secondary Actors
User,
Messaging service
Trigger
User clicks message button next to the user’s name that they’d like to message
Description
Step
Action
1
Chat window opens between the two users
2
User sends message
3
User is notified when they receive a message and vice versa
Use Case
6
Goal in Context
The drive to college (with collections)
Success End Condition
User collects other users on the way to college
Failed End Condition
User doesn’t collect other users on the way to college
Primary,
Secondary Actors
User, map,
Database
Trigger
User gets in their car and presses ‘start journey’ button
Description
Step
Action
1
The map highlights the shortest route to the address of the first user that’ll be collected
2
User confirms collection when they collect the first user
3
Map reroutes to highlight the shortest route to the next and final collection
4
User confirms collection
5
Map reroutes to highlight the shortest route to college
6
User confirms that the carpool has ended when they arrive successfully at college
Use Case
7
Goal in Context
User rates another user after a successful carpool
Success End Condition
User’s rating is updated
Failed End Condition
User rating is not updated
Primary,
Secondary Actors
User,
Database
Trigger
User chooses a rating between 0 – 5
Description
Step
Action
1
When a carpool is complete both users are given the option to rate the user who they’ve given a lift to or received a lift from
2
User selects rating
3
User’s rating is updated on their profile for others to see
Scenario:
Sally is a second year student in DCU who drives to college. She drives 40 minutes to get to and from college. Sally doesn’t have the money to be driving to and from college everyday due to the price of petrol continuing to rise. So Sally downloads the UniPool app to offer other people lifts and get some money towards petrol. Sne registers an account, sets up her profile and selects the college she’s attending. She has to meet up with her partner for a project at 10:30am. She enters a broader time frame than the time it actually takes her to get to college so that she has more chance of getting people to share a ride with. She enters that she will be driving to DCU between 9am and 9:45am. Sally enters that she would like €5 towards the ‘Petrol Pot’.
Brian is a first year student in DCU who does not drive. He lives in an area where the only way for him to get to college is to get 2 busses which takes over an hour every morning. If Brian drove it would only take him 20 minutes to get to and from college. Brian is sick of all the time he wastes on travelling to college and downloads the UniPool app. He registers an account, sets up his profile and selects the college he is attending. He has to be in college for a lecture at 11am on Monday so he requests a lift. He enters the time frame that he wants a lift in, Brian likes to be early so he looks for a lift anytime between 9am and 10:15am.
Brian’s location is pinpointed on Sally’s map because he’s looking for a lift in the same time frame that she will be driving to college. Sally clicks on Brian’s pinpoint because she sees it’s on her way and views Brian’s profile. She is happy to give Brian a lift and accepts his request. Brian gets a notification that his request has been accepted. He views Brian’s profile and is happy to share a lift with her and accepts her offer. Once both users have accepted each other, they have access to message each other to organise the lift in further detail.
They came to an agreement that Sally would collect Brian from his house at 9:30am. When Sally leaves her house the map shows her the shortest route to get to Kevin’s house. After she collects Brian the map re-routes and shows the shortest route to DCU.
When the lift is complete Brian gives Sally the €5 towards the petrol pot and the two rate each other on the app.
2.4 Constraints
Time Constraints:
The deadline for this project to be complete is in May 2019, so I must make sure that I don’t underestimate or overestimate the workload. I am confident that I will get it complete to a satisfactory standard by the deadline, but I will make sure to be aware that time can slip away very easily. I will stick to a schedule and will make sure to plan every piece of work that I carry out.
Database Memory Constraints:
This app will facilitate a small number of users which could easily be increased by paying for more storage on different hosting sites. The database memory that I have using MongoDB is perfect for this project, but would definitely need to be upscaled if I were to take the project any further.
Testing Constraints:
Due to the fact this is a carpooling app it will be tough to test it. Manually testing it would involve driving around picking people up and giving them lifts to college. I will develop a simulator which will showcase, demo and test the app. I will need to come up with many different scenarios and use cases to test this app which will be time consuming.
Lists general constraints placed upon the design team, including speed requirements, industry protocols, hardware platforms, and so forth.
3. Functional Requirements
User Registration & Login
Description – Users will register an account when signing up to the app. This will only occur once and from then on they will login using their username and password which was created during registration.
Criticality – The criticality of this function is pretty high. I must implement correct validation to make sure the details entered are correct and valid. It will also be the first section of the app that people will see so I want to make it easy on the eye and simple to navigate in order to give users a good first impression.
Technical issues – There shouldn’t be any technical issues with this function.
Dependencies with other requirements – This function basically interacts with the entire app. Once a user logs in, their information will be retrieved from the database and will then depict what each user sees when they log in e.g. their profiles, their carpool history etc.
Create, Update & View Profiles
Description – Users will create a profile upon signing up to the app. Other users will then be able to view their profiles which they will access through their location pinpoint on the map. This profile will contain basic information about the user such as a profile photo, their name, age, the course they are doing, their interests, and disabilities they have or any other information another user may need to know about them.
Criticality – The criticality of this function is very high because it will help a user make their decision on whether they’d like to give/receive a lift off someone.
Technical issues – ????
Dependencies with other requirements – User’s profiles will be accessed through their location pinpoint on the map. Users will also be able to access other user’s profiles from their friends list.
Request Lifts
Description – A user will request a lift by choosing a day and entering a time frame on that day that they’d like to request a lift. Their location will then be pinpointed on the map for users offering a lift on the same day in the same timeframe to see.
Criticality –
Technical issues –
Dependencies with other requirements –
Offer Lifts
Description – A user will offer a lift by choosing a day and entering a time frame on that day that they’d like to offer a lift.
Criticality –
Technical issues –
Dependencies with other requirements –
This section lists the functional requirements in ranked order. Functional requirements describes the possible effects of a software system, in other words, what the system must accomplish. Other kinds of requirements (such as interface requirements, performance requirements, or reliability requirements) describe how the system accomplishes its functional requirements.
As an example, each functional requirement could be specified in a format similar to the following:
Description – A full description of the requirement.
Criticality – Describes how essential this requirement is to the overall system.
Technical issues – Describes any design or implementation issues involved in satisfying this requirement.
Dependencies with other requirements – Describes interactions with other requirements.
Others as appropriate
4. System Architecture
I will be using a few different technologies for the implementation of this system. The technology stack I will be using is the MEAN Stack, along with Firebase and the Google Maps Api, altogether on the Ionic Framework.
Ionic Framework
The Framework that I am using which will allow the system to be supported on all platforms
MEAN Stack:
MongoDB
ExpressJs
Angular6
NodeJs
Firebase:
Used for messaging service and push notifications
Google Maps API:
Used to implement the map interface
A user will register an account on the app through the Angular front-end which will make a request to the NodeJs server which will POST their information to the database.
A user will create/update their profile on the app through the Angular front-end which will make a request to the server which will POST their information to the database.
A user will log in to the app through the Angular front-end. Their login details will then be securely queried in the database and returned to the server. If there’s a match they’ll be then able to enter the app.
A user will enter a day and choose a timeframe to offer a lift through the Angular front-end, the server will then POST this information to the database. The user will then be shown all of the location pinpoints of all the people from the same college looking for a lift on the same day in the same timeframe on the map interface.
A user will enter a day and choose a timeframe to request a lift through the Angular front-end, the server will then POST this information to the database. The user will then get a push notification through Firebase when a user accepts to give them a lift.
A user will have the ability to message another user once they’ve been linked which they will do through the Angular front-end. The messaging service will be implemented using Firebase.
This section describes a high-level overview of the anticipated system architecture showing the distribution functions across (potential) system modules. Architectural components that are reused or 3rd party should be highlighted.
5. High-Level Design
This section should set out the high-level design of the system. It should include one or more system models showing the relationship between system components and the systems and its environment. These might be object-models, DFD, etc.
6. Preliminary Schedule
This section provides an initial version of the project plan, including the major tasks to be accomplished, their interdependencies, and their tentative start/stop dates. The plan also includes information on hardware, software, and wetware resource requirements. The project plan should be accompanied by one or more PERT or GANTT charts.
7. Appendices
Specifies other useful information for understanding the requirements.