Technical Analysis & Requirements Engineering
Turn a rough idea into a specification that can be priced, built and tested — before a single line of code is written
Technical analysis is the discipline of converting a business idea into a precise, testable specification: what the system must do, who uses it, what data it holds, what it integrates with, and what it must never do. It is the cheapest phase of any project to change, and the most expensive to skip. Most failed software projects were not badly built — they were badly specified.
In short
- What it produces: a Software Requirements Specification, user stories with acceptance criteria, data model, API contracts, wireframes, and a costed delivery plan.
- Why it matters: ambiguity discovered during analysis costs a conversation; the same ambiguity discovered during development costs a rebuild.
- Vendor-neutral by design. The documents belong to you and can be handed to any development team, including one that is not us.
- Fixed scope, fixed price. Analysis is a defined engagement with a defined deliverable, not an open-ended consulting retainer.
- Useful even mid-project — for rescuing a build that has drifted, or documenting a system nobody has written down.
Requirements You Can Test
Every requirement is written so that it can be verified. "The system should be fast" is not a requirement; "search returns results in under 500ms for 50,000 records" is.
Architecture Before Code
Data model, integration points, authentication approach and scalability path decided deliberately, rather than emerging by accident during the sprint.
A Number You Can Budget Against
A specification detailed enough to be estimated properly — and to hold a supplier to the estimate they gave you.
Vendor-Neutral Documents
You own the output. It can go to tender, to your in-house team, or to another agency. We are comfortable being measured against that.
What Technical Analysis Produces
These are the concrete artefacts delivered at the end of the engagement. Which of them apply depends on the project, and we agree the list up front.
| Deliverable | What it contains | Who uses it |
|---|---|---|
| Business Requirements Document (BRD) | The business objective, stakeholders, success measures, constraints, and what is explicitly out of scope. | Management and project sponsors |
| Software Requirements Specification (SRS) | Functional and non-functional requirements, each numbered, prioritised and testable. | Developers, QA and any bidding supplier |
| User stories & acceptance criteria | Every feature written from the user's perspective with the exact conditions that make it "done". | Development and QA teams |
| Data model (ERD) | Entities, relationships, key fields, and retention rules — the shape of your data before anyone builds a table. | Backend and database engineers |
| Integration & API contracts | Every external system touched — payment gateways, ERP, SMS, shipping, identity — with the contract for each. | Backend engineers and third-party vendors |
| Wireframes & user flows | Low-fidelity screens and the path a user takes through them, agreed before visual design begins. | Designers and stakeholders |
| Risk register | What could derail the project, how likely it is, its impact, and the mitigation for each item. | Project sponsor and delivery manager |
| Estimate & phased delivery plan | Effort per module, a recommended MVP boundary, and a phase plan that delivers value before the whole system is finished. | Budget holders |
If your project is genuinely small and well understood, we will tell you that a lightweight brief is enough rather than sell you a full analysis engagement.
When Technical Analysis Pays For Itself
Before a New Build
You have an idea and quotes that vary wildly. That variance is almost always a specification problem, not a pricing one.
Rescuing a Drifting Project
A build that has lost its shape: scope keeps growing, nobody agrees what "finished" means, and deadlines keep moving.
Documenting a Legacy System
A working system that exists only in the heads of one or two people, with no documentation and real key-person risk.
Preparing a Tender
You need suppliers bidding on identical, unambiguous requirements so their prices can actually be compared.
How We Run the Engagement
- Stakeholder interviews — with the people who will actually use the system, not only the ones who commissioned it. The gap between those two groups is where projects fail.
- Process mapping — how the work is done today, including the spreadsheets and workarounds nobody mentions in the first meeting.
- Requirements workshops — structured sessions to turn what we heard into numbered, prioritised, testable requirements.
- Technical design — data model, integration contracts, architecture and technology recommendations with the reasoning written down.
- Estimation and phasing — effort per module, a defensible MVP boundary, and a delivery sequence that ships value early.
- Review and sign-off — a walkthrough with your team, revisions, and a final document set you formally approve.
The Sequence We Follow
- Kick-off — we agree objectives, who we need to speak to, and exactly which documents you will receive.
- Discovery — interviews, process observation, and review of any existing systems, data and documentation.
- Analysis — we turn findings into structured requirements and identify every conflict, gap and assumption.
- Design — data model, integrations, architecture, and wireframes for the main flows.
- Estimation — effort, phasing, and an MVP recommendation with the trade-offs stated plainly.
- Handover — full document set, a walkthrough session, and the files in editable form so they stay useful as the project evolves.
Frequently Asked Questions
Is technical analysis not just part of development?
It should be, and on our own builds it is. It becomes a separate engagement when you want to compare suppliers on equal terms, when the project is large enough that a wrong architectural decision is expensive, or when you want the specification to exist independently of whoever builds it.
Can I take the documents to a different development company?
Yes, and some clients do exactly that. The deliverables are vendor-neutral and yours to use. We would rather you commission a good specification and go elsewhere than commission nothing and end up with a failed project.
How long does technical analysis take?
It scales with the number of stakeholders and the complexity of the integrations, not with the size of the eventual codebase. A focused single-product scope is measured in weeks; a multi-department enterprise system with several integrations takes longer. We give a fixed timeline after a scoping call.
We already have a developer. Is this still worth it?
Often more so. A capable developer with an ambiguous specification will build something reasonable that does not match what the business expected — and the gap only appears at demo time. Analysis makes the expectation explicit before that happens.
What if analysis shows the project should not go ahead?
Then it has already paid for itself. We have told clients that an off-the-shelf product would serve them better than a custom build, and that a proposed feature would not recover its cost. That answer is part of the service, not a failure of it.
Do you use a specific methodology?
We use IEEE-style requirements structure with Agile user stories and acceptance criteria — structured enough to be contractually meaningful, flexible enough to survive contact with a real project. We adapt to your existing process rather than imposing ours.
Can you analyse a system that is already live?
Yes. Reverse-documenting a live system is a common engagement: we map current behaviour, data model and integrations, identify undocumented logic and key-person risk, and produce the specification that should have existed from the start.
Specify It Properly Before You Build It
Free scoping call and a fixed-scope, fixed-price analysis proposal
