Approval Signatures

FERSOFT
ONLINE BUS TICKET RESERVATION SYSTEM

(OBTRS)
SRS Document Revision #: v1.0
Date of Issue: 15 January 2008
Project Manager:
Seil AYDIN
Software Requirements
Specification
OBTRS
Approval
Signatures
Approved by:
Project Leader
Approved by:
Project Leader
IM/IT
Business
Prepared by:
IM/IT
Project Manager
Prepared by:
Business
Project Manager
Reviewed by:
Quality
Assurance Manager
v1.0 16/01/2008 Page i
Software Requirements Specification
OBTRS
TABLE OF CONTENTS
1. INTRODUCTION 6
1.1 ..PURPOSE
1.2 ..SCOPE
1.3 ..DEFINITIONS, ACRONYMS AND ABBREVIATIONS

1.4 ..REFERENCES
1.5 ..OVERVIEW
2. OVERALL DESCRIPTION
2.1 PRODUCT PERSPECTIVE
10
10
2.1.1 SYSTEM INTERFACES
10
2.1.2 USER INTERFACES
10
2.1.3 HARDWARE INTERFACES 13

2.1.4 SOFTWARE INTERFACES 13
2.1.5 COMMUNICATION INTERFACES
16
2.1.6 MEMORY CONSTRAINTS 16

2.1.7 OPERATIONS
17
2.1.8 SITE ADAPTATION
17
2.2 PRODUCT FUNCTIONS 17

2.3 USER CHARACTERISTICS
18
2.4 CONSTRAINTS 19
2.5 ASSUMPTIONS AND DEPENDENCIES
20
2.6 APPORTIONING OF REQUIREMENTS
20
3. SPECIFIC REQUIREMENTS
21
3.1 EXTERNAL INTERFACE REQUIREMENTS
21
3.2 FUNCTIONAL REQUIREMENTS 21

3.2.1 FUNCTIONS
21
Login21
Logout 22
Sign Up
23
Remind Password
24
View User Info 25

Update User Info
26
View Buses Info
28
Payment
29
Admin Tool
30
3.3 PERFORMANCE REQUIREMENTS

Organisation
Owner
Title/Subject
Approved by
Date
Number
Version Page 2
31
3.4 DESIGN CONSTRAINTS
OBTRS
32
3.5 SOFTWARE SYSTEM ATTRIBUTES

3.5.1 RELIABILITY
32
3.5.2 AVAILABILITY
32
3.5.3 SECURITY
32
3.5.4 MAINTAINABILITY
3.5.5 PORTABILITY
33
3.6 OTHER REQUIREMENTS
4. APPENDIX
4.1 USE CASES
34
34
4.2 ..STATE DIAGRAMS
33
36
33
32
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page 3
OBTRS
Document Change Control
Revision Number
Date of Issue
Author(s)
Brief Description of Change
1.0
15 January 2008
Seil Aydn
Initial Release
According to the IEEE Std. 830-1998, IEEE Standard for Software Requirements
Specifications, the first version of the requirements document was prepared on 15 January
2008.
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page 4
OBTRS
Preface
The document contains the Software Requirements Specification of ONLINE BUS

TICKET RESERVATION SYSTEM (OBTRS), which can be used for the all of the
internet users. The Ticket Reservation System is an Internet based application that can be
accesses throughout the Net and can be accessed by any one who has a net connection.
This application will automate the reservation of tickets and Enquiries about availability of
the tickets. This application includes email information for the tickets.
The Goal of the Software Requirement Specification is to describe overall

functionality of the ONLINE BUS TICKET RESERVATION SYSTEM. This system is
prepared according to IEEE standard [2]. The Software Requirements Specification is in
content compliance with the IEEE standard 830-1998 in which the contents of this
standard are rearranged and a mapping is provided. That is, the content compliant Software
Requirements Specification is mapped into various clauses and sub clauses of the IEEE
standard 830-1998.
The requirements that are stated in this document will determine the final product
and its functionality. This document will also be used to evaluate the success of the project.
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page 5
OBTRS
1. INTRODUCTION
1.1 PURPOSE
The purpose of the Software Requirements Specification document is to maintain all
the functions and the specifications of the Online Bus Ticket Reservation System. Besides,
it contains the detailed descriptions of all the requirements specified before.
1.2 SCOPE
The scope of the OBTRS is:
1. A person should be able to

