Samples Rs

FERSOFT
ONLINE BUS TICKET RESERVATION SYSTEM

(OBTRS)
SRS Document Revision #: v1.0
Date of Issue: 15 1anuary 2008
Project Manager:
Seil AYDIN
Software Requirements Specification OBTRS
v1.0 16/01/2008 Page i
Approval Signatures

Approved by: Business Project Leader Approved by: IM/IT Project Leader

Prepared by: Business Project Manager Prepared by: IM/IT Project Manager

Reviewed by: Quality Assurance Manager

Organisation

Title/Subject

Number

Owner Approved by Date Version Page 2

TABLE OF CONTENTS
1. INTRODUCTION .............................................................................................. 6
1.1 .. PURPOSE .......................................................................................................................6
1.2 .. SCOPE.............................................................................................................................6
1.3 .. DEFNTONS, ACRONYMS AND ABBREVATONS ....................................................7
1.4 .. REFERENCES ................................................................................................................8
1.5 .. OVERVEW......................................................................................................................9
2. OVERALL DESCRIPTION............................................................................. 10
2.1 PRODUCT PERSPECTVE.............................................................................................10
2.1.1 SYSTEM NTERFACES .....................................................................................................10
2.1.2 USER NTERFACES..........................................................................................................10
2.1.3 HARDWARE NTERFACES...............................................................................................13
2.1.4 SOFTWARE NTERFACES................................................................................................13
2.1.5 COMMUNCATON NTERFACES.....................................................................................16
2.1.6 MEMORY CONSTRANTS.................................................................................................16
2.1.7 OPERATONS....................................................................................................................17
2.1.8 STE ADAPTATON............................................................................................................17
2.2 PRODUCT FUNCTONS .................................................................................................17
2.3 USER CHARACTERSTCS............................................................................................18
2.4 CONSTRANTS................................................................................................................19
2.5 ASSUMPTONS AND DEPENDENCES.........................................................................20
2.6 APPORTONNG OF REQUREMENTS .........................................................................20
3. SPECIFIC REQUIREMENTS.......................................................................... 21
3.1 EXTERNAL NTERFACE REQUREMENTS...................................................................21
3.2 FUNCTONAL REQUREMENTS....................................................................................21
3.2.1 FUNCTONS.......................................................................................................................21
Login....................................21
Logout..........................................................................................................................................22
Sign Up........................................................................................................................................23
Remind Password........................................................................................................................24
View User nfo .............................................................................................................................25
Update User nfo..........................................................................................................................26
View Buses nfo...........................................................................................................................28
Payment ......................................................................................................................................29
Admin Tool ..................................................................................................................................30
3.3 PERFORMANCE REQUREMENTS...............................................................................31
Organisation

Title/Subject

Number


3.4 DESGN CONSTRANTS.................................................................................................32
3.5 SOFTWARE SYSTEM ATTRBUTES..............................................................................32
3.5.1 RELABLTY ......................................................................................................................32
3.5.2 AVALABLTY....................................................................................................................32
3.5.3 SECURTY..........................................................................................................................32
3.5.4 MANTANABLTY.............................................................................................................33
3.5.5 PORTABLTY ....................................................................................................................33
3.6 OTHER REQUREMENTS...............................................................................................33
4. APPENDIX...................................................................................................... 34
4.1 USE CASES.....................................................................................................................34
4.2 .. STATE DAGRAMS.......................................................................................................36

Organisation

Title/Subject

Number


Document Change Control

Revision Number Date of Issue Author(s) Brief Description of Change
1.0
15 January 2008
Seil Aydin Initial Release

According to the IEEE Std. 830-1998, IEEE Standard Ior SoItware Requirements
SpeciIications, the Iirst version oI the requirements document was prepared on 15
January 2008.

Organisation

Title/Subject

Number


Preface

The document contains the SoItware Requirements SpeciIication oI ONLINE
BUS TICKET RESERVATION SYSTEM (OBTRS), which can be used Ior the all oI 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 oI tickets and Enquiries about availability
oI the tickets. This application includes email inIormation Ior the tickets.

