Short answer: A usable software requirements document has ten sections: company and project background, current state, objectives and success criteria, scope and out-of-scope, functional requirements, non-functional requirements, integrations, data migration, delivery and support expectations, and proposal format and timeline. Fifteen to twenty-five pages is enough. The most important section is the out-of-scope list. A free template is linked at the end of this article.
A vague requirement turns procurement into a guessing game where each supplier prices its own assumptions.
Three things to do before writing
Describe the problem, not the solution. "We need a CRM" is a solution statement. "Our quotes live across three spreadsheets and we cannot tell which version a customer received" is a problem statement, and it lets a vendor propose something better than what you had in mind.
Map the current process. Who does what, with which tool, in what order. A simple box-and-arrow diagram is sufficient.
Define measurable success. Month-end close drops from five days to one. Quote preparation time halves. Without this you cannot evaluate the result.
The ten sections
SectionMust containCompany and project backgroundIndustry, headcount, locations, transaction volumeCurrent stateSystems in use, versions, what they cannot doObjectives and success criteriaMeasurable targetsScope and out-of-scopeModules included and explicitly excludedFunctional requirementsRole-based scenariosNon-functional requirementsPerformance, security, backupIntegrationsSystem, direction, frequency, counterpartyData migrationSource, volume, how many yearsDelivery, training, supportPhases, response times, source codeProposal format and timelineLine-item breakdown, dates
Why the out-of-scope section matters most
Writing what is not included is as important as writing what is. Anything unwritten is something both parties assumed differently. Example: accounting integration is in scope, payroll is out of scope.
Example non-functional requirements
The system must support 120 concurrent users
List screens must load in under two seconds
Role-based permissions and an audit log are required
Automated daily backups with a tested restore procedure
Access to personal data must be logged for GDPR accountability
What to specify for integrations
Integrations are the largest source of pricing variance in proposals. For each one, state four things: which system, which direction meaning one-way or two-way, what frequency meaning real-time, hourly or daily, and who the counterparty is including whether API documentation exists.
How to write a requirement
A good requirement is testable. A bad one requires interpretation.
Weak: "The system must provide reporting."
Strong: "As a sales manager, I must be able to view revenue, quote count and conversion rate by representative for a selected date range, and export the report to Excel."
Use this pattern: As a [role], I must be able to [action], so that [outcome].
Then attach an acceptance criterion to each. Example requirement: as a warehouse operator, I must be able to receive goods by scanning a barcode. Acceptance criterion: scanning a barcode populates the matching product line automatically, quantity is entered, stock updates immediately on save, and an unrecognised barcode produces a warning and blocks the entry.
Acceptance criteria are the only thing that ends the "is this done" argument at the end of a project.
Prioritising with MoSCoW
ClassMeaningExampleMustSystem is unusable without itE-invoicing integrationShouldImportant, can wait for phase twoAdvanced report builderCouldInclude if budget allowsNative mobile appWon'tDeliberately excluded this phaseHR module
This lets you cut scope against a budget ceiling and lets vendors propose sensible phasing rather than an all-or-nothing number.
Five common mistakes
Dictating screen designs. Describe what you need and leave how it looks to the designer, or you will pay more for a worse result.
Omitting the out-of-scope list. This is where change-order disputes come from.
Letting IT write it alone. Requirements must come from the people who do the work.
Hiding your deadline. If your timeline is tight, say so, and you may get a phased proposal instead of a refusal.
Writing too much. Nobody reads eighty repetitive pages. Fifteen to twenty-five focused pages produce better quotes.
Download the template
The template includes all ten section headings, worked requirement examples, a MoSCoW prioritisation sheet and a proposal comparison table.
[To add before publishing: .docx and .xlsx download links. This page's link-earning potential depends entirely on these files existing.]
Frequently asked questions
What should a software requirements document include?
Ten sections: company background, current state, objectives and success criteria, scope and out-of-scope, functional requirements, non-functional requirements, integrations, data migration, delivery and support expectations, and proposal format with timeline. The out-of-scope list prevents most later disputes.
How long should a requirements document be?
Fifteen to twenty-five pages is enough for a mid-sized project. Length is not a quality signal, and repetitive eighty-page documents go unread and produce worse quotes. What matters is that every requirement is testable.
Can we get quotes without a requirements document?
You can, but the quotes will not be comparable. At minimum define scope, the integration list, user count and data volume. Without those, any price you receive is a guess.
Can the software vendor write the requirements document for us?
Yes, many run a paid discovery phase that produces one. Make sure the output belongs to you and can be used independently to obtain quotes from other suppliers. Check this clause before signing the discovery engagement.
What happens if requirements change mid-project?
Change is normal. What matters is that changes go through a written change-request process showing the effect on timeline and budget. Undefined small additions are the most common cause of budget overruns.
What is the difference between functional and non-functional requirements?
Functional requirements describe what the system does, meaning the features and behaviours users interact with. Non-functional requirements describe how well it must do it: performance, security, availability, backup and compliance constraints.