Requirements Analysis & Specification

Project: Write a Mini-SRS

18 min Lesson 10 of 10

Project: Write a Mini-SRS

Everything you have studied in this tutorial — functional and non-functional requirements, well-formed requirement statements, the SRS structure, user stories with acceptance criteria, MoSCoW prioritisation, validation reviews, change management, and traceability — comes together in one deliverable: the Software Requirements Specification. This capstone lesson walks you through producing a complete, professional mini-SRS for a realistic business scenario. You will see every section populated with real content, and you will understand the decisions made along the way.

The Scenario: CareSlot — A Clinic Booking System

A private multi-specialty clinic, Greenfield Health, operates five doctors across three specialties. Patients currently phone the front desk to book, cancel, or reschedule appointments. The clinic loses roughly 30 bookings per week to missed calls and double-entry errors. Management wants a web-based self-service booking portal. You have been hired as the business analyst. After two stakeholder interviews and a process-observation session, you must deliver a mini-SRS.

Why a real scenario? Abstract examples teach the format; only a concrete scenario teaches the judgement. Notice throughout this lesson how every decision — a choice of priority, a measurable threshold, an acceptance criterion — traces back to something the business stakeholders actually said.

Section 1 — Introduction

The introduction section of a well-formed SRS answers four questions: What is the product? Who are the stakeholders? What is in scope? What assumptions constrain the work?

Product name & purpose: CareSlot v1.0 — a browser-based appointment booking portal for Greenfield Health, enabling patients to self-book, cancel, and reschedule appointments with any clinic doctor.
Intended audience: Patients (primary users), reception staff (power users), clinic manager (reports), IT department (deployment), and this document.
Scope: Patient-facing booking, receptionist back-office view, automated email/SMS confirmations, and a daily appointments report. Out of scope: billing, EHR integration, mobile native app, multi-clinic expansion.
Assumptions: All doctors maintain their own availability calendars. The clinic has a stable internet connection. Patients have access to email. SMS delivery is handled by a third-party gateway already contracted by the clinic.
Dependencies: Third-party SMS gateway API, Google Calendar or equivalent calendar feed per doctor.

Section 2 — Stakeholder Profiles

Before listing requirements, describe who the system must serve. This grounds every feature in a human need.

CareSlot stakeholder map — five stakeholder groups interact with the portal in distinct roles.

Section 3 — Functional Requirements

Use the IEEE 830-style SHALL verb for mandatory requirements. Assign a unique ID to each requirement for traceability.

