Software Requirements

Specification
for

Online Bus Booking System

Version 1.0 approved

Prepared by Shantanu Singh

Shivam Sehgal

NMIMS Shirpur

01-08-2017
Software Requirements Specification for Online Bus Booking System
Page ii

Table of Contents
Table of Contents...........................................................................................................................ii
Revision History.............................................................................................................................ii
1. Introduction..............................................................................................................................1
1.1 Purpose...........................................................................................................................................1
1.2 Product Scope.................................................................................................................................1
2. Overall Description..................................................................................................................2
2.1 Product Functions...........................................................................................................................2
2.2 User Classes and Characteristics.....................................................................................................2
2.3 Operating Environment...................................................................................................................2
2.4 Design and Implementation Constraints.........................................................................................2
2.5 User Documentation.......................................................................................................................2
2.6 Assumptions and Dependencies......................................................................................................3
3. External Interface Requirements...........................................................................................3
3.1 User Interfaces................................................................................................................................3
3.2 Hardware Interfaces........................................................................................................................3
3.3 Software Interfaces.........................................................................................................................3
3.4 Communications Interfaces............................................................................................................3
4. System Features.......................................................................................................................4
4.1 System Feature 1............................................................................................................................4
4.2 System Feature 2 (and so on)..........................................................................................................4
5. Other Nonfunctional Requirements.......................................................................................4
5.1 Performance Requirements.............................................................................................................4
5.2 Safety Requirements.......................................................................................................................5
5.3 Security Requirements....................................................................................................................5
5.4 Software Quality Attributes............................................................................................................5
5.5 Business Rules................................................................................................................................5
6. Other Requirements................................................................................................................5
Appendix A: Glossary...................................................................................................................5
Appendix B: Analysis Models.......................................................................................................5
Appendix C: To Be Determined List...........................................................................................6

Revision History
Name Date Reason For Changes Version
Software Requirements Specification for Online Bus Booking System Page 1

1. Introduction

1.1 Purpose
This document describes the software requirements of an online bus booking system for public
transportation. It is intended for designer, developer and maintainer of the bus booking system.
These requirements were created in response to the problems associated with booking bus tickets
via cash.

1.2 Product Scope

The current bus booking system relies on buying tickets from the conductor for commuting to and fro from a
location through public transportation. The task can be tedious if the number of commuters is large. Also,
payment in cash can be difficult if the payable denominations are uneven. Online Bus Booking system
allows the commuter to either have a specific amount of money on his Android Based mobile, from which
the ticket can be charged. Or, the commuter can buy the ticket on the bus.

2. Overall Description

2.1 Product Functions

Event Name External Stimuli External Responses Internal Data and
State
Application Opens User opens application Application main System will listen for
screen is displayed when that button is
with a button for the pushed
user to buy a bus
ticket.
Buy ticket request Button to buy ticket is Application will System will listen for
pressed on the display a screen asking when that button is
application user for his/her pushed
information
Buy ticket request  Users finished  Users will be  System will check for
submission inputting the data and instructed to wait for a accuracy input and
hits submit on the buy minute while his send answer back to
ticket screen information is checked app
Software Requirements Specification for Online Bus Booking System Page 2

2.2 User Classes and Characteristics

Admins-Must be able to access the database, modify ticket information, verify system working
properly, and handle troubleshooting issues.

Bus Driver- Bus driver must be able to oversee each customer’s input of ticket confirmation
number.

Client-Able to buy a ticket, create a ticket that adds to the database.

2.3 Operating Environment

We believe the application will work on 1.x versions of the OS, but our test cases and support only
exists for 2.1 or higher.  We are also assuming that users have a simple understanding of operating
their Android device.  Basic text field entry and typing skills are assumed by all users.

2.4 Design and Implementation Constraints

Reusability - Highly reusable. This application is a framework that can be ported over to any number of
ticket purchasing systems. By Simply changing the Phone App GUI class, it would allow other
transportation systems to use the same back end network code and same phone app for entry to their own
buses or trolleys or subway systems. By keeping our back-end generalized as much as possible with
separate classes that can be reused, the process of adapting the entire application for a new client will be a
very short and purely visual process.

Maintainability - Easily maintainable. This application doesn't require a whole lot of code modification
once it is in place. The only part that really will ever change is what specific passes will be available for a
customer to purchase. Currently we are accounting for "One Time Use," "One Day Use," "Weekend Use (3
Days)," and "Week Use (7 Days)." If these offerings change, or new ones are included, the process to
maintain the system to the updated services is a short process.

