A software requirements specification (SRS) explains what a system must do, the constraints it must respect, and how the team will verify that it meets the need. It creates a shared reference for product, design, engineering, QA, operations, and stakeholders.
TL;DR
- An SRS describes required behavior, constraints, and the evidence needed to verify a system.
- Record users, workflows, exceptions, integrations, quality requirements, exclusions, and unresolved questions at a suitable level of detail.
- Write testable requirements, link them to acceptance evidence, and agree how changes are reviewed and approved.
- Describe the outcome and system boundary, then document user workflows, exceptions, external interfaces, and exclusions.
- Write each requirement so a reviewer can verify its behavior and trace it to an acceptance check.
An SRS is not a listing of programming code or a complete implementation plan. A small project can use a lightweight requirements document or structured backlog; the important thing is that the required behavior, quality, assumptions, and acceptance evidence are clear.
Make the important decisions visible
A useful specification covers business outcomes, users and roles, core workflows, data ownership, integrations, quality constraints, and acceptance criteria. It also records exclusions and unresolved questions. This connects requirements to SDLC planning and quality assurance.
For formal requirements work, ISO/IEC/IEEE 29148:2018 is the published requirements-engineering reference listed by ISO as checked October 25, 2026. ISO lists the 2018 edition as current and a replacement draft under development. Use the edition required by your project. The outline below is an editorial working template, not a reproduction of the standard or a claim of compliance.
A practical SRS outline
- Purpose and scope: problem, intended outcomes, system boundary, and exclusions.
- Context: users, operating environment, existing systems, and shared vocabulary.
- Workflows and data: normal paths, exceptions, states, ownership, and retention assumptions.
- Functional requirements: required actions and system responses.
- Quality requirements and constraints: performance, reliability, accessibility, security, and mandated technologies where justified.
- External interfaces: data contracts, protocols, errors, limits, authentication, and dependencies.
- Verification and traceability: acceptance method, tests, source need, owner, and status.
- Assumptions and change history: open decisions, approvals, versions, and impact of changes.
Budget and schedule can reference these requirements, but a feature description alone does not establish an estimate. Keep delivery assumptions visible rather than treating the SRS as a price guarantee.
Step 1: Define the outcome and boundary
For a hypothetical purchase-request system, the goal is to make request status and approval ownership visible. Request creation, review, and status tracking are in scope; supplier payments and automatic purchasing are out of scope.
Name requesters, approvers, finance reviewers, and administrators. Identify which records the new system owns and which remain in accounting software. Write a glossary for terms such as “approved,” “rejected,” and “cancelled” so they are not interpreted differently across teams.
Step 2: Capture workflows and exceptions
Observe how people do the work and inspect real examples with appropriate data access. Map a request from creation through approval or rejection. Include missing information, absent approvers, duplicate submissions, failed notifications, and cancellation after approval.
Separate observed needs from proposed solutions. “Employees cannot tell who must act” is a problem; “add a dashboard” is one possible response. Record the source and owner of each need so later scope decisions have context.
Step 3: Write atomic, testable requirements
Use a stable identifier and one obligation per requirement. “Shall” can mark mandatory behavior when the team adopts that convention; consistency matters more than the word alone.
| Field | Example |
|---|---|
| ID | REQ-APP-01 |
| Requirement | The system shall reject an approval attempt when the acting user is the requester. |
| Rationale | Preserve separation between requesting and approving. |
| Source/owner | Approval policy; finance owner |
| Priority | Required for pilot |
| Verification | Direct API and user-interface negative tests |
| Acceptance | No approval state change occurs; the attempt is recorded without exposing sensitive data |
| Status | Proposed, reviewed, approved, implemented, verified, or deferred |
Avoid “easy,” “fast,” “secure,” or “user-friendly” without defining the relevant behavior and evidence. Do not combine several independent actions in one statement when they could be accepted or changed separately.
Step 4: Distinguish behavior, quality, and interfaces
Functional requirements describe actions and responses: create a request, calculate a total, reject an unauthorized approval, or notify an assigned reviewer. Quality requirements describe measurable properties or constraints on that behavior. Security may include both functional controls and quality constraints; it is not confined to one category.
An illustrative performance requirement could be: “The request-list endpoint shall respond within two seconds at the 95th percentile for the agreed test workload of 50 concurrent users and 10,000 requests.” Those figures are hypothetical. Specify the environment, network boundary, query mix, and measurement method before using them as an acceptance target.
An interface requirement should state the data format, required fields, authentication, error response, timeout, retry, and duplicate-handling rules. A screenshot is not enough to define an API or a failure path.
For accessibility and reliability, name the applicable target and verification method. Do not say the system meets a standard merely because the requirement mentions it.
Step 5: Link requirements to acceptance evidence
A traceability table can connect a need to design, implementation, and verification. NASA’s technical requirements guidance checks whether requirements are feasible, verifiable, and consistent with stakeholder needs. Its mission process is more formal than many small software projects need; the distinction between a clear requirement and evidence that it was met is still useful.
For the purchase-request example:
| Need | Requirement | Design decision | Verification evidence |
|---|---|---|---|
| Requesters must not approve their own requests | REQ-APP-01 | Server-side check on the approval action | Negative API test plus UI test |
| Users need visible request status | REQ-STATUS-01 | Status field and permitted transition map | Tests for each allowed and rejected transition |
| Notification failures must be recoverable | REQ-NOTIFY-01 | Retry policy and operator-visible failed state | Simulated timeout, duplicate delivery, and recovery test |
These are hypothetical examples. Replace the evidence column with actual test identifiers and results as work progresses. A link to a test does not mean it has passed; track status and the release version verified.
Work through a change to an approved requirement
Treat an approved requirement change as a decision with consequences, not just a sentence to edit. NASA’s requirements-management guidance calls for assessing effects on cost, schedule, architecture, interfaces, and related requirements before approval. Use a level of review proportionate to your system’s risk.
Continue the hypothetical purchase-request example. The business owner proposes an additional finance approval for requests of USD 500 or more. This is an invented policy for the example, not an actual client rule. Keep the existing ban on self-approval, REQ-APP-01. Add a separate requirement, REQ-FIN-01, for the new finance approval so the two obligations remain independently traceable.
| Affected area | Decision to record | Proposed verification evidence |
|---|---|---|
| Amount and boundary | Use the approved request total in USD cents; finance approval begins at 50,000 cents | Below-boundary and exact-boundary cases: 49,999 and 50,000 cents |
| Existing requests | Decide which policy version applies to pending and already approved requests | Cases for each affected state and policy version; no silent historical rewrite |
| Roles and state transitions | Define who may provide finance approval and what happens if the amount changes | Direct API permission checks, self-approval rejection, and stale-approval tests |
| Interfaces and reports | Identify screens, notifications, exports, and integrations that interpret approval status | Contract and end-to-end checks against the revised state meanings |
| Release and acceptance | Name the approval owner, target version, migration decision, and unresolved risks | Linked results for the tested version and a recorded release decision |
The proposed rule is not ready for implementation while “request total” or the treatment of pending requests is undecided. Record the owner of each open question and the evidence needed to close it. The new requirement must also say how cancelled or revised requests behave; a threshold alone does not define the whole workflow.
After approval, update the requirement, its rationale and version, the affected design and interface records, and the linked acceptance checks. Preserve the previous baseline and the reason for the change. Mark evidence as pending until the relevant tests have actually run. A completed checklist is not proof that the deployed version implements the new rule.
Step 6: Review, approve, and manage changes
Have users check workflow accuracy, product owners check scope, engineers check feasibility, QA check verifiability, and operations check supportability. Bring in relevant domain or security expertise when the consequences require it.
Look for contradictions, missing exception paths, unowned assumptions, and requirements that cannot be tested. Approval establishes a baseline, not a ban on learning. When a requirement changes, record why, who approved it, and the effect on design, implementation, tests, budget, and release scope.
A good SRS makes disagreement visible early and supports a clear acceptance decision later. It does not guarantee that the product is valuable or eliminate all defects. Keep customer feedback and actual operational evidence connected to the document as the software evolves.
Carry the approved requirements into the software building process with their owners, open decisions and acceptance evidence. Hapy sells product development services, so we have a commercial interest in implementation work. Use the same record to scope an MVP development service with explicit assumptions and change control.