The Goal oI the SoItware Requirement SpeciIication is to describe overall
Iunctionality oI the ONLINE BUS TICKET RESERVATION SYSTEM. This system is
prepared according to IEEE standard 2]. The SoItware Requirements SpeciIication is in
content compliance with the IEEE standard 830-1998 in which the contents oI this
standard are rearranged and a mapping is provided. That is, the content compliant
SoItware Requirements SpeciIication is mapped into various clauses and sub clauses oI
the IEEE standard 830-1998.

The requirements that are stated in this document will determine the Iinal product
and its Iunctionality. This document will also be used to evaluate the success oI the
project.
Organisation

Title/Subject

Number


1. INTRODUCTION

1.1 PURPOSE

The purpose oI the SoItware Requirements SpeciIication document is to maintain all
the Iunctions and the speciIications oI the Online Bus Ticket Reservation System.
Besides, it contains the detailed descriptions oI all the requirements speciIied beIore.

1.2 SCOPE

The scope oI the OBTRS is:
1. A person should be able to

Login to the system through the Iirst page oI the application

Change the password aIter logging into the system

Should be able to create a new login Ior the accessing the reservation
Iacility.

Query the buses Ior two weeks (Only two weeks advance reservation
is available).

No reservation beIore two days can be done.

See his/her current reservations on diIIerent buses along with the
details.

Able to choose the seats which can are available Ior a certain class.

Organisation

Title/Subject

Number


Give details about the details about the credit card details.

2. A mail should be send to the concerned person about the conIirmation oI the
ticket to the speciIied email address.

3. The login Id and password should be sent to the mentioned email address iI 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 Iare Ior the corresponding seat and
amount oI money needs to be pay Ior selected seats.

1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS

Acquirer: speciIies requirements Ior and accepts delivery oI a new or modiIied
soItware product and its documentation.
Administrator: The one who manages and maintains computer systems and
soItware.
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 oI Electrics & Electronics Engineering
IS: InIormation Systems
IT: InIormation Technology
Marquee: A piece oI text that scrolls across a browser document window.
Organisation

Title/Subject

Number


SDD: SoItware Design Document
Server: The main computer on a network.
SPMP: SoItware Project Management Plan
SRS: SoItware Requirements SpeciIication
Staff: The people who works Ior Red Bus Company.
Team: The name oI the developer group.
User: People who open the OBTRS web site and the administrator oI the OBTRS
web site.
Web: the network oI computers that Iorms the Internet
FERSOFT: Fast EIIicient Reliable SoItware Company

1.4 REFERENCES

1] IEEE Std 1058-1998, IEEE Standard Ior SoItware Project Management Plans
2] IEEE STD 830-1998, IEEE Recommended Practice Ior SoItware Requirements
SpeciIications
3] IEEE STD 1016-1998, Recommended Practice Ior SoItware Design Descriptions
4] Pressman, Roger S., Software Engineering 'A Practitioners Approach, FiIth
Edition, McGraw-Hill, 2000.
5] http://httpd.apache.org/
6] http://www.macromedia.com
Organisation

Title/Subject

Number


7] http://www.mysql.com/
8] http://www.mozilla.org/
9]http://libresoIt.urjc.es/debian-
counting/sarge/index.php?menuPackage&packagesloccount we will use PHP in our
project.
10] http://www.microsoIt.com

1.5 OVERVIEW

AIter giving a brieI introduction about the project, the body oI the report is divided
into two parts. They are;
The 2
nd
chapter contains a Iull description oI the Iunctions, their properties, their
aims, the constraints and the requirements oI the project.
The last chapter consists oI the details oI the Iunctions and Iunction constraints.

Organisation

Title/Subject

Number

Owner Approved by Date Version Page
10
2. OVERALL DESCRIPTION

This section describes the Iunctions oI the project and their aims. It also includes
the constraints and the requirements oI the project.

2.1 PRODUCT PERSPECTIVE

Online Bus Ticket Reservation System provides a group oI works with interIace
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 interIace is
needed during the development oI this project.

2.1.2 USER INTERFACES