FR-01 (MUST): The system shall allow a patient to search available appointment slots by doctor, specialty, and date range.
FR-02 (MUST): The system shall allow a patient to book an available slot by providing their name, date of birth, contact phone, and email.
FR-03 (MUST): The system shall prevent a doctor being booked for two overlapping appointments.
FR-04 (MUST): The system shall send a confirmation email and SMS to the patient within 2 minutes of a successful booking.
FR-05 (MUST): The system shall allow a patient to cancel or reschedule their own appointment up to 4 hours before the scheduled time.
FR-06 (SHOULD): The system should send a reminder email and SMS 24 hours before the appointment.
FR-07 (SHOULD): The receptionist should be able to view all appointments for the current day on a single dashboard screen.
FR-08 (COULD): The clinic manager could export a weekly appointments report to CSV.
FR-09 (WON'T): The system will not handle billing or payments in v1.0.

Section 4 — Non-Functional Requirements

NFR-01 Performance: The appointment search results page shall load within 2 seconds under a load of 50 concurrent users.
NFR-02 Availability: The system shall maintain 99.5% uptime during clinic operating hours (07:00–20:00 local time, Mon–Sat).
NFR-03 Security: All patient personal data shall be transmitted over HTTPS (TLS 1.2+). Passwords shall be hashed using bcrypt with cost factor ≥ 12.
NFR-04 Usability: A first-time patient with no training shall be able to complete a booking within 3 minutes, as validated by a usability test with five participants.
NFR-05 Maintainability: The system shall be deployable by a single IT staff member following the written runbook in under 30 minutes.

Section 5 — User Stories with Acceptance Criteria

Complement the formal SHALL statements with user stories so the development team understands the human context. Use the Given-When-Then pattern for acceptance criteria.

US-01 — Book an appointment (MUST)

As a patient, I want to book an appointment with a doctor of my choice so that I can get medical care without calling the clinic.

AC-01a: Given I am on the booking page, when I select a specialty and a date, then I see only available slots (no already-booked or blocked times).
AC-01b: Given I select a slot and submit the form with valid details, when the booking is confirmed, then I receive a confirmation email within 2 minutes containing the doctor's name, date, time, and a unique booking reference.
AC-01c: Given two patients attempt to book the same slot simultaneously, when the second patient submits, then the system rejects the booking with a clear message and offers the next available slot.

US-02 — Cancel an appointment (MUST)

As a patient, I want to cancel my appointment online so that the clinic can reallocate the slot and I am not charged a no-show fee.

AC-02a: Given I enter my booking reference and email, when I request cancellation more than 4 hours before the appointment, then the slot is freed and I receive a cancellation confirmation email.
AC-02b: Given I attempt cancellation less than 4 hours before the appointment, when I submit the request, then the system shows an error explaining the cut-off policy.

US-03 — View daily schedule (SHOULD)

As a receptionist, I want to view all appointments for today on a single screen so that I can greet patients by name and flag no-shows quickly.

AC-03a: Given I am logged in as a receptionist, when I open the dashboard, then I see all appointments for the current calendar day sorted by start time, showing patient name, doctor, specialty, and status.
AC-03b: Given an appointment status changes (cancelled or confirmed late), when I refresh the dashboard, then the updated status is reflected within 30 seconds without a full page reload.

Mini-SRS section hierarchy — from high-level introduction down to traceability and appendices.

Section 6 — Constraints and Assumptions

Constraints are facts the team cannot change; assumptions are facts the team believes to be true but which should be explicitly recorded so reviewers can challenge them.

Technical constraint: The portal must run on the clinic's existing shared Linux hosting (no Docker, no Kubernetes).
Regulatory constraint: Patient data must comply with the national personal data protection law; no data may be stored outside the country.
Business constraint: Go-live is required before the clinic's annual membership renewal drive (8 weeks from project kick-off).
Assumption A1: Each doctor will designate an admin assistant responsible for blocking unavailable slots in the calendar system.
Assumption A2: The third-party SMS gateway will maintain 95%+ delivery success rate during operating hours.

Recording assumptions pays dividends later. When a delayed go-live is blamed on requirements changing, you can often point to an assumption that turned out to be wrong. Explicit assumptions convert "scope creep" conversations into "assumption validation" conversations — far more productive.

Section 7 — Traceability Matrix (Excerpt)

Link every user story back to a functional requirement, and forward to the test case that will verify it. Even a partial matrix is better than none.

| FR ID  | Description               | User Story | Priority | Test Case  |
|--------|---------------------------|------------|----------|------------|
| FR-01  | Search available slots    | US-01      | MUST     | TC-101     |
| FR-02  | Book a slot               | US-01      | MUST     | TC-102     |
| FR-03  | Prevent double-booking    | US-01      | MUST     | TC-103     |
| FR-04  | Confirmation email/SMS    | US-01      | MUST     | TC-104     |
| FR-05  | Patient cancel/reschedule | US-02      | MUST     | TC-105     |
| FR-06  | Reminder notifications    | —          | SHOULD   | TC-106     |
| FR-07  | Receptionist dashboard    | US-03      | SHOULD   | TC-107     |
| FR-08  | CSV export                | —          | COULD    | TC-108     |

Section 8 — Glossary and Revision Log

Even a mini-SRS benefits from a short glossary (define "available slot", "booking reference", "receptionist role") and a revision log (Version 0.1 — Initial draft; Version 0.2 — Added NFRs after stakeholder review). This is the section most junior analysts skip and most senior reviewers look at first.

A common mistake in capstone projects: students write excellent functional requirements but produce vague, unmeasurable non-functional requirements such as "the system shall be fast" or "data must be secure". Every NFR in a production SRS must carry a threshold — a number, a percentage, a time limit, or a verifiable standard. If you cannot test it, it is not a requirement: it is a wish.

Pulling It All Together

Writing even a 10-page mini-SRS forces you to resolve ambiguity before a single line of code is written. For the CareSlot system, the exercise revealed three issues that would have become expensive defects: the 4-hour cancellation cut-off was an undocumented clinic policy; the double-booking prevention logic implied a need for optimistic locking in the database; and the SMS gateway dependency introduced a single point of failure that NFR-02 must acknowledge. None of these emerged from a whiteboard brainstorm — they emerged from the discipline of writing things down precisely.

As you move into your own projects, use this mini-SRS as a template. Scale the number of requirements to fit the complexity of the system. Keep every requirement testable, every assumption explicit, and every priority justified. That discipline is what separates a requirements document that guides a successful build from one that sits in a shared drive and is never opened again.