Every software dispute we have ever mediated traces to the same document — the one nobody wrote. Requirements are not bureaucracy; they are the cheap rehearsal of expensive decisions. Here is the format that works, sized for founders and SMBs, not enterprise PMOs.
The one-page core (do this even if nothing else)
The problem sentence. Who has what pain, and what does solved look like? "Clinic front desks spend 2 hours daily on appointment calls; solved means patients self-book and reschedule on WhatsApp." One sentence disciplines everything downstream.
The user list. Every role that touches the system (patient, receptionist, doctor, admin) — because every role multiplies screens, permissions, and cost.
The feature list as user stories. "As a [role], I can [action] so that [outcome]" — twenty of these beat forty pages of prose. Mark each must / should / later; the later column is where MVP discipline lives or dies.
Acceptance criteria on the musts. Testable sentences: "admin can export leads as CSV filtered by date range." This is the line between a fixed price that means something and a fee schedule with vibes. Vague musts become change-order factories.
The five questions vendors will ask (answer them first)
- Integrations: what existing systems must this talk to? (Tally, WhatsApp, payment gateways — each is scope.)
- Data: what exists today, in what mess, and must it migrate?
- Volume: users, records, transactions — rough orders of magnitude change architecture.
- Compliance: GST documents, patient data, DPDP obligations?
- The one thing: if only one workflow ships perfectly, which?
What NOT to write
Technology choices (describe the what; let builders propose the how — premature stack mandates eliminate better options), pixel-level UI (that is discovery and design's job), and imagined edge cases for users you do not have yet.
The payoff math
A day of requirements writing routinely saves 15–30% of project cost in avoided rework and dispute — the highest-ROI day in the entire project. It also gets you comparable quotes: three vendors bidding the same document produce numbers that mean something (how to compare them).
Send us a one-pager in this format and we will return a fixed quote within one business day — that is literally our intake. Stuck on the blank page? Send the problem sentence and we will help you build the rest.
Frequently asked questions
What should software requirements include?
One page minimum: a problem sentence (who, what pain, what solved looks like), every user role, features as user stories marked must/should/later, and testable acceptance criteria on the musts. Add integration, data, volume, and compliance answers.
What are acceptance criteria and why do they matter?
Testable sentences defining done — 'admin can export leads as CSV filtered by date.' They're what makes a fixed price meaningful and prevent vague features from becoming change-order factories. Every must-have deserves them.
What should I NOT put in requirements?
Technology mandates (describe what, let builders propose how), pixel-level UI decisions (design's job), and speculative edge cases for users you don't have. Premature specificity eliminates better options and inflates quotes.
Do detailed requirements really save money?
A day of requirements writing routinely saves 15–30% of project cost in avoided rework and disputes — and gets you genuinely comparable vendor quotes, since everyone bids the same document instead of their own interpretation.