Session 3

This session produces the Software Requirements Specification (SRS) for the Railway Reservation System (RRS) whose scope you wrote in Session 1 and whose size you estimated in Session 2. The SRS is the contract between the people who want the system and the people who will build it. Every design decision in Sessions 5 and 6, every test case in Session 8, and the program in Session 13 must point back to a numbered requirement on this page. If a requirement is missing or vague here, the mistake travels through every later session and costs the most to fix.

Objectives

• Write an SRS in the IEEE 830 shape that the manual (section 1.3.2) asks for.
• State each functional requirement as one numbered, testable “shall” sentence.
• Cover all eight RRS modules and every business rule of the case study.
• Write non-functional requirements with numbers, not adjectives.
• Build a traceability table so later sessions can cite requirement IDs.

Problem Statement

Develop SRS (Software Requirements Specification) for the Railway Reservation System (RRS).

Concept

What an SRS is for

The scope statement (Session 1) says what the product is. The SRS says exactly what it must do, from the outside, without saying how. Designers read it to build the system. Testers read it to write test cases. The customer reads it to sign off. So it must be complete (nothing important left out), consistent (no two requirements contradict), unambiguous (one reading only), and verifiable (you can run a test that passes or fails).

The IEEE 830 shape

The manual gives the IEEE format: Introduction, Overall Description, Specific Requirements, Appendices. Section 1 tells the reader why the document exists and how to read it. Section 2 gives the background that makes the requirements understandable: who the users are, what the product sits next to, what limits apply. Section 3 is the real content: every requirement, numbered. Nothing in sections 1 and 2 is a requirement; if a sentence there says “shall”, move it to section 3.

Writing one requirement

A good requirement has the pattern: The system shall <verb> <object> <condition>. One requirement per sentence. Use “shall” for mandatory, “should” for desirable. Avoid “user friendly”, “fast”, “secure”, “etc.” because no test can check them. Compare:

Functional versus non-functional

Functional requirements (FR) describe behaviour: input, processing, output. Non-functional requirements (NFR) describe qualities of the whole system: speed, security, uptime, ease of use, ease of change. Both get IDs. Here the FR ID is FR-<module>.<number>, so FR-4.3 is the third requirement of module 4 (Booking). NFRs are NFR-<letter><number>, for example NFR-P1 for performance.

Traceability

Traceability means every requirement can be followed forward to the design element, code, and test that satisfy it, and backward to the scope item or user need it came from. The table at the end of the SRS is the start of that chain. In Session 4 the DFD processes are numbered 1.0 to 8.0 to match the modules, so FR-4.x maps to process 4.0.

Software Requirements Specification

Software Requirements Specification for the Railway Reservation System (RRS) Version 1.0, prepared for MCS-217 Session 3.

1 Introduction

1.1 Purpose

This SRS states the functional and non-functional requirements of the Railway Reservation System (RRS). It is written for the designers who will produce the modular design (Session 5) and user interface design (Session 6), the testers who will derive test cases, and the developers who will implement the system (Session 13). It also serves as the agreed statement of what the customer will receive.

1.2 Scope

The RRS is a web-based system through which passengers search trains, check seat availability, book and cancel tickets, and pay online; reservation clerks book and cancel at counters; and administrators maintain trains, routes, coaches, fares, and schedules and view reports. The system generates a unique PNR for every booking, maintains a waitlist per schedule and class, applies time-based refund rules on cancellation, and sends SMS and email notifications through an external service. Out of scope: Tatkal quota, concession categories, catering, parcel booking, and integration with the national railway network.

1.3 Definitions, acronyms and abbreviations

1.4 References

• IEEE Std 830-1998, Recommended Practice for Software Requirements Specifications.
• Statement of Scope for RRS, Session 1.
• Effort and cost estimate for RRS, Session 2.
• MCS-213 Software Engineering, Block 1 (Requirements Analysis).

1.5 Overview

Section 2 describes the product, its users, environment, constraints and assumptions. Section 3 lists the specific requirements: functional requirements by module, external interfaces, and non-functional requirements. Section 4 gives the traceability table.

2 Overall Description

2.1 Product perspective

The RRS is a new, self-contained system. It replaces manual counter registers and a spreadsheet-based seat chart. It depends on two external systems: a Payment Gateway for online payment and a Notification Service for SMS and email. It stores all data in a single relational database shared by the web application and the counter application.

  Passenger (browser)        Reservation Clerk (counter PC)      Administrator (browser)
         |                              |                                  |
         +------------------------------+----------------------------------+
                                        |
                                 +-------------+
                                 |     RRS     |----------> Notification Service (SMS, email)
                                 | web server  |
                                 +-------------+<---------> Payment Gateway
                                        |
                                 +-------------+
                                 |  Database   |
                                 +-------------+

2.2 Product functions

