Key takeaways
- A brief records decisions, not designs: it answers the questions that would otherwise be argued about mid-build.
- Two to four pages is the right length. If nobody can read it in ten minutes, it will not be read.
- Every requirement should name who does what, in which system, and how you would know it worked.
- Separate the first release from everything else explicitly, because an unranked list is the same as no ranking.
- A partner who asks hard questions about your brief is reducing your risk, not stalling the project.
Most software projects that disappoint were agreed on a shared misunderstanding. Everyone in the room nodded at "a portal so clients can send us documents", and nobody established whether that meant a form, a secure inbox, a workflow with approvals, or all three connected to the practice management system. The brief is where that ambiguity gets resolved cheaply, while it is still a conversation rather than a change request.
What is a requirements brief, and what is it not?
A requirements brief is a short document that states the business problem, who the software serves, what it must do first and how you will know it worked. It is a decisions document. Its job is to settle the questions that would otherwise be argued about halfway through development, when changing the answer is expensive.
It is not a design document, a technical specification or a pitch deck. It does not need screen layouts, a database schema or a technology preference. Those come later, from people who are good at them, informed by what the brief decides.
The case for spending a week on it is well documented. PMI research on requirements management found that inaccurate requirements management is the primary cause of failure in 47% of unsuccessful projects, and that 5.1% of every dollar spent on projects and programs is wasted because of poor requirements, which works out at US$51 million for every US$1 billion spent. The same research found only about half of organizations (49%) report having the resources in place to do requirements work properly.
What belongs in the brief?
Eight sections cover what a partner needs. Write them in this order, because each one makes the next easier to answer.
1. The business problem
Two or three sentences on what is going wrong, for whom, how often and what it costs. Be specific enough to be checkable.
Weak: our onboarding process is inefficient. Strong: onboarding a new client takes 11 working days, because four teams collect overlapping documents by email and nobody can see where a file is until someone asks.
2. Users and roles
List every group who will touch the software and what each one can see and do. Include the administrator, the occasional approver and anyone outside the company. Roles drive screens, permissions and testing, so this list is the single biggest influence on size.
For each role: who they are, what they need to accomplish, how often they use it, and on what device.
3. How the process works today
Walk the current process step by step, naming the systems and the handoffs. Include the exceptions, because exceptions are where most of the effort goes: the client who sends documents by post, the order split across two warehouses, the approval that needs two signatures over a threshold.
Say what people do when something goes wrong today. That workaround is usually a requirement in disguise.
4. Must-have versus later
Two explicit lists. The first is what has to work for the first release to be usable by real people in real work. The second is everything else, in rough order.
An unranked list is the same as no ranking, so force the distinction: if this feature were missing on launch day, would anyone still use the software? If yes, it belongs in the second list.
5. Systems and data
Name each system the software must read from or write to, the direction of travel, how current the data needs to be and who administers access. Note anything migrating, roughly how many records and how clean they are.
This section deserves care. The 2025 MuleSoft Connectivity Benchmark Report found that the average enterprise manages 897 applications with only 29% of them integrated, and IT teams spend 39% of their time building custom integrations. Integration is usually the part of an estimate that moves most once reality arrives, so state what you know and flag what you do not.
6. Constraints
Anything that limits the solution: security and compliance obligations, single sign-on, data residency, retention rules, accessibility standards, a date driven by a real external event, systems that cannot be changed, an internal team that must be able to maintain the result.
Say which constraints are genuinely fixed and which are preferences. Treating a preference as a constraint quietly removes good options.
7. Success measures
How you will judge this in three months. Not "the software is delivered", which is a delivery milestone, but something measurable against a baseline you can state today.
Examples: client onboarding drops from 11 days to 5. Ninety percent of stock counts are submitted from the app rather than on paper. Exception handling time per order falls below 4 minutes.
8. Ownership and decisions
Name the business owner who decides when there is disagreement, the process owner who knows the work, the technical contact who can grant system access, and who will own the software after launch. Give a response time for decisions, because waiting for answers is one of the most reliable sources of delay.
What does a strong requirement statement look like?
The difference between a brief that gets built correctly and one that does not is usually specificity at the sentence level. Every requirement should say who does what, in which system, and how you would know it worked.
| Weak statement | Why it fails | Stronger version |
|---|---|---|
| The system should be user friendly | Nobody can build or test it | A branch manager completes a stock count on a phone in under 10 minutes with no training |
| It needs to integrate with our ERP | No direction, records or frequency | Approved purchase orders write to NetSuite within 5 minutes; supplier records refresh hourly |
| Performance must be fast | Not measurable | Search returns results in under 2 seconds against 200,000 records |
| It should handle exceptions | Which exceptions, and then what | If a delivery arrives short, the driver records the shortfall and it routes to the depot supervisor for approval |
| The portal must be secure | Means different things to everyone | Staff sign in with Microsoft Entra ID single sign-on; only the finance role sees pricing; every change is logged with user and timestamp |
| We need reporting | No report, no reader, no decision | Operations managers export a weekly file of exceptions by depot to review in the Monday meeting |
Rewriting six vague lines into six testable ones is often the highest-value hour in the whole process, because each one becomes something a developer can build and a user can confirm.
Illustrative example: Consider a specialty retailer with 40 stores scoping a stock-count app. The first brief says the app should make stock counts easier and work offline. In a review session the team rewrites it: three roles (store staff, area manager, head office), counts submitted from a phone in under 10 minutes, offline capture with sync when the device reconnects, variances over 5% routed to the area manager, results written to the existing inventory system nightly, success measured as counts submitted on time rising from 62% to 90%. Nothing in the second version is more ambitious than the first. It is simply decided, so suppliers can quote the same thing and the team can tell whether it worked.
What should you leave out?
Briefs get weaker when they get longer. Leave out:
- Solution design. Screens, database structure and technology choices. Say what has to be true and let the design work explore how.
- Every possible feature. A wish list flattens priority and inflates every estimate you receive.
- Vendor language. Phrases copied from a product you saw import that product's assumptions.
- Unowned aspirations. Anything nobody is accountable for is not a requirement.
- A forty-slide deck. Extract the decisions into the brief. Attach the deck as background if it helps.
What does a good partner ask back?
The brief starts the conversation rather than ending it. Expect a serious partner to come back with questions like these, and treat their absence as a warning sign:
- Who decides when two of your stakeholders disagree?
- What happens today when this goes wrong, how often, and what does that cost?
- Can we see the real data, including the messy records?
- Which of your must-haves would you launch without, if the date were fixed?
- Who owns each system we need to connect to, and can they grant access before we start?
- What is the baseline for each success measure today?
- Who will run and maintain this after launch, and what skills do they have?
- What have you already tried, and why did it not work?
- What is the deadline actually driven by?
These questions reduce your risk. A supplier who quotes a firm price without asking any of them is pricing a guess, and you will meet the difference later as a change request. Our guide to what drives the cost of custom software explains which answers move a number most.
How do you handle change after the brief is agreed?
Requirements move, and a process that pretends otherwise just pushes the change underground. Handle each one as a miniature brief: what has changed, why, which requirements it affects, what it does to scope, cost and date, then a recorded decision from the named owner.
Two habits make this work. Keep the brief as a living document with a version history, so there is always one current answer. And review the must-have list at each release, because things that felt essential in month one are often quietly obsolete by month three.
The economics justify the discipline. CISQ estimated that the cost of poor software quality in the US had reached $2.41 trillion, with about $1.52 trillion of that in accumulated technical debt, the cost of reworking suboptimal software. A large share of rework traces back to work built against a requirement that was never really agreed.
How Kastling approaches requirements
Kastling is an AI solutions and implementation partner, and we work from the same principle in every engagement: understand the work before the technology. A brief written in the format above is a strong starting point, and an incomplete one is fine too, because establishing the missing parts is part of the job.
An engagement starts with a free discovery call about a specific process and its owner. Where the current process is unclear or spans several teams, a separately scoped, paid audit interviews the people involved and reviews the workflows, systems and data to produce a current-state assessment, prioritized opportunities and a recommended approach. A well-defined brief can move straight to a scoped proposal instead.
Before development starts we agree scope, milestones, how success will be measured, and who owns the data, the code and the accounts. We involve the people who will use the solution, and we test against real business scenarios rather than ideal ones. Whether the answer is Custom Solutions or an integration between systems you already run is decided by the brief, not the other way around. If you are still weighing that choice, build, buy or integrate works through it.
Questions
How long should a requirements brief be?
Two to four pages for most business software, plus appendices for sample data, screenshots of the current process and any policy documents. Length is not a sign of rigor. A brief that nobody can read in ten minutes tends to be skimmed, which defeats its purpose.
Who should write it?
The person accountable for the business outcome, working with the person who actually does the work every day. Briefs written entirely by IT tend to describe systems rather than the process, and briefs written entirely by leadership tend to miss the exceptions that consume most of the effort. A committee produces a list of preferences rather than a set of decisions.
Do we need wireframes or designs in the brief?
No, and leading with them often narrows the solution too early. Include screenshots of the current process and any sketches you already have as reference material, clearly labeled as illustration rather than specification. The brief should say what has to be true; the design work then explores how.
What if we do not know some of the answers?
Write down that you do not know, and say who will find out and by when. An open question that is visible gets resolved in discovery. An open question hidden behind a confident sentence gets discovered halfway through the build, when it is far more expensive to answer.
How do we handle changes once the brief is agreed?
Treat each change as a small brief of its own: what changed, why, what it affects and what it does to scope, cost and date, then an explicit decision. The aim is not to prevent change, because requirements legitimately move. The aim is to make sure every change is a deliberate choice with a named owner.