1 Login to the system through the first page of the application
2 Change the password after logging into the system
3 Should be able to create a new login for the accessing the reservation
facility.
4 Query the buses for two weeks (Only two weeks advance reservation is
available).
5 No reservation before two days can be done.
6 See his/her current reservations on different buses along with the
details.
7 Able to choose the seats which can are available for a certain class.
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page 6
OBTRS
1 Give details about the details about the credit card details.
2. A mail should be send to the concerned person about the confirmation of the
ticket to the specified email address.
3. The login Id and password should be sent to the mentioned email address if a
new account is created.
4. A calendar should be there which helps the person to select dates. It should also
show the public and nation holidays.
5. The system should automatically show the fare for the corresponding seat and
amount of money needs to be pay for selected seats.
1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS
Acquirer: specifies requirements for and accepts delivery of a new or modified

software product and its documentation.
Administrator: The one who manages and maintains computer systems and
software.
Calendar: it is a tool which user enters monthly program
ONLINE BUS TICKET RESERVATION SYSTEM (OBTRS): The project
name.
FAQ: Frequently Asked Questions.
IEEE: Institute of Electrics & Electronics Engineering
IS: Information Systems
IT: Information Technology
Marquee: A piece of text that scrolls across a browser document window.
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page 7
OBTRS
SDD: Software Design Document

Server: The main computer on a network.
SPMP: Software Project Management Plan
SRS: Software Requirements Specification
Staff: The people who works for Red Bus Company.
Team: The name of the developer group.
User: People who open the OBTRS web site and the administrator of the OBTRS
web site.
Web: the network of computers that forms the Internet
FERSOFT: Fast Efficient Reliable Software Company
1.4 REFERENCES
[1] IEEE Std 1058-1998, IEEE Standard for Software Project Management Plans
[2] IEEE STD 830-1998, IEEE Recommended Practice for Software Requirements
Specifications
[3] IEEE STD 1016-1998, Recommended Practice for Software Design Descriptions
[4] Pressman, Roger S., Software Engineering A Practitioners Approach, Fifth
Edition, McGraw-Hill, 2000.
[5] http://httpd.apache.org/
[6] http://www.macromedia.com
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page 8
OBTRS
[7] http://www.mysql.com/
[8] http://www.mozilla.org/
[9]http://libresoft.urjc.es/debian-counting/sarge/index.php?
menu=Package&package=sloccount we will use PHP in our project.
[10] http://www.microsoft.com
1.5 OVERVIEW
After giving a brief introduction about the project, the body of the report is divided into
two parts. They are;
nd
1 The 2 chapter contains a full description of the functions, their properties, their
aims, the constraints and the requirements of the project.
2 The last chapter consists of the details of the functions and function constraints.
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page 9
OBTRS
2. OVERALL DESCRIPTION
This section describes the functions of the project and their aims. It also includes
the constraints and the requirements of the project.
2.1 PRODUCT PERSPECTIVE

Online Bus Ticket Reservation System provides a group of works with interface
environments. Also there will be a database which will keep all the records that done by
user while visiting the page.
2.1.1 SYSTEM INTERFACES

Online Bus Ticket Reservation System is connected with company server database,
thus no more connection with other systems is needed. No system interface is needed
during the development of this project.
2.1.2 USER INTERFACES

The OBTRS shall be designed as a web based that has a main user interface. Format of
main screen shall be standard and flexable. The system shall be user friendly designed.
Pages shall be connected each other in a consistent way. Operations can be done with the
system shall be repeatable. The design of the pages should allow users to do this.
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
OBTRS
Main(Login) Page
Figure 1 Main (Login) Page of OBTRS
As it can be seen in the figure above, main interface includes a Logo, Background,
Username and Password Fileds, Login button and SignUp link, If the user click on SignUp
link it retrieves the Sign Up Page. If the user click Login Button after he/she enters
username and password, the system retrieve Main Page of the user.
Sign Up Page
Organisation
Title/Subject
Number
Owner
Approved by
Date
Version
Page
OBTRS
Figure 2 Sign Up Page of OBTRS
Sign Up Page contains 4 fields which are labeled as E-Mail Address, Confirm EMail Address, Password, Confirm Password. User can sign up the system by entering these
required fields and then pressing the Sign Up Button.
There shall be other pages who has functionality related with the customer
operations and admin tool operations. The example figures of the pages will be added to
the document.
Organisation
Title/Subject
Number
Owner
Approved by
Date
Version
Page
OBTRS
2.1.3 HARDWARE INTERFACES

