Software Requirements

Specification
for

Bus seat

Reservation System
1. Introduction
1.1 Purpose
Bus seat reservation system could be used in a transport company for seat reservation
purposes.

1.2 Document Conventions

N/A

1.3 Intended Audience and Reading Suggestions

This document is useful for system designer as a guideline to development. Also clients
could refer to satisfy if there requirements are entertained completely or not.

1.4 Product Scope

This is a custom product used in Transport Company for seat reservation. This system is
being introduced to overcome the drawbacks, faults such as reserving a pre-reserved seat & also
to save the overhead of personal communication between staff of two different stops in order to
reserve a seat.

1.5 References
SRS Template

2. Overall Description
2.1 Product Perspective
Bus seat reservation system is a replacement of manual system for reserving ticket for a
bus, traveling on a route. This system is being introduced to overcome the drawbacks, faults such
as reserving a pre-reserved seat & also to save the overhead of personal communication between
staff of two different stops in order to reserve a seat.
2.2 Product Functions

The major functionality required from system is:

Inform witch of the buses are on the route, where they are, there arrival time.

Inform if seat for a bus is available or not.

Allow to reserve seat between two stops of a route for available bus.

allow to cancel a reservation

allow to add new route

allow to edit a route to add a stop, change rent, etc

allow to enter new staff member record

allow to start journey of a bus by entering its record

2.3 User Classes and Characteristics

Prospective users for bus seat reservation system are:

1-ticketing staff members

One or more persons on each of the stop on route of a bus that reserve ticket for a
bus for some passenger. they will interact with the system the most.
Besides this to types of staff members also exit, one special staff members who
can plan a journey as they are on starting stop of a route, second administrative staff who have
extra rights of adding employee records, route record etc.

2-customers
Will just view the information about the busses and available seats etc.

2.4 Operating Environment

TBD

2.5 Design and Implementation Constraints

-Schedule for buses journey plan will cover two week span.
 -no reservation could be made before three days of journey.

-customers can’t edit any record.

-ticket could not be issued for a bus for which journey is not yet planned.

-can’t issue a ticket for a bus which is passed from current stop.

-can’t issue ticket for seat that does not exist in bus or is pre-reserved.

2.6 User Documentation

User will provided with user documentation document

3. External Interface Requirements

3.1 User Interfaces
Following are the interactions between users and the system:

Home screen will show the customer interface along with staff member login
option. This interface will be available for both the customer and the staff. Staff member
is provided login and he will make all the transactions there.

After login, he will provide information about all buses available for ticketing. If
the seat is available, he can allocate it for a passenger after entering his info like name,
destination, and cell. If the member is also an administrative, which will be determined
from his login id, he will be shown extra Manu of updating record for a bus like planning
a journey, record for arrival of a bus etc.

3.2 Hardware Interfaces

N/A

3.3 Software Interfaces

N/A ( independent system till )l
4. System Features

4.1 On route bus information display

4.1.1 Description and Priority

This is basically customer view but available for both customer and staff. It will
display the record of each bus that is arriving to the current stop, its location along
with information about availability of seat. Record will be updated at instance as
updated from ay stop by administrator.

4.1.2 Stimulus/Response Sequences

This view will be the home to the product & displayable to each stop. It will show
the information w.r.t current stop.

4.1.3 Functional Requirements

No user response is intended. Following functional requirements need satisfaction

in order to display timely information:
=client (system on current stop) needs to connect with main server, so that
updates come frequently.
=time of response is is important at all.

4.2 Seat reservation

4.1.1 Description and Priority
this functionality is only available to the staff members. Member is able to reserve
ticket after lagging in, if available by entering customer’s information.

4.1.2 Stimulus/Response Sequences

Member will login from home view and will displayed details about seatable
busses. He will provide the option to reserve seat of a on route bus if available. He will
then reserve seat by entering the information of passenger like name, nic, destination,
cell. He will informed about expense and will provided option to print receipt.
 4.1.3 Functional Requirements
Functional requirements are:

connection to main server for information about busses.

authority to update database

5. Other Nonfunctional Requirements

5.1 Performance Requirements
Need for timely responsive system as information is hard time

5.2 Safety Requirements

All staff members transactions should be check for consistency and company laws
implication

5.3 Security Requirements

System should be secure at all

5.4 Software Quality Attributes

Preference should be made to follow standards of development

6. Other Requirements
TBD
Appendix A: Glossary

SEATABLE BUS: bus available for seat allocation, for which journey is planned

CURRENT STOP: stop on which system is being used

Appendix B: Analysis Models

TBD

Appendix C: To Be Determined List

Will be furnished soon