← All services

Requirements analysis and functional specifications.

The Business Analyst work, sold on its own. A specification a board can approve, a vendor can quote and a team can build from — or a fixed-fee review of the one you already have.

What we do

Discovery
Interviews with the people who do the work, not only the people who requested the system. The real problem is rarely the one stated first.
As-is process
How the work is done today, including the workarounds. Spreadsheets and email threads are requirements evidence, not noise.
To-be design
The target process, and which parts software changes and which parts people change. Much of what is asked for as software is a process problem, and saying so is part of the job.
Functional specification
Every requirement with acceptance criteria, plus business rules, the data model, integration points and non-functional constraints. If it cannot be tested, it is not finished.
Scope boundary
The out-of-scope list, the assumptions and the dependencies. This is what makes a fixed price possible, and what protects both sides from drift.
Validation and sign-off
The specification walked back through the stakeholders and agreed before anything is built — so disagreements surface on paper, where they are cheap.

Pick the depth

The same discipline at different weights. Each is quoted as a fixed fee after a free call.

Requirements review

You already have a specification or a backlog. We review rather than redo: ambiguity, missing acceptance criteria, unstated assumptions, integration gaps.

Review memo + gap list

2–5 days

Short-form FDD

One module, one workflow, or a spreadsheet process that needs to become a system. Focused discovery on that process, then the specification.

Short-form functional design

1–2 weeks

Full FDD

A platform, many stakeholders, or a process that carries compliance weight. Discovery across the business, as-is and to-be, full specification and architecture.

Full FDD + architecture and data model

3–6 weeks

Where it usually hurts

If one of these sounds familiar, it is the kind of problem we are called in for.

  • Three vendors quoted three different projects from the same brief.
  • The requirements say "user-friendly" and "integrates with the ERP", and nothing anyone can test.
  • The project is already underway and nobody can say what "done" means.
  • The real requirements live in a backlog of hundreds of tickets and in the head of someone who has left.
  • The board wants a fixed price, and nobody can honestly give one from what exists today.

Where this experience comes from

Our lead analyst's career history, described by sector — not an Elarion client list. More on the About page.

  • Business requirements and functional design documents for a CRM migration in a regulated public-health organisation, with current- and future-state processes and integration architecture.
  • Functional design specifications for an enterprise automation programme at a pension administrator, as business analyst and product owner: business rules, scope boundaries, acceptance criteria and the backlog.
  • Requirements, test scenarios and validation rules for a payroll migration at a transit authority — gross-to-net, CPP and EI, accruals, and T4 year-end — reconciled against legacy payroll runs.
  • Functional and technical specifications for ERP enhancements and integrations in forestry and food manufacturing, including the move from JD Edwards World to EnterpriseOne.

See a real one before you buy one.

The functional design document for this website, published in full apart from two internal sections. It is the format every engagement produces.

Questions buyers ask

Do we have to build with you afterwards?
No. The specification is yours, and it is written so any competent team can quote and build from it. Most clients do build with us — the analyst who wrote it leads the engineers who build it, so nothing is lost in translation — but the document does not depend on that.
We already have requirements. Can you just review them?
Yes. A fixed-fee review covers ambiguity, missing acceptance criteria, unstated assumptions and integration gaps, and returns a memo and a gap list in two to five days. If what you have is sound, the review says so.
Does this only suit waterfall projects?
No. The same discipline produces user stories with acceptance criteria for an Agile backlog as readily as a signed document for a fixed-price contract. What matters is that every requirement can be tested.
Can you work inside our team instead?
Yes. Embedded analysis on a retainer or day rate, working to your process and tooling rather than ours.
What does it cost?
Each depth is a fixed fee, quoted after a free call once the scope of the analysis is clear. We do not publish prices, because the honest answer depends on how many stakeholders and processes are involved.

Further reading

Related services

Need requirements analysis?

30 minutes, free. Bring the problem, or the change you already have in mind.

Book a discovery call