There is no need any hardware interface for Online Bus Ticket Reservation
System.
2.1.4 SOFTWARE INTERFACES

1. There are 2 product options for viewing:
A. Name: Microsoft Internet Explorer
Mnemonic: Specification number: Version number: 5.5
Source: Microsoft Corporation, the interface of the OBTRS is welldocumented and can be found at [10].
Purpose: The web browser specified above is required as the container of the
client software at the client site in order to execute the client site of OBTRS.
Definition of the Interface: The Microsoft Internet Explorer is the software,
provides a flexible and reliable browsing experience with enhanced Web
privacy features for all users.
OR
B. Name: Mozilla Firefox
Mnemonic: Specification number: -
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
OBTRS
Version number: 2.0

Source: Mozilla Foundation, the interface of the OBTRS is well-documented
and can be found at [8].
Purpose: The web browser specified above is required as the container of the
client software at the client site in order to execute the client site of OBTRS.
Definition of the Interface: The Mozilla Firefox Browser is the software,
provides a flexible and reliable browsing experience with enhanced Web
privacy features for all users.
2. Name: Apache HTTP Server

Mnemonic: Specification number: Version number: 2.0.5.5
Source: The Apache Software Foundation, the interface of the OBTRS with the
application system is well-documented and can be found at [5].
Purpose: In order to execute the client site of OBTRS, the web server specified
above is required as the provider of the client software at the server site.
Definition of the Interface: The Apache HTTP Server Project is an effort to

develop and maintain an open-source HTTP server for modern operating
systems including UNIX and Windows NT. The goal of this project is to
provide a secure, efficient and extensible server that provides HTTP services in
sync with the current HTTP standards.
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
OBTRS
3. Name: PHP
Source: PHP Group, the interface of the OBTRS is well-documented and can
be found at [9].
Purpose: In order to build web pages which work with MySQL database and
Apache server?
Definition of the Interface: PHP is a widely-used general-purpose scripting
language that is especially suited for Web development and can be embedded
into HTML.
4. Name: Macromedia Dreamweaver

Mnemonic: Specification number: Version number: 8
Source: Macromedia Inc., the interface of the OBTRS is well-documented and
can be found at [6].
Purpose: The web development tool specified above is required for designing
and coding the project.
Definition of the Interface: Macromedia Dreamweaver is the industry-leading
web development tool, enabling users to efficiently design, develop and
maintain standards-based websites and applications.
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
OBTRS
6. Name: MySQL
Source: MySQL document defining the interface can be found at [7].
Purpose: Required as database server.
Definition of the Interface: MySQL is the world's most popular open source
database software, with over 100 million copies of its software downloaded or
distributed throughout its history. With superior speed, reliability, and ease of
use, MySQL has become the preferred choice of corporate IT Managers
because it eliminates the major problems associated with downtime,
maintenance, administration and support.
2.1.5 COMMUNICATION INTERFACES

The default communication protocol for data transmission between server and the
client is Transmission Control Protocol/ Internet Protocol (TCP/IP). At the upper level
Hyper Text Transfer Protocol (HTTP, default port=80, default of apache port=8080) will be
used for communication between the web server and client.
2.1.6 MEMORY CONSTRAINTS

There is not a specific memory constraint for OBTRS.
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
OBTRS
2.1.7 OPERATIONS
Company database backup and recovery operations should be done by Fersoft

support team. A full system backup will be done once a month. If any update or
modification required on system like interfaces, new specialties; Fersoft project group and
the acquirer will make a new meeting. The detailed operations are defined in User
Interfaces chapter.
2.1.8 SITE ADAPTATION

The Server has requirements to operate PHP scripts Apache Web server 2.0.5.5
with PHP 4.0.
2.2 PRODUCT FUNCTIONS

OBTRS is:
1. Login to the system through the first page of the application

