Software Requirement Specification (SRS) Tutorial and EXAMPLE | Functional Requirement Document

Main ideas and concepts covered

Purpose of an SRS (Software Requirement Specification)

• A formal business analyst document that describes what a software application does and the implications/requirements behind that behavior.
• Acts as a blueprint for design and implementation by the technical team.
• Acts as a communication tool between technical and business stakeholders.

Core requirement types

Functional requirements

• Describe the solution capabilities and behavior under specific conditions.
• Include what information the solution will handle.
• Derived by decomposing stakeholder requirements into system requirements.

Non-functional requirements (NFRs)

• Describe performance/quality characteristics needed for stakeholder satisfaction.
• Typically measurable and act as constraints on the solution.
• Usually apply to the entire system, not just one feature.

Primary audience (who uses the SRS and why)

• Technical team
  • Uses SRS to develop designs and implement the software correctly.
  • Functional requirements should be detailed enough to support unit testing.
• Subject matter expert (SME / “Smee” in subtitles)
  • Reviews SRS for accuracy and completeness.
  • May be relied on for approval testing and sign-off decisions.
• Testing teams (QA / User Acceptance Testing)
  • Use SRS as an outline to build test cases.
  • Help ensure requirements are testable during requirements reviews.

Typical SRS sections/components

• Introduction
• Overall description
• Business rules
• Functional requirements
• Use cases
• Data requirements
• External requirements
• Non-functional requirements
• Reporting requirements
• Supplemental/supporting information

---

Methodology / structure instructions (detailed)

1) What to cover in the SRS (section-by-section guidance)

Introduction

Include:

• Purpose
  • Why the SRS exists
  • Which product it’s for
  • Intended audience
• Project scope
  • Overview of the software being specified
  • Relation to business goals/objectives/expected outcomes

Overall description

Include high-level product view:

• General functionality
• Users of the software
• Operating environment
• Constraints, dependencies, assumptions

Include product perspective:

• Whether the solution is replacing/enhancing an existing system or creating something new
• Key interfaces with the wider system (a context diagram may help)

Include user classes:

• Characteristics/needs/expectations for each user group

Include operating environment:

• Systems/software where it runs (OS versions, databases, hosts, servers, user geography)

Include constraints:

• Influencing factors that cannot be changed (create limitations/restrictions)

Include assumptions:

• Believed-true factors not yet verified; confirm/disprove before impacting decisions

Include dependencies:

• Internal/external factors the solution relies on (e.g., related requirements, resourcing/funding)

Business rules

• Business rule definition
  • A testable, business-driven directive guiding judgment/decision-making
• Business rules typically emerge as constraints (policies/guidelines/standards/regulations/calculations)
• For each business rule, include:
  • Rule ID
  • Description/definition
  • Type
  • Which requirement it impacts (often via table/matrix)

Functional requirements

• Presented as “what the system is supposed to do”
• Best-practice ordering:
  • Start with stakeholder requirements, then decompose into functional specifications
• Alternative approach mentioned:
  • Start with features or business rules driving the specification
• Recommended structure:
  • Actor (system)
  • Action (verb)
  • Object (noun)
  • Qualifier/criteria (if needed)
• Key quality point:
  • Make functional requirements system agnostic to reduce design dependency

Use cases

• Definition
  • A functionality that helps users achieve goals; describes interaction details between actors and the solution
• When to use them
  • When functional requirements include scenarios that affect outcomes
• Include:
  • Use case diagrams and/or narrative descriptions
• Use case diagram components:
  • System name, boundary box, actors, use cases, association relationships, goals
• Use case description components:
  • Use case name, linked function requirement, actors, preconditions, triggers, post conditions, flow of events and scenarios

Data requirements

• What to include:
  • Data the system must consume/process/create
• Common elements:
  • Logical data model (visual depiction of data relationships; often a logical ERD)
  • Data dictionary (business terms + metadata like types, allowed values, definitions)
  • Data maintenance
    • How data is received/updated; retention; verification; archive/backup; disposal timeframes

External requirements

• Requirements outside the solution that interact to make it work
• Include external interfaces:
  • User interface requirements
    • Screens, navigation experience, expected inputs, expected outputs/responses
  • Software interface requirements
    • Integration points with OS, databases, web services, other systems
  • Communications interface requirements
    • Channels/formats (networks, email, messaging systems, other communications)

