This action might not be possible to undo. Are you sure you want to continue?
MAHARAJA AGRASEN INST. OF TECHNOLOGY
Developed by Name : Branch : Eroll no: Gaurav Gaur C.S.E 0101482707
Problem Statement Software Requirement Specification Use case diagram Use case description Activity Diagrams Sequence Diagrams Class Diagram Collaboration Diagram E-R Diagram
PROBLEM STATEMENT FOR RAILWAY RESERVATION SYSTEM
Software has to be developed for automating the manual reservation system of railway. The system should be standalone in nature. It should be designed to provide functionalities like booking of tickets in which a user should be able to applied for tickets of any train and of any class. A limitation is imposed when the number of tickets for which user apply is greater then available seats or no seats are available. If seats are not available then put user transaction in the waiting queue.If the tickets are available then it is issued to the user and it must be updated in the database concurrently. The system generates the receipt for the same. The software takes the current system date and time as the date of issue and calculates the amount to be paid by the user. It also provide the functionality of cancellation of tickets .If the user wants to cancel the tickets, he/she must enter the details. The system check the records from the database if it is matched with the user entered details, then it cancels the tickets. The system also calculates the amount to be return to the user after deductions. The system must update the database for the same. After that system must check for waiting passenger for that train, if any then these tickets are issued to waiting passenger and update the database. The system displays the details of train of which user enter the name. The information is saved and the corresponding updating take place in the database. In the enquiry, the system should be able to provide information like the availability of tickets of particular train, train schedule. The system should be able to reserve a ticket for a particular user if the tickets are not currently available. The corresponding print outs for each entry (issue/cancel) in the system should be generated.
Record of the users of the system should be kept in the log file. through mail or via sms. Each user should have a user id and a password. It should tell us as to which all stations it haults and current status of the train should be informed. Provision should be made for full backup of the system.There should be proper information if the waiting list ticket is confirmed. . Security provisions like the login authenticity should be provided.
train schedule. The intended audience for this document is the development team. waiting lists of passengers. ACRONYMS AND ABBREVATIONS The following abbreviations have been used throughout: DBA – Database Administrator 1. Efforts are been made to define the requirement exhaustively and accurately.1 PURPOSE This specification document describes the capabilities that will be provided by the software application “RAILWAY RESERVATION SYSTEM”. a formal change request will need to be raised and subsequently a new release of this document and/or product will be produced. self-contained and independent software product.SOFTWARE REQUIREMENT SPECIFICATION 1. INTRODUCTION The document aims at defining the overall software requirements for” RAILWAY RESERVATION SYSTEM”. The final product will be having only features/functionalities mentioned in this document and assumption for any additional functionality/feature should not make by any of the parties involved in developing/testing/implementing the products. waiting seat level.2 SCOPE The software “RAILWAY RESERVATION SYSTEM” will be an application that will be used for automating the railway reservation system. waiting seat level. reservation level of the seat. In case it is required to have some additional features. cancellation of seats. reservation level of the seat. This application will greatly improve the current manual system and will be much more efficient.1 PRODUCT PERSPECTIVE The application will be a windows-based. It also states the various required constraints by which the system will abide. The system also provides the facility to the passenger to check the timetable of train. OVERALL DESCRIPTION RAILWAY TICKETING SYSTEM is the overall system used for the purpose of reservation of seat in different class for different trains. 2. testing team and the users of the produced. 1.3 DEFINITIONS. train schedule. 1. check the time-table of train. cancellation of seats. 1.5 OVERVIEW The rest of this SRS document describes the various system requirements. 2. This application will manage information about passengers details regarding the reservation of seat in different class for different trains.4 REFERENCES (a) IEEE recommended practice for software requirements specifications-IEEE standard 18301993. . 1. interfaces and functionalities in details. waiting lists of passengers.
Access to different screens will be based upon the role of the user. address. The final application packages as an independent setup program that will be delivered to the client. date & time of issue and the automatically calculated fare of the tickets according to different class of ticket is issued.1. Following lists will be generated: (a) Passenger list: Printable list of all the passengers reserved for a particular train. (c) Train schedule list: printable list of the schedule of a given train. MS EXCESS 2000 as the DBMS for database future release of the application will aim at upgrading to ORACLE-8i to DBMS. (b) Support for printer: proper drivers must be installed and printer connected will be requested for printing various above mentioned lists. SOFTWARE INTERFACES (i) (ii) (iii) (iv) Any windows based operating system.1.3 HARDWARE INTERFACES (a) Screen resolution of at least 800 X 600 is required for complete and proper viewing of screens.2.L Crystal reports-8 for generating and viewing reports. (d) There will be a screen for capturing and displaying details of all the tickets are available of the different classes of each train.1. (c) Standalone or network based not a concern as it will be possible to run the application on any of them. (f) There will be a screen for capturing and displaying details of user regarding cancellation of tickets. starting junction as well as destination spot. ID number and password for the operator or the user will be provided.1.2 SYSTEM INTERFACES USER INTERFACES The application will have a user friendly and menu based interface. name. sex.5 COMMUNICATION INTERFACES MEMORY CONSTRAINTS . age.1. 2. Visual basic for coding developing the software.1 None 2. (b) There will be a screen for capturing and displaying passenger details viz. Following screens can be found: (a) A login screen for entering the user name.4 None 2. Higher resolution will not be any problem. (c) There will be a screen for capturing and displaying info. (b) Train list: Printable list of the all the trains along with their ID. regarding which seat is alotted to which passenger. (e) There will be a screen for capturing and displaying details of user regarding reservation of tickets. 2.
1 EXTERNAL INTERFACES USER INTERFACES The following screens will be provided: (i) LOGIN SCREEN to . User (with role of DBA) will be able to add/modify/delete information about different passengers that can have name in reservation list. 2. which is not a very powerful DBMS.1 3.6 OPERATIONS DBA at This product release will not cover any automated housekeeping aspects of the data base.5 None APPORTIONING OF REQUIREMENTS 3. 2.1.1. The the client site will be responsible for manually deleting old or non-required data. it will not be able to store a very large number of records. 2. waiting list .At least 256 MB of RAM and 80 GB on hard disk will be required for running the application. SPECIFIC REQUIREMENTS This section contains the software requirement to a level of detail sufficient to enable designers design the system and testers to test the system. A summary of the major functions hat the software will perform are: (i) (ii) (iii) A login facility for enabling only authorized person to the system. User (with role of a operator) will be able to access passengers details. Technical Expertise: Should be comfortable using general purpose applications on a computer.7 SITE ADAPTATION REQUIREMENTS The terminals at client site will have to support the hardware and software interfaces specified ` above section. he/she will be able to excess only specific modules of the system. database auditing will not be provided. 2.2 PRODUCT PERSPECTIVE in the The system will allow access to only authorized personnel. 2. Due to limited features of DBMS being used. 3. Depending on user’s role.1.4 CONSTRAINTS (i) (ii) (iii) Since the DBMS being used is MS EXCESS 2000. train schedule.3 USER CHARACTERISTICS (i) (ii) Educational Level: At least graduate should be comfortable with English Language. fine details and view monthly reports. performance tuning features will not be applied to the queries and thus the system will become slow with the increase in number of records being used. 2. Due to limited features of DBMS being used.
The final application packages as an independent setup program that will be delivered to the client.1. age.. (ii) PASSENGERS INFORMATION SCREEN This screen is accessible to the data entry operator... It allows the user with the second role to add/modify/delete/records of passengers. It will allow user to access different screen based upon the user’s role.1. Screen displays train name. 3. Standalone or network-based-not a concern as it will be possible to run the application of any of them. number of seats in the train. (iii) TRAINS INFORMATION SCREEN This screen is accessible to the data entry operator which allows to add/modify/delete train details. passengers name and other details like issue date.1 SYSTEM FEATURES PASSENGERS INFORMATION MANAGEMENT DESCRIPTION The system will maintain record of passengers name. passenger status either in reservation list or in waiting list. time. number of seats of different class of different trains are available. (c) Role.. address.2 HARDWARE INTERFACES (i) (ii) (iii) 3. (iv) ISSUED TICKET SCREEN This screen is accessible to the data entry operator. Various fields available on this screen will be : (a) User ID : Alphanumeric upto 10 characters (b) Password : Alphanumeric of length upto 10 characters. Printer will be requested for printing of monthly reports. .2. The system will allow creation/modification/deletion of new or existing passengers .3 Screen resolution of at least 800X600 is required for complete and proper viewing of screens. allotted seat no. train number. Higher resolution will not be any problem. seat no. controller. their allotted seat no. Support for printer: Proper drivers must be installed and printer connected. and address.2 3. SOFTWARE INTERFACES (i) (ii) (iii) (iv) Any windows based operating system MS EXCESS-2000 as the DBMS for database future release of the application will aim at upgrading to ORACLE-8i to DBMS.. Crystal reports-8 for generating and viewing reports.1. train.This will be the first screen to be displayed..4 COMMUNICATION INTERCACES None 3. seat no. The screen will display the list of passengers. Visual basic for coding developing the software. The user can add’/modify information. The operator can access and modify these details. 3. This screen will display train no. train no.
Seat number and passenger name can not be blank. TRAINS INFORMATION MANAGEMENT DESCRIPTION The system will maintain information about the train name. ERROR HANDLING/RESPNOSE TO ABNORMAL SITUATIONS If any of the above validations/sequencing flow does not hold true. appropriate error messages will be prompted to the user for doing the needful. seat number. appropriate error messages will be prompted to the user for doing the needful. VALIDITY CHECKS (i) (ii) Only user will role of controller or data entry operator can access issued book’s information. The system will allow creation/modification/deletion of new or existing seats.3 ISSUED TICKETS MANAGEMENT The system will maintain information about seats that are issued. ERROR HANDLING/RESPONSE TO ABNORMAL SITUATIONS . b. VALIDITY CHECKS (i) (ii) (iii) 3. 3. Date of issue must be entered as a six digit number. Every seat has a unique number. class and train name can not be blank. SEQUENCE INFORMATION Ticket information will be present in the system before it can be issued. ERROR HANDLING/RESPONSE TO ABNORMAL SITUATIONS If any of the above validations/sequencing flow does not hold true.2.2 Only user with controller or data entry operator will be authorized to access the passengers information management module. train number.2. The issue details must be present before the seat is cancelled. Number of seats in a.SEQUENCING INFORMATION Passenger information for a particular passenger will have to be entered before any enquiry details. and general class category. SEQUENCE INFORMATION Passenger information and seat information must be entered before a seat can be allotted . Seat number. VALIDITY CHECKS (i) (ii) (iii) Only user with role of controller or data entry operator can access this module. cancellation details can be entered for the student. Corresponding passenger details and date of issue. Every passenger will have allotted a unique ticket number.
appropriate error messages will be prompted to the user for doing the needful.3. 3.3 PORTABILITY The application will be easily portable on any WINDOW based system that has MS-ACCESS 2000 installed.5 3.2. address.1 Date of return should be a valid six digit number.4 CANCEL TICKET INFORMATION MANAGEMT DESCRIPTION The system will calculate refundable amount to passenger after suitable deductions.5.4 DESIGN CONSTRAINTS None 3. sex. (i) (ii) Passenger information : name.7 OTHER REQUIREMENTS None . number of seats in train. Seat information : train number. 3. age. Users will have to enter correct username. VALIDITY CHECKS (i) (ii) (iii) 3. It will be easy to in corporate new requirements in the individual modules . 3.3 3. seat number.If any of the above validations/sequencing flow does not hold true. based on the time with respect to validation of ticket & date of return.1 SOFTWARE SYSTEM ATTRIBUTES SECURITY The application will be password protected. password and role to access the application. 3.6 LOGICAL DATABASE REQUIREMENTS The following information will be placed in a database.5. It cannot be blank Only controller & data entry operator can access this module OTHER REQUIREMENTS PERFORMANCE REQUIREMENTS None 3. 3.5.2 MAINTAINABILITY The application will be designed in a maintainable manner.
USE CASE DIAGRAM Login Enquiry Operator User Booking Cancellation .
Booking. Operator (Login. Cancellation).4 POST-CONDITION If use case is successful. Enquiry. otherwise the system state is unchanged. Enquiry.5 FLOW OF EVENTS 1.1 INTRODUCTION This use case documents the procedure for logging into the Railway Reservation System based on user privileges. User (Login.2 ACTORS Operator. the user is logged into the system.3 PRE-CONDITIONA None 1.5. User 1. 1.USE CASE DESCRIPTION 1. 1. LOGIN 1. Booking.1 BASIC FLOW . Cancellation).
6. ENQUIRY 2. he/she will be logged into the system and presented with operator’s menu. 1. 5.7 RELATED USE CASES None 2. 2. 1. Enquiry for reservation status.6 SPECIAL REQUIREMENTS None 1. Enquiry regarding trains 2. 2. 2.2 ACTORS Operator.5.2 ALTERNATE FLOW 1.This use case starts when actor wishes to log into the Railway Reservation System. 1.5. If the actor is “operator”. Otherwise. The system requests that the actor enters his/her user_id and password.3 PRE-CONDITION Operator must be logged in to the system 2. 4. User.1 INVALID NAME/PASSWORD If the system receives an invalid user_id or password. he/she will be logged into the system and presented with user’s menu. if the actor is “User”. The system validates the user_id and password and checks for his/her privileges.4 POST-CONDITION . The use case ends.2. 3. The actor enters user_id and password. an error message is displayed and the use case ends.1 INTRODUCTION This use case documents the procedure of ENQUIRY for following accounts : 1.
2. 3. 5.2 ALTERNATE FLOWS 2.3 PRE-CONDITION . 4.1 BASIC FLOW The use case starts when a system can get the enquiry from the user.5. User 3. The system checks the type of enquiry 2. The use case ends.then the system shows message according to the query and the use case ends. the user can get information regarding trains.1 INTRODUCTION This use case documents the procedure of booking of tickets and update the database after each transaction . 3. 2.2 ACTOR Operator. BOOKING 3. The resultant information is presented infront of the user.5 FLOW OF EVENTS 2. 2. The controller search the information from the database.reservation Otherwise.5. the system state is unchanged. 1.5.If use case is successful. 3.7 RELATED USE CASES None. The system submits the user query to controller of the system . 2.1 INVALID ENQUIRY If the user enter the wrong details .6 SPECIAL REQUIREMENT None 2.
5.5. 2. The issue details are sent to the printer to generate the tickets.3 PRE-CONDITION Operator/ user must be logged into the system.5 FLOW OF EVENTS 3. 4. 4. 6.and puts the user transaction in waiting state .the system execute the transaction .The system read the information and check the availability of the seats.1 NON -AVAILABILTY If the seats are not available the system sends the message accordingly .Operator/User must be logged into the system 3.5. 3. 4. 4.5. The use case ends.1 INTRODUCTION This use case documents the procedure for canceling of issued tickets according to the customer transaction.4 POST-CONDITION If the use case is successful.If the seats are available . .1 BASIC FLOW 1.2 ACTORS Operator. CANCELLATION 4. 3. The use case end here. User.and according to the priority the seats are allotted to the users .2. the ticket is issued to the passenger . 3. otherwise the system state is unchanged.The resultant information is updated in the data base.2 ALTERNATE FLOW 3.This use case starts when a user enter train name.
5.7 RELATED USE CASES None . The system updates the train reservation status.5. 1.5 FLOW OF EVENTS 4.6 SPECIAL REQUIRMENTS None 4.4 POST-CONDITION If the use case is successful . 4. 2.1 BASIC FLOW This use case starts when a enters the details regarding canceling of tickets.4. 4. The system check the details regarding the query of the customer. The use case ends. 3. the request or recommendation are fulfilled and database is updated accordingly. The system refunds the amount to the user after suitable deductions. The system checks list of waiting passengers and allot the vacant seats. 4.
ACTIVITY DIAGRAM OF LOG IN .
Enter User Name & Password Validation If wrong Enter your correct Password If correct Password Access User Account ACTIVITY DIAGRAM OF BOOKING .
request for a booking check whether a seat is available No Yes add the name in waiting list reserve the seat confirm reservation ACTIVITY DIAGRAM OF CANCELLATION .
get the details for cancellation update train reservation status refund the amount to the passenger after suitable deductions SEQUENCE DIAGRAM : BOOKING .
Operator / User Booking Form Controller Train_detail Sorry message box Passenger detail Passenger Train Detail Enter1: Train name 2: Submit name 3: Get Train Detail 4: Check availability of seats 5: Seat not available 6: Add Record 7: Update Details Update Details 8: 9: Booking Successfully SEQUENCE DIAGRAM : CANCELLATION .
Operator / User Cancellation Form Controller Train Table Passenger Train Detail Table 1: Enter Train Details 2: Submit Details 3: Check Details Cancel4: seat Update table 5: Update table 6: Cancellation successful SEQUENCE DIAGRAM : ENQUIRY .
User / Operator Enquiry Form Controller Train_master 1: Enter Details 2: Submit Details Search 3: 4: Show Train Information SEQUENCE DIAGRAM : LOGIN .
password 2: submit details 3: Get Login details 4: 5: Error or Success Check Login CLASS DIAGRAM : LOGOCAL VIEW .Operator / User Login Form Controller Login_Detail 1: id.
Class(I/II) date Time Add() Delete() Update() GetDetails() Passenger_Details Passenger Name Address Age Phone no. Train Name CLASS DIAGRAM : USE CASE VIEW / LOGIN DETAIL .Login_Detail Username Password Add() Delete() Update() Train_Details Date Time Train Name Available seats(I/II) Add() Delete() Update() GetDetails() Train_Master Train id Train Name Capacity(I/II) Source Destination Time Days Add() Delete() Update() GetDetails() Passenger_Train_Detail Train Name Seat no.
.Login_Detail M Train_Master M Train_Details M M M Passenger_Train_Det.. M M Passenger_Details M M COLLABORATION DIAGRAM : LOGIN .
1: Operator / User Login Form 5: 4: 2: 3: Controller Login_Det ail COLLABORATION DIAGRAM : ENQUIRY 1: Operator /user Enquiry form 2: 4: 3: Controlle -r Train Master COLLABORATION DIAGRAM: BOOKING .
4: 1: Operator /User Booking form 2: Controll-er 9: 7 3: Train Detail 8 5: 6: Sorry Message box Passenger Detail Passenger Train Detail 7: 8: 7 COMPONENT VIEW : MAIN .
boundaries entities Control COMPONENT VIEW : MAIN boundaries entities Control COMPONENT DIAGRAM : CONTROL/MAIN .
Train_ master Train_ Details Passenge r_Details Passenger_T rain_Details COMPONENT DIAGRAM : ENTITIES / MAIN Login_details E –R DIAGRAM .
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.