TABLE OF CONTENTS PAGE
1. PREFACE
2. INTRODUCTION
2.1 PURPOSE
2.2 SCOPE
2.3 OVERVIEW
3. OVERALL DESCRIPTION
3.1 PRODUCT PERSPECTIVE
3.1.1 SYSTEM INTERFACES
3.1.2 USER INTERFACES
3.1.3 HARDWARE INTERFACES
3.1.4 SOFTWARE INTERFACES
3.1.5 COMMUNICATION INTERFACES
3.1.6 MEMORY CONSTRAINTS
3.1.7 OPERATIONS
3.2 PRODUCT FUNCTIONS
3.3 USER CHARACTERISTICS
3.4 CONSTRAINTS
3.5 ASSUMPTIONS AND DEPENDENCIES
3.6 APPORTIONING OF REQUIREMENTS
4. SPECIFIC REQUIREMENTS
4.1 EXTERNAL INTERFACE REQUIREMENTS
4.2 FUNCTIONAL REQUIREMENTS
4.2.1 FUNCTIONS
· Login
· Logout
· Sign Up
· Remind Password
· View User Info
· Update User Info
· View Buses Info
· Payment
· Admin Tool
4.3 PERFORMANCE REQUIREMENTS
4.4 DESIGN CONSTRAINTS
4.5 SOFTWARE SYSTEM ATTRIBUTES
4.5.1 RELIABILITY
4.5.2 AVAILABILITY
4.5.3 SECURITY
4.5.4 MAINTAINABILITY
4.5.5 PORTABILITY
4.6 SYSTEM REQUIREMENT SPECIFICATION
4.7 OTHER REQUIREMENTS
5. USE CASE DIAGRAM FOR OBTRS
5.1 SPECIFICATION OF ACTOR
5.1.1 SPECIFICATION OF ACTOR
5.1.2 SALES MANAGER
5.1.3 SALES PERSON
5.2 SPECIFICATION OF USE CASES
5.2.1 EMPLOYEE REGISTRATION
5.2.2 PRODUCT REGISTERATION
5.2.3 SALES REGISTERATION
5.2.4 CUSTOMER REGISTERATION
5.2.5 SYSTEM LOGIN
5.2.6 UPDATE INFORMATION
5.2.7 SYSTEM OUTPUT
1. 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. 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. 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.
2. INTRODUCTION
2.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
2.2 SCOPE
The scope of the OBTRS is:
i. A person should be able to
· Login to the system through the first page of the application
· Change the password after logging into the system
· Should be able to create a new login for the accessing the reservation facility.
· Query the buses for two weeks.
· No reservation before two days can be done.
· See his/her current reservations on different buses along with the details.
· Able to choose the seats which can are available for a certain class.
· Give details about the details about the credit card details.
ii. A mail should be send to the concerned person about the confirmation of the ticket to the specified email address.
iii. The login Id and password should be sent to the mentioned email address if a new account is created.
iv. A calendar should be there which helps the person to select dates. It should also show the public and nation holidays.
v. The system should automatically show the fare for the corresponding seat and amount of money needs to be pay for selected seats.
2.3 OVERVIEW
After giving a brief introduction about the project, the body of the report is divided into two parts. They are:
· The 2nd chapter contains a full description of the functions, their properties, their aims, the constraints and the requirements of the project.
· The last chapter consists of the details of the functions and function constrain
3. OVERALL DESCRIPTION
This section describes the functions of the project and their aims. It also includes
the constraints and the requirements of the project.
3.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.
3.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.
3.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:
i. Main(Login) Page
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.
ii. Sign Up Page
Contains 4 fields which are labeled as E-Mail Address, Confirm E-Mail 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.
3.1.3 HARDWARE INTERFACES
There is no need any hardware interface for Online Bus Ticket Reservation System.
3.1.4 SOFTWARE INTERFACES
There are 2 product options for viewing:
a. Microsoft Internet Explorer
b. Mozilla Firefox
c. Apache HTTP Server
d. PHP
e. Macromedia Dreamweaver
f. MySQL
3.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 will be used for communication between the web server and client.
3.1.6 MEMORY CONSTRAINTS
There is not a specific memory constraint for OBTRS.
3.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.
3.2 PRODUCT FUNCTIONS
OBTRS is:
i. Login to the system through the first page of the application
ii. Change the password after logging into the system
iii. Should be able to create a new login for the accessing the reservation facility.
iv. Query the buses for two weeks.
v. No reservation before two days can be done.
vi. See current reservations on different buses along with the details.
vii. Able to choose the seats which can are available for a certain class.
viii. Give details about the details about the credit card details.
ix. A mail should be send to the concerned person about the confirmation of the ticket to the specified email address.
x. The login Id and password should be sent to the mentioned email address if a new account is created.
xi. A calendar should be there which helps the person to select dates. It should also show the public and nation holidays.
xii. The system should automatically show the fare for the corresponding seat and amount of money needs to be pay for selected seats.
xiii. The administrator of the web site should used an admin tool for customize the web site.
xiv. The admin tool shall handle followings:
a. Shall change the logo
b. Shall add or remove links onto the main bar
c. Shall give options for search tools
d. Shall add, remove or update links on the menu
e. Shall add, remove or update events on the event calendar
f. Shall add or remove medias in the content menu
xv. Logout from the system.
3.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.
· 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.
3.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 interfaces.
d. Parallel Operations: There are no parallel operations.
e. Audit Functions: There shall be no audit functions.
f. Control Functions: There shall be no control functions
g. 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.
h. Signal Handshake Protocols: This is no signal handshake protocols.
i. 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.
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 satisfied by the back up process at the server side.
3.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 platforms and Microsoft Internet Explorer version 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.
3.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.
4. SPECIFIC REQUIREMENTS
4.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.
4.2 FUNCTIONAL REQUIREMENTS
4.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
i. Users enter their user names.
ii. Users enter their passwords.
* Users can enter their user names and password wrongly. Error message appears
iii. Users click login button.
iv. System connects to database.
v. Homepage displayed.
· Logout
i. The system users click to logout button.
ii. DB connection terminated.
iii. The system logout the user successfully.
iv. The system redirect to the homepage.
· New user with new mail address is required
i. Users enter their e-mail address.
ii. Users enter their passwords.
iii. Users enter other required information.
iv. Users click sign up button.
v. System connects to database.
vi. A message appears which shows the membership applied.
vii. Activation mail is sent.
· Remind Password
i. Users enter their e-mail address.
*Wrong e-mail should be entered. Error message appears
ii. Users click on Remind Password Button.
iii. Password is sent to e-mail address.
· Viewing the user info.
i. The user must be logged on to the system.
ii. The user clicks on desired person or themselves.
iii. The system retrieves the desired person‘s information from DB.
iv. The system shows the person‘s information in new page.
· Updating the user info.
i. The user must be logged on to the system.
ii. The user clicks on themselves.
iii. The system retrieves the desired person‘s information from DB.
iv. The system shows the person‘s information in new page.
v. The user clicks on Update Profile Link.
vi. The user can update his/her profile in desired information field.
vii. The user clicks on Save Button.
viii. The user profile is updated.
· Viewing the buses info.
i. The user must be logged on to the system.
ii. The user clicks on desired time and destination.
iii. The system retrieves the desired buses information from DB.
iv. The system shows the buses information in new page.
v. The system shows the available seats from the selected bus.
· Paying money for the available (selected) seat(s).
i. The user must be logged on to the system which is defined on
ii. The user clicks on desired time and destination.
iii. The system retrieves the desired buses information from DB.
iv. The system shows the buses information in new page.
v. The system shows the available seats from the selected bus.
vi. The system shows the details of the payment.
vii. The system sent an email to the customer for informing.
4.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.
4.4 DESIGN CONSTRAINTS
All documentation of the system shall be prepared related to IEEE standards. Furthermore, the content shall be compliance with IEEE standards.
4.5 SOFTWARE SYSTEM ATTRIBUTES
4.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.
4.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.
4.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 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.
4.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 C4C5 Dev Group. The maintainability shall be easily done by integrating new modules and offering new software solutions for the system.
4.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.
4.6 SYSTEM REQUIREMENT SPECIFICATION
This section will describe the functional and non-functional requirements at a sufficient level of detail for the designers to design a system satisfying the User requirements and testes to verify that the system satisfies the requirements. The system requirements will be developed through object oriented analysis and design methods by the use of UML model language. All system requirements will be uniquely identifiable.
4.7 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
5. USE CASE DIAGRAM FOR OBTRS
The figure shows the Use Case Diagram (UCD) for OBTRS. The UCD is developed as a part of the analysis phase of the system development process. This diagram might be changed during later stages in the development process.
Software Requirements
Activity 1:
Identify functional and non functional requirement.
Functional Requirement:-
1.The details of the buses, price list and employee details are to be maintained and controlled solely by the (Manager) admin alone.
2.The employer can change alone the password assigned to him.
3.Also first the employer needed to login first in order to perform the booking actions.
4.Calculations of the charges and the reimbursements are to be implemented by the application alone as designated by the admin.
5.The details of the buses and seats available are to be maintained and can be updated regularly(of course only by the admin).
6.Enquiry form, booking form and prising list are to be maintained in separate pages.
7.There should be new, update, cancel and search options available.
NonFunctional Requirement:-
1. The software service able to accommodate variations required by each unit within the same domain of functionality.
2. Consuming a service present a low barrier to entry, require no service-specific technical training, and should not lead to consumer lock-in.
3. Service providers sensitive to and accommodate the changing needs of their consumers, in terms of: performance, reliability, availability, and requests for new features.
4. Service consumers frequently rely on third party services to complement their internal business processes.
5. New software services able to integrate with existing business systems, and with services provided by other vendors.
6. The enterprise able to find and retain good developers that can build and maintain its software services.
7. Optimal total cost of ownership (TCO) composed of many factors, all of which should be taken into account.
Identify functional and non functional requirement.
Functional Requirement:-
1.The details of the buses, price list and employee details are to be maintained and controlled solely by the (Manager) admin alone.
2.The employer can change alone the password assigned to him.
3.Also first the employer needed to login first in order to perform the booking actions.
4.Calculations of the charges and the reimbursements are to be implemented by the application alone as designated by the admin.
5.The details of the buses and seats available are to be maintained and can be updated regularly(of course only by the admin).
6.Enquiry form, booking form and prising list are to be maintained in separate pages.
7.There should be new, update, cancel and search options available.
NonFunctional Requirement:-
1. The software service able to accommodate variations required by each unit within the same domain of functionality.
2. Consuming a service present a low barrier to entry, require no service-specific technical training, and should not lead to consumer lock-in.
3. Service providers sensitive to and accommodate the changing needs of their consumers, in terms of: performance, reliability, availability, and requests for new features.
4. Service consumers frequently rely on third party services to complement their internal business processes.
5. New software services able to integrate with existing business systems, and with services provided by other vendors.
6. The enterprise able to find and retain good developers that can build and maintain its software services.
7. Optimal total cost of ownership (TCO) composed of many factors, all of which should be taken into account.
Constraints of the Online Bus Ticketing System
- Server down, hence no registration/ booking could be made.
- Virus (attack server)
- Maintenance
- Lots of competitor
- Other buses’ company
- Other transportations (aeroplane, train, rented car, etc.)
- High-cost petrol
- Lack or lose of trust on the company
- Afraid in case of being cheated
Team Roles
Chief executive officer (CEO)
Indra Shahril Shaini will act as project leader that acts as a facilitator and lead the project session to make sure all works are done.
Director
Amirul Rashid provides department-level support for the project and understanding of how the project must support business function and requirement.
Secretary
Ahmad Fadhlan incharge in maintenance record keeping. He develops an agenda of the project. Presents overall recap of project session and plays important role in doing paperwork.
Project developer
Mohd Hazreen provides technical assistant and resources on issues like security, backup, hardware, software, network capability and also provides overview of the current system and proposed project scope and constraints.
Web developer
Mohd Hamimi is the in charge in developing the web to ensure that the web is always updated. He also ensures that the server down problem must be avoided and also no virus attack occurred.
Information developer
Mohd Firdaus Mohd Said reviews the main business processes, tasks, user roles, input, output and also explains the reason for the project and expresses top management authorization and support.
System analyst
Muhammad Azfar presents outline of specific topics and issues to be investigated. He discusses and document all system requirement and also develops models and prototypes.
Multimedia and services
Wan Muhd Fazri act as an assistant for web developer. He prepares the project schedule such as Gant chart and Pert chart and also in charge in maintenance matter.
Indra Shahril Shaini will act as project leader that acts as a facilitator and lead the project session to make sure all works are done.
Director
Amirul Rashid provides department-level support for the project and understanding of how the project must support business function and requirement.
Secretary
Ahmad Fadhlan incharge in maintenance record keeping. He develops an agenda of the project. Presents overall recap of project session and plays important role in doing paperwork.
Project developer
Mohd Hazreen provides technical assistant and resources on issues like security, backup, hardware, software, network capability and also provides overview of the current system and proposed project scope and constraints.
Web developer
Mohd Hamimi is the in charge in developing the web to ensure that the web is always updated. He also ensures that the server down problem must be avoided and also no virus attack occurred.
Information developer
Mohd Firdaus Mohd Said reviews the main business processes, tasks, user roles, input, output and also explains the reason for the project and expresses top management authorization and support.
System analyst
Muhammad Azfar presents outline of specific topics and issues to be investigated. He discusses and document all system requirement and also develops models and prototypes.
Multimedia and services
Wan Muhd Fazri act as an assistant for web developer. He prepares the project schedule such as Gant chart and Pert chart and also in charge in maintenance matter.
Group Members
Indra Shahril Shaini
Amirul Rashid
Ahmad Fadhlan
Muhammad Azfar
Mohd Hazreen
Mohd Firdaus Mohd Said
Mohd Hamimi
Wan Muhd Fazri
Amirul Rashid
Ahmad Fadhlan
Muhammad Azfar
Mohd Hazreen
Mohd Firdaus Mohd Said
Mohd Hamimi
Wan Muhd Fazri
Subscribe to:
Posts (Atom)
