Software Requirements Specification (SRS): What to Define Before Development

“We need a customer portal where customers can upload files, see status and contact our team.”

That sounds like a clear request. It isn’t yet buildable. A development team reading it would still need to know:

• • Which customers, and which roles within each customer?
• • Which file types, and are there size limits?
• • Who can view each file?
• • What are the status values, and who changes them?
• • Who gets notified, and when?
• • What happens when something is missing or wrong?
• • Does the portal connect to the CRM or another system?
• • What information belongs to each customer record?
• • What proves that a submission is complete?

Each unanswered question becomes a guess. The same idea becomes far clearer once it’s broken down into users, workflows, data, permissions, business rules, system behavior, integrations, exceptions and acceptance conditions.

That’s what a software requirements specification does. An SRS, short for software requirements specification, is a document that defines what a software system needs to do, for whom, under what conditions and how the business will know it works. It’s a translation layer between a business need and something a development team can design, build and verify. A good one describes what the system must do far more than how developers should implement it.

This guide organizes that work into ten parts:

Problem → Users → Workflows → Data → Rules → Features → Connections → Constraints → Acceptance → Ownership

It’s NogaTech’s planning framework for this article, not an ISO or IEEE structure, and not the only way to organize an SRS.

Not every project needs the same level of formal documentation; a small internal tool may need a few pages, a multi-team system much more. This guide covers requirement layers, the ten parts, how to write testable requirements, a fictional worked example, integrations, change control and a review checklist.

What Is a Software Requirements Specification?

A software requirements specification documents what a software system needs to do, who it serves, the conditions it must satisfy, the interfaces and constraints that matter, and how important requirements can be verified.

The international standard on requirements engineering, ISO/IEC/IEEE 29148, treats requirements specifications as information items produced by the requirements engineering process. Organizations apply that idea with very different levels of formality. How formal an SRS document needs to be usually depends on:

• • Project size and complexity
• • How many teams or vendors are involved
• • Contractual requirements
• • Regulatory needs, where they genuinely apply
• • The organization’s existing practices

Requirements may live in a document, a spreadsheet, a requirements tool or a short SRS plus a backlog. The format matters less than whether they’re clear, agreed and verifiable.

What an SRS Is—and What It Is Not

Documents sometimes overlap, but these boundaries are a useful starting point:

An SRS often informs all of those documents. It doesn’t replace them.

From Business Need to Software Requirement

Requirements come in layers, each answering a different question. Using the onboarding portal as a running example:

Keeping these distinct makes each one easier to agree on.

The 10 Parts to Define Before Development

These ten parts give an SRS its substance. They inform each other, and teams often revisit earlier parts as later ones become clear.

1. Problem: Define Why the Software Needs to Exist

Start with the problem, not the solution. Which business process is affected, what’s slow or error-prone today, and why don’t existing tools solve it? In the portal example, onboarding information might arrive by email in inconsistent formats and be retyped into several systems. The output is a short, agreed problem statement that every later requirement can be checked against.

2. Users: Identify Roles and Responsibilities

List the customers, staff, managers, administrators and partners who will use the system, defined as roles rather than job titles. Then define how roles differ: who can create a record, view a document, change a status or approve a submission. Permission differences are easy to overlook and far easier to define now than to retrofit later.

3. Workflows: Document How Work Moves

For each important workflow, capture the trigger, steps, decisions, handoffs, successful outcome and exception paths. In the portal, one workflow starts when staff create a customer account and ends when an accepted submission moves to finance setup, with a path for returning incomplete submissions.

4. Data: Define What Information the System Needs

Identify what the system must capture, display and pass on: required and optional fields, where each comes from, which system is the source of truth, where data changes and where it goes next, plus retention needs where they apply. Keep it at a business level; designing database tables is the development team’s job.

5. Rules: Make Business Logic Explicit

Rules are the decisions the software will make or enforce: who can approve, when a status changes, when a field becomes required, what sends an item back and what triggers a notification. People can handle an informal “it depends” through judgment. If software is expected to make the decision, that ambiguity needs to become explicit logic or a defined route to human review.

6. Features: Describe What the System Must Do

Describe behavior, such as creating and updating records, uploading documents, assigning work, reviewing, approving, searching, notifying and reporting, in terms of what the system does for which role, under what conditions. Avoid a wishlist: every feature should trace back to a user need and the problem.

7. Connections: Define External Systems and Integrations

For each external system, such as a CRM, email service or payment provider, define the source, destination, purpose, data exchanged, trigger, owner and behavior if the connection fails. The integrations section below expands on this.

8. Constraints: Define Important Conditions

Record the conditions the solution must respect: security, privacy, accessibility, capacity, performance, supported browsers and devices, operational limits, and compliance requirements where they genuinely apply. Don’t add obligations that don’t apply, or numeric targets without a real basis.

9. Acceptance: Define How Requirements Will Be Verified

Every important requirement should be observable enough to evaluate, with a pass condition, an error condition where relevant, and agreement on whether it’s checked by business review, technical testing or both. NASA’s Software Engineering Handbook says verification methods such as test, inspection, analysis or demonstration should be included in the software requirements document, either with the requirement or in a separate verification matrix.

10. Ownership: Decide Who Approves and Changes Requirements

Name the requirement owners, the subject-matter experts who confirm accuracy, the final approver and who resolves disagreements. Decide who can change a requirement and who maintains the current version. Without this, requirements drift and nobody is sure which version is agreed.

Functional vs Non-Functional Requirements

Functional requirements describe what the system does. Non-functional requirements describe the qualities, constraints or operating conditions that apply while it does them. Most functional requirements come with non-functional considerations attached:

Non-functional requirements are easy to leave implicit, and “obvious” expectations often differ between people. For an SRS, the essential step is to write the important ones down and make them specific enough to check.

How to Write a Clear Software Requirement

When working out how to write software requirements, a simple pattern helps: one requirement, one main behavior, a defined condition and an observable result. The model in the visual above extends that pattern:

Who → Need / condition → System behavior → Result → Exception → Acceptance

It’s a reader-facing completeness check, not a mandatory syntax. In the portal: when onboarding information is submitted, the system validates required fields; complete records become eligible for review, incomplete ones can’t progress, and the system identifies each missing field.

Watch for vague quality words: user-friendly, fast, flexible, seamless, secure, intuitive, robust, scalable. They express real intentions, but only become useful once the project defines them well enough to guide decisions and verification. NASA’s software engineering handbook warns that requirements written only in natural language stay open to interpretation, which is why definitions and acceptance conditions matter.

Requirement vs Feature vs User Story vs Acceptance Criterion

These terms overlap, and teams use them differently. A practical way to separate them:

None universally replaces the others. Many teams keep agreed requirements in an SRS and deliver through user stories with acceptance criteria. What matters is that requirements are clear and traceable somewhere.

How Detailed Should an SRS Be?

There’s a useful middle ground between saying too little and saying too much.

• Too vague leaves room for interpretation. Different people read the same sentence differently, and the difference surfaces late.
• Useful defines the users, behavior, data, rules, interfaces, constraints and acceptance conditions that matter for this project.
• Too prescriptive dictates implementation choices the business doesn’t actually need, which can limit the development team without adding value.

Some technical constraints are legitimate requirements: a mandated platform, an existing enterprise system, a required security approach, specific browser or device support, or hosting restrictions. NASA’s handbook suggests that when a requirement specifies an implementation method, its rationale should explain why, which is a sensible test for any SRS.

Software Requirements Specification Example

The following software requirements specification example is fictional and illustrative. It isn’t based on a NogaTech client or project. It shows how part of an SRS for a customer onboarding portal might look.

Scenario: Staff create a customer account. The customer supplies missing information and uploads required documents. Operations reviews the submission. Incomplete submissions return to the customer for correction, and accepted submissions move to the next internal stage.

Note the value of IDs: each software requirement specification entry can be referenced in design discussions, tests and change requests.

Requirements and Business Process Mapping: What’s the Difference?

A process map and an SRS are closely related but do different jobs.

A process map captures how the business workflow moves: the trigger, participants, steps, decisions, handoffs, waits and exceptions. NogaTech’s guide to business process mapping covers how to build one.

An SRS takes that workflow and adds what software needs: permissions, data, detailed system behavior, interfaces, constraints, acceptance conditions and ownership. A process map might show “Operations reviews submission.” The SRS specifies what the reviewer can see, what actions they can take, what each action changes and how that’s verified.

If those details are not defined elsewhere, a process map alone leaves them unresolved and open to different interpretations during design and development.

Requirements for Integrations and APIs

Integrations deserve their own requirements, because they involve systems the project may not control. For each connection, define:

The SRS needn’t describe how the integration is coded, but it should make business expectations explicit, especially failure behavior. For a broader explanation, see NogaTech’s guide to API integration.

What Makes a Software Requirement Testable?

A requirement is testable when it leads to an observable condition someone can check, including when things go wrong.

If you can’t describe how a requirement would be checked, it usually needs more definition.

Requirements Change—How Should Updates Be Managed?

Requirements change as users clarify needs, gaps surface or priorities shift. Even NASA’s handbook expects an SRS to be revised as a project progresses. The goal isn’t to prevent change but to make it visible and deliberate.

A simple model:

Request → Why → Impact → Decision → Update → Re-verify

For each change, capture:

• • Who requested it
• • The reason for it
• • Which requirements it affects
• • Which workflows it affects
• • Which acceptance criteria need updating
• • Related dependencies, such as integrations or data
• • The approval decision and who made it
• • The version or date of the update

A simple change log is often enough, as long as each requirement and its acceptance conditions are updated together.

SRS Review Checklist

Before development starts, a business reviewer can use this checklist to test whether an SRS document is ready to rely on:

Common Software Requirements Specification Mistakes

These are common patterns rather than measured statistics:

1. 1. Starting with screens before defining workflows. Screens show appearance, not behavior.
2. 2. Mixing the business goal with the system requirement. A goal needs translating into behavior.
3. 3. Writing vague quality words without defining them. “Fast” means different things to different people.
4. 4. Ignoring exceptions. Incomplete, invalid and failed cases need attention too.
5. 5. Missing roles and permissions. Access is assumed rather than specified.
6. 6. Forgetting integration ownership. Each connected account needs an owner.
7. 7. Treating a process map as complete software requirements. It shows the workflow, not the system behavior.
8. 8. Listing features without acceptance conditions. Without them, “done” becomes a matter of opinion.
9. 9. Silently changing requirements. Teams end up working from different versions.
10. 10. Having no named approver. Disagreements stay unresolved.

When Professional Software Discovery Help Makes Sense

An internal approach may be enough for one simple workflow with few roles, exceptions and integrations, a clear product owner and well-understood requirements.

Professional discovery support becomes more useful when:

• • Several departments are involved
• • Stakeholders disagree about what the system should do
• • Business rules are complex
• • Many user roles need different permissions
• • Legacy systems are involved
• • Data migration matters
• • Several integrations are required
• • The first release is unclear
• • Workflows need discovery before software design can start

If deciding what belongs in a first release is the main challenge, NogaTech’s guide to building an MVP covers that decision. For help turning business needs into requirements and working software, see NogaTech’s custom applications and modernization services.

15 Questions Before Development Starts

Frequently Asked Questions