Case study
Turning a tax filing brief into requirements a team could build from
The client needed an income tax return filing platform, but nobody inside owned the conversation between stakeholders and engineering. We ran the business analysis and solution work so their development team had documents they could estimate and build from.
ClientAn IT services and consulting firm.
Business Analysis & Solution ArchitectureFinancial Services
Tech stack
- AWS
- UML
- Microservices
- Node.js
- React
- Typescript
The problem
The brief existed. The specification did not.
They wanted to build an income tax return filing platform. What they did not have was someone to sit between the stakeholders and the development team.
Low-level requirements were not written down, so the brief was hard to hand over. They also needed a practical technical direction — what the platform should contain, and how it should be built — before anyone started estimating.
What we did
Business analysis and a build-ready specification
We came in as the business analyst. Workshops first, then two documents the business and the technical team could both use.
01
Requirement gathering workshop
- Sat with stakeholders in one working session instead of collecting the brief in fragments
- Got a shared view of what the platform had to do before anyone started writing it down
02
Business Requirement Document
- Captured the collected requirements in one place
- Gave every stakeholder the same reference for later stages
03
Functional Specification
- Scope, functional and non-functional requirements, roll-out strategy and development approach
- Platform components, modules and mock-flows detailed enough for a development team to work from
04
Technical direction
- A suggested path for implementing the platform, not just a list of features
- Enough structure for their technical team to estimate the build
What changed
A specification the business and the build team could share.
Shared understanding
- Stakeholders had one Business Requirement Document to refer to
- The brief stopped living in meetings and email threads
A channel between business and engineering
- The Functional Specification gave both sides the same language
- Scope, modules and mock-flows were written down before build started
A path into implementation
- Their technical team could estimate the work from documented requirements
- Project scope, development approach and platform components were aligned before anyone wrote code
What this unlocked
The client did not leave with a half-built product. They left with a scoped specification and a technical direction — enough to estimate, staff and start the income tax return filing platform without guessing at the brief.
Have a platform idea that still lives in meetings?
Tell us who needs to agree, and what the development team is waiting on. We'll help you get the requirements and the technical direction on paper.