SE Project Report Sample

SOFTWARE ENGINEERING
LAB 9 (W10:14/Sept) and 10 (W11:21/Sept)
Cover Case Study On
“System Requirement Specification”
Automated Railway Reservation System
Page 1 till 45
Reference: [http://www.geocities.com/cs5391/]
LAB 11 (W13:5/Oct/)
Cover Case Study On
“Software Project Management Plan”
Page 59 – 87
Reference: [http://www.geocities.com/cs5391/]
1
Project Log Book
Group Members:
Entry Date Work Done

Discussed the basic plan to build the prototype for CRM in class, noting down all
September 7th, constraints to be taken care of. Furthermore, we decided our next group meeting
2000 would be on September 15th, 2000 (Friday) at 5:30, meeting place: Zaida
Morales' House.
Meeting at Zaida's Place: We discussed about the project objective. Using the
Software Management Plan template printed from the web site, we stepped
September through each section and discussed what was required and what resources were
15th, 2000 available to us. We also discussed how this prototype should be flexible for other
countries. There was constant reference to the "Chinese Railway Passenger
Reservation System" and other related articles.
September
Finished a rough draft prototype and set it up on the online account.
16th, 2000
September Zaida M. Morales checked the document of the Software Project Management
19th, 2000 Plan, and she made some correction marking the corrections in red.
September The mistakes were corrected on the web site, and email was sent to Zaida M.
20th, 2000 morales to check the document for any more mistakes
September The document was checked by Zaida M. Morales and few more mistakes were
20th, 2000 found. These mistakes were corrected and put on the web.
September Meeting at Zaida's Place: We discussed the Reservation System in more detail
22th, 2000 and added more information to the SPMP document.
September Zaida M. Morales checked the document of the Software Project Management
25th, 2000 Plan, and she made some corrections.
September The mistakes were corrected on the web site, and email was sent to Zaida M.
27th, 2000 morales to check the document for any more mistakes.
Meeting at Zaida's Place: We discussed parts 4 and 5 of the Software Project
September Management Plan in more detail and decided to update some information in the
29th, 2000 SPMP document. The different parts of the document were divided between the
team for updates.
October 3th, Finished updating the rough draft prototype and set it up on the online account.
2000 Sent all team members email with link to latest copy of the document.
Zaida M. Morales checked the document of the Software Project Management
October 4th,
Plan. The mistakes were corrected on the web site. The latest version of the
2000
document is available online.
October 20th, Meeting at Zaida's Place: We met with the two new team members and discussed
2000 how to integrate their work into our SPMP document. We started discussing our
first draft of the SRS document and decided to try to have a first pass at it within
2
a week.
Meeting at Zaida's Place, and decided that this was a point in time where all
November 3rd, changes that need to done should be done to the SPMP this week and our focus
2000 should now be more on the SRS. We completed the discussion about the situation
updates and we moved on to the SRS. We managed to complete until 2.3
Completed compiling the SPMP together, however this document will be checked
November 7th,
by another team member to varify that all changes have been addressed. The SRS
2000
was partly complete since there are problems downloading a picture.
Last Updated on Novemeber 7th, 2000
3
Software Requirements Specification
for
Huitang Li
Vahid Keshmiri
Yasin Esmail
Zaida M. Morales
Natasha Dunaeva
Rehan Khan
December 04, 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.4 CRM Review Version 12/04/2000
4
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
5
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.
6
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:
7
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:

 30 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.

This section provides a summary of the functions that the software will perform.
2.2.1 Function Relationships
Figure 2.2 to 2.6 depict the relationships among the functions to be implemented by the
system.
8
Figure 2.2 ARRS General Function Relationship Diagram
Figure 2.3 ARRS Ticket Reservation Function Relationship Diagram
9
Figure 2.4 ARRS Passenger Account Function Relationship Diagram
10
Figure 2.5 ARRS Train Information Function Relationship Diagram
11
12
Figure 2.6 ARRS Display Reports Function Relationship Diagram
2.2.2 Function Descriptions
2.2.2.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.
2.2.2 Make 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.
2.2.3 Drop a Reservation Function
13
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.
2.2.4 Display Current Reservation 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.
2.2.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.
2.2.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.
2.2.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 or CRM Credit account number.
2.2.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.
2.2.9 Drop a Train Function
14
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.
2.2.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.
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.
15
 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.
 Scalping of tickets is a popular activity in China, and CRM wants to discourage such
practices.
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.
16
 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.
17
 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
18
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:
19
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:
20
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.

Specification:
21
Description Remove a reservation from a user’s account
return date and time
travel date, return date and time
Outputs Modified reservation
Precondition Reservation must be a part of user’s current
reservations
Post Condition Reservation is removed from user’s
account
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
22
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
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
23
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
Precondition Web Access
Post Condition Reservation remains unchanged
Side Effects None
Data Flow Diagram:
24
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:
25
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
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 or CRM Credit
account number.
26
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 or CRM credit account
Inputs Type of credit card, credit card number or
CRM credit account 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 or CRM credit
account number
Post Condition Account balance updated
Side Effects None
Data Flow Diagram:
27
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.
Specification:
Description Adds a train to the train schedule

return date, time, and train number
travel date, return date, time, and train
number
Outputs Modified train schedule
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:
28
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:
29
Description Remove a train from the train schedule
return date, time, and train number
travel date, return date, time, and train
number
Outputs Modified train schedule
Precondition Train must be a part of current train
schedule
Post Condition Train is removed from train schedule
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:
30
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
Outputs Requested report
Post Condition No change to reservation information
Side Effects None
Data Flow Diagram:
31
3.2. External Interface Requirements
3.2.1 User Interfaces.
The user interfaces are divided into two major components. One part
includes the user accessing the system using a cell phone. The other portion
involves accessing the system through a remote site or at a particular location
specifically designed to access the system. For instance, the clerks and the CRM
access the reservation system from the reservation or CRM office.
The diagrams and explanations below demonstrate the major transition
from one user interface to another. This is a brief description. However, a more
detailed demonstration is done in the prototype. The purpose of this interaction is
to illustrate the overall view of the ARRS.
The diagram below illustrates the four major functionalities. These
functionalities will be displayed depending on the user. For instance, the CRM
will see all four functionalities while the normal user and the clerks will only see
the Ticket Reservation and the Passenger Account.
32
Selecting one of these functions will take the user to a different user
interface. For instance, choosing Ticket Reservation will display the following
web page. The title of this page is consistent with the function selected, and since
the Ticket Reservation was selected, the title displays Ticket Reservation. The
purpose of this is to allow the user know what part of the system they are
accessing. Furthermore, the user can select any of the four functions.
33
The user can select any of the four functionalities. For the sake of this
demonstration, if the user clicks on the Make Reservation function the diagram
below is displayed. Once again the title is the same as the main function and a
subtitle indicates the second function selected. In addition, the person can fill up
the following information and the date of travel or return if he/she wishes. The
three buttons allow the user to navigate through the interfaces. For instance, the
back button will take the user to the above page, and the clear button will clear the
form of any selection he/she made before. The Display Available displays the
available trains, seats and what city they want to travel to. However, before we get
to the next page when clicking Display Available the picture below illustrates the
Make Reservation function.
34
The Display Available function displays all the trains traveling from one
city to another and the seats available on that train. Furthermore, the last list
displays the number of tickets available for the particular train on the selected
route. The back button will take the user to the above picture, and the confirm
button takes the person to the payment page.
35
The following page allows the user to pay for the ticket as appropriate.
Now, this page is part of the Passenger Account function, and it is used here to
make payment for the ticket selected. This makes it easier for the user since they
do not have to go back to the main menu and to access their account.
Finally, the submit button displays the appreciation page as shown below
with a button to go to the main menu.
36
The above illustration has shown a brief overview of the user interfaces
involved for the normal and clerk users. However, the CRM have specifically
requested a number of reports, and they must be able to adjust their train schedule
as the trains become unavailable. Therefore, the CRM interface is able to access
all four functionalities as shown in the main menu (first diagram). Once the CRM
selects the Reports function, a list of five reports is displayed as linked list. This is
shown in the diagram below:
37
The report selected here shows the number of reservation for each
departure. This report indicates the major traffic flow, and what trains are needed
where during varying time and season. The diagram below shows the report
format to be displayed.
38
As mentioned earlier, the system can also be accessed through the wireless
phones. In that case, the overall system will be the same as the above presentation
except that the format will be simplified, since the phones do not have graphic
support. The phones will have access to the Make Reservation and Passenger
Account, however it is difficult to display the reports and trains information on a
small screen for the CRM.
The aspects of optimizing the interface with the person who must use the system
are briefly described below:
 Allow new users to become members of the system.
 Allow current users to login into the system using a unique user id and
password.
 Allow the users to build new itineraries, change and/or view existing
itineraries, and pay for planned itineraries using different methods (credit
cards, CRM credit account).
 Allow all users to access current train schedules. Allow administrative

users to change train schedules.
 Allow administrative users to announce schedule changes.
39
 Provide administrative users with access to reports including number of
reservations per train, number of passengers turned away, number of no-
shows, number and names of passengers who showed up, and list of
potential scalpers (high-volume ticket buyers).
 Provide an on-line help for all users of the system.
3.2.2 Hardware Interfaces.

The ARRS includes two major hardware components: cellular phones and
regular PC's. The cell phones require WAP (wireless application protocol)
network protocol, which is already programmed in the latest phones. This is
similar to the seven layers of network protocol, except that they are broken down
into five protocols. The WAP protocol is able to communicate with the servers
known as Gateway servers, which listen to requests made using these phone
frequencies. The request is then transmitted to the regular server. Furthermore, the
servers respond to these "air" requests and format the data to be displayed on the
mini window that is available on the phone. The cellular phone has a processor,
which is designed to process a language known as WML (wireless markup
language). Therefore, the server formats the data in WML format, and passes
these pages to the Gateway servers, which transmits the WML pages to the
cellular phones. The processor on these phones then translates the WML into a
simplified version of the actual web page.
The second component involves the regular PC’s, which communicate
with the server. The server then communicates with the database. The protocol
involved between the PC's and the server is the HTTP protocol, which allows
communication between the PC's and the Server. The remote PC's, such as
someone accessing the ARRS from home using the Internet, are able access the
information through the CGI. The requests come in through the HTTP protocol,
and using an ODBC the database results are returned and processed using Perl to
give an HTML web page. The format of the output is displayed as web pages.
3.2.3 Software Interfaces.

An Oracle DBMS will be used to manage the database and any changes made to
it. Furthermore, the DBMS will make regular backups of the database and
generate reports regularly so that they can be accessed by the CRM. The Apache
server between the client and the database will handle all communication, and the
server will run on a Linux operating system. Furthermore, the HTML pages must
be implemented such that they can be displayed on two common browsers:
Netscape and Internet Explorer.
Information about the products used for the ARRS:
(1) Name: Oracle

(2) Mnemonic: Oracle
40
(3) Version Number: 8
(4) Source: Oracle
(1) Name: Linux

(2) Mnemonic: Linux
(3) Version Number: 6.2
(4) Source: Unix
(1) Name: Internet Explorer

(2) Mnemonic: IE
(4) Source: Microsoft
(1) Name: Netscape Communicator

(2) Mnemonic: Netscape Communicator
(4) Source: America Online
(1) Name: Apache

(2) Mnemonic: Apache
(3) Version Number: 1.3.14
(4) Source: Apache Software Foundation
3.3 Performance Requirements.

The following sections list the performance requirements for the system.
3.3.1 User Requirements
User Requirements Description of Requirement

For Design Environment
Location(s) and Number(s) of Users Guangzhou, Nanjing, Shanghai
Expected Growth in Number of Users
After 1 Year 50%
After 2 Years TBD
After 3 Years TBD
User Expectation
Interactivity User expect that it provides a very
easy to use graphical user interface
Reliability For some applications, reliability
must be 100% during the application
session
Adaptability Network must adapt to user additions,
deletions and changes
Security Encryption software would be used
for Credit Card transactions
Cost / Funding Less than $250K
41
3.3.2 Application Requirements
Since no specified service is indicated, then we have listed the applications as best
– efforts. This may change as we learn more about the application.
The communication package is determined to be bursty in nature, with small data

sizes and frequent transmissions. We can consider this application to be
interactive-burst, while the database transaction-processing application is
described by the CRM as transferring large amounts of data (initial estimates are 1
MB/transaction), we have listed this application as interactive-bulk.
Categorizing Application
Applications Best- Locations
Effort
s
Communication 100 Kb/s Guangzhou and Nanjing
Database Access 400 Kb/s All Locations
Database Transaction processing 1.5 Mb/s All Locations
3.3.3 Host Requirements
Type of Numbers and

Host or Locations
Equipment
Host A PC Guangzhou (10), Nanjing(7), Shanghai(10)
Host B Database Shanghai
Server
Host C Application Nanjing
Server
3.4.1 Standards Compliance.

There are no design constraints that can be imposed by other standards
limitations.
3.4.2 Software Limitations.

 must be able to run Internet Explorer or Netscape Communicator web
browsers to access the system.
 must have cell-phone web based capability to access the system from
a mobile phone.
42
3.4.3 Hardware Limitations.
 Input/Output: One or two-button mouse, keyboard, cell-phone, or
touch screen required.
 Network card required at thin-client terminals to make communication
with server possible.
3.5 Quality Characteristics.

There are a number of quality characteristics that apply to the ARRS software system.
3.5.1 Portability
The ARRS system will be developed using HTML and Java so that it can be
accessed from any type of system using just a regular web browser. It will also be
available to users that have web access on their cellular phones. The system will
be tested on all types of hardware before being released to ensure that is it
compliant with this requirement.
3.5.2 Reliability
The system should be capable of processing a given number of reservations
within a give time frame with no errors and the system should be available and
operational all the time. During the development of the prototype for the 3 cities,
the system will be tested in its actual environment to ensure that it can handle the
load of reservations that occur during a regular workday.
3.5.3 Usability
The ARRS system will be developed so that it is an easy to use system that
requires the least amount of user input possible. Every input will be validated.
The user should only have general computer use knowledge. Error messages will
be displayed if the user enters an invalid value or tries to access a function
without the required permissions. An easy and well-structured user manual will
be provided to the CRM and the system will include descriptive help for all
operations allowed.
3.5.4 Correctness
The ARRS system will be considered correct when the CRM approves the
prototype presented and agrees that all the functions they require are implemented
as stated in the Software Requirements Specification.
3.5.5 Flexibility
43
The ARRS system should be developed in such a way that it is easily
customizable. If new functions are required by CRM, there will be little effort
required to update the system to support new cities or new transactions.
3.5.6 Security
The ARRS system should not compromise the customer information at any time.
The user information will never be sold to other parties and will be kept secure at
all times. Users will be authenticated to ensure that no unauthorized users gain
access to private information.
3.5.7 Maintainability
The ARRS source code will be kept well structure and documented so that it is
easier to maintain and extend the system. All changes to the system shall be
documented.
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.
The Automate Railway Reservation System will have two main databases.
One is the Reservation Database, and another is the Passenger Account Database.
These database will be created with Oracle8i (Client/Server) version 8.1.6.0.0
Release 2. The following are the requirements for these databases that are to be
developed as part of the product. They include:
Schedule information for the trains, including
Types of
date, time, departure city, destination city, ticket
information
cost and ticket availability for a particular train
Depends on the passenger demand, which may
Frequency of use
reach 25,000 per day during peak periods
The database should allow access to at least
1,000 people at once; the users will have a
Accessing general access to the information about the train
capabilities schedule, and a secure access to the reports
(available only to CRM officials) using a
username and a password
Data element and
To be determined
file descriptions
Relationship of To be determined
44
data elements,
records and files
Static and dynamic
To be determined
organization
Train schedule information will be available as
Retention long as the train for a particular route is in use
requirements for and at least one year after the train has been
data cancelled. The reports information will be
available at least for 5 years
Passenger Account Database

Passenger account information including their
name, address, phone numbers, last
Types of information
reservations, balance owed, credit card number
(if they paid by a credit card)
Depends on the passenger demand, which may
Frequency of use
reach 25,000 per day during peak periods
The database should allow access to at least
Accessing 500 people at once; the users will have a
capabilities secure access to the database using a username
and a password
Data element and file
To be determined
descriptions
Relationship of data
elements, records To be determined
and files
Static and dynamic
To be determined
organization
Passenger account will be available for as long
Retention as a passenger is using the account, and at least
requirements for data for 6 month since the passenger logged on last
time.
3.6.2 Operations.
The normal operations required by the user can be viewed as the following:
User-initiated Operations:
These operations include the login operation, which is initiated by the users. Also,
the process of becoming a new user is in this category. Building, changing, and
viewing itineraries, as well as paying for the itinerary are all initiated by the users.
45
The user initiates the report generation activity, as well as changing train
schedules.
Interactive Operations and Unattended Operations:
The users initiate all the operations mentioned above, and almost all of them are
somehow interactive. Displaying the train schedule is non-interactive. The report
display is a non-interactive operation, although selecting the desired reports will
require user input.
Data Processing Support Functions:
The user account data is used to create new accounts, as well as to validate user
id's during login functions. For building itineraries, user input, user account data,
and train schedule data are used, and processed. User data along with final results
of user interaction (whether the user purchased a trip, number of tickets bought,
etc.) are collected, and used for report generation purposes. Administrative users'
inputs are collected in order to modify and present schedules.
Backup and Recovery Operations:
Both databases used (passenger account database and reservations database) are
production databases. The main operation used for the backup and recovery is
Oracle's built-in cold backup, which is also known as the "archive mode".
Depending on the customer's needs and budget, additional redundancy can be
added using systems like RAID 5 and tape backup.
3.6.3 Site Adaptation Requirements.

There are no site adaptation requirements for this project.
4. Supporting Information.
There is no supporting information required for this project.
46
Software Requirements Specification
for
Huitang Li
Vahid Keshmiri
Yasin Esmail
Zaida M. Morales
Natasha Dunaeva
Rehan Khan
November 7, 2000
2.0 Second Pass for Review 11/07/2000
1. Introduction.
1.1 1.1 Purpose.
This document describes the software requirements for the Automated Railroad
Reservation System built for the Chinese Railway Ministry (CRM).
1.2 1.2 Scope.
47
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
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 1.3 Definitions, Acronyms, and Abbreviations.
APPM – AsiaPac Marketing Manager

PP - Project Plan
48
UML – Unified Modeling Language
1.4 References.
 Introduction – Chinese Railway Passenger Reservation System Prototype

  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.
49
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.
50
  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
  Server 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.
51
  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.
52
  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.
53
  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 should contain all the details the software developer needs to create a
design. This is
typically the largest and most important part of the SRS.
(1) The details within it should be defined as individual specific requirements, following the
guidelines for sound
requirements (verifiable, unambiguous, etc.)
(2) Specific requirements should be organized in a logical and readable fashion.
(3) Each requirement should be stated such that its achievement can be objectively verified by
a prescribed
method.
(4) Sources of a requirement should be identified where that is useful in understanding the
requirement.
(5) One way to classify the specific requirements is as follows:
(a) Functional Requirements
(b) Performance Requirements
(c) Design Constraints
(d) Attributes
(e) External Interface Requirements
The best organization for this section depends on the application area and the nature of the
software product being
specified. Tables 1 through 4 at the end of this template show four possible organizations.
(1) In Table 1, all the Functional Requirements are specified, then the four types of interface
requirements are
specified, and then the rest of the requirements are specified.
(2) Table 2 shows the four classes of interface requirements applied to each individual
Functional Requirement.
This is followed by the specification of the rest of the requirements.
(3) In Table 3, all of the issues addressed by the Functional Requirements are specified, then
the other
requirements that apply to them are specified. This pattern is then repeated for each of the
External Interface
Requirement Classifications.
(4) In Table 4, the interface requirements and the rest of the requirements are specified as they
pertain to each
Functional Requirement.
The organization of this section of the SRS should be chosen with the goal of properly specifying
the requirements in
the most readable manner. The template outline that follows uses an organization like Table 1.
54
3.1 Functional Requirements.
This subsection of the SRS should specify what is to be done by the product, to what
level or specific requirement,
what inputs should be transformed to what outputs (not how this is done), what specific
operations are required.
Where the rationale for a requirement is not obvious, provide an explanation. Where
issues need to be resolved, cite
those.
For each function, specify requirements on inputs, processing, and outputs. These are
usually organized with these
four subparagraphs:
(1) Purpose of the function: Provide rationale to clarify the intent of the function.
(2) Inputs: sources, valid ranges of values, any timing concerns, operator
requirements, special interfaces
(3) Operations to be performed: validity checks, responses to abnormal conditions,
types of processing required
(4) Outputs: destinations, valid ranges of values, timing concerns, handling of illegal
values, error messages,
interfaces required
For example, the following might be an example specification. Depending on the level of
tracking required by the
project, one might trace each of the components of 3.1.1 as separate requirements, or one
might trace just 3.1.1. Note
that the level of detail here tells what needs to be accomplished against what specific
goals, but it does not specify
how that is to be done.
3.1. Provider Terminal (PT) Functional Requirements
3.1.1. Signature Verification
Purpose: The PT shall have a signature recognition system that can be used to
authenticate users of the ChocAn
membership services.
Inputs: Members sign their name once when applying for membership. Each
authentication effort done when a
service is requested should take no more than one signature by the member.
Processing: Handling of the authorization should take no more than 5 seconds.
Outputs: If the match is successful, a positive acknowledgment must come to the
member at the signature capture
device as well as to the PT. If the match is unsuccessful, an appropriate message to
that effect must be
provided to both the capture device and the PT.
3.2. External Interface Requirements

3.2.1 User Interfaces.
55
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.
56
(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.
57
• 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.
58
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.
59
Software Project Management Plan
Huitang Li
Vahid Keshmiri
Yasin Esmail
Zaida M. Morales
Natasha Dunaeva
Rehan Khan
November 17, 2000

1.0 First Group Review 9/17/00
1.1 Second Group Review 9/24/2000
1.2 CRM Review Version 10/01/2000
First Pass After
2.0 10/20/2000
Review
2.1 Situation update 11/13/2000
2.2 Second Situation 11/17/2000
60
Update
Table of Contents
1. Introduction.
1.1 Project Overview.
1.2 Project Deliverables.
1.3 Evolution of the SPMP.

1.4 Reference Materials.
1.5 Definitions and Acronyms.
2. Project Organization.
2.1 Process Model.
2.2 Organizational Structure.
2.3 Organizational Interfaces.
2.4 Project Responsibilities.
3. Managerial Process.
3.1 Management Objectives and Priorities.
3.2 Assumptions, Dependencies, and Constraints.
3.3 Risk Management.
3.4 Monitoring and Controlling Mechanisms.
3.5 Staffing Approach.
4. Technical Process.
4.1 Methods, Tools, and Techniques.
4.2 Software Documentation.
4.2.1. Software Requirements Specification (SRS).
4.2.2. Software Design Description (SDD).
4.2.3. Software Test Plan.
4.2.4. User Documentation.
4.3 Project Support Functions.
5. Work Packages, Schedule, and Budget.
5.1 Work Packages and Schedule.
5.2 Dependencies.
5.3 Resource Requirements.
5.4 Budget and Resource Allocation.
6. Additional Components.
6.1 Index.
6.2 Appendices.
61
1. Introduction.
The Chinese railroad system currently consists of 65,000 km of rails and plans are being
developed to increase it to 70,000 km by the year 2002. It is estimated that
approximately 3.7 million Chinese and foreign visitors use the country’s railway system.
Furthermore, the railroad use is expected to increase as the population grows and new
railways are added. Therefore, the CRM have expressed great concern about automizing
their reservation system.
Currently, the train tickets can usually be purchased at the China International Travel
Service (CITS) desk in major tourist hotels, through advance booking offices or foreign
desks at the train stations. In order to keep up with the increasing use of the railroad
system in China, the existing reservation systems needs to be refined. Thus the Chinese
Railway Ministry (CRM) requests proposals to build a prototype of an Automated
Railroad Reservation System (ARRS) based on their current railway system.
The new ARRS needs to be scalable enough so that it can accommodate the increase in
reservations caused by new railroad building in China. The proposal must express this
ideology in the project plan (PP) and implement a prototype to illustrate this
functionality. The PP and the prototype to be presented will be evaluated on the
feasibility of the development plan and process description. However, the management
approach and appropriateness to the project at hand will play an important part in the
selection of the proposal. If the prototype proves to be a feasible alternative to the
needed ARRS, our team will be given the opportunity to manage the overall development
of the actual ARRS that will be implemented throughout reservation offices in China. In
the case that our plan is approved by the CRM, the PP will be updated as the project
progresses.
ARRS begins the new journey in the development of a scalable and

improved reservation system for Chinese Railroads. The goal of the
project is to create a working prototype of the ARRS, that will be
designed to provide an electronic version of the railway passenger
reservation system in China. The ARRS will have a user-friendly
graphical interface, and it will be cost effective compared to the current
non-electronic version of the reservation system.
62
The objectives of the development effort are as follows:
 To provide existing clerks with a new environment in which to make
reservations for railroad travel.
 To provide an avenue for customers to obtain their tickets in a more
convenient way.
 To regain control of the railway ticket sales in order 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 refine the requirements.
 To collect statistics in a more efficient manner for future railroad
development and construction.
 To increase efficiency of reservations.
Furthermore, the project is divided into major work tasks that enables to
determine the phase of the project plan. The list below indicates the work
activities:
 Problem specification
 Risk Analysis
 Design stage
 Implementation
 Testing and evaluation
 Quality Assurance
 Maintenance
Project resources fall into two categories: people and equipment. People
working for the ARRS include 26 professional software developers of
Chinese nationality, who shall be provided by the CRM, and other 6
members from our management team. Furthermore, the CRM will also
provide the necessary hardware and software for implementing the project.
The ARRS system structure to be developed will include a central
database to keep all reservation information, and several web servers to
process all reservation transactions. Travelers will be able to obtain their
tickets online through a web browser, by calling a reservation desk or a
travel agency. There are no budget constraints for the project at this time.
The major milestone involves building a prototype within one month of

getting to China, which will be a tough challenge. This prototype relates
to the attempt by CRM to develop a full-blown reservation system, which
unfortunately failed. The actual look and feel of the reservation system
prototype will be similar to the current online reservation system
implemented by AMTRAK at www.amtrak.com.
63
Table 1: Project Deliverables
Deliverable Delivery Date Delivery Location Quantity

SPMP (version 1) October 5, 2000 Austin, TX 1
SPMP (version 2) December 7, 2000 Beijing, China 1
Software Requirement December 7, 2000 Beijing, China 1
Specification
Prototype One December 7, 2000 Beijing, China 1
Software Development Plan TBD TBD TBD
High Level Design TBD TBD TBD
Specification
High Level Function TBD TBD TBD
Prototype
Detail Design Specification TBD TBD TBD
Detail Product Prototype TBD TBD TBD
System Construction Plan TBD TBD TBD
System Construction TBD TBD TBD
Prototype
Testing and Evaluation TBD TBD TBD
Specification
Final Product TBD Beijing, China TBD
The different parts of the project will be divided among the team
members, who will submit their work in a group Yahoo web account. The
individual parts of the project will be checked and put together by the
project manager. All changes will be reflected on the table at the beginning
of this document and each version and change date will be noted. A team
member will regularly review all documents. Weekly updates shall be
communicated to the project manager who will immediately address these
changes. After comments and issues are resolved, the document will be
approved and a new version will be made available.
More information about the project can be found in the following

documents:
64
 Introduction – Chinese Railway Passenger Reservation System
Prototype
 Situation Update – Chinese Railway Passenger Reservation System
http://www.cs.swt.edu/~donshafer/Marketing%20Update(1).htm
 China 2000
http://www.china2thou.com/
 Pressman, Roger S., Software Engineering: A Practitioner’s
Approach, McGraw-Hill Companies, Inc., 1997.
APMM – AsiaPac Marketing Manager

PP - Project Plan
UML – Unified Modelling Language
This section refers to the process model for the project and its organizational
structure.
2.1 Process Model.
The ARRS project requires frequent customer and user interaction. For that
reason, our first choice included the Prototype model. However, we had doubts
about the prototype model, and therefore we concluded to use the Spiral Model.
The risk-based approach of the Spiral Model is significant to the development of
this prototype, and it would also help select an established lifecycle model or
65
determine a different model constructed from various phases of other lifecycle
models. After regular reviews using the risk analysis table stated in the appendix,
we decided that the best approach was to use a hybrid model that would
implement the risk management of the spiral model along with the incremental
model, which is a mixture of the prototype model and the linear sequential model.
Currently, the project revolves around two established stages: Requirement
Analysis and Prototype Development. Figure 1 shows the life cycle for the
development process as well as entry and exit criteria for the different phases of
the project.
Figure 1: Life Cycle Model
The internal management of the project, as well as how the project relates
to the rest of the organization is included in Figure 2.
Figure 2: Organization Chart
66
The administrative and managerial interfaces between the project and

primary entities with which it interacts are presented in Table 2.
Table 2: Project Interfaces
Organization Liaison Contact Information
Customer: APMM Don Shafer 86-1-5128931
Subcontractor: None Don Shafer
Software Quality Assurance: Don Shafer 86-1-5128931

CRM
Software Configuration Don Shafer cs5391@yahoo.com

Management: Team 2
67
Change Control: Team 2 Don Shafer cs5391@yahoo.com
The project responsibilities are presented in Table 3.
Table 3: Project Responsibilities.
Role Description Person
Project Leader Leads project team; responsible for project Yasin Esmail
deliverables
Project Management Assisting in building SPMP, SRS and prototype, as Zaida M. Morales
Team/Analysts well as doing the necessary requirement and risk Vahid Keshmiri
analysis for the project
Huitang Li
Natasha Dunaeva
Rehan Khan
Project Leads Chinese software developers; responsible for TBD
Development project deliverables
Manager
Programming Responsible for the communication between the TBD

Manager Management Team and the rest of the software
development team; the Programming Manager is
also responsible for reallocating the human
resources and equipment of the project.
Software Managers Responsible for managing the team of 7 people; TBD

does the design of the software; after reviewing
reports from Test Engineer decides whether code
needs to be sent back to Development Engineer for
improvement or to be send to Quality Assurance
Manager for quality assurance phase
Development Responsible for designing of software and TBD

Engineers distributing work among Code Developers
Code Developers Responsible for writing programming code TBD
Test Engineer Responsible for testing and validation process in TBD

his/her team; leads Test Technician in the testing
68
process and reports the results of the testing process
to the software manager
Test Technician Performs the testing and validation procedure; TBD

reports found errors to Test Engineer
Quality Assurance Responsible for quality assurance; reports to TBD

Manager Software Manager and Project Development
Manager
Quality Engineer Performs quality assurance procedure; reports the TBD

results to Quality Assurance Manager
This section specifies the management process for this project.
Poor management process increases the failure rate of any project.

Therefore, it is essential to establish the management objectives and
priority for the ARRS. The goal of the project is to satisfy the
requirements with a feasible development process that will improve the
reservation process for the Chinese Railway System. The central idea of
the management of this project is the on time delivery of a reliable and
good quality product, along with an intensive and early exchange of ideas
and concepts necessary for the successful completion of the project at
reduced cost. This will be achieved by early reviews of existing or new
information and implementation on a regular basis.
In order to achieve the established management goals, management

priorities must be rrecognized and acted upon immediately. The ARRS
priorities involves delivery of the project plan and a prototype to the
CRM. Therfore, gathering and analysing information must be completed
in order to fully comprehend the ARRS problem domain. Furthermore,
this enables flexibility in finding innovative solutions for the problem,
approximate cost schedules for the ARRS and evaluate and resolve major
risks.
The flexibility matrix in Table 4 communicates the characteristics of the

different project dimensions
Table 4. Flexibility Matrix.
69
Project Dimension Fixed Constrained Flexible
Cost
X
Schedule
X
Scope (functionality)
X
The ARRS project will be tested among three major cities before being
implemented on a larger scale. Therefore, the foundation of the prototype
must be based on several assumptions and restrictions.
Assumptions on which the project management plan is based are as

follows:
 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 Guangzhou to Shanghai each day and five
other trains travel from Shanghai to Guangzhou each day. Two of
the trains traveling from Guangzhou to Shanghai stop at Nanjing
each day, and one of the trains traveling from Shanghai to
Guangzhou 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.
70
 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.
Dependencies, or external events, upon which the project is dependent on

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.
71
 Scalping of tickets is a popular activity in China, and CRM wants
to discourage such practices.
 26 developers will be provided by the CRM as follows:
 1 project manager who speaks English very well.
 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 will help to make arrangements with
government authorities, organize travel arrangements, and serve as
a host to China.
 The telecommunications channels available in China are sufficient
for the development of a feasible client server system.
 Three additional analysts are available from Banglore Software
Development in Banglore, India. Our company hired them in case
we required some form of help for the ARRS project.
 A software design company located in Australia is sponsored by
our organization to aid if neccessary.
 Two documentation specialists from our company.
 Three field applications mangers from the Taiwan office.
Constraints, under which the project is to be conducted, 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 to Shanghai stop at

Nanjing each day and one of the trains traveling from Guangzhou
to Shanghai stops at Nanjing each day. No trains originate
Nanjing.
72
 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 have limited access to the

Internet, and thus they may not be able to get to the system.
Table 5 gives a detailed description of the process used to identify,

analyze, and manage the risk factors associated with the project.
Table 5: Risk Management.
Potential Risk Risk Monitoring Risk Management
Size of the software being Reviewing constant feedbacks Being flexible in the software
very large and larger from the customers in project design to accommodate the
number of users than meetings necessary changes
planned
The software not being Response from the CRM, Early and intensive interaction
accepted by the CRM reviewed on every project with the customer for the success
meeting of project.
Cost factor involved in this Reviewing reports on Have additional funding allocated
project expenditure and other cost for it in advance and using it in
related tp the estimated cost in case of emergencies.
the SPMP
Customer requirements CRM participation in design A new prototype will replace the
amy change process and reviewing feedback previous one to accommodate the
information in group meetings change
Technology will not meet Constantly reviewing project Exploring alternatives for the
73
expectation progress reports by Project outdated technologies
Development Manager and
software managers
Lack of training on tools Reviewing progress report by Providing adequate training that is
and staff being software managers to determine necessary for the completion of the
inexperienced the status of the project project
The prototype not being Constant reviews among team Setting deadline before the actual
delivered on time members to ensure continuous time for submission of the project
progress on the prototype
Reporting
Auditing Mechanism will be as follows: The Report Formatting

procedure will be that it will discuss the progress of the project .How is
the present phase going , it will also include the errors and difficulties that
team had during that phase .In the last the future plans for the next phase
of the project
Software Quality Assurance Plan
The Software Quality Assurance Plan is a proposal for the

Software Quality Assurance System of the organization. In addition, it is
also an organizational structure and a series of activities, which help
ensure a persistent high quality by product monitoring and control during
the development of the software
Quality Assurance (QA) includes procedures, techniques and tools

used to ensure that a product meets or exceeds specified standards during
its development cycle.
The purpose of this Software Quality Assurance Plan (SQAP) is to

define the techniques, procedures, and methodologies that will be used to
assure timely delivery of the software that meets specified
requirements within project resources.
Management
Within an organization, Quality Assurance should be carried out by

an independent software quality assurance team that reports to Software
Manager and project development manager The Quality Assurance team
will be associated with a particular development group but also
responsible for Quality Assurance across the organization. Figure 3 shows
the basic management structure for software Quality Assurance.
74
Figure 3: Basic Management Structure
The Quality Assurance team must, in the first place, ensure the
quality of the software process. So, the Quality Assurance team:
 Defines process standards such as how reviews should be
conducted, and when reviews should be held;
 Monitors the development process to ensure that the standards are
being followed; and
 Reports the software process to software manager and project
development manager.
Responsibilities
The Quality Assurance team is responsible for the development

and maintenance of the product and process standards, The QA team is
responsible for proposing and establishing techniques, procedures, and
methodologies that may be effective used to assure timely delivery of the
software that meets specified requirements within project resources.
Communication and Reporting Plan
Table 6 shows the reporting and communication plan for the project. This
may change as the project progresses.
Table 6: Communication and Reporting Plan.
75
Time Period
Information From To
Communicated
Once per two

Project Review Project Management Team
weeks
Development
Manger
Every eight days
Status Report Team 1, 2, 3 Project Development
Manager
Software
Manager
Once a week
Status Report Programming Project Development
Manager Manager
Weekly
Status Report Development Team 1, 2, 3
Engineer, Test Software Manager
Engineer and
Quality
Assurance
Manager
Progress report Quality Software Manager and Project Weekly as needed

Assurance Team Development Manager
As needed
Status Report Test Technician Development Engineer and
and Code Test Engineer
Developers
We intend to use the people recommended by the CRM for various tasks.
At the moment, we don’t foresee a need for any extra staffing on the
project. The staffing approach for this project is as follows:
 Management Team – Yasin, Zaida, Natasha, Rehan.

 The Project Management Team decides who is qualified enough to be
Project Development Manager among the 26 people provided by the
CRM.
 The Software Manager for team 1, team 2, and team 3 and the
Programming Manager is interviewed by the Project Development
76
Manager and the Project Management Team. The Project
Development Manager decides who gets to be manager of which team.
 The Software Manager of team 1, team 2, and team 3 and the
Programming Manager will decide who will become Development
Engineer, Test Engineer, Code Developer, and Test Technician. In the
end, the Project Development Manager approves the decision.
 The Project Development Manager and the Project Management Team
staff the Quality Assurance Manager and the Quality Engineer
positions.
 Vahid and Huitang will receive UML and CASE training in the next
two weeks in USA and apply this new knowledge on this project to
improve work efficiency and effectiveness. They will not go to China.
However, parts of their jobs will serve as home knowledge base for
client training and project plan advising.
 The Project Manager gets to decide or redistribute the work force
among teams in the case that any member of the team gets sick.
Nevertheless, he needs to inform the Project Development Manager
about it.
This section specifies the technical methods, tools, and techniques to be used on the
project. It also includes identification of the work products and reviews to be held and
the plans for the support group activities in user documentation, training, software
quality assurance, and configuration management.
The approach used for the project development is an objected oriented

technique, and thus, the programming language will be object oriented as
well. Furthermore, Function Points will be used to track defects on the
modification and maintenance. More details will be added as the Software
Requirements Specification is further developed.
The CASE tool and its object oriented development methodology with
unified modeling language representation (UML) and instant Java code
generation is used in this software development project. The manager with
Project Management Professional (PMP) knowledge works closely with
international marketing groups to use all the varied hardware and software
capabilities within the corporation to win new international business.
77
The work falls into separate categories, where each category involves one
or more people working on it. A reference to initial computing design
structure is shown in Section 4.2.2 Software Design Description (SDD) to
illustrate the functionalities of the work products. The initial design
requires four work products. However, this is a target of constant change
after every review. The work products are divided according to their
different contributions to the whole project. For instance, data storage and
warehousing is a different module from the server, since both have
different functionalities. One holds data, while the other controls traffic
flow and access to the database.
Table 7 displays the work products and the types of reviews held for each
one.
Table 7: Work Products and Review Schedules
Work Products Review
Database Schema Design

Warehousing Review
Server
Design Review
Implementation
User Interface Functional

Design Review
Coding Code Review
4.2.1 Software Requirements Specification (SRS).
This requires separate documentation so refer to the SRS

document for more information.
4.2.2 Software Design Description (SDD).
Figure 4 is not a concrete software design description, but it

is the basis for the design structure that we will develop at a
later time. Furthermore, the diagram helped to determine
our resource requirements and it effectively focused our
thoughts and refined our ideas. Once again, this is not an
established SDD for the project but a rough implementation
78
of the project design. More information will be provided
during the High Level Design and Detailed Design phases.
Figure 4: Software Design Description
4.2.3 Software Test Plan.
90% of the gathered information relevant to the ARRS in

the SPMP must be evaluated and fully understood. The
problem domain must be explored extensively then we
proceed to the SRS. The SRS can be tested in two ways.
First, we can validate the SRS by cross checking it with the
SPMP to ensure all identified risks are resolved and the
requirements are satisfied. The second test will occur when
the CRM is fully satisfied with the SRS and agrees to
proceed to the next phase of the project.
The design must satisfy the SDD, since it is based on the

SRS. Reviews of the SDD must be based on the SRS, and
the test criterion includes strictly validating the SDD
79
against the SRS. Each risk in the SRS must be confronted
and shown to be resolved in the SDD. Redesign or
alteration of the SDD will be implemented if unsatisfied
requirements are confronted during SDD validation and
verification tests or reviews.
Each developer will be responsible for a portion of the

project. There are two things that are important in the
coding phase. First, the code functionality must strictly
meet the SDD. The second important part is the
consistency of code writing for the ease of product
maintenance.
Therefore, weekly code reviews shall track the progress
made by individuals, and furthermore, eradicate any
undetected serious errors. In addition, there shall be
consistency in the program, and the developers will become
familiar with each other’s code. This makes it easier for
them to maintain the product in the future. Finally, the code
reviews will be verified against the SDD to ensure that the
project implementation follows the process we originally
intended.
Developer’s work will be validated and verified to satisfy

the SRS and SDD by other developers before commencing
the system and functional tests. Once all modules have
been verified, only then will the modules be integrated
together. Ten Chinese testers, who will make sure that the
system meets the SRS and the SDD, will perform the
system test.
4.2.4 User Documentation.
User documents will be uploaded online and the CRM will

receive a hardcopy after the project completes. The two
document specialists from our organization will prepare
these documents.

The project manager is responsible for the project
configuration management.
Zaida is assigned the job for software quality assurance, the
testers from CRM are responsible for verification and
validation while Rehan and Natasha are the supervisors for
planning and inspecting the verification and validation.
80
In this section, the work packages, dependency relationships, resource requirements,
allocation of budget and resources to work packages, and a project schedule are
specified
5.1 Work Packages and Schedule.
Table 8 shows the work packages for the activities and tasks that must be
completed in order to satisfy the project agreement. Each work package is
uniquely identified.
Table 8: Work Packages and Schedule
Work Packages, Tasks & Week

Activities 1 2 3 4 5 6 7 8 9 10 11 12
Concept Internal Case
Exploration Study
Communicate
with CRM
Initial Project SPMP Pass #1
Plan Review by CRM
SPMP Pass #2
Travel & Meeting with
Orientation CRM
Representatives
Meeting with 26
programmers
Recruiting into
Organizational
Chart
OOP Training
Initial SRS SRS Pass #1
Prototype 1
(Screens)
SRS Review by
Team
Final SPMP Pass #3
Final SRS SRS Review as
per SPMP
SRS Submission
to CRM
Design High level
Design
High Level
Review
Prototype 2
81
Detail Level
Design
Detail Level
Review
Prototype 3
System Source Code &
Construction Executable
Program
Review by CRM
System Testing
Verification Summary Report
& Validation Review by CRM
Customer
Acceptance
Feedback
System System Delivery
Delivery & Maintenance
5.2 Dependencies.
Figure 5: Dependencies of the Main Work Packages
82
83
The resource requirements are divided into four separate categories, and
these may be needed at different times during the lifecycle of the project.
The division of resources falls into hardware and software requirements,
travel, computer time and number and types of personnel.
At the initial stages of the project, we need offices, phones, fax machines
and other editorial and visual programs on each workstation. This phase of
the project involves the six members of team 2 refining and polishing the
SRS and SDS. The time frame varies from six months to one year for a
satisfactory completion of these phases since they are a vital part of the
project implementation.
Furthermore, a large chunk of resource requirements involves hardware

and software. However, major use of these resources comes into play
after the project design is completed. Some of the resources required are
listed below:
 A network (LAN) is required to facilitate the whole operation.

This network consists of a database server, several workstations,
and a build server to host the compilers. Refer to section 4.2.2 -
Software Design Description for more information.
 Each person will have a separate workstation. Since there are 26

Chinese employees and four members of team 2, then we need 30
workstations for each employee.
 A Linux operating system for different servers and apache server

programs is also required.
These are the basic computer resources required. The coding period
involves the use of all hardware and software, as well as 30 persons
working on the project. Therefore, all resources are used at this point in
time.
Travel issues for maintenance purposes will be addressed after the

completion of the project. Therefore, such resource requirements come at
the end of the project. However, there will be traveling done to the three
different cities once the installation of the software and testing begins.
Once again, such requirements fall at the later stages of the project
lifecycle.
The other resource that is worth acknowledging since it may be used

extensively throughtout China. The wireless resource falls in both the
software and hardware categories. According to our Liason, Don Shafer,
84
the mobile phones have excellent reception in China, and several Chinese
own these mobile units. Furthermore, the technology to have access to the
internet is possible through specially designed mobile phones that support
WAP structure. Therefore, we decided to use the semi-conductor
fabrication plant in Taiwan to design the components that provide the
support for internet access. Additionally, the cellular phone assembly plant
in Guangzhou can assemble these components to be sold to the Chinese.
Finally, the application design such as WML (language interpreted by the
WAP technology) shall be implemented by us so that the Chinese have the
ability to access the ARRS using their mobile units.
Use of resources is limited to a minimum during the initial stages of the

project. However, this increases once the coding, testing and installation
processes begin. Close to the end of the project, the requirement of these
resources stabilizes since some amount of maintenance is expected.
Figure 6 displays the relation of the resource requirement as a function of

time.
Figure 6: Approximate Resources Vs Time Graph
Table 9: Resource Allocation
Project Development, Quality Development Test

Management Programming Assurance Engineer Engineer
Team and and Software Manager and Code and Test
Project Managers and Quality Developer Technician
85
Development Engineer
Manager
Personnel 1 Chinese 4 Chinese 6 Chinese 9 Chinese 6 Chinese
person (with analysts/ analysts/ analysts/ analysts/
English programmers programmers programmers programmers
skills) and 4
members of
team 2
Hardware Two 4 6 9 9
workstations, workstations, workstations, workstations, workstations,
one per one per person one per one per one per
person, and person person person
one box for
database
warehouse
Other
Required software for the project includes: Oracle DBMS, Linux Operating
System, Apache Web Server, Sun Java Virtual Machine 1.2, Sun Java
Development Kit 1.2, C/C++ Compiles, Internet Explorer or Netscape Navigator,
and some version control software, such as CVS or CMVC, wireless equipement.
Budget
Some of the basic items required for the development process, and their prices are
listed in Table 10.
Table 10: Budget Allocations
Resource Description Allocated Budget
Project Management Team Wages for 2 months $39166

Traveling Expenses (Round Trip Air-Fare for 4 $6000
people)
Traveling Expenses (Round Trip Train-Fare for $240
4 people)
Issue Work Visa to China (Visa F – Business $180
Visa)
Living Expenses (30 Days) $1800
Eating Expenses (30 Days) $6000
Software
Oracle $200
Linux $29.95
Apache Free software available on the web
Hardware Provided by CRM
86
Total $53,616
This section contains any additional components required for clarification of the
different part of the SPMP.
6.1 Index.
An index to the key terms and acronyms used throughout the SPMP will
be provided in the future.
6.2 Appendices.
A. Current Top 10 Risk Chart
Risk Items Risk Management Techniques

Staffing with top talent, job matching; team building; morale
Personnel Shortfalls
building; cross training; pre-scheduling key people
Detailed, multi source cost and schedule estimation; design to
Unrealistic schedules
cost; incremental development; software reuse; requirement
and budgets
scrubbing
Developing the wrong Organizational analysis; mission analysis; ops-concept
software functions formulation; user surveys; prototyping; early users' manuals
Developing the wrong Task analysis; prototyping; scenarios; user characterization
user interface (functionality, style, workload)
Requirement scrubbing; prototyping; cost-benefit analysis; design
Gold Plating
to cost
Continuing stream of High change threshold; information hiding; incremental
requirement changes development (defer changes to later increments)
Shortfalls in externally Benchmarking; inspections; reference checking; compatibility
furnished components analysis
Shortfalls in externally Reference checking; pre-award audits; award-fee contracts;
performed tasks competitive design or prototyping team building
Real-time performance Simulation; benchmarking; modeling; prototyping;
shortfalls instrumentation; tuning
Straining computer- Technical analysis; cost-benefit analysis; prototyping; reference
science capabilities checking
B. Current Project Work Breakdown Structure
87
C. Current Detailed Project Schedule
D. Software Risk Management Plan
1 Identify the project’s top10 risk items

2 Present a plan for resolving each risk item
3 Update list of top risk items, plan, and results monthly
4 Highlight risk-item status in monthly project reviews.

Compare with previous month’s ranking status
5 Initiate appropriate corrective actions
D. General Information
88
Software Project Management Plan
Huitang Li
Vahid Keshmiri
Yasin Esmail
Zaida M. Morales
September 17, 2000

Table of Contents
1. Introduction.
89
2.1 Process Model.
4.2.1. Software Requirements Specification (SRS).
4.2.2. Software Design Description (SDD).
4.2.3. Software Test Plan.
4.2.4. User Documentation.
5.1 Work Packages.
5.2 Dependencies.
5.5 Schedule.
6.1 Index.
6.2 Appendices.
90
1. 1. Introduction.
The Chinese Railroad Ministry (CRM) requests proposals to build a prototype of an

automated railway reservation system (ARRS) for their current railroad system and new
The project objective is to build a prototype of an automated railway reservation

system for the Chinese Railroad Ministry (CRM). Its foundation must be based
on a feasible development plan and process description. The resources include 26
professional software developers of Chinese nationality and the necessary
hardware and software for implementing the project. In addition, the major
milestone involves building the prototype in one month, which will be a tough
challenge. Finally, this prototype relates to the attempt by CRM to develop a full-
blown reservation system, which unfortunately failed. The budget for this project
is unknown at this point
The deliverables are as follows:
  Delivery date: 17th October 2000

  Location: 6 East Chang’an Street Beijing China
  Quantity: Unknown
Parts of the project will be divided among the four group members, who will
submit their work in a group Yahoo web account. The individual parts of the
project will be checked and put together by the project manager. The changes will
be reflected on the table at the beginning of this document and each version and
change date will be noted.
More information about the project can be found in the following documents:
  General People’s Railroad Information

  Railroad Building in China
  China 2000-Railroad Building
  The China Railways Home Page
  The China Railways News Page
91

PP - Project Plan
2. 2. Project Organization.
2.1 Process Model.
The ARRS requires frequent user interaction, thus it would be best to use the
Prototype model since it incorporates all or most software qualities in the final
product. Currently, the process model includes the following stages, although this
may change in the future:
  Requirement analysis
  Prototype
  Design
  Coding
  Testing
  Release
  Maintenance
92
Figure 1: Baseline Life Cycle
93
Figure 2: Organization Chart
2.3 2.3 Organizational Interfaces.
Table 1. Project Interfaces
Organization Liaison Contact Information
Customer: CRM Don Shafer 86-1-5128931
Subcontractor: None Don Shafer
Software Quality Assurance: Don Shafer 86-1-5128931

CRM
Software Configuration Don Shafer

Management: Team 2
Change Control: Team 2 Don Shafer
Table 2.4 Project Responsibilities.
Role Description Person
Project Manager leads project team; Team 2

responsible for project
deliverables
Development CRM
Analysts/Architects Team 2 and CRM
Project Leaders
Developers/ testers
3. 3. Managerial Process.
94
A flexibility matrix might be helpful in communicating what dimensions of the

project are fixed, constrained and flexible. Each degree of flexibility column can
contain only one "X".
Table 3. Flexibility Matrix.
Project Dimension Fixed Constrained Flexible
Cost X
Schedule X
Scope (functionality) X
The project objectives include building a prototype, and the priorities involves the
prototype meets the user specification and is has a feasible development plan
under fixed schedule. The assumption are the operation of ten trains travelling
between two cities. The prototype must be made around these assumptions and
constraints however, the product may accommodate on a larger scale
At the moment, the risks involved are not more than two. The first risk is of
higher priority than the latter one since it involves the completion of the prototype
on time. The other risk involves the prototyping being rejected by the CRM. This
puts a lot strain on our time and money.
Define the reporting mechanisms, report formats, review and audit mechanisms,
and other tools and techniques to be used in monitoring and controlling adherence
to the SPMP. Project monitoring should occur at the level of work packages.
Include monitoring and controlling mechanisms for the project support functions
(quality assurance, configuration management, documentation and training).
A table may be used to show the reporting and communication plan for the
project. The communication table can show the regular reports and
communication expected of the project, such as weekly status reports, regular
reviews, or as-needed communication. The exact types of communication vary
between groups, but it is useful to identify the planned means at the start of the
project.
95
Table 4. Communication and Reporting Plan.
Information From To Time Period

Communicated
Status report Project Team Project Manager Weekly
Status report Project Software Manager, Weekly
Manger Project Team
Project Review Project Team Software Manager Monthly
We intend to use the people recommended by the CRM for various tasks. At the
moment we have categorized the list of required skills as follows:
  software programming skills

  software testing skills: knowledge in use of tools and knowledge about
trains and reservations
  program use training
  design skills
  development skills
4. 4. Technical Process.
This section specifies the technical methods, tools, and techniques to be used on the project.
It also includes identification of the work products and reviews to be held and the plans for
the support group activities in user documentation, training, software quality assurance, and
configuration management.
Identify the computing system(s), development method(s), standards, policies,

procedures, team structure(s), programming language(s), and other notations,
tools, techniques, and methods to be used to specify, design, build, test, integrate,
document, deliver, modify or maintain the project deliverables.
Specify the work products to be built for this project and the types of peer reviews
to be held for those products. It may be useful to include a table that is adapted
from the organization’s standard collection of work products and reviews. Identify
any relevant style guide, naming conventions and documentation formats. In
96
either this documentation plan or the project schedule provide a summary of the
schedule and resource requirements for the documentation effort.
To ensure that the implementation of the software satisfies the requirements, the
following documentation is required as a minimum:
4.2.1 Software Requirements Specification (SRS).
The SRS clearly and precisely describes each of the essential requirements
(functions, performances, design constraints, and attributes) of the
software and the external interfaces. Each requirement is defined such that
its achievement is capable of being objectively verified and validated by a
prescribed method, for example, inspection, analysis, demonstration, or
test.
4.2.2 Software Design Description (SDD).
The SDD describes the major components of the software design

including databases and internal interfaces.
4.2.3 Software Test Plan.
The Software Test Plan describes the methods to be used for testing at all
levels of development and integration: requirements as expressed in the
SRS, designs as expressed in the SDD, code as expressed in the
implemented product. The test plan also describes the test procedures, test
cases, and test results that are created during testing activities.
4.2.4 User Documentation.
Describe how the user documentation will be planned and developed.

(This may be just a reference to a plan being built by someone else.)
Include work planned for online as well as paper documentation, online
help, network accessible files and support facilities.
Provide either directly or by reference, plans for the supporting functions for the
software project. These functions may include, but are not limited to,
configuration management, software quality assurance, and verification and
validation. Plans for project support functions are developed to a level of detail
consistent with the other sections of the SPMP. In particular, the responsibilities,
resource requirements, schedules and budgets for each supporting function must
be specified. The nature and type of support functions required will vary from
project to project, however, the absence of a software quality assurance,
97
configuration management, or, verification and validation plan must be explicitly
justified in project plans that do not include them.
5. 5. Work Packages, Schedule, and Budget.
Specify the work packages, dependency relationships, resource requirements, allocation of

budget and resources to work packages, and a project schedule. Much of the content may be
in appendices that are living documents, updated as the work proceeds.
5.1 Work Packages.
Specify the work packages for the activities and tasks that must be completed in
order to satisfy the project agreement. Each work package is uniquely identified.
A diagram depicting the breakdown of project activities and tasks (a work
breakdown structure) may be used to depict hierarchical relationships among
work packages.
5.2 Dependencies.
Specify the ordering relations among work packages to account for

interdependencies among them and dependencies on external events. Techniques
such as dependency lists, activity networks, and the critical path method may be
used to depict dependencies among work packages.
Provide, as a function of time, estimates of the total resources required to

complete the project. Numbers and types of personnel, computer time, support
software, computer hardware, office and laboratory facilities, travel, and
maintenance requirements for the project resources are typical resources that
should be specified.
Specify the allocation of budget and resources to the various project functions,
activities, and tasks.
5.5 Schedule.
Provide the schedule for the various project functions, activities, and tasks, taking
into account the precedence relations and the required milestone dates. Schedules
may be expressed in absolute calendar time or in increments relative to a key
project milestone.
98
6. 6. Additional Components.
Certain additional components may be required and may be appended as additional sections
or subsections to the SPMP. Additional items of importance on any particular project may
include subcontractor management plans, security plans, independent verification and
validation plans, training plans, hardware procurement plans, facilities plans, installation
plans, data conversion plans, system transition plans, or the product maintenance plan.
6.1 Index.
An index to the key terms and acronyms used throughout the SPMP is optional,
but recommended to improve usability of the SPMP.
6.2 Appendices.
Appendices may be included, either directly or by reference, to provide

supporting details that could detract from the SPMP if included in the body of the
SPMP. Suggested appendices include:
A. Current Top 10 Risk Chart
B. Current Project Work Breakdown Structure
C. Current Detailed Project Schedule
99
100

SE Project Report Sample

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

SE Project Report Sample

Diunggah oleh

Hak Cipta:

Format Tersedia

SOFTWARE ENGINEERING

LAB 9 (W10:14/Sept) and 10 (W11:21/Sept)

Cover Case Study On

“System Requirement Specification”

Automated Railway Reservation System

Cover Case Study On

“Software Project Management Plan”

Automated Railway Reservation System

Entry Date Work Done

Last Updated on Novemeber 7th, 2000

December 04, 2000

Version Changes Made Date

1.0 First Pass for Review 10/24/2000

The CRM is requesting proposals to build a prototype of an Automated Railroad

The objectives of this development effort are:

 To provide existing clerks with a new environment in which to make reservations

 To provide an avenue for customers to get their tickets in a more convenient

 To increase efficiency of railroads.

1.3 Definitions, Acronyms, and Abbreviations.

APPM – AsiaPac Marketing Manager

 Introduction – Chinese Railway Passenger Reservation System Prototype

Chapter 2 of the SRS is a brief description of the characteristics of the software to be

Chapter 3 is about specific requirements, such as functional requirements, external

2. The General Description.

2.1 Product Perspective.

Figure 2.1 Overview Diagram of the ARRS

Functions of System Components:

Computer Hardware and Peripheral Equipment to be used:

2.2 Product Functions.

2.2.1 Function Relationships

Figure 2.3 ARRS Ticket Reservation Function Relationship Diagram

2.2.2 Function Descriptions

2.2.2.1 Log In Function

2.2.2 Make Reservation Function

Description: This function allows the user to make a reservation for a

2.2.3 Drop a Reservation Function

2.2.4 Display Current Reservation Function

2.2.5 Display Train Schedule Information Function

2.2.6 Display Balance Function

Description: This function provides a listing of the current balance due

2.2.7 Pay Reservation Function

Description: This function allows the user to pay his/her current

2.2.8 Add a Train Function

2.2.9 Drop a Train Function

2.2.10 Display Report Function

Description: This function allows the user to display the following

2.3 User Characteristics.

2.4 General Constraints.

2.5 Assumptions and Dependencies.

 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.

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

 The trains will be assumed to be of a constant size that accommodates 1080

 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: