SRS FORMAT AND GUIDELINES

1. SRS Report (After forwarding through their Guides)

(Format of SRS and some General guidelines are given below)

 Diagrams with detailed explanation

 ER Diagram for database related applications
 Use Case Diagram
 Class Diagram for Object oriented applications
 Sequence Diagram
 Zero and One level DFD

2. Gantt Chart (using any tool like Microsoft Project).

Other diagram / write-ups etc. may be added as per the requirement of the project.

3. All the project groups have to Present their work through PPTs (Approx 20 Slides).It
should Include:-
 PPT of highlights of project SRS.
 PPT of all Diagrams.
 PPT of any module if it is running.
 GROUP NO-60

AJAY KUMAR GARG ENGG. COLLEGE, GHAZIABAD

Software Requirement Specification (SRS)

Peer to Peer Car Pooling

Submitted for fulfillment of award of

Bachelor of Technology

In

Information Technology

By

Anisha Srivastava 1900270110005

Tushar Rawat 1900270130178
Urvi Singh 1900270110060
Vinayak Mahendra 1900270130190

Under the Guidance of

Mr. Lucknesh Kumar

AJAY KUMAR GARG ENGINEERING COLLEGE, GHAZIABAD

YEAR: 2022-2023

Mr Lucknesh Kumar
 SRS FORMAT
Table of Contents
1. Introduction

Since inappropriate planning of the cities, there has been a big problem of traffic in most cities of Turkey.
People waste very long times in traffic every day. In Addition, because of so many vehicles in traffic,
there has been an increasing problem of air pollution. Oil supplies are very limited all over the world and
oil prices are extremely expensive in our country. Therefore, most of the people have to take buses and
since number of the public transportation vehicle are not sufficient, they travel under uncomfortable
conditions. There are some attempts to solve these problems. The most effective one is [Link]
which is widely used in Europe. However, they focus only on intercity transportations. Also, in Turkey,
there is [Link] and [Link]. Both of them allows only users in Istanbul. However, our
project will be used for both intercity and urban transportations all over the world. As a result, our
system will be designed to solve these problems and deficiencies of other systems.
1.1 Purpose
Aim of this software specification requirements document is to provide a complete description of all
of the features that are planned to implement to system and define the expectations from the
Carpool project. It also describes how the system operates and how users interact with the
application. Besides external systems and interfaces which the application depends, are specified in
this SRS document The potential audiences for this document are design and development team of
the Carpool Project in order to specify software designs. Test team utilizes this software
specification requirements document to define test scenarios according to the mentioned
requirements. Besides project manager, quality manager and acquirer use this SRS document for
reviewing purposes.
1.2 Scope

The Carpool Project is an MVC (Model-View-Controller) blockchain based web-application which

includes user interaction. Our project is going to be a web portal. It is going to provide
communication environment for users (drivers and hitchhikers). Every user has their own profiles
and they can have access with given password to the system. The drivers can draw their routes from
map in our web site. And hitchhikers can communicate with the driver via the messaging system and
pick their path. After mutual agreement with each other, they record the transportation information
to the system. At the end, users can assess each other via feedback system. The system will bring
many advantages. For instance, the drivers and hitchhikers spend less money on traffic. Moreover,
traffic jam and air pollution will be decreased. And everyone benefits from these advantages. In high
level details, system will use Google Map API for retrieve location information, the blockchain ledger
to store and manipulate the data, and GUI to interact with users.

1.3 Definition, Acronyms and abbreviations

The definitions of the terms, which are used in this SRS document, are shown below:
Terms Definitions
Acquirer Project Consultant
Customer Drivers and hitchhikers
GUI Graphical User Interface
Ledger Database
IEEE Institute of Electrical and Electronics Engineers
SDD Software Design Description
SRS System Requirements Specification
API Application Programming Interface
Hitchhiker User accompanies the driver during the
transportation
 Driver User who owns the car
Route Transportation path
SMS Short Message Service
CAPTCHA Completely Automated Public Turing test to tell
Computers and Humans Apart

1.3 References

[1] IEEE STD 1233-1998, IEEE Guide for Developing System Requirements Specifications

[2] IEEE STD 830-1998, IEEE Recommended Practice for Software Requirements Specifications

1.4 Overview

The rest of the document contains overall description of the system which includes interface
properties, product functions and dependencies. In addition, it contains system specific
requirements which composed of functional and nonfunctional requirements. Moreover, there will
be data and description models of the system and these models are specified with diagrams such as
use cases. And finally at the end of the document, there is conclusion part which explains the overall
description about the system. SRS is organized according to the table of content.