The OBTRS shall be designed as a web based that has a main user interIace. Format
oI main screen shall be standard and Ilexable. The system shall be user Iriendly designed.
Pages shall be connected each other in a consistent way. Operations can be done with the
system shall be repeatable. The design oI the pages should allow users to do this.

Organisation

Title/Subject

Number

11
Main(Login) Page

Figure 1 Main (Login) Page of OBTRS

As it can be seen in the Iigure above, main interIace includes a Logo,
Background, Username and Password Fileds, Login button and SignUp link, II the user
click on SignUp link it retrieves the Sign Up Page. II the user click Login Button aIter
he/she enters username and password, the system retrieve Main Page oI the user.

Sign Up Page
Organisation

Title/Subject

Number

12

Figure 2 Sign Up Page of OBTRS

Sign Up Page contains 4 Iields which are labeled as E-Mail Address, ConIirm E-
Mail Address, Password, ConIirm Password. User can sign up the system by entering
these required Iields and then pressing the Sign Up Button.

There shall be other pages who has Iunctionality related with the customer
operations and admin tool operations. The example Iigures oI the pages will be added to
the document.

Organisation

Title/Subject

Number

13
2.1.3 HARDWARE INTERFACES

There is no need any hardware interIace Ior Online Bus Ticket Reservation
System.

2.1.4 SOFTWARE INTERFACES

1. There are 2 product options Ior viewing:
A. Name: MicrosoIt Internet Explorer
Mnemonic: -
Specification number: -
Version number: 5.5
Source: MicrosoIt Corporation, the interIace oI the OBTRS is well-
documented and can be Iound at |10|.
Purpose: The web browser speciIied above is required as the container oI the
client soItware at the client site in order to execute the client site oI OBTRS.
Definition of the Interface: The MicrosoIt Internet Explorer is the soItware,
provides a Ilexible and reliable browsing experience with enhanced Web
privacy Ieatures Ior all users.
OR
B. Name: Mozilla FireIox
Mnemonic: -
Organisation

Title/Subject

Number

14
Version number: 2.0
Source: Mozilla Foundation, the interIace oI the OBTRS is well-documented
and can be Iound at |8|.
Purpose: The web browser speciIied above is required as the container oI the
client soItware at the client site in order to execute the client site oI OBTRS.
Definition of the Interface: The Mozilla FireIox Browser is the soItware,
provides a Ilexible and reliable browsing experience with enhanced Web
privacy Ieatures Ior all users.

2. Name: Apache HTTP Server
Mnemonic: -
Version number: 2.0.5.5
Source: The Apache SoItware Foundation, the interIace oI the OBTRS with
the application system is well-documented and can be Iound at |5|.
Purpose: In order to execute the client site oI OBTRS, the web server
speciIied above is required as the provider oI the client soItware at the server
site.
Definition of the Interface: The Apache HTTP Server Project is an eIIort to
develop and maintain an open-source HTTP server Ior modern operating
systems including UNIX and Windows NT. The goal oI this project is to
provide a secure, eIIicient and extensible server that provides HTTP services
in sync with the current HTTP standards.

Organisation

Title/Subject

Number

15
3. Name: PHP
Mnemonic: -
Version number: 4.0
Source: PHP Group, the interIace oI the OBTRS is well-documented and can
be Iound 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 Ior Web development and can be embedded
into HTML.

4. Name: Macromedia Dreamweaver
Mnemonic: -
Version number: 8
Source: Macromedia Inc., the interIace oI the OBTRS is well-documented
and can be Iound at |6|.
Purpose: The web development tool speciIied above is required Ior designing
and coding the project.
Definition of the Interface: Macromedia Dreamweaver is the industry-
leading web development tool, enabling users to eIIiciently design, develop
and maintain standards-based websites and applications.
Organisation

Title/Subject

Number

16

6. Name: MySQL
Mnemonic: -
Version number: 5.0
Source: MySQL document deIining the interIace can be Iound at |7|.
Purpose: Required as database server.
Definition of the Interface: MySQL is the world's most popular open source
database soItware, with over 100 million copies oI its soItware downloaded or
distributed throughout its history. With superior speed, reliability, and ease oI
use, MySQL has become the preIerred choice oI corporate IT Managers
because it eliminates the major problems associated with downtime,
maintenance, administration and support.

