Software Requirements Specification

for

Automated Railway Reservation System

Huitang Li

Vahid Keshmiri

Yasin Esmail

Zaida M. Morales

Natasha Dunaeva

Rehan Khan

November 28, 2000

Version	Changes Made	Date
1.0	First Pass for Review	10/24/2000
1.2	Second Pass for Review	11/07/2000
1.3	Third Pass for Review	11/28/2000

1. Introduction.

1.1 Purpose.

This document describes the software requirements for the Automated Railroad Reservation System built for the Chinese Railway Ministry (CRM).

1.2 Scope.

The CRM is requesting proposals to build a prototype of an Automated Railroad Reservation System (ARRS) for their current system. This new ARRS needs to be scalable enough so that it can accommodate the increase in reservations caused by new railroad building in China.

The system will be designed to provide an electronic version of the railway passenger reservation system in China. The system will have a user-friendly graphical interface and will be more cost effective compared to the current non-electronic version of the reservation system.

The objectives of this development effort are:

· To provide existing clerks with a new environment in which to make reservations for railroad travel.

· To provide an avenue for customers to get their tickets in a more convenient way.   

· To regain control of the railway ticket sales to avoid scalping and overselling of tickets.

· To implement a prototype of a scaled down version of the final system to test the solution and further develop requirements.

· To collect statistics in a more efficient manner for future railroad development and construction.

· To increase efficiency of railroads.

1.3 Definitions, Acronyms, and Abbreviations.

APPM – AsiaPac Marketing Manager

ARRS – Automated Railroad Reservation System

CASE – Computer Aided Software Engineering

CITS – China International Travel Agency

CRM – Chinese Railroad Ministry

PP - Project Plan

SDD - Software Design Description

SRS - Software Requirement Specification

SDS – Software Design Specification

SPMP - Software Project Management Plan

GUI – Graphical User Interface

QAM – Quality Assurance Manager

PDM – Project Development Manager

PMP – Project Management Professional

TBD – To be determined

UML – Unified Modeling Language

1.4 References.

· Introduction – Chinese Railway Passenger Reservation System Prototype

http://www.cs.swt.edu/~donshafer/project_documents/5391_Case.html

· Situation Update – Chinese Railway Passenger Reservation System

http://www.cs.swt.edu/~donshafer/Marketing Update(1).html

· China 2000

http://www.china2thou.com

· Pressman, Roger S., Software Engineering: A Practitioner’s Approach, McGraw-Hill Companies, Inc., 1997.

1.5 Overview.

Chapter 2 of the SRS is a brief description of the characteristics of the software to be built, its functions, its users, its constraints and its dependencies.

Chapter 3 is about specific requirements, such as functional requirements, external interface requirements, performance requirements, and also design constraints and quality characteristics.

Finally, chapter 4 includes all the supporting information, such as the Table of Contents, the Appendices, and the Index.

2. The General Description.

This section describes the general factors that affect the product and its requirements. This section consists of five subsections that follow. This section does not state specific requirements. Each of the subsections makes those requirements easier to understand, it does not specify design or express specific requirements. Such detail is provided in section 3.

2.1 Product Perspective.

The Automated Railway Reservation System diagram showing the overview of the system’s modules and the relationship

of the system to external interfaces is presented in Figure 2.1.

Figure 2.1 Overview Diagram of the ARRS

Functions of System Components:

Database:

· Stores data

· Creates reports

· Provides access to data

· Updates information

Server:

· Provides access to the database

· Authenticates users

· Processes reservations

· Performs backups

· Produces reports

External Interfaces:

Terminal

· Users use terminals to access the server

· Passengers and travel agents use terminals to reserve the tickets and to get information about the available seats on particular trains.

· Railroad administration may use terminals to see the reports generated by the database software.

Personal Computers

· Users (passengers, travel agents, and railroad administration) may use personal computers to obtain a remote access to the server and the reservation database via the Internet.

Cell Phones

· Serve as a medium of accessing the server and the reservation database.

· Passengers may use cell phones and the latest telecommunication technologies to access the server and the reservation database via Internet, or they may use cell phones to call travel agents to inquire about railroad and ticket information.

Computer Hardware and Peripheral Equipment to be used:

· 32 workstations, which include CPUs, monitors, keyboards, and mice

· Printers

· Network

· Terminals

· Cell phones to test connection to the server via remote access

2.2 Product Functions.

Provide a summary of the functions that the software will perform. Sometimes the function summary that is necessary

for this part can be taken directly from the section of the higher-level specification (if one exists) that allocates

particular functions to the software product. The functions should be organized in a way that makes the list of