2. Change the password after logging into the system
3. Should be able to create a new login for the accessing the reservation facility.
4. Query the buses for two weeks (Only two weeks advance reservation is available).
5. No reservation before two days can be done.
6. See current reservations on different buses along with the details.
7. Able to choose the seats which can are available for a certain class.
8. Give details about the details about the credit card details.
9. A mail should be send to the concerned person about the confirmation of the ticket
to the specified email address.
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
OBTRS
10. The login Id and password should be sent to the mentioned email address if a new
account is created.
11. A calendar should be there which helps the person to select dates. It should also
show the public and nation holidays.
12. The system should automatically show the fare for the corresponding seat and
amount of money needs to be pay for selected seats.
13. The administrator of the web site should used an admin tool for customize the
web site.
14. The admin tool shall handle followings:
1) Shall change the logo
2) Shall add or remove links onto the main bar
3) Shall give options for search tools
4) Shall add, remove or update links on the menu
5) Shall add, remove or update events on the event calendar
6) Shall add or remove medias in the content menu
15. Logout from the system.
2.3 USER CHARACTERISTICS
The user types that would use the OBTRS are as follows :
Administrator: Administrators shall usually do anything on the site, in all pages.
Administrator is responsible for updating and the maintenance of the web site
content such as adding/removing information about the company, adding/removing
links onto the main bar, adding/removing medias in the content menu,
adding/removing/updating links on the event calendar and the menu, changing the
logo.
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
OBTRS
Customer: Customers are people who shall use OBTRS. To use this service
people should have the basic computer using ability. They shall see the buses
information which is belong to current time. User can see all general information,
FAQ can use search.
External Users: External users are people who have not got any user account for
the web site. They shall use the general information, FAQ.
2.4 CONSTRAINTS
1. Regulatory Policies: There are no regulatory policies.

2. Hardware Limitations: There are no hardware limitations.
3. Interfaces to other Applications: There shall be no interfaces.
4. Parallel Operations: There are no parallel operations.
5. Audit Functions: There shall be no audit functions.
6. Control Functions: There shall be no control functions
7. Higher-order Language Functions: The PHP shall be used for developing the
web pages with the help of Macromedia Dreamveawer. For the database
information, SQL shall be used.
8. Signal Handshake Protocols: This is no signal handshake protocols.

9. Reliability Requirements: Total number of bugs in the system shall not exceed
%1 of the total line number of code, except connection reliability which is out of
our range.
10. Criticality of the Application: The server applications shall be available 365 days.
11. Safety and Security Considerations: The password and a valid username are the
security issues. Data protection shall be satisfied by the back up process at the
server side.
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
OBTRS
2.5 ASSUMPTIONS AND DEPENDENCIES

The user must have the ability to use the internet.
The user must have connected to the internet to use the system.
The users computer must be Windows 95 or later version platforms and Microsoft
Internet Explorer version 5.5 or later
TCP/IP protocol must be installed to communicate through HTTP messages.
The accuracy of the information of users is the responsibility of all users.
2.6 APPORTIONING OF REQUIREMENTS
The requirements that may be delayed until future versions of the OBTRS are as
follows:
Backup and recovery of the information will not be done in the first version of the
OBTRS. In the future versions of the OBTRS, these issues will be handled.
When the OBTRS developed in the future handle these requirements, this subsection of the
corresponding SRS document will be updated.
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
OBTRS
3. SPECIFIC REQUIREMENTS
3.1 EXTERNAL INTERFACE REQUIREMENTS
Interfaces external to the OBTRS can be explained as User Interfaces. The
section 2.1.2 User Interfaces provide details of the user interfaces.
3.2 FUNCTIONAL REQUIREMENTS

3.2.1 FUNCTIONS
Use cases and the state transition diagram can be seen at Appendix section. In order
to see the overall view of the system.
Login
Use Case No
Use Case Name
Login
Defined By
Seil Aydn
Last Updated By
Seil Aydn
Defined On
15.01.2008
Last Updated On
15.01.2008
Actors:
User and Admin
Descriptions
User Login.
Pre-conditions
The user must be a member of the system.
Post-conditions
Priority
High
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
Normal Course
Events
OBTRS
1 Users enter their user names.

2 Users enter their passwords.
3 Users click login button.
4 System connects to database.
5 Homepage displayed.
A 3.1 Users can enter their user names and password wrongly.
Alternative
Courses
A 3.2 Error message appears.