Testability - Quickly testable. This application is generalized and as such has only a few testable parts. This
will enable the testing phase to be very quick and simple. Having only two GUI classes (phone and bus)
simplifies the GUI testing process. Other than the GUI classes, we also have the Customer and address class
which also makes it simpler for unit testing since we won’t have to run a very large amount of tests. The
most difficult tests will involve querying the database and automating "garbage collection," meaning
deleting the expired passes as entries in the database.

Performance - High performance. Both sides of the system, phone and bus, have a single screen populated
by simply test fields. Performance for data entry is dependent upon the programming language used and the
machines implementing the app. This should be negligible. The biggest drag on performance will be
accessing the database. We are keeping our queries simple to counter the use of mobile broadband
connections as our internet access.

Portability - High portability. The entire purpose of this application is to be portable and used by mobile
devices. For this reason, we have decided on a small number of classes so that the code is as small as it has
to be. Users are limited to a android device and must be in an area with mobile broadband access.
Luckily, most areas with bus systems are already equipped with cell towers allowing at least Edge
connection, if not 3g/4g.

Safety - High safety. Customer data is highly confidential and only system administrators have access to
any data in the database. Credit card information will never be stored anywhere, even on the database, and
Software Requirements Specification for Online Bus Booking System Page 3

will be handled by a third party payment company (such as paypal) to ensure security of payment
information.

2.5 User Documentation

Documentation is mainly intended for database administration for understanding how to handle
database entry and editing.  They are expected to understand whatever database administration
program they prefer that supports reading and editing SQLite databases.
On screen instructions will be provided for Phone App users and Bus App users.  No paper
documentation is required.

2.6 Assumptions and Dependencies

We are assuming that all users will be using Android phones with OS version 2.1 or higher.  We
believe the application will work on 1.x versions of the OS, but our test cases and support only
exists for 2.1 or higher.  We are also assuming that users have a simple understanding of operating
their Android device.  Basic text field entry and typing skills are assumed by all users.

3. External Interface Requirements

3.1 User Interfaces

 Phone application interfaces with user

o Using touch input, users select a text field, the phone OS provides data entry
methods
 Inputs:
 First Name - String, 30 characters max, not case sensitive
 Last Name - String, 30 characters max, not case sensitive
 Email - String, 30 characters max, not case sensitive, requires exactly
1 "@" sign and at least 1 "." symbol
 Ticket Type - Drop down menu with "Single Use," "1 Day Pass," "3
Day Pass,"Week Pass." Defaults to "Single Use"
 Credit card type - Drop down menu with "Visa," "Discover,"
"Mastercard," "American Express." Defaults to "Select type."
 Credit card number - String, Exactly 16 numeric characters
 Expiration date month - String, Exactly 2 numeric characters
Software Requirements Specification for Online Bus Booking System Page 4

 Expiration date year - String, Exactly 4 numeric characters

 Phone application interfaces with database
 When sending output "data," database returns 6 digit string "confirmation
code"
 Input:
 Confirmation Code - String, 6 digit numeric code assigned by
database as a key when receiving successful "data" input from Phone
App. Sent back to phone application to display on screen
 Using touch input, users touch an image button "Purchase", "Data" output is
only sent once
 Outputs:
 Data - String, all text fields entered as inputs concatenated together,
separated by semicolons
 Database interfaces with phone application
 database receives "data" string
 Input:
 Data - String, all text fields entered on phone concatenated together,
separated by semicolons
 database sends "confirmation code" string back to phone application
 Output:
 Confirmation Code - String, 6 digit numeric code assigned by
database as a key when receiving successful "data" input from Phone
App.
 Bus application interfaces with user
 Using keyboard, users enter "confirmation code" provided upon successful
purchase from phone app
 Input:
 Confirmation Code - String, 6 digit numeric code assigned by
database as a key when receiving successful "data" input from Phone
App.
 Bus application interfaces with database
Software Requirements Specification for Online Bus Booking System Page 5

 When sending output "code," database will return a Boolean indicating

successful removal of given entry from database
 Input:
 Success - Boolean, returned from database, if "True" then display
success message to user.  If "False" display fail message to user.
 Using mouse, users click an image button "Sign In", "Code" output is only
sent once
 Output:
 Code - String, 6 digit numeric code, exact copy of "Confirmation
Code."  Sent to database to verify existence of user information
 Database interfaces with Bus application
o database receives "code" string
 Input:
 Code - String, 6 digit numeric code, used to check if string already
exists in database as a key. When found, that entry in database is
removed, and output "success" is returned.
 database sends "success" Boolean back to bus application
 Output:
Success - Boolean, "true" if entry specified by "code" was found and successfully removed.  "False"
if entry specified by "code" was not found.  Database is unchanged if "Success" is false

3.2 Hardware Interfaces

 Phone Application