functions understandable to the customer or to anyone else reading the document for the first time. Block diagrams

showing the different functions and their relationships can be helpful. Such a diagram is not a requirement on the

design of a product itself; it is simply an effective explanatory tool.

2.3 User Characteristics.

The main users of the system will be the passengers buying train tickets, the travel agents that process reservations for passengers, and the CRM administration that access the reports generated by the system. The users are not required to have knowledge in the computer field. The graphical interface provides an easy way of using the ARRS system with minimum of training.

2.4 General Constraints.

The constraints for the project are:

· The number of trains from city Guangzhou to Shanghai and from Shanghai to Guangzhou is limited to 5 trains.

· The number of passengers that can be taking a train at once is limited to 1080 passengers.

· Two of the trains traveling from Guangzhou or Shanghai stop at Nanjing each day and one of the trains traveling from Guangzhou or Shanghai stops at Nanjing each day. No trains originate Nanjing.

· The functional prototype should be available after 30 days upon the arrival of the management team to China. This may prove to be a serious time constraint on the development of a successful prototype.

· Communication with the Chinese team members may prove to be difficult since some Chinese developers do not speak English and the management team does not speak Chinese. Even with the presence of a translator, communication may be difficult. Absence of the translator may severely affect project development.

· Team members are restricted from bringing their own equipment, and insufficient equipment supply may hinder project development.

· Team members are restricted to bringing only the analysts of the team to China. This might affect the project development if more people are needed or the required skills are not available.

· The majority of the Chinese population does not have or have a limited access to the Internet.

2.5 Assumptions and Dependencies.

The assumptions for the project are:

· Ten trains transport the passengers between three cities known as Guangzhou, Shanghai and Nanjing. These trains originate only in cities Guangzhou and Shanghai, and they make a stop at Nanjing before arriving to their destination.

· Five trains travel from city Guangzhou or Shanghai each day and five travel from city Guangzhou or Shanghai each day. Two of the trains traveling from Guangzhou or Shanghai stop at Nanjing each day and one of the trains traveling from Guangzhou or Shanghai stops at Nanjing each day. No trains originate Nanjing.

· There are five classes of tickets as listed below

§ Sleeping (soft) - compartment style coaches - 4 passenger per compartment

§ Sleeping (hard) - compartment style coaches - 6 passenger per compartment

§ Sitting (soft) - typical first class coach

§ Sitting (hard) - tourist class couch

§ Standing (hard and soft sitting coaches only)

· Reservation can be made up to one month before a particular trip.

· Seats are assigned during reservation.

· Phone reservation involves tickets being purchased within 24 hours after making the reservation. Otherwise, the reservation will be cancelled.

· No reservations can be made 48 hours prior to the trip. Rather, it will be done on a first come first serve basis from that point on.

· Passenger lists will be provided for conductors at each stop.

· The trains will be assumed to be of a constant size that accommodates 1080 passengers at a time. They will consist of:

§ 2 soft-sleeping coaches (12 compartments each)

§ 2 hard-sleeping coaches (12 compartments)

§ 2 soft-seating coaches (60 seats)

§ 9 hard-sitting coaches (80 seats each)

· The following management reports will be available:

§ Number of reservations made for each departure date/train

§ Number of customers turned away because of full trains for each departure/train

§ Number of no-shows for each departure

§ Number and names of people who show up without reservation for each departure

§ List of high buyers of train tickets.

· The expected reservations during test period may amount to approximately 25,000 per day. This volume varies by hour, day, and season.

· Chinese Ministry will provide us with information about identification process used in China, so that it can be applied to the reservation system and scalping of tickets is avoided.

· Network connection will always remain established.

The dependencies, or external events, for the project are:

· CRM trains occasionally may become non-operational. In that case, a new train will be dispatched, but a delay of up to a few days could occur.

· Scalping of tickets is a popular activity in China, and CRM wants to discourage such practices.

· 26 developers will be provided by the CRM.

§ 1 development manager who speaks and writes good English.

§ 3 analysts, who have had extensive experience in developing applications, none speak English, all read English, and all have a fair ability to write in English.

§ 1 Programmer/Analyst who has extensive telecommunications skills and communicates fairly well in English.

§ 11 Programmers with 5 or more years experience in developing extensive applications. 3 of this group have excellent English communication skills.

§ 10 Programmers with less than 5 years experience. The Ministry is extremely interested in these people receiving on-the-job training so they must be used. Only 2 of this group can communicate in English.

· The CRM will provide all the required hardware and software resources for the development of the project.

· A facilitator from CRM to help make arrangements with government authorities, make travel arrangements, and serve as a host to our country.