2.1.5 COMMUNICATION INTERFACES

The deIault communication protocol Ior data transmission between server and the
client is Transmission Control Protocol/ Internet Protocol (TCP/IP). At the upper level
Hyper Text TransIer Protocol (HTTP, deIault port80, deIault oI apache port8080) will
be used Ior communication between the web server and client.

2.1.6 MEMORY CONSTRAINTS

There is not a speciIic memory constraint Ior OBTRS.
Organisation

Title/Subject

Number

17

2.1.7 OPERATIONS

Company database backup and recovery operations should be done by FersoIt
support team. A Iull system backup will be done once a month. II any update or
modiIication required on system like interIaces, new specialties; FersoIt project group
and the acquirer will make a new meeting. The detailed operations are deIined in User
InterIaces 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 Iirst page oI the application
2. Change the password aIter logging into the system
3. Should be able to create a new login Ior the accessing the reservation Iacility.
4. Query the buses Ior two weeks (Only two weeks advance reservation is
available).
5. No reservation beIore two days can be done.
6. See current reservations on diIIerent buses along with the details.
7. Able to choose the seats which can are available Ior 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 conIirmation oI the
ticket to the speciIied email address.
Organisation

Title/Subject

Number

18
10. The login Id and password should be sent to the mentioned email address iI 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 Iare Ior the corresponding seat and
amount oI money needs to be pay Ior selected seats.

13. The administrator oI the web site should used an admin tool Ior customize the
web site.

14. The admin tool shall handle Iollowings:
a) Shall change the logo
b) Shall add or remove links onto the main bar
c) Shall give options Ior search tools
d) Shall add, remove or update links on the menu
e) Shall add, remove or update events on the event calendar
I) Shall add or remove medias in the content menu

15. Logout Irom the system.

2.3 USER CHARACTERISTICS

The user types that would use the OBTRS are as Iollows:
Administrator: Administrators shall usually do anything on the site, in all pages.
Administrator is responsible Ior updating and the maintenance oI the web site
content such as adding/removing inIormation 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

Title/Subject

Number

19

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
inIormation which is belong to current time. User can see all general inIormation,
FAQ can use search.

External Users: External users are people who have not got any user account Ior
the web site. They shall use the general inIormation, FAQ.

2.4 CONSTRAINTS

a. Regulatory Policies: There are no regulatory policies.
b. Hardware Limitations: There are no hardware limitations.
c. Interfaces to other Applications: There shall be no interIaces.
d. Parallel Operations: There are no parallel operations.
e. Audit Functions: There shall be no audit Iunctions.
f. Control Functions: There shall be no control Iunctions
g. Higher-order Language Functions: The PHP shall be used Ior developing the
web pages with the help oI Macromedia Dreamveawer. For the database
inIormation, SQL shall be used.
h. Signal Handshake Protocols: This is no signal handshake protocols.
i. Reliability Requirements: Total number oI bugs in the system shall not exceed
1 oI the total line number oI code, except connection reliability which is out oI
our range.
j. Criticality of the Application: The server applications shall be available 365
days.
k. Safety and Security Considerations: The password and a valid username are the
security issues. Data protection shall be satisIied by the back up process at the
server side.

Organisation

Title/Subject

Number