2. The Overall Description

This section gives background information about specific requirements of the web based carpool
environment to be developed in brief. Although we will not describe every requirement in detail, this
section will describe the factors that affect the final product.
2.1 Product Perspective

This subsection of the SRS puts the product into perspective with other related products or

projects. (See the IEEE Guide to SRS for more details).

2.1.1 System Interfaces

The system has Google Map API as a subsystem. Google Map subsystem has their own web based
interface which is a map consists of roads and locations in a desired area and user can easily intersect
with this system.

2.1.2 Interfaces

This software product is developed for drivers and hitchhikers. Product will be deployed to web site and
all users of the system will access the system through the web interface which includes multiple pages
according to the system functionality for example for login functionality there will be login page. To
access the system, every user has unique user name and password. In addition, there will be a database
who stores and manipulate all the data about the users. Website will only be the interface for all the
user data which stored by database and the execution of provided functionalities. After the sign up, user
information will be transferred to database. In the sign up process, there will be e-mail verification to
verify user information. After that point, users can register through the web interface. After log in, user
will be able to log out whenever he or she wants.

2.1.3 Hardware Interfaces

Because carpool system is web based, it is compatible with all the browsers and can be run on any
operating system and processor.

2.1.4 Software Interfaces

Blockchain ledger is required software product for Carpool system because all data about system for
example user and route information must be stored in database for later use and system functionality.
MySQL database management system is used for that purpose and it has nice open source user interface
which displays table and rows in well formatted form for developers to create and manage the whole
database. Another server that will be used is Google Map Server to provide geographical service and to
visualize transportations. In terms of user interface, HTML and Bootstrap library will be used to illustrate
the system attractively. These client and server sides attraction will be handled with Http Requests by
JavaScript and PHP Languages

2.1.5 Communication Interfaces

The system shall send automatic verification e-mail to the user who wants to register to the system.
Moreover, in communication between driver and hitchhiker, users shall send and receive an e-mail
through the e-mail interface. For communication between users, system shall support SMS functionality
and users can be able to send and receive SMS through the remote mobile devices

2.1.6 Memory Constraints

64-bit, 4 cores processor. 8 GB RAM. 80 GB for system drive.

2.1.7 Operations

This part is explained in the user interfaces section.

2.1.8 Site Adaptation Requirements

Carpool system is able to perform every platform for example any browser that can be run on any
operating system so it does not need any adaptation to a particular platform.

2.2 Product Function

All use cases are explained below

 Sign Up: Users need to sign up to use the web site. The users should have a username and password.
After filling their name, surname, email, age, job, phone and gender information, they register the
system.

 Sign In: If a user is signed up, s/he can sign in the system by filling username and password boxes.

 Sign Out: A user may need to sign out the system. S/he can do it by clicking the sign out button which is
placed in every page.

 Add Transportation Route: Users may add transportations by specifying a route, time/time period and
number of empty seats. The user can select the route by two different way. The first way is entering start
and end locations. Thus, the route is drawn on the map. The other way is selecting start and end
locations on the map. Also, he/she can select at most 8 waypoints.

 Delete Transportation Route: A user may delete his/her transportation route. After deleting route,
other passengers in that transportation will be informed by the system.

 Request Transportation Route: A user may use a transportation by sending transportation request to
the driver of the transportation.

 Search Transportation Route: A user can search for transportations that the user can see suitable
routes to his/her route by specifying time and route.

 Send Message: The users can have communicate each other by sending message.
 Reply To A Message: After receiving a message, the user can read the message.

 Block User: When a user receive disturbing message, s/he can block the user who send that message.

 Rate User: After having a transportation, the users in the same transportation can rate each other on
the web site. Thus, other users can see the user rates and they can decide which transportation is better.

 Change Language: The user can change the web site language by clicking small flags that is available in
all pages. There are two suitable languages which are Turkish and English.
2.4 Constraints
Carpool system is required mutual trust for example user’s security of life must be protected by the
government’s law system but there is no legal infrastructure about this driver and hitchhiker
relation in our country. So, this is an important constraint for Carpool system. Another constraint is
that the system requires remote server which enables the system functionality and data storage.
Because of this situation, when the server crashes the system will not be able to its operations until
the server become available to respond system requests. In addition to these, since the user
information is stored on a ledger and this ledger can be hacked and user information will be no
longer private to the user. To sum up, Carpool system has constraints in terms of regulatory,
reliability, safety and security but these constraints can be manageable.
2.5 Assumptions for dependencies

User interface and some functionalities can change during the development process of project. And
also new functionalities can be added which is able to change the dependent system requirements.