A 3.3 Continue with Step 1 in the normal Course Events.
A 4.1 An error may occur during the database operation.
A 4.2 System shows error messages.
Exceptions
Assumptions
Notes:
Table 1. Use Case of Login Function
Logout
Use Case No
Use Case Name
Logout
Defined By
Seil Aydn
Last Updated By
Seil Aydn
Defined On
15.01.2008
Last Updated On
15.01.2008
Actors:
User and Admin
Descriptions
User Logout.
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
OBTRS
Pre-conditions
The user must be Log on to the system.
Post-conditions
Priority
Middle
Normal Course
Events
1. The system users click to logout button.

2. DB connection terminated.
3. The system logout the user successfully.
4. The system redirect to the homepage.
Alternative
Courses
Exceptions
Assumptions
Notes:
Table 2. Use Case of Logout Function
Sign Up
Use Case No
Use Case Name
Sign up
Defined By
Seil Aydn
Last Updated By
Seil Aydn
Defined On
15.01.2008
Last Updated On
15.01.2008
Actors:
User
Descriptions
User Sign up.
Pre-conditions
New user with new mail address is required
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
OBTRS
Post-conditions
Priority
Medium
Normal Course
Events
1. Users enter their e-mail address.

1.1 Users enter their passwords.
1.2 Users enter other required information.
2. Users click sign up button.
3. System connects to database.
4. A message appears which shows the membership applied.
5. Activation mail is sent.
A 4.1 Same e-mail address is existed in database
Alternative
Courses

A 4.3 Continue with Step 1 in the normal course events.
A 3.1 An error may occur during the database operation.

A 3.2 System shows error messages.
Exceptions
Assumptions
Notes:
Table 3. Use Case of Sign Up Function
Remind Password
Use Case No
Use Case Name
Remind Password
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
OBTRS
Defined By
Seil Aydn
Last Updated By
Seil Aydn
Defined On
15.01.2008
Last Updated On
15.01.2008
Actors:
User
Descriptions
Reminding forgotten passwords.
Pre-conditions
The user must be a member of the system.
Post-conditions
Priority
Medium
Normal Course
Events
1. Users enter their e-mail address.

2. Users click on Remind Password Button.
3. Password is sent to e-mail address.
A 2.1 Wrong e-mail should be entered.
Alternative
Courses

A 2.3 Continue with Step 1 in the normal course events
Exceptions
Assumptions
Notes:
Table 4. Use Case of Remind Password Function
View User Info
Use Case No
Use Case Name
View user Info
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
OBTRS
Defined By
Seil Aydn
Last Updated By
Seil Aydn
Defined On
15.01.2008
Last Updated On
15.01.2008
Actors:
User
Descriptions
Viewing the user info.
Pre-conditions
The user must be logged on to the system.
Post-conditions
Priority
High
Normal Course
Events
Alternative
Courses
1. The user must be logged on to the system which is defined on

use case 1.
2. The user clicks on desired person or themselves.
3. The system retrieves the desired persons information from DB.
The system shows the persons information in new page.
A 3.1. The system cannot access to the DB.
A 3.2. The system puts a message on the top of the window about the
problem.
A 3.3. Continue with Step 2 in the normal course events.
Exceptions
Assumptions
Notes:
Referenced Use Case 1.
Table 5. Use Case of View User Info Function
Update User Info
Use Case No
Use Case Name
Update User Info
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
OBTRS
Defined By
SA
Last Updated By
SA
Defined On
15.01.2008
Last Updated On
15.01.2008
Actors:
User
Descriptions
Updating the user info.
Pre-conditions
Post-conditions
Priority
Normal Course
Events
Alternative
Courses
High
use case 1.
2. The user clicks on themselves.
3. The system retrieves the desired persons information from DB.
The system shows the persons information in new page.
4. The user clicks on Update Profile Link.
5. The user can update his/her profile in desired information field.
6. The user clicks on Save Button.
7. The user profile is updated.
A 3.2. The system redirect to the home page.
problem.

