Muhammad Saqib Ali SE SRS

Submitted By:
Muhammad Saqib Ali Malik

Roll Number:
ITF11206
Submitted To:
Sir Muhammad Arif
Date:
Thursday, May 9, 2024
Software Requirements
Specification
for
Android Local Train Ticketing

System
Version 15.1.36 approved
Prepared by Muhammad Saqib Ali Malik
National University of Modern Languages, Islamabad
Thursday, May 9, 2024
Copyright © 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.
Software Requirements Specification for Android Local Ticketing System Page ii
Table of Contents
Table of Contents .......................................................................................................................... ii
Revision History ............................................................................................................................ ii
1. Introduction ..............................................................................................................................3
1.1 Purpose............................................................................................................................................. 3
1.2 Document Conventions .................................................................................................................... 3
1.3 Intended Audience and Reading Suggestions .................................................................................. 3
1.4 Product Scope .................................................................................................................................. 3
1.5 References ........................................................................................................................................ 4
2. Overall Description ..................................................................................................................4
2.1 Product Perspective.......................................................................................................................... 4
2.2 Product Functions ............................................................................................................................ 5
2.3 User Classes and Characteristics ..................................................................................................... 5
2.4 Operating Environment .................................................................................................................... 5
2.5 Design and Implementation Constraints .......................................................................................... 5
2.6 User Documentation ........................................................................................................................ 6
2.7 Assumptions and Dependencies ...................................................................................................... 6
3. External Interface Requirements ...........................................................................................7
3.1 User Interfaces ................................................................................................................................. 7
3.2 Hardware Interfaces ..................................................................................................................... 113
3.3 Software Interfaces ...................................................................................................................... 113
3.4 Communications Interfaces ........................................................................................................... 14
4. System Features ...................................................................................................................114
4.1 System Feature 1 .......................................................................................................................... 114
5. Other Nonfunctional Requirements ...................................................................................115
5.1 Performance Requirements .......................................................................................................... 115
5.2 Safety Requirements .................................................................................................................... 115
5.3 Security Requirements ................................................................................................................. 115
5.4 Software Quality Attributes ......................................................................................................... 115
5.5 Business Rules ............................................................................................................................. 116
6. Other Requirements ..............................................................................................................16
Appendix A: Glossary..................................................................................................................16
Appendix B: Analysis Models .....................................................................................................16
Appendix C: To Be Determined List ..........................................................................................17
Revision History
Name Date Reason For Changes Version
Software Requirements Specification for Android Local Ticketing System Page 3
1. Introduction
1.1 Purpose
The purpose of this source is to describe the Android Local Train Ticketing System which provides the
train timing details, reservation, billing, cancelation on various types of reservation namely.
• Confirm Reservation for confirm Seat.
• Reservation against Cancellation
• Waiting list Reservation.
• Online Reservation.
• Tatkal Reservation
1.2 Document Conventions

The Document Is Made Using Calibri Where:
• Main Section Are Indicated with Bold Letters Font 14
• Subsections Also Bolded with Font 14.
• Writing style is Arial and Font size is 11.
An Appendix A Is Added for Acronyms and Abbreviations
1.3 Intended Audience and Reading Suggestions

This document is intended to be read by the customer. This is A technical document and the terms should
be understood by the customer. The designer needs to understand this document fully so that they can
draft A design document using this SRS presented to them by the analyst.
The different types of readers are

• Customer
• Developers
• Management
• Passengers
• Counter clerk
1.4 Product Scope

• All the manual work should be converted into computerized so that the load of employees should
decrease.
• The database should be stored in computer rather than in register/manually.
• The train ticketing software is an easy-to-use self-service system which enables the customer buys
train ticket online.
• After process buys train ticket is successfully, the customer can get the train ticket by print out the
train ticket.
• Freight Revenue enhancement.
• Passenger Revenue enhancement.

• Improved & optimized service.
1.5 References
Sections of this document are based upon the IEEE guide to Software requirements specification (IEEE
830).
Chen, X., & Li, L. (2019). Research on the design and implementation of an android-based train ticketing
system based on NFC technology. [Research Report]
Sandakan, N., Dipti, R., & Pandey, S. (2013). 2013 Android Railway Ticketing with GPS as Ticket
Checker. In Proceedings of National Conference on New Horizons In IT-NCNHIT.
Chaudhari, A., Rodrigues, B., Sakhare, P., & Fernandes, C. (2015). Prototype for intelligent ticketing
system using NFC. In 2015 International Conference on Green Computing and Internet of Things
(ICGCIoT), 877-880. IEEE.
Liu, X., & Zhang, L. (2021). Research on the design and implementation of an android-based local train
ticketing system based on facial recognition technology. Journal of Advanced Transportation, 2021.
Link
2. Overall Description
2.1 Product Perspective

