Before you commission a BI or software project: what a good requirements document contains
By MMT Consulting · · 6 min read
Most projects that go wrong did not fail at the build stage. They failed earlier, when the people asking and the people building held two different pictures of the same project. A requirements document is how you make those pictures match before any money is spent.
Start with the problem, not the solution
Write down what is wrong today in one or two paragraphs. Use the words your team uses. "Fee balances are disputed every month" is a better starting point than "we need a portal". A builder who understands the problem can often suggest something simpler or cheaper than the solution you first imagined.
Then say what success looks like and how you will know. A measurable outcome, such as fewer disputed invoices or a monthly report produced in one hour instead of three days, keeps the project honest later.
Describe how work is done today
List the people involved, the tools they use and the steps in order. Include the awkward parts: the spreadsheet that only one person understands, the manual re-typing between two systems, the approval that happens on WhatsApp. These are exactly the places a new system must handle, and they are the details most often forgotten.
List what the new system must do
Write requirements as short, numbered statements that a stranger could test. Separate what is essential from what would be nice to have, because that line decides the first release and the budget.
- Users and roles: who logs in, and what each role can see and change
- Core functions: the tasks the system must support, in the order people do them
- Reports and numbers: the figures leaders need, and how often
- Connections: other systems it must read from or write to, such as accounting software or a payment gateway
- Data: where it lives now, roughly how much there is, and how clean it is
Be honest about constraints
Say what the project cannot change: a go-live date tied to a new term or financial year, a budget ceiling, rules about where data may be stored, or a platform your team already pays for. A builder can design around a constraint they know about. They cannot design around one they discover in month three.
Agree what is out of scope
A short "not included" list prevents most arguments later. If mobile apps, data migration from old systems or staff training are not part of this phase, say so in writing.
Treat early numbers as estimates
Timelines and budgets in a first document are estimates. They become commitments only after a conversation that tests the assumptions behind them. A good partner will say so openly instead of quoting a confident figure from a one-page brief.