Software Requirement Specification (SRS)

For

RedBus

Prepared by:
Potluri Jaya Prakash Rao – 160720733061

Rapolu Sumanth – 160720733064

Yen Reddy Adithya Vardhan Reddy – 160720733065

Methodist College of Engineering and Technology

To

Er. Sandeep Ravikanti

Assistant. Professor-CSE
Table of Contents:

Serial number Figure PAGE

NUMBER
1 INTRODUCTION III
1.1 Purpose III
1.2 Document Conventions III
1.3 Intended Audience & Reading Suggestions III
1.4 Project Scope III
1.5 References III
2 Overall Description IV-V
2.1 Product Perspective IV
2.2 Product Features IV
2.3 User Classes & Characteristics IV
2.4 Operating Environment IV
2.5 Design & implementation Constraints IV-V
2.6 User Documentation V
2.7 Assumptions & Dependencies V
3 Specific Requirements V
3.1 Functional Requirements V
3.1.1 Registration V
3.1.2 Login V
3.1.3 Authorization V
3.1.4 Search V
3.1.5 Booking V
3.1.6 Payment V
3.1.7 Logout V
3.1.8 Ticket Generation V
4 Interface Requirements VI
4.1 Hardware Interface VI
4.2 Software Interface VI
5 System Design Specification VI-X
5.1 Data Flow Diagram VI
5.1.1 Level 0 Data Flow Diagram VII
5.1.2 Level 1 Data Flow Diagram VII
5.2 Class Diagram VII-VIII
5.3 Use Case Diagram VIII-X
5.3.1 IX
● Use case diagram for Bus Booking
5.3.2 IX
● Use case diagram for Bus Tracking
5.3.3 X
● Use case diagram for Customer Service
6 Testing X-XI
 1. INTRODUCTION
This document is prepared in order to determine a software requirement specification for
RedBus. RedBus is built as one of the ecommerce sites and will be very responsive to ticket
booking and always keeps the latest offers and best routes in its online catalogue. The overview
about the report is given, the purpose, scope, and an overall description of the Red Bus’s system
is demonstrated. In addition to these, system features such as Searching, Booking, best route,
boarding & drop selection and customer service functions are described.

1.1 PURPOSE
lThis document presents a detailed explanation of the objectives, features, user interface and
application of RedBus in real life. It will also describe how the system will perform and under
which it must operate. In this document it will also be shown the user interface. Both the
stakeholders, users, and the developers of the system can benefit from this document.

1.2 Document Conventions

We will also use bold letters to emphasize main topics and for all the major functions of the
system. We will use some acronyms through this document.

1.3: Intended Audience and Document Overview:

This project is a prototype for the online shopping system. This document is intended for
different types of readers such as customers, stakeholder, system designer, system developer
and tester. By reading this document a reader can learn and understand about what the project
is implemented for and how it will present its basic ideas. This document has a sequential
overview of the whole project so if a reader reads the document from top to bottom, he will get
a clear idea about the project.

1.4: Project Scope:

The purpose of the online shopping system is to ease user shopping and to create a convenient
and easy-to-use platform for customers, trying to book online bus, train etc. This study aims at
studying client servicing and business development processes.

1. Finding out the strengths and weaknesses of the RedBus.

2. Finding the number of future purchases.
3. Finding the customer satisfaction and their means of awareness of RedBus.
4. Finding the position among the competitors.
5. Finding out the perception of customers about RedBus.
6. The main target is stronger supply chain and aggressive acquisitions.

1.5: References:

Software engineering standard committee of the IEEE computer society, IEEE recommended
practice for software requirements specification 1998
• [Link]
• [Link]

2. Overall Description
2.1 Product Perspective

This software will help the user to connect to the bus agencies, through this system the agency
owner can reach to other areas, helps to make the booking for those who are unable to go to
the nearby agencies, it keeps record and payments details so, owner can make good decision,
provides a great variety to the user.

2.2 Product Features

• Online booking via mobile application.