This subsection should relate the requirements of that larger system to functionality of the software and
should identify interfaces between that system and the software. A block diagram showing the major
components of the larger system, interconnections, and external inter-faces can be helpful.
The online ticket reservation system involves two actors, the administrator and the passenger. The
administrator controls the communication and services. The database system manages for application and
financial information. Passenger communicates with system to reserve train tickets, cancel train tickets,
view and print tickets.
2.2 Product Functions

A summary of the major functions that the software will perform. The key features of this system can be
abstracted as follows.
• User Registration and Authentication

• Train Schedule and Route Information
• Ticket Booking and Reservation
• Seat Availability and Fare Calculation
• Payment Integration
• Ticket Cancellation and Refunds
• Passenger Information and Ticket Management
• Notification and Alerts
• Provide train ticket to view and print.
• Provide process to cancel reserved train ticket.
• Provide Admin to control the accounts, update seat and fares.
• Integration with Other Services
• Feedback and Support
2.3 User Classes and Characteristics

This subsection of the SRS should describe those general characteristics of the intended users of the
product including educational level, experience, and technical expertise. Users are students and admin.
Their characteristics:
• The user should be familiar with the Internet.
• User should be computer literate.
2.4 Operating Environment

The online ticket reservation system is an internet-oriented application, it set to operate on a high available
and QOS network, since registration is a sensitive thing, the quality of the network should be Good for this
process. Mostly a device that can access the internet and can support a huge web application for
registration. Any OS can support this system as it is not particularly software or hardware dependent.
2.5 Design and Implementation Constraints

The system is internet-based system, a webapp that should be developed to support any web browser to
be used. Passenger Account and Payment for train ticket should be secure, the system design should
include a lot of DB and SYSTEM validation. Developers needs to be always there to support the
delivered system in terms of validation and maintenance.
2.6 User Documentation

The Online ticket reservation website or apps should provide a help on how to use an online ticket
reservation application. Users of the system will be guided by the system all the way when registering. The
user documentation components could include:
• User Manual: A detailed guide covering all aspects of using the ticketing system. It should include
instructions on how to download and install the app, create an account, browse events, purchase
tickets, manage orders, and any other relevant features. Screenshots or illustrations can enhance
clarity.
• Onboarding Tutorial: A step-by-step tutorial aimed at guiding new users through the initial setup
process and familiarizing them with the app's interface and functionality. This can help users get
started quickly and efficiently.
• FAQs (Frequently Asked Questions): A document addressing common queries and issues users
may encounter while using the ticketing system. This could cover topics such as account
management, payment methods, event search, ticket delivery, refunds, and troubleshooting tips.
• Online Help: In-app assistance accessible from within the application. This could include tooltips,
contextual help buttons, or a searchable help database to provide users with immediate assistance
when they need it.
• Accessibility Guidelines: Documentation outlining accessibility features and options available in

the app for users with disabilities. This could include information on screen reader compatibility,
text resizing, color contrast, and other accessibility settings.
• Release Notes: Documentation detailing the changes, updates, and bug fixes in each version of
the application. This helps users stay informed about new features, improvements, and any known
issues that have been addressed.
• Delivery Formats/Standards: The documentation may be provided in various formats such as

PDFs, online web pages, or integrated within the mobile app itself. It should follow standard
documentation practices, ensuring clarity, consistency, and ease of access for users. Additionally,
it's essential to adhere to relevant Android design and usability guidelines to provide a seamless
user experience.
2.7 Assumptions and Dependencies

The assumptions and dependencies relevant to the system are as follows.
• All users have a computer or any web enable device
• User should have internet access.
• The user must have access or be on a reliable network.
• Administrator should have been employee of the Railway.
• Passengers are provided ticket only if seats are available.
3. External Interface Requirements
3.1 User Interfaces

