0% found this document useful (0 votes)
150 views16 pages

SRS

Uploaded by

Aparna Shukla
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
0% found this document useful (0 votes)
150 views16 pages

SRS

Uploaded by

Aparna Shukla
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
You are on page 1/ 16
PabLic 8 < on a ea le bad Gandhi Institute of Technology and Management, Bangalore This is to certify that Team-#14 has successfully designed a Software Requirements Specification(SRS) report and the UML diagrams required, for the project “Railways Tracking & Arrival Time Prediction System” by exploring various methods of Software design & understanding every aspect of the report to the fullest of their knowledge under the Guidance and Support of Mr.Abdul Javeed Prepared by : > Tunir Bhattacharya (Team Lead) >Keerthi B > Harshith N > Mittapalli Prathyusha Date of Submission : 29.10.2021 Subject Teacher - Mr.Abdul Javeed “Railways Tracking & Arrival Time Prediction System” System Requirements Specification(S! Report Team: #14 Team lead - Tunir Bhattacharya (321910302054) ‘Team Members © Keerthi B (321910302055) © Harshith N (321910302056) © Mittapalli Prathyusha (321910302057) Table of Contents : > INTRODUCTION © Objective © Scope © Glossary > OVERALL DESCRIPTION © Product Perspective © Product Functions © User Characteristics © Assumptions and Dependencies > REQUIREMENT SPECIFICATION © Functional Requirements m Performance Requirements a Design Constraints = Hardware Requirements m Software Requirements = Other Requirements © Non-Functional Requirements m= Security m= Availability a Reliability = Maintainability m= Supportability > SYSTEM ARCHITECTURE > CONCLUSION > REFERENCES 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). This is a documentation of the project “Railways Tracking & Arrival Time Prediction System” done sincerely and satisfactorily by my group members. Objective: It has happened so many times that you have been waiting at the railway station for someone to arrive and you don’t have any exact information about train timing and other stuff. Here we present to you a project on Railway Tracking and Arrival Time Prediction. Using this system user’s can get the information about train timings and is it on time or not. This system will track the train timing at what time the train departed from a particular station and pass these timing details to another station’s system where it will display the timing according to the train departed from the previous station. If the system finds any delay in the train due to a signal it will automatically update the train timing in the next station and will be displayed to viewers. Scop “Railways Tracking and Arrival Time Prediction System” is an attempt to simulate the basic concepts of an online Tracking system. The system enables to perform the following functions: > Tracking the Train > Timing Details of the Train > Expected Arrival and Departure Timings of the Train — Improved and Optimised Service > Remote Deployment to Travellers > Time Saving Intended Audience:- e Passengers travelling in train (any age group) e Customers who are in the Station for pickup e Passengers who have a linked train to board Glossary: This should define all technical terms and abbreviations used in the document: > NTES - National Train Enquiry System > SRS - Software Requirements Specifications 7 ART - Accident Relief Trains > UML - Unified Modelling Language > ETA - Estimated Time of Arrival OVERALL DESCRIPTION This document contains the problem statement that the current system is facing which is hampering the growth opportunities of its makers/developers. 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 systems. Product Perspect! The system has the following loopholes: > The existing system is highly manual involving a lot of paperwork and calculation and therefore may be erroneous. This has led to inconsistency and inaccuracy in the maintenance of data. Since the number of passengers have drastically increased therefore maintaining and retrieving detailed records of passengers is extremely difficult. This System is thus proposed with the following perspective: > This system is Computerized hence, The passenger can easily retrieve the ETA and any required addition, deletion or updation can be done. > The system provides for user-ID validation, hence unauthorized access is prevented. > The machine performs all calculations. Hence chances of error are nil. Product Functions: The major functions of this system that makes it relatively simple and user friendly are: > LOGIN/REGISTER: Administrator -- The whole system is controlled by an administrator, administrator login into the system by giving his authentication details such as username and password. After login into the system, he can see the trains currently available to the passengers. The train details are Train name, arrival/departure timings, destination, seat availability and running days. An administrator can also add a new train into the databases. @ Passenger/Customer -- The user can login into the system by providing their credential, if a user is new to this application, and doesn't have their credential details such as username and password, he can register as a new member in this system by registering. Then they can check the details of timings and ETA for a particular station by entering their respective train details. > SEARCH::- After successfully login into the system, passengers can search the available trains by their requirements. The requirements may be arrival/departure Timings, destination, journey date. The list of available trains is shown to the user. Then the user may select the train that suits his/her timings requirements and check the ETA. If no train is available, then the user may change the journey date, arrival/departure timings or destination. ~ SELECTION:- This function allows a particular train to be selected from the displayed list. All the details of the train are shown :- @ Train Name/Number Date, Time, Place of Arrival/Departure @ Train Running Duration Number of Stoppages @ Train Running Status @ Train ETA in a particular Station(as per the passenger requirements) > TRACKING:- The passenger has the option to track the Trains in real time. The train's physical location will show in the map with the place the train is travelling currently. Passengers can select a particular train, and then train details such as previous station, next station, train start date and expected time to reach the next station are shown to the user.The trains currently running on time will be shown in Green colour and trains currently running late will be shown in Red colour. User Characteristics: This Section purely satisfies the comfortness of the Customer/Passenger. > Educational Level:- At least users of the system should be comfortable with English or Hindi languages. > Technical Expertise:- At least users of the system should be comfortable using general purpose applications on the computer system or Mobile phones. Assumptions and Dependencies: > Passengers/Customers and Admin will be having a valid username and password to access the Software. > The Software needs the Admin to have complete knowledge of the Railway tracking System. > Software is dependent on access to the internet. REQUIREM: ECIFICATION Functional Requirements: > Performance Requirements:- User Satisfaction -- The system is such that it stands up to the user's expectations. Response Time -- The response of all the operations 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 Constraints:- 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. 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. @ 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 behavior in the face of certain kinds of faults are specified. Recovery requirements are often an integral part here, detailing what the system should do if 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: @ Processor -- Pentium IV @ Hard disk drive -- 80 GB @ RAM -- 256 MB @ Cache -- 512 kb @ Floppy Drive -- 1.44 MB @ Monitor -- 15 VGA Color ® Mouse -- Logitech > Software Requirements: @ Operating System -- Windows xp,7,8 or higher version @ Tool Kit -- Android 2.0 Latest Version @ IDE -- Android Studio @ Internet -- LAN Connection @ Coding Language -- JAVA 1.6 or Python @ Running Device -- Android Mobile 2.2 to Latest Version/ Computer system Windows xp to Latest Version > Other Requirements: The system should satisfy the following requirements as well, @ Flexibility @ Testability @ Efficiency @ Reusability Non-Functional Requirements: > Security:- 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 the container and its underlying operating system. > 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 being accessed by 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, 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 helps System Requirements. SYSTEM ARCHITECTURE We strongly believe that the correct combination of latest information and communication technologies can provide an effective and feasible solution for the requirement of a reliable and accurate train tracking system to improve the efficiency and productivity of Indian Railways. The solution we propose encompasses a powerful combination of mobile computing, Global System for Mobile *communication (WIRELESS), Global Positioning System (GPS), Geographical Information System (GIS) technologies and software to provide an intelligent train tracking and management system to improve the existing railway transport service. All these technologies are seamlessly integrated to build a robust and scalable architecture. Desktop Agcess ge Le | (DG) ah — cs J-aee A Ax std GSM Network = control ~~ T “A Train Controllers Centre \n-train GPs m n-train GPS/GSM module ee ai CONCLUSION SRS helps the customers to define their needs with accuracy, while it helps the development team understand what the customers need in terms of development. Investing time in writing the SRS document will lead to the successful development of the software the customers need. Based on our SRS, We will be able to develop our software for tracking the timing details of Trains using the unified model of software development. Our further steps will be analysing the design process and then testing and debugging as per the requirements for which we will be making use of JAVA/PYTHON and HTML with JAVASCRIPT. Succeeding in the above mentioned steps will lead to the deployment of our software which will be able to overcome all the flaws of previous such softwares and will satisfy the customer needs to the fullest. The example view of our Software:- Train Enquiry Center & Train Status > EB PNR Status 99 iz d © Trains b/w Time Ticket View Stations Table Availability More Live Train Status Map View Time Table Coach Pos Acro! Station ras pad ee WP tecraena SC @ Secunderabad Jn° eo 070s 7oskm | PFW ova 0708 Delay a o72s KZJ @ ~~ Kazipet Jn°7 case scree ees eet 08:59 Delay 1m 0704 Cee ae ) °e err © | BR Monarashtra Next stop 90kmstogo GID 1s REFERENCES > www.google.com > wwwairetc.co.in > www.nationaltrainenquirysystem.com > www.indianrail.gov.in academia.edu > www.railyatri.com 16

You might also like