Non-functional requirements (NFRs)

Categories listed:

• Availability (uptime %, accessible/operating when needed)
• Compatibility (works with other components/environment)
• Performance (speed/responsiveness under constraints)
• Portability (ease moving to other environments)
• Reliability (availability/performance before failing)
• Scalability (growth/increased workload handling)
• Security (protection against unauthorized use/modification/destruction/disclosure)
• Supportability (install/configure/maintain ease; quality of documentation/training support)
• Usability (learnability/navigation ease)
• Localization (local languages/laws/currencies/cultural and geographic needs)

Reporting requirements

• Describe reports the system generates (if applicable)
• Include per report:
  • Report title and purpose
  • Target users
  • Inputs/layout/logic/sequencing
  • Header/footer specifications (layout and print details)
  • Body layout (fields, columns/rows, charts/graphs)
  • Optional wireframe suggestion
  • Security/access rules by user group
  • Report logic (triggers, rules, calculations, latency, conditions impacting generation)

Supporting/supplemental sections

• Glossary of terms
  • Shared definitions, especially when stakeholders use terms differently or acronyms exist
• Appendix
  • Attachments/links (diagrams, charts, tables, additional samples)
• Approvals and sign-off
  • Signatures from stakeholders with decision authority
  • Ensures agreement and alignment before development/testing continues

---

2) Best practices (checklist-style guidance)

• Create a separate Business Requirements Document (BRD) first
  • BRD should be approved before drafting the SRS.
• Involve key stakeholders early and throughout
  • Include SMEs, developers (decomposition assistance), and testers (requirements testability).
• Make the SRS manageable and traceable
  • Structure requirements so changes are easy to update with minimal impact.
  • Use a traceability matrix so each change can be traced to an original requirement.
• Use a requirements checklist
  • Verify each functional and non-functional requirement meets completeness and quality standards.
• Use visuals
  • Diagrams/flow charts to clarify complex requirements and ensure shared understanding.
• Write clearly
  • Use concise, unambiguous language; avoid jargon.
  • Be specific about what the software should do and achieve.
  • Use diagrams/examples where helpful.

---

Example SRS walkthrough (what the video’s sample includes)

Project example

• Admissions Department website for a university (versioning, revision history, table of contents).

Introduction

• Purpose and scope:
  • Defines functional and non-functional requirements for at least version 1.0 of the admissions website.
  • Scope includes transitioning applications/forms online and establishing electronic user accounts.

Overall description

• Product is an enhancement to an existing Department of Education website.
• Context diagram idea: shows interfaces/external entities.
• User classes:
  • Student types (active/prospective)
  • Admissions staff
  • Administrator
• Operating environment example:
  • Must work with updated web browsers (Windows browsers listed in subtitles)
• Constraints example:
  • Must pull student info from current university databases
• Assumptions example:
  • Available 24/7 outside scheduled maintenance
• Dependencies example:
  • Forms transition must occur before implementation

Business rules example

• Student eligibility rule, e.g. minimum high school GPA on a 4.0 scale
  • Includes rule ID and impacted requirement.

Functional requirements example

• Grouped by user group (student vs admissions staff).
• Example: appointment scheduling/calendar display:
  • Show available dates
  • Show available time slots after selecting a date

Use case section

• Scenario narrative with:
  • Main path
  • Alternate flows
  • Exception flows

Data requirements

• Uses:
  • ERD (entity relationship diagram)
  • Data dictionary
• Data maintenance example:
  • Retain appointment history for up to 365 days

External requirements

• UI example:
  • FAQ section on each page
  • Admissions portal / department portal / student portal sections
• Communication example:
  • Email confirmation for scheduled appointments
• Also mentions transmitting enrollments between portals/systems.

Non-functional requirements example

• Availability, compatibility, reliability/update behavior, scalability/concurrent users, localization/date/time formats.

Reporting requirements example

• Describes report structure (title, headers/footers, logic/conditions, field order, grouping, totaling, and sample report idea).

Glossary and appendix

• Defines terms like “prospective student”
• Includes BRD, process maps, data dictionary, report samples

Approvals/sign-off

• Stakeholders with decision authority sign off.
• SRS becomes the baseline for development and requirement changes.

---

Speakers / sources featured

• No named speakers or external sources are identified in the subtitles.