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.
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
- How to write a functional design documentA functional design document is the reference a system is priced, built and accepted against.
- Why software projects fail at requirements, and how to stop scope creepWhen a software project fails, the code gets the blame.
- How to choose a software development companyPortfolios and testimonials tell you a firm has built things.
Related services
Need requirements analysis?
30 minutes, free. Bring the problem, or the change you already have in mind.