problem.
Exceptions
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
OBTRS
Assumptions
Notes:
Referenced Use Case 1.
Table 6. Use Case of Update User Info Function
View Buses Info
Use Case No
Use Case Name
View buses Info
Defined By
Seil Aydn
Last Updated By
Seil Aydn
Defined On
15.01.2008
Last Updated On
15.01.2008
Actors:
User
Descriptions
Viewing the buses info.
Pre-conditions
Post-conditions
Priority
Normal Course
Events
High
use case 1.
2. The user clicks on desired time and destination.
3. The system retrieves the desired buses information from DB.
4. The system shows the buses information in new page.
5. The system shows the available seats from the selected bus.
Alternative
Courses

problem.
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
OBTRS

Exceptions
Assumptions
Notes:
Referenced Use Case 1
Table 7 . Use Case of View Buses Info Function
Payment
Use Case No
Use Case Name
Payment
Defined By
Seil Aydn
Last Updated By
Seil Aydn
Defined On
15.01.2008
Last Updated On
15.01.2008
Actors:
User
Descriptions
Paying money for the available (selected) seat(s).
Pre-conditions
Post-conditions
Priority
Normal Course
Events
High
use case 1.
2. The user clicks on desired time and destination.
3. The system retrieves the desired buses information from DB.
4. The system shows the buses information in new page.
5. The system shows the available seats from the selected bus.
6. The system shows the details of the payment.
7. The system sent an email to the customer for informing.
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
OBTRS
Alternative
Courses

problem.
Exceptions
Assumptions
Notes:
Table 8 . Use Case of Payment Function
Admin Tool
Use Case No
Use Case Name
Admin Tool
Defined By
Seil Aydn
Last Updated By
Seil Aydn
Defined On
15.01.2008
Last Updated On
15.01.2008
Actors:
Admin
Descriptions
Paying money for the available (selected) seat(s).
Pre-conditions
The admin must be logged on to the system.
Post-conditions
Priority
Normal Course
Events
High
1. The admin must be logged on to the system which is defined on
use case 1.
2. The admin must be clicked on the admin operations. The
system gives opportunity the admin doing the following:
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
OBTRS
If the change logo is clicked, the admin can change the

logo of the company.
If the add/remove/update links is clicked, the admin can
change the links.
If the give option is clicked, the admin can change the
search options.
If the add/remove/update event is clicked, the admin
can change the events on the calendar.
If the add/remove content is clicked, the admin can
change the content of the web site.
Alternative
Courses

problem.
Exceptions
Assumptions
Notes:
Table 9 . Use Case of Admin Tool Function
3.3 PERFORMANCE REQUIREMENTS

The system performance is adequate. However, OBTRS is working with the user
internet connection, 60% of the performance is up to the client side.
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
OBTRS
3.4 DESIGN CONSTRAINTS

All documentation of the system shall be prepared related to IEEE standards.
Furthermore, the content shall be compliance with IEEE standards [1, 2 and 3].
3.5 SOFTWARE SYSTEM ATTRIBUTES

3.5.1 RELIABILITY
The system shall operate 95% of the time. The number of defect should not
exceed 10 per function. In addition, before the submission of the final release the
calendar must be tested in case of the defects over 10 per function.
3.5.2 AVAILABILITY
The availability of the OBTRS is up to the internet connection of the client. Since
this is client-server related web-site, web-site shall be attainable all the time. User should
have an account to enter the system, if user does not have an account; for the availability of
the OBTRS user should sign up to the system by clicking the sign up link from the home
page.
3.5.3 SECURITY
The authorization mechanism of the system will block the unwanted attempts to the
server and also let the system decide on which privileges may the user have. The system
has different types of users so there are different levels of authorization. There
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
OBTRS
will be also a firewall installed on the server so the incoming transactions can be filtered.
Data integrity for critical variables will also be checked.
3.5.4 MAINTAINABILITY
The requirements, modules that are explained in this document are enough to
satisfy the customers needs and wants. In case of a change or addition demand after
completing the system or in development processes of the system, a new agreement shall
be done between the acquirer and FERSOFT Dev Group. The maintainability shall be
easily done by integrating new modules and offering new software solutions for the
system.
3.5.5 PORTABILITY
The OBTRS is an online service. So, anyone can use the service. One and only the
server of the system must have the required software including MySQL, Apache.
3.6 OTHER REQUIREMENTS