o must run on android based phone OS Version 2.x.  May work on version 1.x but is
not supported.
o phone must have access to internet via either WiFi or Mobile Broadband
 Bus Application
o must run on windows or mac based computer with keyboard and mouse access. 
o computer must have access to internet via either WiFi or Mobile Broadband
Software Requirements Specification for Online Bus Booking System Page 6

3.3 Software Interfaces

 We will follow typical Java naming convention.
o Number of characters will not exceed 100 characters per line.
o The first character in the variable name wil be lower case as will the following
characters until the secnod word in the variable.
o The first character of all continuing words shall be capitalized.
o No spaces or underscores shall be used in the naming variables.
o The first word and the first character of all following words of the class header shall
be capitalized.
 All data will be stored as Strings in the database.
o The only calculations that will be performed is the search implemented to check the
"code" with all the entry Keys in the database.
o The only other methods that are run are the add and remove methods for entries in
the database

3.4 Communications Interfaces

The system will be developed using Extensible Hypertext Markup Language (XHTML), PHP
Hypertext Preprocessor (PHP), Structure Query Language (SQL), Ajax, Cascading Style Sheet
(CSS), and JavaScript. The relational database was adopted because is made up of a group of
logically connected tables (data that has a relationship to other data). Therefore, establishing a
relational database management system is a great way to increase data integrity, efficiency, ask
questions, sort and filter data, provide stronger security, and share information, ease of use, data
independent among others

4. System Features
 The user opens up the phone application and is prompted for the following: First
name, Last name, email, phone number, type of ticket, credit card number, credit
card type, credit card security code, expiration date, billing zip, and any additional
billing information.
 After all information is inputted, the user hits submit.As long as all required fields
are filled, data gets sent to the server and data will be checked for validity.
 In the event the all input is valid, the user will receive a confirmation in some
fashion (through email, screen output, or both). In the event any input is invalid, an
error message is displayed via the phone screen.

 Upon entering the bus, confirmation code is entered (by user or bus driver) on a
keypad.
 This information is sent to the database for verification. If verified by keypad(or bus
driver), user is allowed on the bus (through some visual output).
 If not valid, user will be asked to re-enter the code correctly, or leave the bus. If the
client feels their rejection was in error, a phone number will be presented of
administration.
 Upon successfully entering the code, that client's data is removed from the
database.

 The administration has access to the database and can add or edit data as
needed when called by users or any other purposes.
Software Requirements Specification for Online Bus Booking System Page 7

5. Other Nonfunctional Requirements

5.1 Performance Requirements

 Response time
o The maximum response time for the submission of a job will be 1 minute.

 Capacity
o The maximum number of jobs schedulable is limited only by the capacity of the
nodes to fulfill the jobs’ deadlines; there is no upper limit inherent in the Libra
scheduler as such.

 Deadline sensitivity
o Assuming submitted statistics for jobs are accurate, the Libra scheduler will ensure
that all jobs are completed with a 10% error allowance.

 Cost sensitivity
o Under all circumstances, the maximum cost payable as submitted by the user will be
the maximum cost charged to the user.

5.2 Safety Requirements

5.3 Security Requirements

Security is used to ensure credit card information as confidential and is not stored anywhere.  The
only location any user data is visible is when users enter in their information.  System Administers
are trained on customer privacy.

5.4 Software Quality Attributes

 After each revision the system will be analyzed and compared with the system requirements
designated by the client. We will than try to break the program with test cases. 
 We will all be responsible for quality assurance.  We will cross-analyze the system
implementation with the System Requirements to verify system accuracy.  
 All final documents will be reviewed for spelling errors, broken links, and any other issues
that affect the quality of the document.  Any errors found in either the system or supporting
documents will be fixed at the time errors are found. 
Software Requirements Specification for Online Bus Booking System Page 8

5.5 Business Rules

<List any operating principles about the product, such as which individuals or roles can perform
which functions under specific circumstances. These are not functional requirements in
themselves, but they may imply certain functional requirements to enforce the rules.>

6. Other Requirements
<Define any other requirements not covered elsewhere in the SRS. This might include database
requirements, internationalization requirements, legal requirements, reuse objectives for the
project, and so on. Add any new sections that are pertinent to the project.>

Appendix A: Glossary
 Concept of Operations 
 Software Requirements
 Test Plan
 Professional Android 2 Application Development by Reto Meier
 Java standard reference

Appendix B: Analysis Models

UML Diagram 
Software Requirements Specification for Online Bus Booking System Page 9
Software Requirements Specification for Online Bus Booking System Page 10

Appendix C: To Be Determined List

<Collect a numbered list of the TBD (to be determined) references that remain in the SRS so they
can be tracked to closure.>