20
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 user`s computer must be Windows 95 or later version platIorms and
MicrosoIt Internet Explorer version 5.5 or later
TCP/IP protocol must be installed to communicate through HTTP messages.
The accuracy oI the inIormation oI users is the responsibility oI all users.

2.6 APPORTIONING OF REQUIREMENTS

The requirements that may be delayed until Iuture versions oI the OBTRS are as
Iollows:
Backup and recovery oI the inIormation will not be done in the Iirst version oI the
OBTRS. In the Iuture versions oI the OBTRS, these issues will be handled.
When the OBTRS developed in the Iuture handle these requirements, this subsection oI
the corresponding SRS document will be updated.
Organisation

Title/Subject

Number

21
3. SPECIFIC REQUIREMENTS

3.1 EXTERNAL INTERFACE REQUIREMENTS

InterIaces external to the OBTRS can be explained as 'User InterIaces. The
section 2.1.2 User InterIaces provide details oI the user interIaces.

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 oI the system.

Login

Use Case No 1
Use Case Name Login
DeIined By Seil Aydin Last Updated By Seil Aydin
DeIined 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 oI the system.
Post-conditions
Priority High
Organisation

Title/Subject

Number

22
Normal Course
Events
1 Users enter their user names.
2 Users enter their passwords.
3 Users click login button.
4 System connects to database.
5 Homepage displayed.
Alternative
Courses
A 3.1 Users can enter their user names and password wrongly.
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 2
Use Case Name Logout

Actors: User and Admin
Descriptions User Logout.
Organisation

Title/Subject

Number

23
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 successIully.
4. The system redirect to the homepage.
Alternative
Courses

Exceptions
Assumptions

Notes:

Table 2. Use Case of Logout Function

Sign Up

Use Case No 3
Use Case Name Sign up

Actors: User
Descriptions User Sign up.
Pre-conditions New user with new mail address is required
Organisation

Title/Subject

Number

24
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 inIormation.
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.
Alternative
Courses
A 4.1 Same e-mail address is existed in database
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 4
Use Case Name Remind Password
Organisation

Title/Subject

Number

25

Actors: User
Descriptions Reminding Iorgotten passwords.
Pre-conditions The user must be a member oI 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.
Alternative
Courses
A 2.1 Wrong e-mail should be entered.
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 5
Use Case Name View user InIo
Organisation

Title/Subject

Number

26

Actors: User
Descriptions Viewing the user inIo.
Pre-conditions The user must be logged on to the system.
Post-conditions
Priority High
Normal Course
Events
1. The user must be logged on to the system which is deIined on
use case 1.
2. The user clicks on desired person or themselves.
3. The system retrieves the desired person`s inIormation Irom DB.
The system shows the person`s inIormation in new page.
Alternative
Courses
A 3.1. The system cannot access to the DB.
A 3.2. The system puts a message on the top oI the window about the
problem.
A 3.3. Continue with Step 2 in the normal course events.
Exceptions
Assumptions
Notes: ReIerenced Use Case 1.

Table 5. Use Case of View User Info Function
Update User Info

Use Case No 6
Use Case Name Update User InIo
Organisation

Title/Subject

Number

27
DeIined By SA Last Updated By SA

Actors: User
Descriptions Updating the user inIo.
Post-conditions
Priority High
Normal Course
Events
use case 1.
2. The user clicks on themselves.
3. The system retrieves the desired person`s inIormation Irom DB.
The system shows the person`s inIormation in new page.
4. The user clicks on Update ProIile Link.
5. The user can update his/her proIile in desired inIormation Iield.
6. The user clicks on Save Button.
7. The user proIile is updated.
Alternative
Courses
A 3.2. The system redirect to the home page.
problem.

problem.

Exceptions
Organisation

Title/Subject

Number

28
Assumptions
Notes: ReIerenced Use Case 1.

Table 6. Use Case of Update User Info Function
View Buses Info

Use Case No 7
Use Case Name View buses InIo

Actors: User
Descriptions Viewing the buses inIo.
Post-conditions
Priority High
Normal Course
Events
use case 1.
2. The user clicks on desired time and destination.
3. The system retrieves the desired buses inIormation Irom DB.

4. The system shows the buses inIormation in new page.
5. The system shows the available seats Irom the selected bus.
Alternative
Courses
problem.
Organisation

Title/Subject

Number

29
Exceptions
Assumptions
Notes: ReIerenced Use Case 1

Table 7 . Use Case of View Buses Info Function

Payment

Use Case No 8
Use Case Name Payment

Actors: User
Descriptions Paying money Ior the available (selected) seat(s).
Post-conditions
Priority High
Normal Course
Events
use case 1.
2. The user clicks on desired time and destination.
3. The system retrieves the desired buses inIormation Irom DB.
4. The system shows the buses inIormation in new page.
5. The system shows the available seats Irom the selected bus.
6. The system shows the details oI the payment.
7. The system sent an email to the customer Ior inIorming.
Organisation

Title/Subject

Number

30
Alternative
Courses
problem.
Exceptions
Assumptions

Table 8 . Use Case of Payment Function

Admin TooI

Use Case No 9
Use Case Name Admin Tool

Actors: Admin
Descriptions Paying money Ior the available (selected) seat(s).
Pre-conditions The admin must be logged on to the system.
Post-conditions
Priority High
Normal Course
Events
1. The admin must be logged on to the system which is deIined on
use case 1.
2. The admin must be clicked on the admin operations. The
system gives opportunity the admin doing the Iollowing:
Organisation

Title/Subject

Number

31
II the change logo is clicked, the admin can change the
logo oI the company.
II the add/remove/update links is clicked, the admin can
change the links.
II the give option is clicked, the admin can change the
search options.
II the add/remove/update event is clicked, the admin
can change the events on the calendar.
II the add/remove content is clicked, the admin can
change the content oI the web site.

Alternative
Courses
problem.
Exceptions
Assumptions

Table 9 . Use Case of Admin Tool Function

3.3 PERFORMANCE REQUIREMENTS

The system perIormance is adequate. However, OBTRS is working with the user
internet connection, 60 oI the perIormance is up to the client side.

Organisation

Title/Subject

Number

32
3.4 DESIGN CONSTRAINTS

All documentation oI 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 oI the time. The number oI deIect should not
exceed 10 per Iunction. In addition, beIore the submission oI the Iinal release the
calendar must be tested in case oI the deIects over 10 per Iunction.

3.5.2 AVAILABILITY

The availability oI the OBTRS is up to the internet connection oI 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, iI user does not have an account; Ior the availability
oI the OBTRS user should sign up to the system by clicking the sign up link Irom the
home page.
3.5.3 SECURITY

The authorization mechanism oI 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 diIIerent types oI users so there are diIIerent levels oI authorization. There
Organisation

Title/Subject

Number

33
will be also a Iirewall installed on the server so the incoming transactions can be Iiltered.
Data integrity Ior critical variables will also be checked.

3.5.4 MAINTAINABILITY

The requirements, modules that are explained in this document are enough to
satisIy the customers` needs and wants. In case oI a change or addition demand aIter
completing the system or in development processes oI 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 oIIering new soItware solutions Ior the
system.
3.5.5 PORTABILITY