• Make the payment through various methods.
• Selecting the best routes.
• Boarding & drop selection.
• Vehicle type selection.

2.3 User Classes and Characteristics

There are five types of actors and one cooperating system

• CHARACTERISTICs: There are several users of this system.
• USER: With no any special training to operate the software. The user will have a
username and password to make a booking, it includes user name, address, and phone
number. This information may be used for keeping the records of the user for customer
service-related data.
• AGENCIES: Will get booking/reservation from the user and reserve the seat on the
passenger’s name.
• WISH MASTER: Gets information and books ticket from the selected bus/seat and
generates a ticket with Passenger information.
• ADMIN: Who can make changes in the interface of the application. He or she is
responsible for monitoring functions and procedures on the platform. Administrator is
responsible to provide valid information of a booking to the concerned authority in case
of any dispute between the customer and agencies or in case of exchange.

2.4 Operating Environment

Operating environment for the airline management system is as listed below.

● distributed database
● client/server system
● Operating system: Windows, Android, IOS
● database: SQL database
● platform: Python/CSS/HTML

2.5: Design and Implementation Constraints:

There are some constraints which are reducing the popularity of REDBUS:
• Slow speed of internet of user device, restaurant device or wish master in particular area.
• Online booking majorly decreases contact with the community.
• Sometimes users must face an unexpected lack of information in the booked seat.
• Slow speed of the application forces users to switch to another faster platform.
• Refunds can sometimes be complicated/delayed.

2.6: User Documentation:

Users can read documentation of applications or can make a contact to the customer service
for any assistance.
[Link]
[Link] us
[Link] agreement
[Link] a payment
[Link] account details
[Link] security.
[Link] policy.

2.7 Assumptions and Dependencies:

● All the users, Agencies, bus-drivers are comfortable with the operating system.
● Not all the agencies, routes are connected to the services.
● Not all the agencies are available at all routes.
● If booking is cancelled automatic refund will be made.
● Software will never crash.
● The Internet is required to access software.
3. SPECIFIC REQUIREMENTS
3.1: Functional specifications:
3.1.1: Registration: If a customer wants to book the ticket, then he/she must be registered, an
unregistered user cannot book the tickets.
3.1.2: Login: Customer logins to the system by entering a valid phone number and OTP.
3.1.3: Authorisation: The entered phone number and OTP are checked in the database and if
it is valid then the user is allowed to login
3.1.4: Search: Searches can be made in order of type of vehicle, route, agencies etc
3.1.5: Book: If the customer wants to further proceed with the seat selection, he can press the
buy tickets.
3.1.6: Payment: For Customers, there are many types of secure billings which will be prepaid
as debit or credit card, redeem points, & EMI option is also available.
3.1.7: Logout: After the payment, the customer can be logged out of the app.
3.1.8: Ticket Generation: After booking for the tickets, the system will send one copy of ticket
info to the user’s Email address and another one for the system database.
 [Link] Requirements
Various interfaces for the product would be
1. Login.
2. Search for the starting & destination.
3. Sort according to the user preferences.
4. If the customers select the seats & proceed, then another screen of payment will be
opened.
5. After all transaction the system makes the selling report as portable document file (.pdf)
and sent to the customer Email address
There are mainly 2 types of interfaces as such supported by this software system namely;

● Software Interface
● Hardware Interface
Hardware Requirements: In Windows or android-versions such as XP and 7 and more has
Azure Disk Storage which helps in running the software Red Bus.
Software Requirements:
1. In apple iOS: It has an advanced mobile operating system with its easy-to-use interface
containing azure data lake storage, VMware ESXi, Amazon Work-mail, VMware server which
helps in using RedBus.
[Link]-side programming language: PHP used on a subdomain - a scripting language for
creating websites.
[Link]-side programming language: JavaScript-JavaScript is a lightweight, object-oriented,
cross-platform scripting language, often used within web pages.
[Link] elements: External CSS-External Cascading Style Sheets define style rules in a
separate CSS file. Embedded CSS-Embedded Cascading Style Sheets define a set of style
rules in a <style> element within a web page.
[Link] Language: HTML5 is the fifth revision of the HTML standard.

