How to Write a Software Requirements Specification (SRS)

• Stakeholder communication
  It helps customers, users, developers, testers, and other stakeholders share an understanding of the system.
• A foundation for development
  It provides a reference for design, implementation, and testing.
• Change management
  It gives the project a basis for tracking and managing changes to requirements.
• Verification and validation
  It provides criteria for checking that the system meets the specification and that it fulfills users' needs.

1. Introduction
   • Purpose
     describes why the SRS exists and who should read it.
   • Scope
     summarizes the software's name, objectives, and main functions, and defines its boundaries.
   • Definitions, acronyms, and abbreviations
     explains technical terms and abbreviations used in the document.
   • References
     lists materials used to prepare the SRS, such as the project plan and relevant standards.
   • Overview
     outlines the remaining sections and what each covers.
2. Overall Description
   • Product perspective
     explains how the system relates to other or existing systems, for example whether it stands alone or is part of a larger system.
   • Product functions
     summarizes the main functions. Detailed functional requirements follow in the next section.
   • User characteristics
     describes the main user groups and their knowledge, experience, and technical background.
   • Constraints
     lists restrictions affecting development or the finished product, such as required hardware or software, programming language restrictions, budgets, deadlines, or security rules.
   • Assumptions and dependencies
     records assumptions underlying the SRS and external factors that affect the project's success.
3. Specific Requirements
   This is the core of the SRS. It details every requirement the system must meet, commonly grouped into functional, nonfunctional, and interface requirements. We'll look at these in more detail below.
4. Appendices and Index
   (optional)
   These can hold material that doesn't fit into the main text, such as data models, detailed use cases, or an index of terms.

• They often begin with “The system shall…” or “The user can…”.
• Each function should be clear, unambiguous, and verifiable.

• “Users shall be able to sign in with a username and password.”
• “The system shall let users search for books by title, author, or publisher keywords.”
• “Administrators shall be able to create user accounts and edit or delete existing user information.”
• “When a user places an order, the system shall check inventory and notify the user if stock is insufficient.”

• Identify needed functions from the user's perspective. Use case analysis can help.
• Specify inputs, processing, outputs, and exception cases for each function.
• Give each requirement a unique ID, such as “FR-001: User sign-in,” so you can track and manage it.

• Performance
  “Under normal conditions, the system shall respond to user requests within two seconds.”
  “The system shall support 1,000 concurrent users.”
• Usability
  “The system shall provide an interface that allows first-time users to learn the basic functions within ten minutes.”
  “Every function shall be accessible using only a keyboard.”
• Reliability
  “The system shall provide 99.9% annual availability, with at most 8.76 hours of downtime a year.”
  “After a system failure, the system shall recover automatically within five minutes.”
• Security
  “All user passwords shall be stored in encrypted form.”
  “The system shall be protected against SQL injection and cross-site scripting (XSS).”
• Maintainability
  “Code shall follow internal coding standards, and key modules shall include comments.”
  “Adding a payment module shall leave existing payment functions unaffected.”
• Portability
  “The system shall run on both Windows and Linux.”

• Clear and unambiguous
  Write each requirement so it has only one interpretation. Avoid subjective descriptions or vague terms.
  • Weak example: “The system shall be user-friendly.” This is vague.
  • Better example: “Users shall be able to reach the main features in three clicks or fewer.” This is specific.
• Complete
  Cover all the functions, performance requirements, and constraints the system must satisfy. Keep items marked “To Be Determined” (TBD) to a minimum.
• Consistent
  Requirements must not contradict or conflict with one another. Use consistent terminology and wording.
• Correct
  Each requirement should accurately reflect what customers or users actually need.
• Verifiable or testable
  Write each requirement so a test or analysis can determine whether the system meets it. Avoid requirements that cannot be measured.
• Traceable
  Assign a unique ID to each requirement and link it to design documents, code, and test cases so changes can be traced.
• Modifiable
  Organize the document so requirements are easy to update and manage when they change.
• Prioritized
  Requirements have different levels of importance. A method such as MoSCoW (Must have, Should have, Could have, Won't have) makes priorities explicit and helps you plan within limited resources.

Next time, we'll explore requirements analysis techniques, including formal and informal analysis, interviews, and workshops.

• IEEE 830-1998 — IEEE Recommended Practice for Software Requirements Specifications↗ (English. The IEEE guidance may require paid access, so look for a summary or explanation if needed.)
• Software requirements specification — Wikipedia↗ (English. An overview of SRS documents.)
• How to Write a Software Requirements Specification (SRS Document) — Perforce↗ (English. A detailed guide to writing an SRS.)