S0ftware Requirements

Specification
for
Airline Flight Booking System
Version 1.0 approve
!repare "y #uke !aireepinart$ %avi &eyes$ 'ingtao #iu$ Frank (e)o
an Seth *rell
Avance Software +ngineering
Fe"ruary ,-$ ,00.
Copyright 2002 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.
Software Requirements Specification for Airline flight booking system
Page ii
Table of Contents
1. Introduction................................................................................................................................1
1.1 Purpose............................................................................................................................................. 1
1.2 Document Conventions..................................................................................................................... 1
1.3 Intended Audience and Reading Suggestions...................................................................................1
1.4 Project Scope.................................................................................................................................... 1
1.5 References........................................................................................................................................ 2
2. Overall Description....................................................................................................................2
2.1 Product Perspective...........................................................................................................................2
2.2 Product Features............................................................................................................................... 2
2.3 User Classes and Characteristics.......................................................................................................3
2.4 Operating Environment..................................................................................................................... 4
2.5 Design and Implementation Constraints...........................................................................................4
2.6 User Documentation......................................................................................................................... 4
2.7 Assumptions and Dependencies........................................................................................................4
3. System Features.........................................................................................................................4
3.1 Login function.................................................................................................................................. 4
3.2 System Feature 2 (and so on)...........................................................Error! Bookmark not defined.
3.3 Reserve Seats.................................................................................................................................... 6
4. External Interface Requirements.............................................................................................9
4.1 User Interfaces.................................................................................................................................. 9
4.2 Hardware Interfaces..........................................................................................................................9
4.3 Software Interfaces...........................................................................................................................9
4.4 Communications Interfaces.............................................................................................................10
5. Other Nonfunctional Requirements.......................................................................................10
5.1 Performance Requirements.............................................................................................................10
5.2 Safety Requirements.......................................................................................................................10
5.3 Security Requirements.................................................................................................................... 10
5.4 Software Quality Attributes............................................................................................................10
6. Other Requirements................................................................................................................11
Revision History
Name Date Reason For Changes Version
Software Requirements Specification for Airline flight booking system Page 1
1. Introduction
1.1 Purpose
This SRS covers the entirety of the Airline Flight Booking system, version 1.0.
It represents the client requirements analysis effort to define the functional and non-functional
requirements of an airline website and its different functionalities. The system provides a solution to
the user to securely search for flights satisfying the user criteria, to reserve a seat, to manage the
user account and to book a flight.
This SRS describes the whole airline system
<Identify the product whose software requirements are specified in this document, including the
revision or release number. Describe the scope of the product that is covered by this SRS,
particularly if this SRS describes only part of the system or a single subsystem.>
1.2 Document Conventions
The document follows the IEEE format standard (IEEE Std. 830 1998).
<Describe any standards or typographical conventions that were followed when writing this SRS,
such as fonts or highlighting that have special significance. or e!ample, state whether priorities
for higher"level requirements are assumed to be inherited by detailed requirements, or whether
every requirement statement is to have its own priority.>
1.3 Intended Audience and Reading Suggestions
The intended audiences of this document are Dr. Chen, who is the client, software engineers, the
spring 2009 CS5391 software engineering class and for anyone who has interest in software
engineering.
Sections #, $, %, and & will be of particular interest to client. 'ar(eting staff should focus on
sections $ and &. Developers should cover all sections, as should pro)ect managers.
Section *, in particular, contains very in"depth requirements, and
<Describe the different types of reader that the document is intended for, such as developers,
pro)ect managers, mar(eting staff, users, testers, and documentation writers. Describe what the
rest of this SRS contains and how it is organi+ed. Suggest a sequence for reading the document,
beginning with the overview sections and proceeding through the sections that are most pertinent
to each reader type.>
Software Requirements Specification for Airline flight booking system Page 2
1.4 Project Scope
The airline website is an application that is stored in the user server. The purpose of the
website is to resolve the client problem to allow website users to perform different tasks. Non-
member users are only allowed to search for available flights; non-member users are required
to create an account in order to reserve a seat or to book a flight. Member users have the right
to search for available flights, to reserve a seat, to book a flight and to cancel a flight. Member
users are required to login into their account prior to flight booking.
<,rovide a short description of the software being specified and its purpose, including relevant
benefits, ob)ectives, and goals. Relate the software to corporate goals or business strategies. If a
separate vision and scope document is available, refer to it rather than duplicating its contents
here. -n SRS that specifies the ne!t release of an evolving product should contain its own scope
statement as a subset of the long"term strategic product vision.>
1.5 References
- Pressman, Roger S. Software Engineering: A Practitioners Approach. New York, NY:
McGraw-Hill, 2005.
- Lecture slides
<.ist any other documents or /eb addresses to which this SRS refers. 0hese may include user
interface style guides, contracts, standards, system requirements specifications, use case
documents, or a vision and scope document. ,rovide enough information so that the reader could
access a copy of each reference, including title, author, version number, date, and source or
location.>
2. Overall Description
2.1 Product Perspective
This project represents the initial version of the Airline Booking system. All requirements listed
herein describe a self-contained system. At a high level, this project will allow a user to book
flights, check flights, do account maintenance, and query flight information. The goal is to allow
customers greater and easier access to the airlines booking system, twenty-four hours a day.
2.2 Product Features
We can subdivide the project into 7 main features. Details of each of the following functions can be
found in Section 3.
REQ-01: Login
o Allows the user to log in to the system with his/her frequent flyer number and
password.
REQ-02: Enrollment
Software Requirements Specification for Airline flight booking system Page 3
Description: This function allows unregistered user to enroll and to create a new account
with the website. In order to create a new account, the user has to provide
required information such as first name, last name, email address and
password. Other optional information, such as phone number, credit card
information and mailing address, can be provided during the registration
process. The system checks if all required data are provided and prompts the
user to enter additional information if required. After all required information
is provided, the system auto-generates a frequent flyer number that the user
must use as username for future authentications. The system auto-generates
a frequent flyer number in less than five seconds.
Inputs: irst name, last name, email address and frequent flyer number
are required data. Optional data include phone number, credit card
information and mailing address.
Source: All data e!cept the frequent flyer number are inputs from the user. The
frequent flyer number is from the database.
Output: frequent flyer number.
Destination: The design database. The changes are committed on completion of the
"enrollment# function.
Precondition: The user must not have an existing account with the website
Postcondition: A user account is created, and the user is able to access all functionalities
provided by the function "$y account# %refer to &'(-)*+.
REQ-03: Book Flights
o Allows the user to book a flight online.
o Handles transactions for payments.
REQ-04: Reserve Seats
o Allows the user to reserve particular seats on his/her flight.
REQ-05: Flight Schedules
o Allows anyone to view flight status and information.
REQ-06: My Account
Description: This function gives the user the power to view, save, edit or delete the
information stored in his/her account. The user can check his/her
accumulated, look at the status of a flight that was booked, cancel a flight
that was already booked (optional) and change his/her address, phone
number, email or password. This feature is not available for non-registered
user.
Inputs: Account changes, if any, made by the user. Account changes include updates
on first name, last name, email address, mailing address, password or phone
numbers.
Source: All data are inputs from the user.
Output: ,one
Destination: The design database. The changes are committed on completion of the "my
account# function.
Precondition: The user must have an account with the website and must be logged in prior
to access his/her account.
Postcondition: All changes, if any such as password change, submitted by the user are
applied to the user account on completion of the function.
Software Requirements Specification for Airline flight booking system Page 4
REQ-07: Logout
o Provides a way for the user to securely log out of the system.
2.3 User Classes and Characteristics
The main actors in the system are (1) the user and (2) a flight. The user will select a flight and book
seats on the flight. Brief descriptions of these classes follow:
User
o Has properties like Name, Address, Age
o Associated with Flight Miles accumulated and Credit Card information.
Flight
o Has properties like Departing/Arriving City, Departure/Arrival dates and
times, Miles, and an identifying Flight Number.
Our user may be associated with multiple flights, and many users may be associated with any
particular flight. Thus, a many-to-many relationship exists through the act of booking flights.
The flight is but an object to be acted upon, so careful emphasis should be placed on satisfying the
user in his/her booking experience. The user is our primary customer.
2.4 Operating Environment
<Describe the environment in which the software will operate, including the hardware platform,
operating system and versions, and any other software components or applications with which it
must peacefully coe!ist.>
2.5 Design and Implementation Constraints
<Describe any items or issues that will limit the options available to the developers. 0hese might
include1 corporate or regulatory policies2 hardware limitations 3timing requirements, memory
requirements42 interfaces to other applications2 specific technologies, tools, and databases to be
used2 parallel operations2 language requirements2 communications protocols2 security
considerations2 design conventions or programming standards 3for e!ample, if the customer5s
organi+ation will be responsible for maintaining the delivered software4.>
2.6 User Documentation
<.ist the user documentation components 3such as user manuals, on"line help, and tutorials4 that
will be delivered along with the software. Identify any (nown user documentation delivery formats
or standards.>
2.7 Assumptions and Dependencies
<.ist any assumed factors 3as opposed to (nown facts4 that could affect the requirements stated
in the SRS. 0hese could include third"party or commercial components that you plan to use,
issues around the development or operating environment, or constraints. 0he pro)ect could be
Software Requirements Specification for Airline flight booking system Page 5
affected if these assumptions are incorrect, are not shared, or change. -lso identify any
dependencies the pro)ect has on e!ternal factors, such as software components that you intend
to reuse from another pro)ect, unless they are already documented elsewhere 3for e!ample, in the
vision and scope document or the pro)ect plan4.>
3.System Features
<0his template illustrates organi+ing the functional requirements for the product by system
features, the ma)or services provided by the product. 6ou may prefer to organi+e this section by
use case, mode of operation, user class, ob)ect class, functional hierarchy, or combinations of
these, whatever ma(es the most logical sense for your product.>
3.1 Login function
A. Introduction
This function allows a registered user to login his account using his frequent flyer
number with the airline and password. If a user is not registered, the website should allow
the user to enroll first. The system will check both the frequent flight number and password,
when a user attempts to login.
In most case, the frequent flight number is convenient for both the user and system
performance. The user easily memorizes his or her flight numbers but not a dull string. For
the system, when provided the flight number, flight information will be delivered at the
same time. Therefore, such operation reduces the second query chance.
Theoretically, more than one record can retrieve by users frequent flight number and
password. Two or more users may have chosen the same password and same flight number.
The way to break a tie is that system will go further to ask users email confirmation to
identify.
B. Function description
If a user stays at the initial interface, system shall provide both login and enrollment
interfaces. The user selects to enter which interfaces. When user is at login interface, it will
trigger the login function. This function traces and set the login states. All the other
functions keep tracing this state.
In general, there is two functions compose this part: login and retrieval.
b1. Login function.
Precondition:
User needs to provide account (frequent flight number) and password.
Postcondition:
If system retrieved the information, it returns true. And user is able to see the follow
interfaces: my account, book flight and flight schedule. The login state is being set to true.
If function cannot find any matched information, user will see the login interface
again. Also, a retrieval interface becomes available.
If a tie found, function will ask additional information to identify user. After user
supplies correct information, the system will set the login state to true and bring the three
interfaces.
Iteration of Login:
Input: user provided his or her account name and password.
Or user provided frequent flight number and password.
Output: set login state true, if information found.
Action:
Software Requirements Specification for Airline flight booking system Page 6
Step 1. Get user password and account(frequent flight number)
Step 2. Query from database.
Step 3. If matched, system brings user another three more interfaces. Set the global
login state.
Else, unset the login state, system will show a retrieval interface.
b2. retrieval function.
Precondition:
Login state is not set. Login function not successfully returned.
Postcondition:
a notice email sent out.
Iteration of Retrieval:
Input: either user account or frequent flight number, or email address.
Output: send out a email to notify the account and password.
Action:
Step 1. Read account or flight number, or email
Step 2. Send a email according to that user with the old password and account.
C. Use case
1. Logout function
A. Introduction.
Logout function pulls out the login state from system. Hence it protects the users privacy
and ends up a saved session. At anywhere, if logout required by user, system will clear
current operation and go back to the very initial interface, which only has login and
enrollment modules.
B. Function description.
Precondition:
When login state is set to true.
Postcondition:
All operations, such as input, query, or booking, shall be saved. After that, system
clears the current user login state. Initial interface is available.
3.2 Enrollment
3.2.1 Description and Priority
This function allows unregistered user to enroll and to create a new account with the website.
3.2.2 Stimulus/ Response Stimulus
User Action System Application
1. The system shows a list of required
data that must be provided by the
user in order to create a new
account
2. The user provides information such
as first name, last name, address,
email address, credit card
information and password by filling
fields. Some data are optional,
while others are required (refer to
3. The system checks if all required
information have been provided by
the user. If a required data is
missing, the system prompts the
user to provide the specific data in
order to process the account
Software Requirements Specification for Airline flight booking system Page 7
section 2.2, REQ-02). creation.
4. When every required data is
provided, the system creates an
account and auto-generates a unique
flyer number that must be used as a
username for future authentication.
The system also sends the user
account information, including the
flyer number, to the email address
provided by the user during the
account creation process.
3.2.3 Functional requirements
This feature is elaborated in details in the requirement &'(-)-. The system does not process
with the account creation if there is some missing required information provided by the user. the
system prompts the user to provide the missing information.
3.3 Reserve Seats
3.3.1 Description and Priority
The user can use the reserveseat function to reserve seats for an airplane flight. The seats to
be reserved are initially found through the users previous bookings. These bookings were
previously completed through the bookflight function. Available seats are shown for the departing
and returning flights booked by the user. The user selects individual seats from each flight, where
the number of selected seats from each flight is the number that the user booked on that particular
flight. An example would be if a user had previously two identical roundtrip flights for himself and
another person, the user would then need to select two departing and two returning seats. Once the
flight seats are selected, the user confirms the seat(s) selection. From that point, the seats are
removed from available/unreserved seats and the users booking is linked to those particular seats.
If the user fails to reserve a seat prior to flight takeoff, the user is randomly assigned a seat from
available seats a pre-determined amount of time prior to takeoff, currently which is exactly 30
minutes prior to initial scheduled takeoff. The reserveseats function is open to users immediately
after flight booking and available up to 30 minutes before flight takeoff.
3.3.2 Stimulus/Response Sequences
Step1. Initial seats Shown/User selects seats The system will show the user a
list of available seats for all the fights the user has previously booke an has
not alreay reserve seats for. The fights must also have a takeo! time "#
minutes greater than current time. The user will then selects particular seats
for the fight$s% an continue forwar.
Step1&. 're(conition )ogin If user is not logge in* they must be taken to a
login function for their information.
're(conitions The user must be logge in. This enables the system to access
a list of booke fights for the user an use this information to list all available
seats for those fights. User must have previous booke fights that are alreay
not alreay past reservation time winow or previously reserve by user. See
Login function.
Software Requirements Specification for Airline flight booking system Page 8
'ost(conitions The user must have selecte one or more fight seats.
Input +eceive from the system is users previously booke fights an user
information. +eceive from the user is iniviual seat$s% choices.
,utput -light information combine with available iniviual seats
Step.. User con/rms seat selection The system will output to the user their
iniviual selections. The user will have the option to con/rm or re0ect the
selections.
're(conitions User must have selecte fight seat$s% to reserve.
'ost(conitions User must either accept or re0ect the selection.
Input Iniviual seat$s% selection from user an previous information
from step1.
,utput Selecte seat$s% an fight information attache to those seat$s%
Step". 1on/rmation The user receives a con/rmation 2 con/rmation is
output to user which will isplay the fight information along with seat$s%
reserve.
're(conitions User must have con/rme seat$s% selection.
'ost(conition Screen must isplay all fight information of the user
pertaining to this reserveseats transaction.
Input 'revious information from step 1 an . of selecte seats* fight
information an user information.
,utput 1on/rmation information of selecte seat$s% to be reserve along
with fight information.
3.3.3 Functional requirements
+34(15 System must be able to link reserve seat$s% to uni6ue user account
an fights.
+34(.5 System returns from fight seat$s% to user only available/unreserve
seat$s%.
+34("5 User must be able to select fight seat$s% to reserve after booking of
fight$s%.
+34(75 System must be able to ranomly assign seats to user* if user fails to
reserve seat$s% prior to fight.
+34(85 System must be able to isplay con/rmation of seats an isplay user
fight$s% information.
+34(95 System must block other users from reserving or viewing reserve
seat$s% that user has electe
3.3.4 Charts and Diagrams
Software Requirements Specification for Airline flight booking system Page 9
3.4 Flight Status
3.4.1Description and Priority
3.4.2 Stimulus/ Response Stimulus
3.4.3 Functional requirements
3.5 Flight Schedule
3..1Description and Priority
3..2 Stimulus/ Response Stimulus
3..3 Functional requirements
3.6 My account
3.!.1Description and Priority
This function gives the user to view, save, edit or delete the information stored in his/her account.
3.!.2 Stimulus/ Response Stimulus
User action System Application
1. The system provides multiple
options to the user to manage
his/her account. Managing account
tasks include:
- Email setting
- Password & sig-in settings
- Purchase & billing information
Software Requirements Specification for Airline flight booking system Page 10
- View accumulated mileage
- My itineraries (to check m)
- View/Edit Personal Information
- Search flights
- Log out
2. The user performs one of the tasks
provided
3. Either the system applies the
changes, if any, to the user account
or the system displays the requested
data to the user.
3.!.3 Functional requirements
3.7 Account Log out
3.".1Description and Priority
3.".2 Stimulus/ Response Stimulus
3.".3 Functional requirements
4.External Interface Requirements
4.1User Interfaces
<Describe the logical characteristics of each interface between the software product and the
users. 0his may include sample screen images, any 78I standards or product family style guides
that are to be followed, screen layout constraints, standard buttons and functions 3e.g., help4 that
will appear on every screen, (eyboard shortcuts, error message display standards, and so on.
Define the software components for which a user interface is needed. Details of the user interface
design should be documented in a separate user interface specification.>
4.2Hardware Interfaces
<Describe the logical and physical characteristics of each interface between the software product
and the hardware components of the system. 0his may include the supported device types, the
nature of the data and control interactions between the software and the hardware, and
communication protocols to be used.>
4.3Software Interfaces
<Describe the connections between this product and other specific software components 3name
and version4, including databases, operating systems, tools, libraries, and integrated commercial
components. Identify the data items or messages coming into the system and going out and
describe the purpose of each. Describe the services needed and the nature of communications.
Refer to documents that describe detailed application programming interface protocols. Identify
Software Requirements Specification for Airline flight booking system Page 11
data that will be shared across software components. If the data sharing mechanism must be
implemented in a specific way 3for e!ample, use of a global data area in a multitas(ing operating
system4, specify this as an implementation constraint.>
4.4Communications Interfaces
<Describe the requirements associated with any communications functions required by this
product, including e"mail, web browser, networ( server communications protocols, electronic
forms, and so on. Define any pertinent message formatting. Identify any communication
standards that will be used, such as 0, or 900,. Specify any communication security or
encryption issues, data transfer rates, and synchroni+ation mechanisms.>
5.Other Nonfunctional Requirements
5.1Performance Requirements
<If there are performance requirements for the product under various circumstances, state them
here and e!plain their rationale, to help the developers understand the intent and ma(e suitable
design choices. Specify the timing relationships for real time systems. 'a(e such requirements as
specific as possible. 6ou may need to state performance requirements for individual functional
requirements or features.>
5.2Safety Requirements
<Specify those requirements that are concerned with possible loss, damage, or harm that could
result from the use of the product. Define any safeguards or actions that must be ta(en, as well
as actions that must be prevented. Refer to any e!ternal policies or regulations that state safety
issues that affect the product5s design or use. Define any safety certifications that must be
satisfied.>
5.3Security Requirements
<Specify any requirements regarding security or privacy issues surrounding use of the product or
protection of the data used or created by the product. Define any user identity authentication
requirements. Refer to any e!ternal policies or regulations containing security issues that affect
the product. Define any security or privacy certifications that must be satisfied.>
5.4Software Quality Attributes
<Specify any additional quality characteristics for the product that will be important to either the
customers or the developers. Some to consider are1 adaptability, availability, correctness,
fle!ibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability,
and usability. /rite these to be specific, quantitative, and verifiable when possible. -t the least,
clarify the relative preferences for various attributes, such as ease of use over ease of learning.>
Software Requirements Specification for Airline flight booking system Page 12
6.Other Requirements
<Define any other requirements not covered elsewhere in the SRS. 0his might include database
requirements, internationali+ation requirements, legal requirements, reuse ob)ectives for the
pro)ect, and so on. -dd any new sections that are pertinent to the pro)ect.>
Appendix A: Glossary
<Define all the terms necessary to properly interpret the SRS, including acronyms and
abbreviations. 6ou may wish to build a separate glossary that spans multiple pro)ects or the entire
organi+ation, and )ust include terms specific to a single pro)ect in each SRS.>
Appendix B: Analysis Models
<:ptionally, include any pertinent analysis models, such as data flow diagrams, class diagrams,
state"transition diagrams, or entity"relationship diagrams.>
Appendix C: Issues List
< 0his is a dynamic list of the open requirements issues that remain to be resolved, including
0;Ds, pending decisions, information that is needed, conflicts awaiting resolution, and the li(e.>