[Link] DESIGN AND IMPLEMENTATION

5.1 Data Flow Diagram

Data Flow Diagram Level-0: The below DFD level-0 diagram gives us the overview of the
online booking system in the Red Bus application.

Data Flow Diagram Level-1 gives us the detailed information regarding the customer or user
functions upon the process and the information regarding the process output is obtained to
admin.
 5.1.1 Data Flow Diagram Level 0

5.1.2 Data Flow Diagram Level 1

5.2 Class Diagram

A class diagram describes the structure of the Online booking system (Red Bus) by its classes
of Account, Account management and Customer services etc and their attributes and operations
along with the relation between each class.
The structural representation of Red Bus is explained with following classes:

● Account: (a) New Account (b) Registered Account

● Account Management
● Tracking
● Customer Service
● Booking
● Payment
 5.2 Class diagram
5.3 Use Case Diagram

A use case diagram can summarize the details of your system's users (also known as actors)
and their interactions with the system. To build one, you will use a set of specialized symbols
and connectors.

5.3.1 Use case diagram for Bus Booking: The Use case diagram represents the functional
requirements for booking a bus ticket in the red bus application. These are the basic flow of
scenarios for booking a ticket in the Red Bus.

5.3.2 Use Case diagram for bus tracking: The Use case diagram represents the functional
requirements for the bus tracking in the red bus application. These are the basic flow of events
for tracking a bus in the red bus applications.

5.3.3 Use Case diagram for customer service: The Use case diagram represents the functional
requirements for the customer service in the red bus application. These are the basic flow of
events for tracking a bus in the red bus applications.
5.3.1 Use Case diagram for Bus Booking

5.3.2 Use Case diagram for bus tracking

 5.3.3 Use Case diagram for customer service
6 Testing

The parameters of the test are: Test Case ID, Test Scenario, Test Case Description, Test Steps,
Prerequisite, Test Data, Expected Result, Test Parameters, Actual Result etc.
Test case ID: Test_01

Test priority (Low/Medium/High): Medium

Medium Module name: login

Test title: verify login with valid username and password

Precondition: User has invalid username and password

6.1 Test Case Parameter

Test Test Scenario Test Test Steps Input Expected Actual Result/
Scenario Case ID Result Result Status
ID
Register
TC-1.1 Click Sign in Valid Registered As Pass/Succ
Phone & page will Expected, essful
Check register OTP be
TS-1 application displayed
 Tc-1.2 Click Sign in In Valid Registered Show Fail/Unsu
Phone & page is not try ccessful
OTP displayed again
Login
Tc-2.1 Click Login Registered Login As Pass/Succ
Phone & Access will expected, essful
Valid OTP be provided
Tc-2.1 Click Login Registered Will not As Fail/Unsu
Phone & verify us Expected ccessful
In-Valid OTP
OTP
TS-2 Check Login Tc-2.1 Click Login Unregister Will not As Fail/
ed Phone verify the Expected, Unsuccess
no Phone no ful
Tc-2.1 Click Login Unregister Will not As Fail/
ed Phone verify the Expected, Unsuccess
& In-Valid Phone no ful
OTP
6.2 Test Case for Register and Login

RESULT: The Myntra system was designed and implemented successfully.

C. List of abbreviations
Serial
Number Abbreviation Meaning

1 App Application
2 UI User Interface
3 DFD Data Flow Diagram
4 UML Unified Modeling Language
5 UPI Unified Payments Interface
6 AWS Amazon Web Service
7 SaaS Software as a Service
8 ID Identity
9 OTP One Time Password
10 TS Test Scenario
11 TC Test Case
12 IOS iPhone Operating System
13 DB Data Base
14 PHP Hypertext Preprocessor
15 SQL Structured Query Language
16 CSS Cascading style sheet
17 HTML Hypertext Markup Language
18 JS Java Script
19 ASP Active Server Pages
20 .net Network
QR CODE