0% found this document useful (0 votes)
63 views

A System Conecting Assi2

This document outlines requirements for a system connecting vehicle drivers with nearby garages, mobile mechanics, or tow truck drivers. It includes functional requirements like allowing users to find nearby service providers on a map, send service requests, update their account, and non-functional requirements like the system being available 24/7, having a consistent user interface, and using specific technologies. It also provides use case diagrams, design goals, subsystems including maps, authentication, and data storage, and identifies the architectural style as MVC to separate responsibilities into the model, view and controller layers.

Uploaded by

Toby Mac
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
63 views

A System Conecting Assi2

This document outlines requirements for a system connecting vehicle drivers with nearby garages, mobile mechanics, or tow truck drivers. It includes functional requirements like allowing users to find nearby service providers on a map, send service requests, update their account, and non-functional requirements like the system being available 24/7, having a consistent user interface, and using specific technologies. It also provides use case diagrams, design goals, subsystems including maps, authentication, and data storage, and identifies the architectural style as MVC to separate responsibilities into the model, view and controller layers.

Uploaded by

Toby Mac
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 8

HAWASSA UNIVERSITY

Institute of technology
SCHOOL OF INFORMATICS
DEPARTMENT OF COMPUTER SCIENCE
Section one

A SYSTEM CONECTING VEHICLE DRIVER WITH


NEARBY GARAGE, MOBILE MECHANIC, OR TOW-
TRUCK DRIVER
Assignment II
Selected topics in computer science CoSc 4181

Group members
Meklit Teklu Behago Cs/0073/10
Anteneh Esayas Woyso Cs/0012/10
Lydia Gezahegn Ayele Cs/0068/10

SUBMITED TO; DR. DEGIF T.


Functional and Non-Functional Requirement
Functional Requirements

 A user shall be able to find service providers nearby on the map.


 A user shall be able to search service provider’s lists on the list view page.
 A user shall be able to send emergency request to service providers.
 A user shall be able to send appointment-based request to garages.
 A user shall be able to send service task, photo of repairing area of vehicle,
appointment date, vehicle info (type, make, model, license number, year and etc.),
message and his current location.
 A user shall update his account information.
 A user shall update his vehicle information.
 A user shall be able to set service reminder that notify when his vehicle recurrence
service day come upon. And can share this alarm info for his customer garage or
mobile mechanic.
 A user shall be able to make the service reminder auto send the request to garage
when the day arrives.
 A user shall able to get guides of how to fix minor problems of vehicles.
 A user shall able to save a service provider to call for another time.
 A user shall able to rate and review a service provider.
 A user shall able to share a service provider to his friends.
 A user shall able to sync his contacts.
 Able to get joined service providers from his contact list.

Non-Functional Requirements

Product Requirements

 The system shall able to remember a user logged in.


 The system shall be available for all users 24hr.
 The system shall able to remember what the user searched before.
 The system shall able to search by accepting user voice.
 The system shall able to show the recommended service providers to drivers.
 The system shall provide the option to choose the app language to users.
 The system has constant UI color (hollo orange) in all activities.
 The system shall be attractive user interface that contains motion events, descriptive
images, easy and readable typography, notes, instructions, and etc.
 Except map page all other activity pages has high speed when responding to users.
All large sized images are changed to thumbnail and stored temporarily in the cache.
 When the user pass from one activity to another it shall take a millisecond.
 The map page shall take 1 - 3 seconds to track the current location of a user and the
service providers. Because, it uses internet, GPS and the help of satellite. The radio
signal takes about 120 milliseconds to reach a geostationary satellite and then 120
milliseconds to reach the ground station, so nearly ¼ of a second overall.
 The system shall able to calculate the distance between driver and service provider
on the map. Also, show the nearest route.
 The system shall calculate the exact vehicle service date, left days, and notify for the
users.
 The system shall need minimum 15mb of storage.
 The system shall hide the privacy data (password, email, license number and etc.) in
both local and cloud database.
 The system shall authenticate the users when they try to log in.
 The system shall verify users email and phone number when they register to the
system.
 The system shall check when the user tries to login or register with empty text field
or user name and show error message.
 The system shall work on both land scape and portrait of mobile.
 The system shall show the same interface for all android versions.
 The system shall able to ask the users to grant permissions like internet, location,
storage, camera, and etc.
Organizational Requirements

 The system shall be developed by java programming language.


 The system shall be developed in Android studio.
 Users of Nearby Garage System shall authenticate themselves using their phone
number and password.
 The system shall run in android mobile device.
 The system shall require android API version above 16 and below 30.

External Requirements

 The system shall use Google map to track users and use Google firebase database to
store data (text, image), to authenticate users and to verify users phone number and
email.
 The system shall access user’s vehicle data from Ethiopia Transport Minister to
verify the License number of vehicles.
Use Case Diagram

Figure 1.1 Use case for The NG Request Sender Application System
Figure 1.3 Use case diagram for NG Management System

Figure 1.2 Use case Diagram for The NG Request Accepter Application System
Design Goals
 Provide easy way to find Service providers
 Allow users to make appointments easily for maintenance services
 Ensure the user and data security
 Allow users to update information about their car or motor
 Provide easy way to find information about the service providers.

Subsystems and their Decompositions


Software systems used in the project are:
1. Business Services: - This Set of Business services will be developed which will provide
all Services to the Android and Web Application. Business Services are the only way to
access the database for all application. In our project the Business services provider is
Firebase Database.
2. Website: - Website which will be developed in HTML and CSS will have all UI modules.
Logging, Registration, Offer the service-providers, Map and provide access to
Administrators and super Administrators through separate modules to manage the
Application and Users.
Subsystems: -
 Google Maps plugin (used to locate service-providers and drivers)
 Firebase plugin (to connect with Firebase Database)
 jQuery JavaScript library
 Firebase Auth module (used to login/logout and keep track of administrators)
 Firebase Fire store module (to store and access data)
 Firebase Admin PHP SDK (enables access to Firebase services from privileged
environments (such as servers or cloud) PHP)
3. Android App for Drivers: - Android App will provide Logging, Registration,
Account/Profile, find a service-provider, rate a service-provider, Map, Send Emergency
service request, Send Appointment based service request, etc. App will use the Business
services to connect the Database services.
Subsystems: -
 Google Map API (used to locate service-providers and drivers)
 Firebase plugin (to connect with Firebase database)
 Firebase Auth module (used to login/ logout and keep track of administrators)
4. Android App for Service-providers (Garages, Mechanics and Tow-Truck): - Android
App which will provide Logging, Account/Profile, Accept/Decline Request, Track
Drivers, Map, Send Quotes, Schedule, etc. This app will also use the Business services to
connect the Database services.
Subsystems: -
 Google Map API (used to locate service-providers and drivers)
 Firebase plugin (to connect with Firebase database)
 Firebase Auth module (used to login/ logout and keep track of administrators)

Architectural Style
Model View Controller

The architecture style that we choose is MVC (Model View Controller) framework. The reason
we choose MVC architecture is because to separate the responsibilities or to differentiate the
layers and MVC has the feature that separates in to model view and controller, it has the ability
to provide multiple views and it is easy to maintain the code. The main point in MVC is straight
forward: the following responsibilities must be clearly separated.
Figure 2. 1 Model view controller framework
The controller deals with the user requests. It controls the service-provider who accept the user
request. The model consists of the data and the rules or policies regarding the data. The view
creates a way to represent the data obtained from the model.

You might also like