The eight modules and their main functions:

2.3 User classes and characteristics

2.4 Operating environment

• Server: Linux, Python 3 web application, PostgreSQL 14 or later database.
• Client: any browser released in the last three years, desktop or mobile, no plug-ins.
• Counter PC: same browser client on the railway intranet, with a receipt printer.
• Network: HTTPS over the public internet for passengers; intranet for clerks and administrators.

2.5 Design and implementation constraints

• Card numbers and CVV shall never be stored; all card handling happens on the gateway page.
• All timestamps are stored in Indian Standard Time.
• The database is the single source of truth for seat allocation; no seat map is cached on the client.
• The system must run on the hardware already available at counters (4 GB RAM PCs).
• Development effort is bounded by the Session 2 estimate (225 adjusted FP, about 13,500 LOC).

2.6 Assumptions and dependencies

• The Payment Gateway responds within 5 minutes to every payment request, with a final SUCCESS or FAILURE.
• The Notification Service accepts messages through an HTTP API and reports delivery status.
• Station codes, train numbers, and routes are supplied by the administrator from official railway data.
• One train runs at most once per day, so (train_no, run_date) identifies a schedule.
• Fares depend only on train, class, and distance; no dynamic pricing.

3 Specific Requirements

3.1 Functional requirements

Priority: M = must have, S = should have.

Module 1: User Management

Module 2: Train and Schedule Management

Module 3: Search and Availability

Module 4: Booking

Module 5: Cancellation and Refund

Module 6: Payment

Module 7: Notification

Module 8: Reports

3.2 External interface requirements

User interfaces

Every screen shall work at 360 px width (phone) and 1280 px width (desktop). Every error shall say what was wrong and what to do.

Hardware interfaces

• Receipt printer at counters through the browser print dialog; the ticket page shall have a print layout on A5 paper.

Software interfaces

Communication interfaces

• All browser traffic over HTTPS with TLS 1.2 or later.
• Gateway and notification calls authenticated with API keys kept in server configuration, not in source code.

3.3 Non-functional requirements

4 Requirements traceability

Non-functional requirements apply across modules: NFR-S1 to NFR-S4 trace to the security paragraph of the scope; NFR-A1 and NFR-A2 to “twenty-four-7 accessibility”; NFR-U1 to NFR-U3 to “user friendly, simple interface” and “multilingual”.

Viva Questions

• Q: What is the difference between the scope statement and the SRS? A: The scope says what the product is and its boundary; the SRS states every requirement precisely enough to design and test against.
• Q: Why must a requirement be verifiable? A: Because a tester needs to write a test that clearly passes or fails; “the system should be fast” cannot be tested.
• Q: What does “shall” mean in an SRS? A: A mandatory requirement; “should” marks a desirable one.
• Q: Where in the IEEE 830 format do functional requirements go? A: Section 3, Specific Requirements; sections 1 and 2 give context only.
• Q: Give one non-functional requirement of the RRS with a number in it. A: NFR-P1: search results within 2 seconds for 95 percent of requests at 500 concurrent users.
• Q: What is traceability? A: The ability to follow a requirement forward to design, code, and tests, and backward to the need that produced it.
• Q: Why is the refund rule in the SRS and not left to the design? A: It is a business rule the customer must agree to; the design only decides how to compute it.
• Q: What are the external interfaces of the RRS? A: Browser user interface, receipt printer, database, Payment Gateway API, Notification Service API.
• Q: What happens if a payment fails after seats are held? A: FR-6.4 and FR-4.7: the payment is marked FAILED and the held seats are released after the 10-minute hold.

Common Mistakes

• Writing the SRS as a feature list of one-line bullets without IDs; then no later session can refer to a requirement.
• Mixing design into requirements (“the system shall use a hash table for seats”). Say what, not how.
• Non-functional requirements without numbers: “secure”, “reliable”, “user friendly” are wishes, not requirements.
• Leaving out the business rules (refund bands, max 6 passengers, no booking after departure). These are the requirements a viva examiner asks about first.
• Forgetting the external actors. Payment Gateway and Notification Service are not users, but their interfaces must be specified.
• Two requirements that contradict each other, for example one saying search needs login and another saying it does not. Read the whole list once for consistency before submitting.

Session Summary

• Problem statement copied verbatim.
• SRS sections 1 and 2: introduction, definitions table, product perspective diagram, product functions table, user classes table, environment, constraints, assumptions.
• Section 3.1: functional requirements tables for all eight modules, FR-1.1 to FR-8.5, each a single testable “shall” sentence with priority.
• Section 3.2: user, hardware, software, and communication interfaces.
• Section 3.3: non-functional requirements NFR-P, S, R, A, U, M, each with a measurable value.
• Section 4: traceability table from modules and FR ranges to scope items and DFD processes.