There are no other requirements in this phase. If some extra requirements are
wanted by the customer or acquirer, these are added in this part later
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page
OBTRS
4. APPENDIX
4.1 USE CASES
Figure 3 Use Case of User
Organisation
Title/Subject
Number
Owner
Approved by
Date
Version
Page
OBTRS
Figure 4 Use Case of Admin
Organisation
Title/Subject
Number
Owner
Approved by
Date
Version
Page
OBTRS
Figure 5 Use Case of External User
4.2 STATE DIAGRAMS

Organisation
Title/Subject
Number
Owner
Approved by
Date
Version
Page
OBTRS
Figure 6 State Diagram of Login
Organisation
Title/Subject
Number
Owner
Approved by
Date
Version
Page
OBTRS
Start Logout
Click the logout

link
Home page
displayed
Figure 7 State Diagram of Logout
Organisation
Title/Subject
Number
Owner
Approved by
Date
Version
Page
OBTRS
Start Sign up
User enters
required
information
Clicks the sign

up button
[filled wrong]
[Cannot Access to the database]
[Access to the DB]
Membership
applied message
is displayed
Figure 8 State Diagram of Sign Up
Organisation
Title/Subject
Number
Owner
Approved by
Date
Version
Page
OBTRS
Start Remind
Password
User enter
their email
Error
Message
Click the
Remind
[filled
wrong]
[filled correctly]
Password
sent to email
End of Remind
Password
Figure 9 State Diagram of Remind Password
Figure 10 State Diagram of Update User Info
Organisation
Owner
Start
Update
Approved by
Number
Date
Version
Page
Use Case
1
OBTRS
Organisation
Title/Subject
Owner
Approved by
Date
Number
Version
Page

Approval Signatures

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Approval Signatures

Uploaded by

Copyright:

Available Formats

FERSOFT

ONLINE BUS TICKET RESERVATION SYSTEM

v1.0 16/01/2008 Page i

Software Requirements Specification

1.3 ..DEFINITIONS, ACRONYMS AND ABBREVIATIONS

2.1.1 SYSTEM INTERFACES

2.1.2 USER INTERFACES

2.1.3 HARDWARE INTERFACES 13

2.1.6 MEMORY CONSTRAINTS 16

2.1.8 SITE ADAPTATION

2.2 PRODUCT FUNCTIONS 17

2.6 APPORTIONING OF REQUIREMENTS

3.1 EXTERNAL INTERFACE REQUIREMENTS

3.2 FUNCTIONAL REQUIREMENTS 21

View User Info 25

View Buses Info

3.3 PERFORMANCE REQUIREMENTS

Software Requirements Specification

3.4 DESIGN CONSTRAINTS

3.5 SOFTWARE SYSTEM ATTRIBUTES

3.6 OTHER REQUIREMENTS

4.2 ..STATE DIAGRAMS

Software Requirements Specification

Document Change Control

Brief Description of Change

Software Requirements Specification

The document contains the Software Requirements Specification of ONLINE BUS

The Goal of the Software Requirement Specification is to describe overall

Software Requirements Specification

1. A person should be able to

Software Requirements Specification

Acquirer: specifies requirements for and accepts delivery of a new or modified

Software Requirements Specification

SDD: Software Design Document

Software Requirements Specification

Software Requirements Specification

2.1 PRODUCT PERSPECTIVE

2.1.1 SYSTEM INTERFACES

2.1.2 USER INTERFACES

Software Requirements Specification

Figure 1 Main (Login) Page of OBTRS

Software Requirements Specification

Figure 2 Sign Up Page of OBTRS

Software Requirements Specification

2.1.3 HARDWARE INTERFACES

2.1.4 SOFTWARE INTERFACES

Software Requirements Specification

Version number: 2.0

2. Name: Apache HTTP Server

Definition of the Interface: The Apache HTTP Server Project is an effort to

Software Requirements Specification

4. Name: Macromedia Dreamweaver

Software Requirements Specification

2.1.5 COMMUNICATION INTERFACES

2.1.6 MEMORY CONSTRAINTS

Software Requirements Specification

Company database backup and recovery operations should be done by Fersoft

2.1.8 SITE ADAPTATION

2.2 PRODUCT FUNCTIONS

1. Login to the system through the first page of the application

Software Requirements Specification

2.3 USER CHARACTERISTICS

Software Requirements Specification