The seven sections every software scope needs — and the three everyone skips
Assumptions, risks and exclusions are the cheapest insurance in software procurement. What each of the seven sections of a scope should say.
Most failed software projects did not fail in the code. They failed in a document that was too short, too vague or never written. A development team can only build what someone has described, and a price is only as good as the description it was calculated against.
A scope is that description. Done properly, it lets two unrelated teams price the same project and arrive at numbers you can compare. Done badly, it is a wish list with a total at the bottom.
Below are the seven sections we put in every scope, in the order a reader needs them. The first four are familiar to anyone who has bought software. The last three are the ones that get skipped, and they are the ones that decide who pays when something turns out to be bigger than it looked.
1. Project summary
One page, no more. What is being built, for whom, and why now. It should name the business outcome in plain words (“dispatchers stop re-entering jobs from email into the planning sheet”) rather than the technology (“a React application with a Node backend”).
The summary exists so that anyone joining the project later — a new engineer, a finance approver, a partner’s QA lead — understands the point of the work in two minutes. If you cannot write it in a page, the project is not understood well enough to price.
Wording that works: “The system replaces the shared spreadsheet used by the dispatch team to assign field jobs. Success means every job is created once, in one place, and reaches the technician’s phone without being retyped.”
2. Feature scope, written per user role
List features by who uses them, not by screen or by module. “The dispatcher can reassign a job to another technician and the original technician is notified” is testable. “Job management” is not.
Writing per role does two useful things. It exposes roles nobody thought about — the accountant who needs an export, the admin who resets passwords — and it turns each line into something that can later be accepted or rejected. That matters when payment depends on acceptance.
A good feature line has an actor, an action and an observable result. If a line has none of the three, it is a heading, not a requirement.
3. Technical requirements and integrations
This is where the scope names the systems the new software has to talk to, and how. For each integration, write down:
- which system, and which version or plan (API limits differ between tiers)
- the direction of data: read, write, or both
- how often: real time, hourly, nightly
- who owns the credentials and the vendor relationship
- what happens when the other system is unavailable
Integrations are the most common source of estimate drift, because the difficulty depends on details nobody checks until work starts: undocumented fields, rate limits, a sandbox that behaves differently from production. Naming them in the scope forces someone to look before the price is fixed.
Data model notes belong here too — not a full schema, but the main entities and the records that must survive a migration.
4. Non-functional requirements
Performance, security, accessibility, availability, data retention. These are the requirements that are invisible when met and expensive when discovered late.
Keep them measurable. “Fast” is not a requirement. “Search results return within one second for a catalogue of 50 000 products” is. “Secure” is not a requirement. “Personal data is encrypted at rest, access is logged, and the application passes an external penetration test before launch” is.
If you do not know the right number, write the question down instead of leaving the section empty. An open question is visible; a missing requirement is not.
5. Assumptions — what we are taking as given
Every estimate rests on things the estimator believes to be true. The scope should list them, because each one is a place where the price can change.
Typical assumptions:
- The client provides final copy and product data before the build milestone starts.
- The payment provider’s sandbox is available and matches production behaviour.
- Existing customer data can be exported as CSV with unique identifiers.
- One round of design revisions per screen group.
An assumption written down can be checked, challenged, or turned into a task. An assumption left in the estimator’s head becomes a change request the day it proves false — and at that point the client has no way to know whether it was reasonable.
Wording that survives a dispute: “This estimate assumes X. If X is not the case, the affected work is re-estimated before it starts, and no work beyond the original estimate proceeds without written approval.”
6. Risks — what could move the timeline, named in advance
Assumptions are things believed to be true. Risks are things that might happen. The difference matters because risks get owners and responses.
For each risk, write what could happen, what it would affect, who watches for it, and what the response is. For example:
| Risk | Effect | Response |
|---|---|---|
| The ERP vendor’s API does not expose stock reservations | Checkout cannot hold stock during payment | Spike in week 1; fallback is a nightly reconciliation job, re-estimated separately |
| Key stakeholder unavailable during design review | Approval delays of one to two weeks | Named deputy with sign-off authority agreed at kickoff |
A risk section is not pessimism. It is the part of the document that tells you whether the team pricing your project has actually thought about it.
7. Exclusions — what is explicitly not in this price
This is the most valuable section in the document and the one most often missing.
Exclusions draw the edge of the work. They stop a reasonable-sounding request in month three from becoming an argument about what was “obviously included”. Typical exclusions: data migration beyond a stated date, content entry, a customer-facing portal planned for a later phase, native apps when the scope is a responsive web app, support after the warranty period, third-party licence fees.
Writing exclusions feels like negotiating against yourself. It is the opposite. A client who reads the exclusions before signing is never surprised by them later, and a partner who writes them never has to argue about scope with someone who feels misled.
Why the last three get skipped
Because they slow the sale down. Assumptions, risks and exclusions are the sections where the buyer realises the project is bigger, less certain or narrower than they hoped. A vendor who wants the signature this week has every reason to leave them out.
They are also the cheapest insurance available in software procurement. An hour spent on them before pricing costs almost nothing. The same conversation after a disputed milestone costs weeks, and sometimes the relationship.
A short checklist before you approve a scope
- Could two unrelated teams price this document and produce comparable numbers?
- Does every feature line have an actor and an observable result?
- Is every integration named, with direction, frequency and credential owner?
- Are the non-functional requirements measurable?
- Is there an assumptions list, and do you agree with every item on it?
- Does every risk have a response?
- Are the exclusions written, and have you read them?
If any answer is no, the document is not ready to be priced — and a price calculated against it is not ready to be signed.
This is the structure we use at ANASBRENT for every project before a partner is asked to quote. If you would like to see what it looks like for your own project, send us a paragraph about it.
