Requirement analysis

Requirements refers to the needs of fabricated software to work efficiently and

effectively, some of the requirements of this software are as follows:

1. EXTERNAL INTERFACE REQUIREMENTS:

External Interface requirements refers to needs of this software’s front end to

work efficiently, the requirements are further classified into certain topics,
which are as:

i. User Interfaces:
For the efficient working of the User Interface, i.e. the Front End of the
system, the OS must be having at least Internet Explorer 8 installed. To log
into the website.

ii. Hardware Interfaces :

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 restriction, cache size,
processor, RAM etc. those are required for software to run.
Minimum Hardware Requirements
Processor Pentium IV
HDD 40 GB
RAM 128 MB
Cache 512 kb

Preferred Hardware Requirements

Processor Core 2 Duo E7300
HDD 80 GB
RAM 512 MB
Cache 1 MB L1
Cache 512kb L2

iii. Software Interfaces:

For Hosting: Any Windows Operations System with DOS Support and Visual
Studio for development. Primarily Windows 8, having Dream Weaver Installed
with a working LAN connection to be mandatory.
For Using: Any type of Operating System with at Least Internet Explorer
Installed
and having minimum of 512 kbps working LAN compulsorily.

iv. Communication Interfaces:

Indian Railway’s web-site, www.indianrail.gov.in offers PRS enquiries on
the internet Berth/Seat availability, Passenger Status, Fare, Train Schedule
etc,.
National Train Enquiry System (NTES) website,
www.trainenquiry.comgives dynamic information about the running status
of any train and its expected arrival/departure at any given station.

Mobile telephone based SMS enquiry service. A new mobile phone based
facility for rail users’ which is. Country wide extension of Universal Rail
Enquiry number “139”through setting up of Interactive Voice Response
System (IVRS).

2. FUNCTIONAL REQUIREMENTS:
Functional requirements refer to the Functions, which were required before and
covered in this system/ software we have developed. Mentioned below are the
functions/ features of our newly fabricated software system:

i. Feature #1 - TRAIN DETAILS:

Customers may view the train timing at a date their name and number of
tickets.

ii. Feature #2 – RESERVATION:

After checking the number of seats available the customers reserve the
tickets.

iii. Feature #3 – BILLING:

After reserving the required amount of tickets, the customer paid the amount.

iv. Feature #4 – CANCELLATION:

If the customers want to cancel the ticket, then half of the amount paid by the
customer will be refunded to him.

v. Feature #5 – PERFORMANCE REQUIREMENTS:

It is available during all 24 hours.

vi. Feature #6 – SOFTWARE SYSTEM ATTRIBUTES:

Reliable
Available
Secure

3. USE CASES:
A use case diagram in the Unified Modeling Language (UML) is a type of
behavioral 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 behavior, 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, to6
indicate the scope of system. Anything within the box represents functionality
that is in scope and anything outside the box is not

i. Use case #1 : Ticket Availability, Reservation type, Booking and

Cancellation :

ii. Use case #2 – Ticket Booking and Cancellation and money refunding:

4. OBJECTS/ CLASSES:
In software engineering, a class diagram in the Unified Modeling
Language(UML) is a type of static structure diagram that describes the structure
of a system by showing the system's classes, their attributes, operations (or
methods), and the relationships among objects.
The class diagram is the main building block of object-oriented modelling. It is
used both for general conceptual modelling of the systematics of the
application, and for detailed modelling translating the models into programming
code. Class diagrams can also be used for data modeling. The classes in a class
diagram represent both the main elements, interactions in the application, and
the classes to be programmed.

Classes are represented with boxes that contain three compartments:

The top compartment contains the name of the class. It is printed in bold and
centered,
and the first letter is capitalized.
6The middle compartment contains the attributes of the class. They are left-
aligned
and the first letter is lowercase.
The bottom compartment contains the operations the class can execute. They
are also
left-aligned and the first letter is lowercase.

In the design of a system, a number of classes are identified and grouped

together in a class diagram that helps to determine the static relations between
them. With detailed modelling, the classes of the conceptual design are often
split into a number of subclasses. In order to further describe the behavior of
systems, these class diagrams can be complemented by a state diagram or UML.
Classes:
o Train
o Passenger
o RailwayAdministration
o Ticket