The OBTRS is an online service. So, anyone can use the service. One and only the
server oI the system must have the required soItware including MySQL, Apache.
3.6 OTHER REQUIREMENTS

There are no other requirements in this phase. II some extra requirements are
wanted by the customer or acquirer, these are added in this part later
Organisation

Title/Subject

Number

34

4. APPENDIX
4.1 USE CASES

Figure 3 Use Case of User

Organisation

Title/Subject

Number

35

Figure 4 Use Case of Admin

Organisation

Title/Subject

Number

36

Figure 5 Use Case of External User

4.2 STATE DIAGRAMS

Organisation

Title/Subject

Number

37

Figure 6 State Diagram of Login

Organisation

Title/Subject

Number

38

Figure 7 State Diagram of Logout
Click the logout
link

Home page
displayed
Start 'Logout
Organisation

Title/Subject

Number

39

Figure 8 State Diagram of Sign Up
User enters
required
inIormation

Clicks the sign
up button
Membership
applied message
is displayed
Start 'Sign up
|Access to the DB|
|Iilled wrong|
|Cannot Access to the database|
Organisation

Title/Subject

Number

40

Figure 9 State Diagram of Remind Password

Figure 10 State Diagram of Update User Info
User enter
their e-
mail
address

Click the
Remind
Error
Message
Password
sent to e-
mail
Start 'Remind
Password
|Iilled correctly|
End oI Remind
Password
|Iilled
wrong|
Use Case 1

Start 'Update User InIo
Organisation

Title/Subject

Number

41

Samples Rs

Uploaded by

Document Information

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

Samples Rs

Uploaded by

Copyright:

Available Formats

FERSOFT

ONLINE BUS TICKET RESERVATION SYSTEM

You might also like