3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

PRACTICAL 1
Aim: Discussion and selection of project based on interest.
Forming group of students and distribute work.

Forming group of students and distribute work:

1) Selection of domain of project (Financial, multimedia, entertainment,

research, Linux based, management system, e commerce application,
interactive application etc...).

We have selected the domain of Railways Reservation services. Precisely Railways

Reservation System. A Software has to be developed for automating the manual
Railway Reservation System.

Our Group along with task allocation consist of:

Purva Darji (180110116007)

 Hardware/Software Requirements, Dataflow Diagram, Data Dictionary, SRS

Document, Sprint Chart.

Dhvani Patel (180110116016)

 Non-Functional Requirements, State Diagram, Sequence Diagram, ER-

Diagram, SRS Document.

Chandni Patel (180110116032)

 Functional Requirements, Use Case, Class Diagram, ER-Diagram, SRS

Document.

All Contributed in Requirement Analysis.

1
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

PRACTICAL 2
Aim: Analysis of Project domain and final definition of project with
scope analysis and hardware and software requirement.
Introduction:
The project Railways Reservation System done sincerely and satisfactorily by my group
members. A Software has to be developed for automating the manual Railway Reservation
System.
 RESERVE SEATS – Reservation form has to be filled by passenger. If seats are
available entries like train name, number, destination are made.
 CANCEL RESERVATION- The clerk deletes the entry in the System and changes
in the Reservation Status.
 VIEW RESERVATION STATUS-The user needs to enter the PIN number printed
on ticket.
Purpose, Scope & Objective
Purpose:
The purpose of this source is to describe the railway reservation system which provides
the train timing details, reservation, billing and cancellation on various types of
reservation namely,
• Confirm Reservation for confirm Seat.

• Reservation against Cancellation.

• Waiting list Reservation.

• Online Reservation.

Scope:
“Railways Reservation System” is an attempt to simulate the basic concepts of an online
Reservation system. The system enables to perform the following functions:
 Search For Train
 Booking of a Selected Flight
 Payment
 Cancellation

2
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

 Freight Revenue enhancement

 Passenger Revenue enhancement
 Improved & optimized service

Objective:
The purpose of this source is to describe the railway reservation system which provides the
train timing details, reservation, billing and cancellation on various types of reservation.

Hardware & Software Configuration:

For web application the user requires a suitable

browser. Thus, it can be used irrespective of any
appliance i.e.
 Mobile phone
 PC
 Laptops
 Tablets etc.

3
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

PRACTICAL 3
Aim: Requirement Analysis based on module assigned to project based on
given template/SRS.
User Interfaces:
Booking agents with varying levels of familiarity with computers will mostly use this system.
With this in mind, an important feature of this software is that it be relatively simple to use.
The scope of this project encompasses: -

Search: This function allows the booking agent to search for train that are available between
the two travel cities, namely the "Departure city" and "Arrival city" as desired by the traveller.
The system initially prompts the agent for the departure and arrival city, the date of departure,
preferred time slot and the number of passengers. It then displays a list of train available with
different airlines between the designated cities on the specified date and time.

Selection: This function allows a particular train to be selected from the displayed list. All
the details of the train are shown: -

1. train Number
2. Date, time and place of departure
3. Date, time and place of arrival
4. TRAIN Duration
5. Fare per head
6. Number of stoppages – 0, 1, 2…

Review: If the seats are available, then the software prompts for the booking of train. The
train information is shown. The total fare including taxes is shown and flight details are
reviewed.

Traveler Information: It asks for the details of all the passengers supposed to travel
including name, address, telephone number and e-mail id.

4
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Payment: It asks the agent to enter the various credit card details of the person making the
reservation.

1. Credit card type

2. Credit card number
3. CVC number of the card
4. Expiration date of the card
5. The name on the card

Cancellation: The system also allows the passenger to cancel an existing reservation.
This function registers the information regarding a passenger who has requested for a
cancellation of his/her ticket. It includes entries pertaining to the train No., Confirmation No.,
Name, Date of Journey, Fare deducted.

Need for the Website:

 Railways carry people and goods over long distances quickly and cheaply. It has an
efficient system of rail traffic, signaling and communication system. It is also an
economic lifeline of India since many passengers use it every single day and the Indian
Government gets a lot of money from railways.

 Railways stretches its hands in conducting activities like business, sightseeing,

pilgrimage along with transportation of goods. It is easier for long-distance travel. Plays
a vital role in national integration. It strengthens the development of the industry and
agriculture.

5
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

PRACTICAL 4
Aim: Project requirement gathering based on project modules.
Functional Requirements:
Performance requirements:

 User Satisfaction: - The system is such that it stands up to the user expectations. 

 Response Time: -The response of all the operation is good. This has been made
possible by careful programming.

 Error Handling: - Response to user errors and undesired situations has been taken
care of to ensure that the system operates without halting.

 Safety and Robustness: - The system is able to avoid or tackle disastrous action. In
other words, it should be foul proof. The system safeguards against undesired events,
without human intervention. 

 Portable: - The software should not be architecture specific. It should be easily

transferable to other platforms if needed.
 User friendliness: - The system is easy to learn and understand. A native user can
also use the system effectively, without any difficulties. 

Design constrain:

There are a number of factors in the client’s environment that may restrict the choices of a designer.
Such factors include standards that must be followed, resource limits, operating environment,
reliability and security requirements and policies that may have an impact on the design of the system.
An SRS (Software Requirements Analysis and Specification) should identify and specify all such
constraints.

Ø Standard Compliance: - This specifies the requirements for the standards the system must follow.
The standards may include the report format and accounting properties.

Ø Hardware Limitations: - The software may have to operate on some existing or predetermined
hardware, thus imposing restrictions on the design. Hardware limitations can include the types of
machines to be used, operating system available on the system, languages supported and limits on
6
primary and secondary storage.
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Ø Reliability and Fault Tolerance: - Fault tolerance requirements can place a major constraint on
how the system is to be designed. Fault tolerance requirements often make the system more complex
and expensive. Requirements about system behaviour in the face of certain kinds of faults are
specified. Recovery requirements are often an integral part here, detailing what the system should do I
some failure occurs to ensure certain properties. Reliability requirements are very important for
critical applications.

Ø Security: - Security requirements are particularly significant in defence systems and database
systems. They place restrictions on the use of certain commands, control access to data, provide
different kinds of access requirements for different people, require the use of passwords and
cryptography techniques and maintain a log of activities in the system.

Hardware requirements:

For the hardware requirements the SRS specifies the logical characteristics of each interface b/w the
software product and the hardware components. It specifies the hardware requirements like memory
restrictions, cache size, the processor, RAM size etc... those are required for the software to run.

Minimum Hardware Requirements

Processor Pentium III

Hard disk drive 40 GB

RAM 128 MB

Cache 512 kb

Preferred Hardware Requirements

Processor Pentium IV

Hard disk drive 80 GB

RAM 256 MB

Cache 512 kb

7
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Software requirements:

 Any window-based operating system with DOS support are primary requirements for
software development. Windows XP, FrontPage and dumps are required. The systems
must be connected via LAN and connection to internet is mandatory. 

Other requirements:

Software should satisfy following requirements as well:-

 SECURITY
 PORTABILITY
 CORRECTNESS
 EFFICIENCY
 FLEXIBILTY
 TESTABILTY
 REUSABILTY

Non-Function Requirements

Security:

The system use SSL (secured socket layer) in all transactions that include any confidential customer
information. The system must automatically log out all customers after a period of inactivity. The
system should not leave any cookies on the customer’s computer containing the user’s password. The
system’s back-end servers shall only be accessible to authenticated management.

Reliability:

The reliability of the overall project depends on the reliability of the separate components. The main
pillar of reliability of the system is the backup of the database which is continuously maintained and
updated to reflect the most recent changes. Also the system will be functioning inside a container.
Thus the overall stability of the system depends on the stability of container and its underlying
operating system.

8
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Availability:

The system should be available at all times, meaning the user can access it using a web browser,
only restricted by the down time of the server on which the system runs. A customer friendly
system which is in access of people around the world should work 24 hours. In case of a of a
hardware failure or database corruption, a replacement page will be shown. Also in case of a
hardware failure or database corruption, backups of the database should be retrieved from the
server and saved by the Organizer. Then the service will be restarted. It means 24 x 7
availability.

Maintainability:

A commercial database is used for maintaining the database and the application server takes
care of the site. In case of a failure, a re-initialization of the project will be done. Also the
software design is being done with modularity in mind so that maintainability can be done
efficiently.

Supportability:

The code and supporting modules of the system will be well documented and easy to
understand. Online User Documentation and Help System Requirements.

9
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

PRACTICAL 5
Aim: Design analysis and UML diagram design (Use case, class diagram,
sequence, state activity etc).

Fig5.1 Use Case Diagram

10
3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Fig5.2 Class Diagram

11
3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Fig5.3 Sequence Diagram

12
3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Fig5.4 Activity Diagram

13
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Fig5.5StateDiagram

Level 0:

Enter
Railway
User Admin
Reservatio
Get

Level 1:

14
3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

15
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Level 2:

Reservation Check availability

Apply for ticket

Give
availabili Admin
ty

Conform ticket
Cancellatio
n process
Apply for
cancelatio
User n Conform
Cancelation
cancellation Railway
cancelation database
View
detail details

Enter
Check
paymen status Payment
t detail process

Payment
done

Payment

Fig5.6 Data flow diagram

16
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

PRACTICAL 6

Aim: Data base design, Table formation and Normalization with Connectivity.
Data Dictionary

Admin_details: This table contains details of the administrator

Sr. No Name DataType Size Constraint Description

1. ID Int Primary Key Id of admin

2. Email String 20 Not Null Email for

, Unique logging
in
3. Password String 255 Not Null Password for
admin

4. Contact BigInt 10 Not Null Unique Admin

contact
number
5. Role String 10 Not Null Super Admin /
Admin

User_details: This table contains details of the User

Sr. No Name DataType Size Constraint Description
1. ID Int Primary Key Id of user

2. Email String 20 Not Null Email for

, Unique logging
in
3. Password String 255 Not Null Password for
User

4. Name String 20 Not Null User First name

5. Contact BigInt 10 Unique, Not Null User’s contact

number

Train details: This table contains details of the Train

Sr. No Name DataType Size Constraint Description
17
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

1. Train ID Int Primary Key ID for Train

2. Name String 30 Not Null Name of Train

3. Arrival Time Date Time 10 Not Null, Unique Arrival time

4. Departure Time Date Time 10 Not Null, Unique Departure

time

18
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

5. Platform name String 20 Not Null Name of platform

6. City String 20 Not Null Train’s city

7. State String 15 Not Null State name

8. Pictures String 20 Not Null Train Pictures

Facilities details: This table contains details of the Facilities

Sr. No Name Data Type Size Constraint Description

1. ID Int Primary Key Id of afacilities

2. Name String 15 Not Null facilities Name

3. Description String 30 Description

of facilities

Services_details: This table contains details of the Services

Sr. No Name Data Type Size Constraint Description

4. ID Int Primary Key Id of services

5. Name String 15 Not Null Services Name

6. Description String 30 Description

of Services

Comission_details: This table contains details of the Commission

Sr. No Name Data Type Size Constraint Description

1. ID Int Primary Key Id of

Commission
2. Train ID String Foreign Key Train’s Id

19
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

3. Booking Id String Foreign Key Booking Id

4. Commission Int 6 Not Null Amount of

Amount Commission

Train compartment_details: This table contains details of the train compartment

Sr. No Name Data Type Size Constraint Description

1. compartment ID Int Primary Key compartment

record ID
2. train ID Int Foreign Key train ID

3. Type String 20 Not Null Type of

compartment
4. Services Int 30 Foreign Key Services
Available

5. Photos String Not Null Photos of

compartment

Booking_details: This table contains details of the Bookings

Sr. No Name Data Type Size Constraint Description

1. Booking ID Int Primary Key Booking

record Id
2. Train ID Int Foreign Key Train ID
from train

3. User ID Int Foreign Key User’s ID

4. Payment ID Int Foreign Key Payment ID

5. compartment ID Int Foreign Key compartment’s

ID
6. Check-in Date Not Null Date of
checking
IN
7. Check-out Date Not Null Date of Check
Out
20
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Payment_details: This table contains details of the Payment

Sr. No Name Data Type Size Constraint Description

1. Transaction ID Int Primary Key Transaction

Record Id
2. timestamp Date Time Not Null Time and date
of transaction
3. payable Amount Int 10 Not Null Amount of
transaction
4. Payment String 15 Not Null Method
method of
payment
5. Transaction ID String 50 Not Null Transaction ID
by gateway

21
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

PRACTICAL 7
Aim: Interactive GUI design with paper prototype.
The system shall provide a uniform look and feel between all the web pages.
Home Page:

Login:

Registration:
22
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Search Train:

Other Screen:

23
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Example:

Indian Railways Official Website:

24
3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

25
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

PRACTICAL 8
Aim: Prepare SRS document with required detail of security, performance
and testing strategy parameter.

Security:

Our system is capable of preventing SQL injection attacks.

UsercanonlychangeaccountdetailsafterverifyingOTPthroughEmailorPhoneNumber.
Dataisnotsharedwithanythird-partyinstitutiontoprotectuseranddriver`sprivacy.
Password and other details are stored only in Hashed Format in Database.

Reliability

Reliability is one of them ethics that are used to measure quality. For reliable software,
the system shall be tested during development process. It shall be delivered on time and
shall meet the requirements that are specified in this document. In the application when
any fault occurs on application or database, it shall be recovered in a very short time in
terms of reliability.

The system should be available always.

System should display informative messages when its components doesn’t work
properly.
Mean time between failures must be almost 2 hours.

Performance

Our system will be able to support at least 5000 users. The capacity can be extended in
future if needed.

All of the functions that is for retrieving location should be perform less than 30
seconds.
There will be large amount of information to be handled in database such as live
location up date and the server will be enough space to handle this occupation.

2|Page
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Supportability

Since changing is inevitable in today’s world, these developments shall design to any
possibility of updating.

Design elements should be documented well.

Since programming language is object-oriented, program tasks are independent of each
other and there for easier to maintain.

3|Page
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Practical 9
Aim: Prepare final SRS in given template.

“Railway Reservation”
A Project Report Submitted to
Gujarat Technological University in Fulfillment of the Requirements for the Degree of
Bachelor of Engineering
in
Information Technology
B.E. IV, Semester-VI
By
Purva Darji 180110116007
Dhvani Kachhiya 180110116016
Chandni Patel 180110116032
Faculty Guide
Dr. Miral Patel

Academic Year 2021-2022

Department of Information Technology
G H Patel College of Engineering & Technology
Vallabh Vidhyanagar, Anand

4|Page
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

ACKNOWLEDGEMENT
We would like to express our gratitude and appreciation to all those who gave us the incentive to
work on this project. A special thanks to our project guide, Dr. Miral Patel, whose presence,
stimulating suggestions and encouragement, helped us to coordinate our project.

Hereby, we would also like to acknowledge with much reverence the crucial role of our
department, who were supportive and provided us with all the possible assistance as and when
required.

Moreover, we are thankful to the Head of the Department (Information Technology), Dr. Nikhil
Gondaliya, who has given his unmatched guidance in achieving the goal as well as his
motivation to maintain our project's progress in track. Last but not the least, the involvement of
the panels during every single presentation helped us vivify our vision for this project, their
straight- forwardness and concise comments aided our ambition in making of this project.

5|Page
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Table of Contents
1. INTRODUCTION
Objective
Scope
Glossary
Overview
2. OVERALL DESCRIPTION
Product Perspective
Product Functions
User Characteristics
Constrains
Assumptions and Dependencies
Apportioning of requirements
3. REQUIRMENT SPECIFICATION
Function Requirements
Performance Requirements
Design Constraints
Hardware Requirements
Software Requirements
Other Requirements
Non-Function Requirement
Security
Reliability
Availability

6|Page
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Maintainability
Supportability
4. DIAGRAM
Use Case Diagram
Class Diagram
State Diagram
Sequence Diagram
Data flow Diagram
5. GUI
Screen Shots
6. REFERENCES

7|Page
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Introduction

8|Page
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

1.Introduction
The introduction of the Software Requirements Specification (SRS) provides an overview of the entire
SRS purpose, scope, definitions, acronyms, abbreviations, references and overview of SRS.A
Software Requirements Specification (SRS) - a requirements specification for a software system - is
a complete description of the behaviour of a system to be developed. It includes a set of use cases that
describe all the interactions the users will have with the software. Use cases are also known as
functional requirements. In addition to use cases, the SRS also contains non-functional (or
supplementary) requirements. Non-functional requirements are requirements which impose constraints
on the design or implementation (such as performance engineering requirements, quality standards, or
design constraints). The aim of this document is to gather and analyse and give an in-depth insight of
the complete Marvel Electronics and Home Entertainment software system by defining the problem
statement in detail. This is a documentation of the project Railways Reservation System
done sincerely and satisfactorily by my group members. A Software has to be developed for
automating the manual Railway Reservation System.

 RESERVE SEATS – Reservation form has to be filled by passenger. If seats are

available entries like train name, number, destination are made.

 CANCEL RESERVATION- The clerk deletes the entry in the System and changes in
the Reservation Status.

 VIEW RESERVATION STATUS-The user needs to enter the PIN number printed on
ticket.

Objective:

The purpose of this source is to describe the railway reservation system which provides the train
timing details, reservation, billing and cancellation on various types of reservation namely,
• Confirm Reservation for confirm Seat.
• Reservation against Cancellation.
• Waiting list Reservation.
• Online Reservation.

9|Page
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

• Tatkal Reservation.

The origin of most software systems is in the need of a client, who either wants to automate the
existing manual system or desires a new software system. The software system is itself created by the
developer. Finally, the end user will use the completed system. Thus, there are three major parties
interested in a new system: the client, the user, and the developer. Somehow the requirements for the
system that will satisfy the needs of the clients and the concerns of the users have to be communicated
to the developer. The problem is that the client doesn’t usually design the software or the software
development process and the developer does not understand the client’s problem and the application
area. This causes a communication gap between the parties involved in the development of the project.

The basic purpose of Software Requirement Specification (SRS) is to bridge this communication gap.
SRS is the medium through which the client’s and the user’s needs are accurately specified; indeed
SRS forms the basis of software development.

Another important purpose of developing an SRS is helping the clients understanding their own
needs. An SRS establishes the basis for agreement between the client and the supplier on what the
software product will do.

An SRS provides a reference for validation of the final product. A high quality SRS is a prerequisite
tohigh quality software and it also reduces the development cost.

A few factors that direct us to develop a new system are given below -:

1. Faster System
2. Accuracy
3. Reliability
4. Informative
5. Reservations and cancellations from anywhere to any place

10 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Scop:

“Railways Reservation System” is an attempt to simulate the basic concepts of an online

Reservation system. The system enables to perform the following functions:

 Search For Train

 Booking of a Selected Flight
 Payment
 Cancellation
 Freight Revenue enhancement
 Passenger Revenue enhancement
 Improved & optimized service

Glossary:

This should define all technical terms and abbreviations used in the document

 NTES – National Train Enquiry System

 IVRS – Interactive Voice Response system
 PRS – passenger reservation system
 DFD :- Data Flow Diagram
 ERD :- Entity Relationship Diagram
 SRS :- Software Requirements Specification
 STD :- State Transition Diagram

Overview:

The remaining sections of this document provide a general description, including characteristics of the
users of this project, the product's hardware, and the functional and data requirements of the product.
General description of the project is discussed in section 2 of this document. Section 3 gives the
functional requirements, data requirements and constraints and assumptions made while designing
the E-Store. It also gives the user viewpoint of product. Section 3 also gives the specific requirements
of the product. Section

11 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

3 also discusses the external interface requirements and gives detailed description of functional
requirements. Section 4 is for supporting information.

12 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Overall Description

13 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

2. Overall Description
This document contains the problem statement that the current system is facing which is hampering
the growth opportunities of the company. It further contains a list of the stakeholders and users of the
proposed solution. It also illustrates the needs and wants of the stakeholders that were identified in the
brainstorming exercise as part of the requirements workshop. It further lists and briefly describes the
major features and a brief description of each of the proposed system.

Product Perspective:

Before the automation, the system suffered from the following DRAWBACKS:

 The existing system is highly manual involving a lot of paper work and calculation
and therefore may be erroneous. This has led to inconsistency and inaccuracy in the
maintenance of data.

 The data, which is stored on the paper only, may be lost, stolen or destroyed due to
natural calamity like fire and water.

 The existing system is sluggish and consumes a lot of time causing inconvenience to
customers and the airlines staff. 

 Due to manual nature, it is difficult to update, delete, add or view the data.

 Since the number of passengers have drastically increased therefore maintaining and
retrieving detailed record of passenger is extremely difficult.

 A railway has many offices around the world, an absence of a link between these
offices lead to lack of coordination and communication.

Hence the railways reservation system is proposed with the following

 The computerization of the reservation system will reduce a lot of paperwork and
hence the load on the airline administrative staff. 

14 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

 Ø The machine performs all calculations. Hence chances of error arenil. 

 The passenger, reservation, cancellation list can easily be retrieved and any required
addition, deletion or updation can be performed. 

 The system provides for user-ID validation, hence unauthorized access is prevented.

Project Functions:

Booking agents with varying levels of familiarity with computers will mostly use this system. With
this in mind, an important feature of this software is that it be relatively simple to use. The scope of
this project encompasses: -

¨ Search: This function allows the booking agent to search for train that are available between the two
travel cities, namely the "Departure city" and "Arrival city" as desired by the traveller. The system
initially prompts the agent for the departure and arrival city, the date of departure, preferred time slot
and the number of passengers. It then displays a list of train available with different airlines between
the designated cities on the specified date and time.

¨ Selection: This function allows a particular train to be selected from the displayed list. All the
details of the train are shown: -

7. train Number
8. Date, time and place of departure
9. Date, time and place of arrival
10. TRAIN Duration
11. Fare per head
12. Number of stoppages – 0, 1, 2…

¨ Review: If the seats are available, then the software prompts for the booking of train. The train
information is shown. The total fare including taxes is shown and flight details are reviewed.

¨ Traveller Information: It asks for the details of all the passengers supposed to travel including
name, address, telephone number and e-mail id.

15 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

¨ Payment: It asks the agent to enter the various credit card details of the person making the
reservation.

6. Credit card type

7. Credit card number
8. CVC number of the card
9. Expiration date of the card
10. The name on the card

¨ Cancellation: The system also allows the passenger to cancel an existing reservation. This
function registers the information regarding a passenger who has requested for a cancellation of
his/her ticket. It includes entries pertaining to the train No., Confirmation No., Name, Date of Journey,
Fare deducted.

User Characteristics:

 Ø EDUCATIONAL LEVEL:-At least user of the system should be comfortable with

English language.

 Ø TECHNICAL EXPERTISE: - User should be comfortable using general purpose

applications on the computer system. 

Constrains:

Software constraints:

 The system will run under windows98 or higher platforms ofoperating system. 

Assumptions and Dependencies:

 Ø Booking Agents will be having a valid user name an password to access the
software

 Ø The software needs booking agent to have complete knowledge of railways

reservation system. 

16 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

 Ø Software is dependent on access to internet.

17 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Requirement Specification

18 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

3.Function Requirements
performance requirements:

 User Satisfaction: - The system is such that it stands up to the user expectations. 

 Response Time: -The response of all the operation is good. This has been made
possible by careful programming.

 Error Handling: - Response to user errors and undesired situations has been taken
care of to ensure that the system operates without halting.

 Safety and Robustness: - The system is able to avoid or tackle disastrous action. In
other words, it should be foul proof. The system safeguards against undesired events,
without human intervention. 

 Portable: - The software should not be architecture specific. It should be easily

transferable to other platforms if needed.
 User friendliness: - The system is easy to learn and understand. A native user can
also use the system effectively, without any difficulties. 

Design constrain:

There are a number of factors in the client’s environment that may restrict the choices of a designer.
Such factors include standards that must be followed, resource limits, operating environment,
reliability and security requirements and policies that may have an impact on the design of the system.
An SRS (Software Requirements Analysis and Specification) should identify and specify all such
constraints.

Ø Standard Compliance: - This specifies the requirements for the standards the system must follow.
The standards may include the report format and accounting properties.

Ø Hardware Limitations :- The software may have to operate on some existing or predetermined
hardware, thus imposing restrictions on the design. Hardware limitations can include the types of
machines to be used, operating system available on the system, languages supported and limits on
primary and secondary storage.

19 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Ø Reliability and Fault Tolerance: - Fault tolerance requirements can place a major constraint on
how the system is to be designed. Fault tolerance requirements often make the system more complex
and expensive. Requirements about system behaviour in the face of certain kinds of faults are
specified. Recovery requirements are often an integral part here, detailing what the system should do I
some failure occurs to ensure certain properties. Reliability requirements are very important for
critical applications.

Ø Security: - Security requirements are particularly significant in defence systems and database
systems. They place restrictions on the use of certain commands, control access to data, provide
different kinds of access requirements for different people, require the use of passwords and
cryptography techniques and maintain a log of activities in the system.

Hardware requirements:

For the hardware requirements the SRS specifies the logical characteristics of each interface b/w the
software product and the hardware components. It specifies the hardware requirements like memory
restrictions, cache size, the processor, RAM size etc... those are required for the software to run.

Minimum Hardware Requirements

Processor Pentium III

Hard disk drive 40 GB

RAM 128 MB

Cache 512 kb

Preferred Hardware Requirements

Processor Pentium IV

Hard disk drive 80 GB

RAM 256 MB

Cache 512 kb

20 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Software requirements:

 Any window-based operating system with DOS support are primary requirements for
software development. Windows XP, FrontPage and dumps are required. The systems
must be connected via LAN and connection to internet is mandatory. 

other requirements:

Software should satisfy following requirements as well: -

 SECURITY
 Ø PORTABILITY
 Ø CORRECTNESS
 Ø EFFICIENCY
 Ø FLEXIBILTY
 Ø TESTABILTY
 Ø REUSABILTY

Non-Function Requirements

Security:

The system use SSL (secured socket layer) in all transactions that include any confidential customer
information. The system must automatically log out all customers after a period of inactivity. The
system should not leave any cookies on the customer’s computer containing the user’s password. The
system’s back-end servers shall only be accessible to authenticated management.

Reliability:

The reliability of the overall project depends on the reliability of the separate components. The main
pillar of reliability of the system is the backup of the database which is continuously maintained and
updated to reflect the most recent changes. Also the system will be functioning inside a container.
Thus the overall stability of the system depends on the stability of container and its underlying
operating system.

21 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Availability:

The system should be available at all times, meaning the user can access it using a web browser, only
restricted by the down time of the server on which the system runs. A customer friendly system which
is in access of people around the world should work 24 hours. In case of a of a hardware failure or
database corruption, a replacement page will be shown. Also in case of a hardware failure or database
corruption, backups of the database should be retrieved from the server and saved by the Organizer.
Then the service will be restarted. It means 24 x 7 availability.

Maintainability:

A commercial database is used for maintaining the database and the application server takes care of
the site. In case of a failure, a re-initialization of the project will be done. Also the software design is
being done with modularity in mind so that maintainability can be done efficiently.

Supportability:

The code and supporting modules of the system will be well documented and easy to understand.
Online User Documentation and Help System Requirements.

22 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Diagram

23 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

A use case diagram in the Unified Modelling Language (UML) is a type of behavioural diagram
defined by and created from a Use-case analysis. Its purpose is to present a graphical overview of the
functionality provided by a system in terms of actors, their goals (represented as use cases), and any
dependencies between those use cases. The main purpose of a use case diagram is to show what
system functions are performed for which actor. Roles of the actors in the system can be depicted.
Interaction among actors is not shown on the use case diagram. If this interaction is essential to a
coherent description of the desired behaviour, perhaps the system or use case boundaries should be re-
examined. Alternatively, interaction among actors can be part of the assumptions used in the use case.
 Use cases
A use case describes a sequence of actions that provide something of measurable value to an
actor and is drawn as a horizontal ellipse.
 Actors
An actor is a person, organization, or external system that plays a role in one or more
interactions with the system.
 System boundary boxes(optional)
A rectangle is drawn around the use cases, called the system boundary box, to indicate its
scope of system. Anything within the box represents functionality that is in scope and anything
outside the box is not.

24 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Use-case Diagram

25 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Class Diagram

User
-userid : string
-password : string
-loginstatus : string
-Name : string
*
-Email : string
+verifylogin()() : bool

*
1

Admin Train
Ticket -SendconformEmail() : void Customer -train no : int
-ticketnumber : int -SendRecipt() : void -address : string -train name : string
-tavellingclass : string -deleteAlbum : void -phone : int -source : string
-confirmOrder() : void * -destination : string
-Dateofjourny : int +register() : void
-deleteOrder() : void +login() : bool -arrivaltime : int
+updateprofile() : string -departuretime : int

*
order
-orderId : int Railway
payment -orderedDate : int
Bank -customerName : string -name
-paymentMode : string -shifttime
-bankName : string -customerId : int
-branch : string +validatePayment()() : void -stutus : string +authentication()
-bankId : int +putOrder() : void +updateDetail()
+creditcardNo() +printOrder() : void
*
1

* *

Debitcard orderDetailed
-cardHoldername : string
-orderId : int
-securityCode : int
-quantity : int
-expireDate : int
-totalcost : int
-cardNumber : int -calculatePrice : int
+validdatePayment() : void
+calPrice() : void
+checkFormet() : void

26 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

State Diagram

27 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Sequence Diagram

Customer Train Railway admin Printer Database Bank

login to reservation

Check avaiblity

If availanle

Request reservation form

Provide reservation form

Fill form & submit

Update detail

Request debit amount

Update reservation detail

Request to print tickets

Printing performed & issued

Request cancellation

Get reservation detail

Perform cancellation
Ticket cancelled

Update cancelled detail

Update new detail

28 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Data Flow Diagram

A data flow diagram (DFD) is a graphical representation of the "flow" of data through an
information system. DFDs can also be used for the visualization of data processing (structured
design).On a DFD, data items flow from an external data source or an internal data store to an internal
data store or an external data sink, via an internal process. A DFD provides no information about the
timing of processes, or about whether processes will operate in sequence or in parallel. It is therefore
quite different from a flowchart, which shows the flow of control through an algorithm, allowing a
reader to determine what operations will be performed, in what order, and under what circumstances,
but not what kinds of data will be input to and output from the system, nor where the data will come
from and go to, nor where the data will be stored (all of which are shown on a DFD).

It is common practice to draw a context-level data flow diagram first, which shows the interaction
between the system and external agents which act as data sources and data sinks. On the context
diagram (also known as the 'Level 0 DFD') the system's interactions with the outside world are
modelled purely in terms of data flows across the system boundary. The context diagram shows the
entire system as a single process, and gives no clues as to its internal organization.

This context-level DFD is next "exploded", to produce a Level 1 DFD that shows some of the detail of
the system being modeled. The Level 1 DFD shows how the system is divided into sub-systems
(processes), each of which deals with one or more of the data flows to or from an external agent, and
which together provide all of the functionality of the system as a whole. It also identifies internal data
stores that must be present in order for the system to do its job, and shows the flow of data between the
various parts of the system.

29 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Level 0:

Enter
Railway
User Admin
Reservatio
Get

Level 1:

30 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Level 2:

Reservation Check availability

Appily for
ticket Give
availabili
Admin
ty

Conform ticket
Cancellatio
n process
Apply for
cancelatio
n Conform
User Cancelation
cancellation Railway
cancelation database
View
details
detail

Enter Check
paymen status Payment
t detail process

Payment
done

Payment

31 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Graphical User
Interface

32 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

5.1 Screen Short

The system shall provide a uniform look and feel between all the web pages.
Home Page:

Login:

Registration:

33 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Search Train:

Other Screen:

34 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

35 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Example:

Indian Railways Official Website:

36 | P a g
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

11. References
1. IEEE SRS Format
2. Yatra.com
3. Irctc.co.in
4. Indianrail.gov.in
5. www.google.com
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

PRACTICAL - 10

AIM: Submit a case study report on a real time project.

Insurance Company Cuts Cycle Time by 20% and Saves Nearly $5
Million Using Agile Project Management Practices
Project durations have been reduced by 20%, for a net savings of nearly $5 million. The percentage of
projects coming in on time and within budget increased by 40%. As a result, management has broadened the
scope of the initiative to implement agile practices across the organization.
Company

A US-based Fortune 100 company providing insurance products and services to clients in North America.
Challenge

With a billion dollar project portfolio numbering in the hundreds of projects, the client needed to decrease
time-to-market in response to competitive pressures and its expanding product line. They set aggressive goals
to reduce average project duration by approximately 50% and improve internal customer satisfaction by 25%
over a three-year period. The client’s project management environment at the time was rigid, depending
almost entirely on traditional phase-based deliverable schedules, with a heavy development methodology.
Solution

The client adopted the Scrum framework and other agile product development techniques, hoping to benefit
from the shorter project durations promised by an iterative approach. In adopting agile practices and
techniques as part of this initiative, the organization was set to introduce radically new management practices
to a traditionally trained project management community, with an emphasis on early and frequent delivery of
value to end-users.
During the beginning stages of this initiative, PM Solutions became an integral part of an internal group that
provided agile coaching to teams employing agile development practices, coupled with training tailored to
their specific environment.
PM Solutions also mentored the client’s project management organization through the various changes these
new practices required of an organization schooled in traditional approaches.
 3171609 SOFTWARE PROJECT MANAGEMENT 180110116007

Results

After 18 months of mentoring and coaching, a number of significant results were realized:

Average project duration (cycle time) was reduced by approximately 20%, for a net
savings of nearly $5 million Customer satisfaction improved nearly 30% (exceeding
the goal of 25%), 18 months ahead of projections Project startup duration decreased
from an average of 10 weeks to 3 weeks Time-to-first-solution implementation
decreased from an average of 20 weeks to 7 weeks 90% of projects adopting agile
practices and techniques now deliver the desired value to end-users on-time and
within initial budgets – by contrast, with traditional approaches, only 50% of
projects delivered desired value on-time and within initial budgets.
Approximately 15% of the client’s portfolio of projects has now adopted some form
of agile project management. Due to demonstrated successes using a combination of
agile project management and development practices, the client has established
strategic goals that formalize the intent to “go agile” across the organization. As a
result, management has now mandated a doubling of the percent of projects using
agile methods.

PM Solutions continues to help lead coaching and mentoring efforts that will further
ingrain agile practices into the company’s business operations.