5. NON-FUNCTIONAL REQUIREMENTS:
Nonfunctional requirements make up a significant part of the specification.
They are important as the client and user may well judge the product on its non-
functional properties. Provided the product meets its required amount of
functionality, the nonfunctional properties -- how usable, convenient, inviting
and secure it is -- may be the difference between an accepted, well-liked
product, and an unused one.

1. Performance:
This system helps in increasing the overall performance of the Railway
Reservation functionality by shifting a large chunk of load online causing in
less hassle in ticket booking, cancellation or querying. This System is 22
hours Live per day giving us greater availability time as compared to that of
9 hours offline activity.

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

3. 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 hardware failure or
database corruption, a replacement page will be shown. Also, in case of a
hardware failure or database corruption, backup of the database should be
retrieved from the server and saved by the Organizer. Then the service will
be restarted. It means 24x7 availability.

4. Security:
This system should work under 3-Level Architecture combining DB-Class-
Front end with different security facilities and encryption. The System use
SSL in all transactions that include any confidential customer information.
The system must automatically log out all customer after a period of
inactivity of those users respectively. 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.

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

6. Supportability:
The code and supporting modules of the system will be well documented and
easy to understand. Online user Documentation and Help system
requirements.

6. INVERSE REQUIREMENT:
A requirement stated as a negative proposition (shall not). An inverse
requirement is untestable. Everything outside the system is what the system
does not do. Testing would have to continue forever to prove the system
does not do something. State what the system does. It isn't that difficult to
correct a negative requirement. Substitute an active constraint that
expresses what the system must do. For example change "the system shall
not allow X," to "the system shall prevent Y." Another method is to use the
prefix "un," such as: The system shall reject unauthorized users.
Problem requirement: The system shall produce the ABC report in a
timely manner.

Discussion: "Timely" needs to be defined in accordance with the needs of

the railway management Problem requirement: The system shall require users to
select only one of the following...

Discussion: The placement of booking can cause problems. In this

requirement, "booking" can mean the one action available to users is
"select," or it can mean users are limited to one item from the list. The
correction is not adding more words ("one and only one"). The correction
is deleting "booking," which is an extraneous word.

Problem requirement: The system shall automatically do month selection

when numbers are entered."

Discussion: If there is an event that triggers this system action, it may need
to be stated. Otherwise, automated systems are, by nature, automated, so
the numbers are unnecessary.

7. DESIGN CONSTRAINT:
Design constraints can be imposed by other standards, hardware limitations, etc.
 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.

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

Quality Characteristics:
There are a number of quality characteristics that can apply to software. Pick the
ones most important to this product and develop a section for each one.
Definitions of the quality characteristics follow.

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

mission objectives.

Efficiency - amount of computing resources and code required to perform

function.
 Flexibility - effort needed to modify operational program
Integrity/security - extent to which access to software or data by unauthorized
people can be controlled
Interoperability - effort needed to couple one system with another
Maintainability - effort required to locate and fix an error during operation
Portability - effort needed to transfer from one h/w or s/w environment to
another
Reliability - extent to which program performs with required precision
Reusability - extent to which it can be reused in another application
Testability - effort needed to test to ensure performs as intended
Usability - effort required to learn, operate, prepare input, interpret output
3.8. LOGICAL DATABASE REQUIREMENTS
The system must store all the user account information as well as the sessional
grade records. All the data shall be stored in text-based flat files. For each user
account, the login ID, name, password, age, email address (optional) shall be
stored in one file. The email address gives the user option to receive any further
information or update about the software. Each attribute shall be delimited by a
semicolon, and all the entries shall be sorted alphabetically by the login ID.
Furthermore, for each user account, there shall be a grade report file which
contains every sessional grade result for a certain user. A grade report file shall
contain the following attributes: session ID, date (dd/mm/yyyy), duration
(minutes), video ID, number of pauses, and number of correct timings. Each
entry shall also be delimited by a semicolon and sorted alphabetically by the
session ID. Here is an example which shows how the data shall be stored and
presented.

Accessibility and Security : Only the user who has access to a certain account
can access the grade report file belongs to that account. None of the users has
access to modify any of the data files.
9. 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.
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.
Operations.
This could specify the normal and special operations required by the user
such as:
The various modes of operations in the user organization; for example,
userinitiated
operations
Periods of interactive operations and periods of unattended operations
Data processing support functions
Backup and recovery operations
Note: This is sometimes specified as part of the User Interfaces section.
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.