· The telecommunications channels available in China are sufficient for the development of a feasible client server system.

· Three analysts in the Bangalore software development center.

· Australian design center manager

· Two documentation specialists from company.

· Three field applications mangers from the Taiwan office.

3. Specific Requirements.

This section of the SRS contains design requirements for the Automated Railway Reservation System.

3.1 Automated Railway Reservation System Functional Requirements.

3.1.1 Log In Function

Description: This function ensures that only authorized users gain access to the Reservation databases. An authorized user is a

user who has an account on the system. Users include passengers, train officials, and CRM ministry officials. The user must

type a valid username and password to gain access.

Rationale: Logging into the system provides security and confidentiality to the system. It reduces the chance that someone can

Taper any individual’s personal information and prevents unauthorized users from modifying the confidential information such as

Reports for CRM or train schedule information.

Specification:

Description	Allows access to online ARRS
Inputs	Username, password
Source	User inputs username and password
Outputs	Successful login; unsuccessful login
Destination	None
Precondition	Authorized User
Post Condition	No change to Passenger Accounts Database
Side Effects	Failures and successful logins are sent to Reservation Database

Data Flow Diagram:

3.1.2 Make a Reservation Function

Description: This function allows the user to make a reservation for a particular train on a particular date for a certain number of

tickets. If the user does not already have a reservation, then a new reservation is created. If the user already has a previous reservation,

a new reservation is added to the list of current reservations, and the passenger account balance gets updated.

Rationale: A user must have the ability to add a reservation to his/her account. This function makes this process simple and easy.

Specification:

Description	Adds a reservation to the user’s account
Inputs	From city, to city, seat type, travel date, return date and time
Source	User inputs from city, to city, seat type, travel date, return date and time
Outputs	Modified reservation
Destination	Computer screen Reservation database Passenger Account database
Precondition	Valid information; train route and tickets available; user does not have another reservation at the same time
Post Condition	Reservation added to passenger account
Side Effects	User’s current reservations adjusted Balance due adjusted

Data Flow Diagram:

3.1.3 Drop Reservation Function

Description: This function allows the user to drop a reservation for a particular train on a particular date for a certain number of

tickets. If the user does not already have a reservation, then all reservations are dropped. If the user already has a previous reservation,

a chosen reservation is dropped from the list of current reservations, and the passenger account balance gets updated.

Rationale: A user must be able to remove a reservation from his/her account. This function makes this process simple and easy.

Specification:

Description	Remove a reservation from a user’s account
Inputs	From city, to city, seat type, travel date, return date and time
Source	User inputs from city, to city, seat type, travel date, return date and time
Outputs	Modified reservation
Destination	Computer screen Reservation database Passenger Account database
Precondition	Reservation must be a part of user’s current reservations
Post Condition	Reservation is removed from user’s account
Side Effects	User’s current reservations adjusted Balance due adjusted Ticket availability updated

Data Flow Diagram:

3.1.4 Display Current Reservations Function

Description: This function allows the user to see a list of all his/her current reservations. If the user does not have any reservations at

the time (assuming that the user has a valid account on the Reservation system), and empty list with a message “No Reservations Have

Been Made” is displayed.

Rationale: This function will be used primarily as a device to verify reservations during and after the reservation process.

Specification:

Description	Allow user to check reservations
Inputs	Name, address, phone number
Source	Log In function
Outputs	Date, train #, from city, to city, seat type, # of tickets, total
Destination	Computer screen
Precondition	Successful login to secure network
Post Condition	Reservation balance is displayed on computer screen
Side Effects	None

Data Flow Diagram:

3.1.5 Display Train Schedule Information Function

Description: This function allows the user to see a list of all scheduled train departures including train name, city from and to which

the train is going, the number of seats available, and the prices for different ticket types.

Rationale: A list of train departures helps the user to decide what information to enter to the Make a Reservation and Drop a

Reservation functions.

Specification:

Description	Allow user to check train availability by city from and to which the train is going, number of seats available, and ticket price
Inputs	None
Source	Log In Function
Outputs	Train schedule and availability status
Destination	Computer screen
Precondition	Web Access
Post Condition	Reservation remains unchanged
Side Effects	None

Data Flow Diagram:

3.1.6 Display Balance Function

Description: This function provides a listing of the current balance due and payments received in the past. This information is

Presented in an easy to follow format and separately displays each reservation.

Rationale: This function allows the user to keep accurate financial records on his/her total reservations payed. This information

is also useful in figuring out how much the user has spent in train travel.

Specification:

Description	Provides a listing of current balance due and past payments received
Inputs	Log In Function
Source	Passenger Reservation Database
Outputs	Name, address, phone number, date, train #, City from, city to, seat type, # of tickets, subtotal, total
Destination	Computer screen
Precondition	Successful login to secure network
Post Condition	No change to payment information
Side Effects	None

Data Flow Diagram:

3.1.7 Pay Reservation Function

Description: This function allows the user to pay his/her current reservation cost. The user may either pay entire balance due or

select to pay in person within 48 hours. The user must also input a valid credit card number.

Rationale: This function allows the user to pay online rather than to pay in person. To pay online is both more convenient and

less time consuming, because the user is not subject to the hours of operation of the Travel Agent Office.

Specification:

Description	Allow user to pay reservation via a credit card
Inputs	Type of credit card, credit card number, expiration date, cardholder name, cardholder phone number
Source	User provides all the necessary inputs
Outputs	Passenger balance
Destination	Computer screen and Passenger Account Database
Precondition	Valid credit card number
Post Condition	Account balance updated
Side Effects	None

Data Flow Diagram:

3.1.8 Add a Train Function

Description: This function allows the user to add a train with a particular seat type on a particular date and time to travel between the

cities specified. If the train does not already exist in the train schedule, then a new train route is created and the ticket availability for

that route is updated. If the train already exists in the train schedule, the train schedule information is updated.

Rationale: A user must have the ability to add a train to the available train schedule if new trains become available or existing trains

are not operational. This function makes this process simple and easy.

Specification:

Description	Adds a train to the train schedule
Inputs	From city, to city, seat type, travel date, return date, time, and train number
Source	User inputs from city, to city, seat type, travel date, return date, time, and train number
Outputs	Modified train schedule
Destination	Computer screen Reservation database Passenger Account database
Precondition	Valid information; train route is valid; train is not scheduled for another trip at the same time
Post Condition	Train added to train schedule
Side Effects	Current reservations adjusted Current train schedule adjusted Ticket availability adjusted

Data Flow Diagram:

3.1.9 Drop a Train

Description: This function allows the user to drop a train of a particular seat type on a particular date and time that was traveling

between the cities specified. If the train does not exist in the current train schedule, the request is ignored. If the train exists in the

reservation database, the chosen train is dropped from the list of current train schedules, and the train schedule gets updated.

Rationale: A user must be able to remove a train from the train schedule if it is no longer operational. This function makes this process

simple and easy.

Specification:

Description	Remove a train from the train schedule
Inputs	From city, to city, seat type, travel date, return date, time, and train number
Source	User inputs from city, to city, seat type, travel date, return date, time, and train number
Outputs	Modified train schedule
Destination	Computer screen Reservation database Passenger Account database
Precondition	Train must be a part of current train schedule
Post Condition	Train is removed from train schedule
Side Effects	User’s current reservations adjusted Current train schedule updated Ticket availability updated

Data Flow Diagram:

3.1.10 Display Report Function

Description: This function allows the user to display the following reports:

Number of Reservations for Each Departure Date/Train

Number of Customers Turned Away

Number of No-Shows

Number and Names of People who Showed Up

List of High Buyers

These reports are only available to Chinese Railway Ministry Employees.

Rationale: The Chinese Railway Ministry must be able to generate reports to keep track of ticket sales and reservations. This function makes this process simple and easy.

Specification:

Description	Display a system report
Inputs	Log In Function
Source	Passenger Account Database and Reservation Database
Outputs	Requested report
Destination	Computer screen
Precondition	Successful login to secure network
Post Condition	No change to reservation information
Side Effects	None

Data Flow Diagram:

3.2. External Interface Requirements

3.2.1 User Interfaces.

This should specify:

(1) The characteristics that the software must support for each human interface to the software product. For

example, if the user of the system operates through a display terminal, the following should be specified:

(a) Required screen formats

(b) Page layout and content of any reports or menus

(c) Relative timing of inputs and outputs

(d) Availability of some form of programmable function keys.

(2) All the aspects of optimizing the interface with the person who must use the system. This may simply

comprise a list of do's and don'ts on how the system will appear to the user.

3.2.2 Hardware Interfaces.

Specify the logical characteristics of each interface between the software product and the hardware components of

the system. Include such matters as what devices are to be supported, how they are to be supported, and protocols.

3.2.3 Software Interfaces.

Specify the use of other required software products (for example, a data management system, an operating system, or a mathematical package), and interfaces with other application systems .

For each required software product, the following should be provided:

(1) Name

(2) Mnemonic

(3) Specification Number

(4) Version number

(5) Source

For each interface:

(1) Discuss the purpose of the interfacing software as related to this software product.

(2) Define the interface in terms of message content and format. It is not necessary to detail any well-documented

interface, but a reference to the document defining the interface is required.

3.2.4 Communications Interfaces.

Specify the various interfaces to communications such as local network protocols, etc.

3.3 Performance Requirements.

This subsection should specify both the static and the dynamic numerical requirements placed on the software or on

human interaction with the software, as a whole.

(1) Static numerical requirements may include:

(a) The number of terminals to be supported

(b) The number of simultaneous users to be supported

(c) Number of files and records to be handled

(d) Sizes of tables and files

Static numerical requirements are sometimes identified under a separate section entitled capacity.

(2) Dynamic numerical requirements may include, for example, the numbers of transactions and tasks and the

amount of data to be processed within certain time periods for both normal and peak workload conditions.

All of these requirements should be stated in measurable terms, for example, 95% of the transactions shall be

processed in less than 1 s, rather than, operator shall not have to wait for the transaction to complete.

Note: Numerical limits applied to one specific function are normally specified as part of the processing

subparagraph description of that function.

3.4 Design Constraints.

Design constraints can be imposed by other standards, hardware limitations, etc.

3.4.1 Standards Compliance.

Specify the requirements derived from existing standards or regulations. They might include:

(1) Report format

(2) Data naming

(3) Accounting procedures

(4) Audit Tracing. For example, this could specify the requirement for software to trace processing activity.

Such traces are needed for some applications to meet minimum government or financial standards. An audit

trace requirement might, for example, state that all changes to a payroll data base must be recorded in a trace

file with before and after values.

3.4.2 Hardware Limitations.

Identify the requirements for the software to operate inside various hardware constraints.

3.5 Quality Characteristics.

There are a number of quality characteristics that can apply to software. Pick the ones most important to this product

and develop a section for each one. Definitions of the quality characteristics follow.

• Correctness - extent to which program satisfies specifications, fulfills user’s mission objectives

• Efficiency - amount of computing resources and code required to perform function

• Flexibility - effort needed to modify operational program

• Integrity/security - extent to which access to software or data by unauthorized people can be controlled

• Interoperability - effort needed to couple one system with another

• Maintainability - effort required to locate and fix an error during operation

• Portability - effort needed to transfer from one h/w or s/w environment to another

• Reliability - extent to which program performs with required precision

• Reusability - extent to which it can be reused in another application

• Testability - effort needed to test to ensure performs as intended

• Usability - effort required to learn, operate, prepare input, interpret output

3.5.1 xxx

Describe the rationale for including this characteristic for this product.

Describe how the presence, absence, or level of this characteristic will be measured; identify ways to test the

characteristic once the product is complete.

3.5.2 yyy.

etc.

3.6 Other Requirements.

Certain requirements may, due to the nature of the software, the user organization, etc., be placed in separate

categories such as those below.

3.6.1 Data Base.

This could specify the requirements for any data base that is to be developed as part of the product. This might

include:

(1) Types of information

(2) Frequency of use

(3) Accessing capabilities

(4) Data element and file descriptions

(5) Relationship of data elements, records and files

(6) Static and dynamic organization

(7) Retention requirements for data

Note: If an existing data base package is to be used, this package should be named under Interfaces to Software and details of using it specified there.

3.6.2 Operations.

This could specify the normal and special operations required by the user such as:

(1) The various modes of operations in the user organization; for example, user-initiated operations

(2) Periods of interactive operations and periods of unattended operations

(3) Data processing support functions

(4) Backup and recovery operations

Note: This is sometimes specified as part of the User Interfaces section.

3.6.3 Site Adaptation Requirements.

This could:

(1) Define the requirements for any data or initialization sequences that are specific to a given site, mission, or

operational mode, for example, safety limits.

(2) Specify features that should be modified to adapt the software to an installation.

4. Supporting Information.

The supporting information; that is, the Table of Contents, the Appendices, and the Index, make the SRS easier to use.

The Appendices are not always considered part of the actual requirements specification and are not always

necessary. They might include:

(a) Sample I/O formats, descriptions of cost analysis studies, results of user surveys.

(b) Supporting or background information that can help the readers of the SRS.

(c) A description of the problems to be solved by the software.

(d) The history, background, experience and operational characteristics of the organization to be supported.

(e) A cross-reference list, arranged by milestone, of those incomplete software requirements that are to be

completed by specified milestones.

(f) Special packaging instructions for the code and the media to meet security, export, initial loading, or other

requirements.

(3) When Appendices are included, the SRS should explicitly state whether or not the Appendices are to be

considered part of the requirements.