3. Specific Requirements

3.1 External Interfaces

The system shall consist of user friendly web based user interfaces which are explained in 2.2. Product
Functions section. Also, visualized version of the interfaces are explained in 5.1. Description for Software
Behavior section.

3.2 Functions
Sign Up

Use Case ID UC1

Actor(s) User

Description User Sign In (Register)

Preconditions No precondition

Post conditions User will be able to log in to the

system

Precedence Mandatory
Normal flow of event 1. The user opens the browser
and types the address of the
 system.
2. User presses the sign up
button.
3. User enters her or his user
name, surname, password
and e-mail information.
4. User checks his or her e-mail
account to verify his or her
user information.
3.2.2. Sign In

Use Case ID UC2

Actor(s) User

Description User Log In

Preconditions The user shall be able to sign in to

the system.

Post conditions User will be able to use the system.

Precedence Mandatory
Normal flow of event 1. The user opens the browser
and types the address of the
system.
2. User presses the log in
button.
3. User enters her or his user
name and password.
4. If the user forget his or her
account information, he or
she get account information
via the “forgot your
password?” panel under the
log in page.

Alternative Flow(s) Flow 1:

1. If the user enter wrong
username or password
information, the warning
message for example ”Wrong
username and password
information” will be shown
 to the user.
Flow 2:
2. If the user enters his or her
user name and password
information correctly, user
will be redirected to the
application relevant page of
the system.
3.2.3. Sign Out

Use Case ID UC3

Actor(s) User

Description User Log Out

Preconditions The user shall be able to log in to

the system.

Post conditions User will be able to leave the

system.

Precedence Not mandatory

Normal flow of event 1. User presses the log out
button.
2. User leaves the system.
3. The system’s main page will
be loaded.

3.2.4. Add Transportation Route

Use Case ID UC4

Actor(s) User

Description User shall be able to add route from

the map.

Preconditions The user shall be able to sign in to

the system.

Post conditions User shall be retrieve

transportation requests from the
other users.
Precedence Mandatory
Normal flow of event 1. User shall enter her or his
profile page.
2. User shall press add new
transportation button.
3. Add transportation page will
be loaded.
4. User enters departure time,
available seats and iteration
 of transportation like “one
time” or “periodic”.
5. User draws a route on the
map panel.

Alternative Flow(s) Flow 1:

1. The user clicks the radio
button of “one time”.
2. User enters date information
in terms of day, month and
year.
Flow 2:
1. The user clicks the radio
button of “periodic”.
2. User selects days from the
week day check boxes.

3.2.5. Delete Transportation Route

Use Case ID UC5

Actor(s) User

Description User shall be able to delete route.

Preconditions The user shall add transportation

route before.

Post conditions User cannot see the route which is

deleted by the user.

Precedence No mandatory
Normal flow of event 1. User shall presses my
transportations button.
2. My transportations page will
be loaded.
3. User selects the route he or
she wants to delete.
4. Delete button is clicked.
5. The user deletes the route.
3.2.7. Search Transportation Route

Use Case ID UC7

Actor(s) User

Description User shall be able to search route.

Preconditions The user shall sign in to the system.

Post conditions User will be able to select route

from the available route list.

Precedence No mandatory
Normal flow of event 1. User fills “from” input field.
2. User fills “to” input field.
3. User presses the search
button.

Alternative Flow(s) Flow 1:

1. User forgets to fill “from” or
“to” input field.
2. The related warning
message is shown to the user
to fill the input fields
properly.
Flow 2:
 1. User fills the input fields
properly.
2. The available routes will be
listed.

3.2.8. Send Message

Use Case ID UC8

Actor(s) User

Description User shall be able to send message

through the system.

Preconditions The user shall sign in to the system.

Post conditions Users will be able to communicate

with each other.

Precedence No mandatory
Normal flow of event 1. User enters the profile page
of the user who is intended
to be communicated.
2. User presses the send
message button.
3. The message page will be
loaded.
4. User types the content of the
message.
5. User presses the send button
 to send the message content.
6. The message content will be
stored and viewed in the
message panel.

3.2.9. Reply to Message

Use Case ID UC9

Actor(s) User
Description User shall be able to reply to
incoming message through the
system.

Preconditions The user shall receive the message

from other user.

Post conditions Users will be able to communicate

with each other.

Precedence No mandatory
Normal flow of event 1. User presses the message
box button.
2. The message box page will
be loaded.
3. User clicks the intended row
from the message list.
4. The message page will be
loaded.
5. User types the content of the
message.
6. User presses the send button
to send the message content.
7. The message content will be
stored and viewed in the
message panel.
3.2.10. Block User

