This essay sample on Requirement Analysis For Railway Reservation System provides all necessary basic info on this matter, including the most common “for and against” arguments. Below are the introduction, body and conclusion parts of this essay.
Railway Reservation System Requirements Specification Table of Contents 1. Introduction3 1. 1Goals and Purpose3 1. 2Scope of Project3 1. 3Definiton & Abbreviations4 1. 4 References 1. 5Overview4 2. Overall Description5 2. 1Product Perspective 2. 2 Product Function 2. 3 User Characteristics 2. 4 General Constraints 2. 5 Assumptions & Dependencies 5 3. Specific Requirement6 3. 1External Interface Requirement6 3. 1. 1 User Interface 3. 1. 2 Hardware Interface 3. 1. 3 Software Interface 3.
1. 4 Communication Interface 3. 2Functional Reqiuerment7 3. 3Performance Requirement8 3. 4Design Requirement 3. Attributes 3. 6 Others Requiremnt 9 Requirement Specification Introduction The Railway Reservation System is an online application for assisting user or railway manager in managing reservation in a Railway Department. The system would provide basic set of features to conduct reservation or cancellation, train scheduling timing, search for available reservation, and manage check-in / checkout processes. The following document provides the key requirements specifications for the system based on the client’s statement of need. Goals and Purpose The Railway Reservation system would have the following key goals: – Provide a GUI for user to interface with the backend database – Screens to reservation/cancellation database – Screens to train schedule – Screens to search for a train/seats based on user driven parameters – Minimize the overall time 2 Scope of Project The main scope and deliverables of the project would be: – Easy, Fast and efficient working – Easy way for cancellation and reservation of the tickets.
– Get exact information about trains, available seat, charges, etc. – Faster communication
The key milestones and deliverables of the project would be as follows: |Tasks |Deliverable |Due date | |Prepare detailed user |User Requirements Specification |, 2008 | |requirements document | | | |Review the requirements and |Requirements Review Checklist & | | |update the requirements document |Template.
| | |and obtain client sign-off |Updated URS (Version 2. ) | | |High Level Design of application |HLDD | | |system | | | |Test Plan for application |Test Plan Document | | |Detailed Design Document |Unit Design Document | | |Prototype |Code & GUI screens | | |Test Cases and Report |Test report | | |System Demo |Demonstration | | 1. 3. Definition & Abbreviations AARS: Automated Railway Reservation System 3 References Railway reservation website Google Books 1. 5 Overview The product of the requirements elicitation process is requirements document, which include functional requirements, interface requirements, performance requirements, design constraints, Preliminary Object-Oriented Domain Analysis, operational scenarios and others requirements. Overall Description 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. [pic] Functions of System Components: Database:
• • Stores data
• • Creates reports
• • Provides access to data
• • Updates information Server:
• • Provides access to the database
• • Authenticates users
• • Processes reservations
• • Performs backups
• • Produces reports External Interfaces: Terminal
• • Users use terminals to access the server
• • Passengers and travel agents use terminals to reserve the tickets and to get information about the available seats on particular trains.
• Railroad administration may use terminals to see the reports generated by the database software. Personal Computers
• • Users (passengers, travel agents, and railroad administration) may use personal computers to obtain a remote access to the server and the reservation database via the Internet. Cell Phones
• • 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 Product Functions. The product main function is to provide functionality to overcome the problem which is faced by the existing system. This product helps any type of user to know each and every thing regarding reservation in any train. It also helps to provide information regarding railways by means of phone so that work can done fast and in very efficient manner. 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. 4 General Constraints. The Product is developed using Microsoft Visual Basic 6. 0. The backend database for this SQL Server. The product is accomplished with login facility so that specific function is available to specific users . Under this hardware, software and design constraints we consider. 2. 5 Assumptions and dependencies The assumptions for the project are:
• 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. 3. External Interface Requirement 3. 1. 1 User Interfaces User Interface plays the most important role for communication between user and software product. The interface should present and acquire information in a consistent fashion. 3. 1. 2 Hardware Interfaces ? Operating System: Windows XP/ME ? Processor: Pentium 3. 0 GHz ? RAM: 256 Mb ? Hard Drive: 10 GB 3. Software Interfaces ¬ Database: SQL Server. Application: Visual Basic 3. 2. Functional Requirements This list of Functional and non functional requirements which are applicable to the Railway Reservation System. This section should describe a set of scenarios that illustrate, from the user’s perspective, what will be experienced when utilizing the system under various situations. In the broad sense, a scenario is simply a proposed specific use of the system. A set of scenarios is represented below_: Use Case: Indian Railways provides for advance reservation on all long-distance travel. The passenger seeking reservation of berth or seats should purchase the tickets from Railway Reservation Offices .
To make an advance booking, the passenger is expected to fill in a prescribed application form and submit it to the reservation counter with the appropriate amount. Advanced Reservations are made up to 60 days in advance for all trains, for all classes exclusive of the day of departure of trains. An individual can book only up to six passengers on one requisition form provided all passengers are for the same destination and for the same train. Indian Railways wishes to develop a ticketing and reservation system. This must support advance booking of tickets, cancellation of tickets and change of class of a ticket. All these are handled by a Reservation Clerk. The system will also have a web-interface where users can register themselves and purchase tickets online.
They can pay either by using their online banking account or by credit card or by VPP. Reservations made over the internet can only be cancelled across the counter. The system will also have a querying facility that allows users to check train time-tables, fares and availability of tickets. Identify the Actors:- The actors in the system are the passenger, the counter clerk and the reservation system consisting of form processing, reservation, fare computation, ticket processing, ticket printing, collection of fare amount and posting as sub-systems. The passenger is a passive user–actor who initiates the process and obtains the ticket(s), a goal of measurable value.
The counter clerk is an active user–actor, who triggers the system and has the role of issuing the tickets with the responsibility of collecting the correct fare amount from the passenger, which is a measurable value. Predesigned and deployed ticket reservation system at the back end is a system actor–user to ensure that ticket processing is done correctly and different system status are updated on issuing of tickets. This actor has an active role and responsibility at the back end. Table:- |User |Roles |Use Case | |1)Person |a)Enquiry |a)Enquire ticket availability and other | | |b)Reservation & Ticketing |details. | |c)Cancellation |b)Reserve seats and berths, tickets | | | |c) Cancel tickets | |2)Counter clerk |a)Form data entry |a) Enter Reservation Requisition Form | | |b) Requisition processor booking |b) Process requisition for booking | | |c)Ticket processor |c)Process ticket to print | | |d) Data manager |d) Submits ticket data for updation | |3)Reservation and ticketing system |System server a) Process reservation data, process | | | |ticketing system ticketing process | | | |cancellation | | | |b) Update the status by date, train, etc. | The system has three users, eight roles and eleven use cases. To illustrate the Process of identifying the use cases, let us take the passenger (a user of the system). A passenger as a user may play one or more of three roles. The roles are 1.
Enquiring about the availability of tickets on particular dates to a destination and the fare per ticket. The role is enquiring. 2. Reserving the ticket(s) on a particular train on particular date for a destination by requisitioning through a reservation form The role is reserving and booking tickets. 3. Cancelling the tickets after issuing and payment The role is cancelling 1) Use Case:Make Reservation Actors: Passenger, Reservation Clerk Purpose:Reserve a seat or berth Overview:Allows the user to make a reservation for a journey. Normal Flow: 1. User logs in 2. User specifies the train and journey details 3. User specifies passenger details 4. User specifies payment details 5. User confirms transaction 2) Use Case: Cancel Reservation
Actors: Reservation clerk, Passenger Purpose: Cancel the ticket Overview:Allows the user to cancel a reservation for a journey. Normal Flow: 1. User logs in 2. User specifies the train and journey details. 3. Clerk checks the time and date of ticket 4. If date is passed there is no meaning of cancelation and if the date is not passed the clerk deducts some transaction fee and returns the remaining amount. 5. Ticket is cancelled. 3) Use Case: Modify class Actors: Reservation clerk, Passenger Purpose: Modify the ticket class Overview: Allows the user to modification of the class according to user demand for a journey. Normal Flow: 1.
User logs in 2. User specifies the train and journey details. 3. User specifies payment details 4. User specifies the train detail according to class 4) Use Case: Print ticket Actors: Reservation clerk, passenger Purpose: print the ticket Overview: Allows the user to give the ticket to the passenger for a journey. Normal Flow: 1. User logs in. 2. User specifies the train and journey details. 3. User specifies payment details 4. Reservation clerk print the ticket according to users details 5) Use case: Query Timetable Actors: User, Query counter clerk Purpose: To give the details of train to the passenger for journey Normal Flow:- 1) User log in ) User specifies the particular train details 3) User gets the record according to the train 6) Use case: Check seat Availability Actors: User, Reservation Clerk Purpose: To give information regarding seat availability Normal Flow:- 1) User logs in. 2) User specifies Train details. 3) Check the available seats and reserved seats. 7) Use case: Check Fare Actors: User, Reservation counter clerk Purpose: To give the details of fare to the passenger for journey Normal Flow:- 1) User log in 2) User specifies the particular train details 3) Check the fare 4) User gets the record according to the train 5) Make the reservation 3 Performance Requirements
The proposed system that we are going to develop will be used as the Chief performance system within the campus which interacts with the staff and students. Therefore, it is expected that the database would perform functionally all the requirements that are specified by the campus. 1. Design Requirements The proposed system is fully automated. It will give quick response and retrieval time. As everything is automated, not much of human help needed. The data is less questionable when working with computers. The calculations done are more precise and accurate. The processing is easy and usable. The new system is adaptable and can easily be changed according to the user’s need. There is no repetition of data occurs. The data is in Consistent state. 3. 4 Attributes Requirements