The user is going to interact with the system through different interfaces. Listed below are the different
components of user interfaces under their respective headings:
• Passenger log-in / create profile
• Ticket reservation process.
• Ticket cancellation process.
• View and print
• Admin login-in
• Seats and Fares updating process
Home page:
Fig.1.0
Passenger log-in / create profile:
Fig.2.0
Fig.2.1
When the client presses “Sign In” Button (Fig.1.0), Client will divert to Client Sign- In Page as appeared in
(Fig.2.0).
When the client presses “Sign Up” Button in (Fig.1.0), Client will divert to Client Sign-Up Page as
appeared in (Fig.2.1).
On the off chance that the Client is unused to the Framework, he / she needs confirm their mail by entering
the OTP — One Time Watchword sent on their entered Mail ID. They can moreover inquire the site to re-
send them a modern produced OTP. (Fig.2.2)
Fig.2.2
Main/ Informative Pages:
When the user presses “Search” Button after selecting Source Station and Destination Station along with
Date of Journey in (Fig.1), User will redirect to Available Trains Page along with Total number of trains.
(Fig.3.0).
Fig.3.0
After Displaying Available Trains, User can select Train of his/her Choice and will ask to enter Passenger
details. A User can book Ticket for Maximum 3 Passengers at a Time. All Passenger Details are stored for
reference of Passenger. (Fig.3.1)
Fig.3.1
Payment and Ticket Confirmation:
Once Client has entered all subtle elements for Traveler, and clicking the “Submit” button, Information will
be put away, and Prepare Subtle elements will be appeared to Client. (Fig.4.0) Once orally affirming the
subtle elements, Client can proceed towards Ticket Installment Segment (Fig.4.1)
Fig.4.0
After affirming points of interest, Client can make installment through Credit Card, by entering his/her
Credit Card Points of interest, looking over down the page. It'll be last installment for Ticket. (Fig.4.1)
Fig.4.1
After Completion of Installment, Client will be appeared a last See of Ticket that has been produced for
User's Travel (Fig.4.2). Client will to get a duplicate of Ticket Points of interest by means of Enrolled E-mail
of Client Itself (Fig.4.3).
Fig.4.2
User Profile and History Section:
User Profile is useful for Displaying User details that can be helpful for verification, or just Confirmation by
User itself. The User can also Change his/her password by Clicking the “Change Password” Button.
(Fig.5.0)
Fig.5.0
Your booking history shows all the tickets you've booked, along with the total number of tickets. You can
also find a "Forgot Password" option at the top left of the page, which lets you change your password if
needed. (Fig.5.1)
Fig.5.1
Admin Panel — Managing the Train Data:
The Admin Panel is a functionality exclusively designated for Administrators. It is not intended for end-user
interaction. Access to the Admin Panel is restricted to authorized personnel by entering special credentials
specifically designated for Administrators.
Fig.6.0
3.2 Hardware Interfaces

Minimum Hardware Requirements: The system will run on different hardware gadgets. Below are the
minimum hardware Requirements for the smooth running of the system:
• 1GB RAM PC
• 1.8Hz processor
• 14” color monitor
• 120GB HDD CPU
• Proper running internet
3.3 Software Interfaces

Train/Ticket Inventory/Database System
• Transmission and Storage of Ticket Properties: The system should be able to receive and store
detailed properties of ticket items such as quantities, train number, departure/return time/date,
seat, and location.
• Availability Updates: The system should maintain updated information about the availability of
tickets and train information to determine if a requested reservation is available or not.
• Query Response: When the Railway Reservation System (RRS) makes a query about ticket
information with constraints, the system should provide all information that satisfies the query.
• Information Update Operations: The system should accept information update operations
coming from the administrator interface system, such as adding new trains, updating ticket
availability, or modifying train schedules.
User Query/View System:
• Query Posting: Users should be able to post various queries about ticket information available at
present. They should have the flexibility to use any combination of available criteria.
• Result Display: The system should display the resulting list of queries to users, allowing them to
further sort the list by subfields of ticket information (e.g., price). The view should be user-friendly
and flexible.
• Reservation Placement: Users should be able to place reservations for tickets through the
system.
• Conflict Detection: The system should detect conflicts if a user attempts to place two incompatible
reservations, such as overlapping time slots or unavailable seats.
• Reservation Viewing: Users should be able to view their reservations through the system.
• Reservation Modification: Users should be able to modify their reservations, such as changing
the date or time of travel or upgrading their seat.
• Account Management: Users should be able to manage their accounts within the Railway
Reservation System, including updating personal information, changing passwords, or viewing
transaction history.
3.4 Communications Interfaces

The main Communication Interfaces link that the system will be using is Internet.
4. System Features
The Online Ticket Reservation System comprises of two main features, namely, internet connectivity
which will enables users to communicate with the server through a browser or web agent, and secondly
the system requires database service to store the user’s data. In a nutshell this system is web application
and thus is only operational in an internet enabled environment.
4.1 System Feature 1

Ticket Booking and Reservation Management
4.1.1 Description and Priority

This feature allows users to search for, book, modify, and cancel train tickets. It is of high
priority as it forms the core functionality of the Android Local Ticketing System.
4.1.2 Stimulus/Response Sequences
• User opens the ticketing app and navigates to the booking section.
• System displays a search interface for users to input travel details such as date, time,
origin, and destination.
• User enters search criteria and submits the request.
• System retrieves and displays a list of available trains and tickets based on the user's input.
• User selects desired options and proceeds to booking.
• System prompts user to enter passenger details and payment information.
• System confirms successful booking and issues a booking reference number.
4.1.3 Functional Requirements