Use Case ID UC10

Actor(s) User

Description User shall be able to block the user

through the system.

Preconditions The user shall enter the intended to

blocked user’s profile page.

Post conditions Users will be able to prevent

communication with the user.

Precedence No mandatory
 Normal flow of event 1. User enters the profile page
of the user who is intended
to be blocked.
2. User presses the block user
button.
3. The same page will be
reloaded as marked as
blocked.

3.2.11. Rate User

Use Case ID UC11

Actor(s) User

Description User shall be able to rate the driver

through the system.

Preconditions The transportation route shall be

completed with driver and
hitchhiker.

Post conditions The driver’s rating will be updated.

Precedence No mandatory
Normal flow of event 1. After the transportation, the
hitchhiker login to the
system.
 2. Popup window is opened.

Alternative Flow(s) Flow 1:

1. Hitchhiker clicks the star
icon to rate driver’s related
attitude.
Flow 2:
1. Hitchhiker clicks close icon.
2. The popup window will be
closed.

3.2.12. Change Language

Use Case ID UC12

Actor(s) User

Description User shall be able to change the

language

Preconditions No precondition.

Post conditions User shall be able to see the system

in selected language.

Precedence No mandatory
Normal flow of event 1. User clicks the change
language button.
2. The system converts its
content in the selected
language.

Alternative Flow(s) Flow 1:

1. The user clicks the “Tu rkçe”

from the navigation bar.

2. The page content will be
converted to English
language.
Flow 2:
1. The user clicks the “English”
 from the navigation bar.
2. The page content will be
converted to Turkish
language.

3.3 Performance requirements

The user who has 8Mbits internet connection speed, shall be able to enter a page of the system in less
than 1 second. The system shall be able to respond more than one thousand users simultaneously. The
system shall be able to keep user information of more than one hundred thousand users.

3.4 Logical database requirements

3.5 Design Constraints

Passwords of the user shall be encrypted in DBMS for security purposes. To prevent spam robots, the
system has verification CAPTCHA module for security purposes. When the system crashes it will return
back at most one hour in maintainability purposes. The system shall run on every browsers (Chrome,
Safari, Mozilla Firefox etc.) and operating system (Windows, Linux, Mac Mavericks etc.)

3.6 Software System attributes

3.7 Organization of specific requirements

3.8 Diagrams with detailed explanation

3.8.1 Use Case Diagram

 3.8.2 ER Diagram for database related applications
3.8.3 Class Diagram for Object oriented applications

3.8.4 Sequence Diagram

3.8.5 Zero and One level DFD

3.9 Gantt Chart……………………………………………………………..

……………………………………………………………………
4.0 Glossary………………………………………………………………....
5.0 References……………………………………………………………….

Table of Contents…………………………………………………i

List of Figures…………………………………………………….ii

Table of Figures
Figure 1 - <Figure name>………………………………………………….<page no>
Figure 2 - <Figure name>………………………………………………….<page no>
Figure 3 - <Figure name>………………………………………………….<page no>
Figure 4 - <Figure name>………………………………………………….<page no>
|

SOME GENERAL GUIDELINES

1. Number of copies to be submitted for evaluation:- One copy to be submitted to the

department at the time of presentation.
2. Size of SRS:- The size of SRS should minimum 25-30 pages of typed matter reckoned from the
first page.

3. Arrangement of Contents:-

The sequence in which the report material should be arranged and bound should be as follows:

1. Cover Page
2. Table of Contents/ Index
3. Arrangements of content must be strictly follow the sequence, specified in table of
contents.

4. Page Dimensions and Margin:-

The SRS (at the time of submission) should have the following page margins

Top Edge : 30 to 35 mm
Bottom Edge : 25 to 30 mm
Left Side : 35 to 40 mm
Right Side : 20 to 25 mm

The SRS should be prepared on good quality white paper preferably 75-80 gsm.

5. Heading and Subheadings:-

Heading : Font Size – 14 Font Type – Times New Roman and Bold
Sub Heading : Font Size – 12 Font Type – Times New Roman and Italic
Content : Font Size – 12 Font Type – Times New Roman

Line spacing must be single

Content must be justified

6. Binding Specifications:-

The SRS report should be in spiral Binding.

7. Writing “Introduction”:-

In Section 1.1 “Purpose”, describe the purpose of the project.

In Section 1.2 “Scope”, describe the scope of the project.
8. Writing “Overall Description (SRS)”:-

Overall description of the project

Others:-

End your SRS document by the following line (centered across the page):
*** End of the SRS ***