The most expensive mistake in software development is not choosing the wrong technology — it is starting to build before anyone has clearly defined what needs to be built. A Software Requirements Document (SRD) is the antidote. It is a written description of what your software should do, who will use it, and what is explicitly out of scope for the initial version.

You do not need to be a developer to write one. In fact, some of the best SRDs we have reviewed were written by business owners who had never written a line of code. This guide walks you through every section, with examples drawn from the kind of software projects common in Kenya and East Africa.

Why the SRD Matters (and Why It Saves You Money)

When a developer receives a vague brief — "I want an app like M-Pesa but for savings groups" — they have to make dozens of assumptions to produce a quote. Each assumption adds a buffer to the price to cover the unknown. The vaguer the brief, the higher the quote.

A detailed SRD removes assumptions. Developers can quote precisely on what you have described, not on their worst-case interpretation of what you might want. In our experience, a well-written SRD can reduce a development quote by 20–40% and virtually eliminates the scope creep that causes projects to overrun budget.

Beyond cost, an SRD protects you contractually. If you and your developer agree on a written document before work begins, you have a clear reference point if there is ever a dispute about what was supposed to be delivered.

The 5 Sections Every SRD Needs

Section 1: Project Overview

A 2–3 paragraph description of what you are building, who it is for, and the core problem it solves. Avoid technical language here — write it as if explaining to a smart friend who knows nothing about your industry.

Example (savings app): "We are building a mobile application that allows informal savings groups (chamas) in Kenya to manage their contributions, track loans, and disburse funds via M-Pesa. The platform will serve group treasurers as the primary administrators and group members as secondary users. The core problem is that most chamas currently operate on paper records or WhatsApp groups, leading to disputes, fraud risk, and poor financial visibility."

Section 2: User Roles

List every type of person who will interact with the system and describe their permissions. Most applications have 2–4 user roles. Be specific — "admin can do everything" is not helpful.

For the savings app example:

Group Member: Can view their own contribution history, loan balance, and group account summary. Can initiate a deposit via M-Pesa STK Push. Cannot see other members' individual balances.
Group Treasurer: Can record contributions, approve and disburse loans, generate monthly statements, add or remove members, and export transaction history to PDF.
Super Admin (HazinaPay staff): Can view all groups, manage subscriptions, and access system-wide analytics. Cannot see individual transaction details for compliance reasons.

Section 3: Functional Requirements

This is the main body of your document — a list of everything the system should do. The clearest way to write functional requirements is as user stories using this format:

As a [user role], I want to [action] so that [benefit].

Examples for the savings app:

As a group member, I want to receive an SMS reminder 3 days before my monthly contribution is due so that I do not miss the deadline.
As a treasurer, I want to record a manual cash contribution for a member who paid in person so that the system reflects the correct balance even when M-Pesa is not used.
As a group member, I want to apply for a loan from the group fund by submitting a request with the amount and repayment period so that the treasurer can review and approve it.
As a treasurer, I want to disburse an approved loan directly to the member's M-Pesa number so that the transaction is traceable and does not require cash handling.

Write as many user stories as you can think of. Twenty to forty stories for a medium-complexity application is normal. Each story becomes a unit of work that a developer can estimate individually.

Section 4: Non-Functional Requirements

These describe how the system should perform, not what it should do. They are often overlooked but have a significant impact on cost and architecture decisions.

Performance: "The app should load the member dashboard within 3 seconds on a 3G connection."
Availability: "The system should be available 99.5% of the time. Planned downtime for maintenance should occur between 1 AM and 4 AM EAT."
Security: "All user passwords must be hashed using bcrypt. All API communication must use HTTPS. M-Pesa transaction logs must be retained for 7 years per CBK guidelines."
Scalability: "The system should support up to 10,000 groups and 500,000 members in year one without architectural changes."
Offline support: "Group members in areas with poor connectivity should be able to view their last-known balance and contribution history without an internet connection."

Section 5: Out of Scope

This section is as important as the functional requirements. It explicitly lists what you are not building in this version. This prevents developers from including features you did not ask for (and billing you for them), and prevents misunderstandings about what the first version will include.

Example out-of-scope items for the savings app MVP:

Investment features (unit trusts, fixed deposits, stock market integration)
Multi-currency support
iOS application (Android and web only for v1)
Integration with any bank other than M-Pesa
In-app messaging between group members

How to Describe M-Pesa Flows in Requirements

Payment flows deserve special attention because they involve multiple parties and multiple possible outcomes. For any M-Pesa flow, describe the happy path and the failure paths explicitly.

Example — Member Contribution via STK Push:

Member taps "Pay Contribution" and enters the amount (or it is pre-filled with the monthly target).
System triggers an M-Pesa STK Push to the member's registered phone number.
Member sees a PIN dialog on their phone and enters their M-Pesa PIN.
On successful payment, the system records the contribution with the M-Pesa receipt number and updates the member's contribution ledger within 30 seconds.
Member receives an in-app notification and SMS confirmation with the receipt number.
Failure: Insufficient funds. System shows the member an error message explaining the payment was declined and offers a "Try Again" button. No transaction is recorded.
Failure: User cancels. System shows a cancellation message. No transaction is recorded.
Failure: Callback not received within 5 minutes. System marks the transaction as "pending" and queries the M-Pesa status API. Member sees "Verifying payment..." status until confirmed or failed.

Common Mistakes That Make Developers Quote 3× Too High

Describing the solution instead of the problem. "I want a dashboard with 12 charts showing..." forces the developer to build exactly what you imagined. Instead, describe the decision the user needs to make and let the developer propose the best interface.
Mixing MVP features with "nice to have" features. Separate your must-haves from your wishlist. Quote the MVP first, then prioritise additions based on budget remaining.
Using the word "simple." "A simple admin panel to manage users" is not a requirement. What can an admin see? What can they edit? Can they delete accounts? Can they export data? Each answer changes the cost.
Leaving payments vague. "The user pays online" is not a requirement. Specify the payment method (M-Pesa STK Push, Paybill, card), what triggers the payment, what happens on success and failure, and how refunds work.
Forgetting email and SMS flows. List every automated message the system should send: when it sends, to whom, what it says (even a rough template), and what event triggers it.

A Quick Template to Get Started

Copy this structure and fill in the blanks for your project:

PROJECT OVERVIEW
Project name:
Problem being solved:
Target users (who are they?):
Target geography (Kenya only? East Africa?):
Platform (Android app / iOS app / web / all three?):

USER ROLES
Role 1: [name] — can do: ...
Role 2: [name] — can do: ...

FUNCTIONAL REQUIREMENTS (user stories)
As a [role], I want to [action] so that [benefit].
(repeat for every feature)

NON-FUNCTIONAL REQUIREMENTS
Performance target:
Uptime requirement:
Security requirements:
Expected user numbers at launch:

OUT OF SCOPE (V1)
We are not building:
-
-

A completed SRD for a medium-complexity application is typically 3–8 pages long. Longer is usually better — more detail means fewer assumptions and a more accurate quote.

At HazinaPay, every project starts with a requirements review. If you have a partial SRD or even just a clear idea, our quote tool will help you structure it into a proper scope. Start with a free quote and we will help you think through what you actually need to build.

How to Write a Software Requirements Document (SRD) — A Non-Technical Guide