REQ-1: The system shall be internet oriented and require an online server.
REQ-2: The system shall save the passengers’ details to a remote database service .
Req-3: The system shall allow passengers to register and to log in their account.
REQ-4: The system will allow passenger to reserve train tickets.
REQ-5: The system will allow passenger to cancel their reserved train tickets.
REQ-6: The system will allow passenger to view and print train ticket.
REQ-7: The system will allow admin to manage passengers account, updates trains list, seats
and fare.
5. Other Nonfunctional Requirements
5.1 Performance Requirements
• All Web pages generated by the system shall be fully downloadable in no more than 10
seconds over a 40KBps modem connection.
• Responses to queries shall take no longer than 10 seconds to load onto the screen after the
user submits the query.
• The system shall display confirmation messages to users within 4 seconds after the user submits
information to the system.
• The system is required a fair amount of speed especially while browsing through the trains list and
availability of seats.
• The database shall be able to accommodate a minimum of 100000 records of passengers.
• The software will support multiple users.
5.1.1 Variety of compartments based on comfort:
1. AC first-class
2. A sleeper
3. First class
4. AC three tier
5. sleeper class
6. Ordinary chair car
5.2 Safety Requirements

The System is required provide a protection of the database.
Examples are:
• Data Encryption
• Secure Authentication
• Protection against Malicious Activities
• User Privacy
• Transaction Security
• System Reliability
• Compliance with Regulatory Standards
5.3 Security Requirements

The main security concern is for users’ accounts and payment details, hence proper login Mechanism
should be used to avoid hacking. The online ticket reservation system shall not disclose personal
information of passengers to unauthorized users or the public.
5.4 Software Quality Attributes

The database will have to be available to passengers 24/7.
5.5 Business Rules

• The online ticket reservation system shall include two types of accounts: the administrators and the
passengers.
• To log in to the system user name and password is required.
6. Other Requirements
No Other Requirements.
Appendix A: Glossary
❖ DB: Database
❖ SQL: simple query language
❖ Admin: Administrator
❖ SRS: software requirements specification
❖ Webapp: web application
❖ RAM: random access memory
❖ PC: personal computer
❖ CPU: Central processing unit
❖ OS: operating system Software
Appendix B: Analysis Models

Data Flow Diagram:
A Data flow diagram (DFD) is a visual representation of the information flow through a process or system.
Appendix C: To Be Determined List

Appendix C: To be Determined Lits
• TBD-001: Define criteria for event approval process.

• TBD-002: Specify supported payment methods and associated fees.
• TBD-003: Determine data retention policies for customer information.
• TBD-004: Clarify requirements for mobile ticket scanning functionality.
• TBD-005: Identify third-party APIs for geolocation services.
• TBD-006: Determine system requirements for offline ticketing mode.
• TBD-007: Specify error handling procedures for payment processing.

Muhammad Saqib Ali SE SRS

Uploaded by

Copyright:

Available Formats

Muhammad Saqib Ali SE SRS

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Muhammad Saqib Ali SE SRS

Uploaded by

Copyright:

Available Formats

Submitted By:

Muhammad Saqib Ali Malik

Android Local Train Ticketing

Version 15.1.36 approved

Prepared by Muhammad Saqib Ali Malik

National University of Modern Languages, Islamabad

Thursday, May 9, 2024

1.2 Document Conventions

An Appendix A Is Added for Acronyms and Abbreviations

1.3 Intended Audience and Reading Suggestions

The different types of readers are

1.4 Product Scope

• Passenger Revenue enhancement.

2.1 Product Perspective

2.2 Product Functions

• User Registration and Authentication

2.3 User Classes and Characteristics

2.4 Operating Environment

2.5 Design and Implementation Constraints

2.6 User Documentation

• Accessibility Guidelines: Documentation outlining accessibility features and options available in

• Delivery Formats/Standards: The documentation may be provided in various formats such as

2.7 Assumptions and Dependencies

3. External Interface Requirements

3.1 User Interfaces

Passenger log-in / create profile:

Main/ Informative Pages:

Payment and Ticket Confirmation:

User Profile and History Section:

Admin Panel — Managing the Train Data:

3.2 Hardware Interfaces

3.3 Software Interfaces

User Query/View System:

3.4 Communications Interfaces

4.1 System Feature 1

4.1.1 Description and Priority

4.1.3 Functional Requirements

5. Other Nonfunctional Requirements

5.1 Performance Requirements

5.1.1 Variety of compartments based on comfort:

5.2 Safety Requirements

5.3 Security Requirements

5.4 Software Quality Attributes

5.5 Business Rules

Appendix B: Analysis Models

Data Flow Diagram:

Appendix C: To Be Determined List

• TBD-001: Define criteria for event approval process.

You might also like