Business Analyst
We analyse your business processes, identify where they can be improved, and turn your needs into clear, actionable functional requirements. The role is as much about writing as about getting the right people to talk.
What we do
Process analysis and modelling
A description of the current state as it is actually practised, including the workarounds nobody documents, then a model of the target. Comparing the two makes visible what the project really changes for the teams.
Functional specifications
Testable requirements, traced back to the original need, written to be read both by the business that approves them and the technical team that builds them. A requirement nobody can verify is not a requirement.
Business and technical liaison
We interpret between two vocabularies that do not overlap. It is continuous translation work, not a kick-off meeting, and it is where most expensive misunderstandings are settled.
How we work
-
1
Listen before modelling
Interviews with the people who run the process, not only those who describe it. The gap between the two is often the real subject of the project.
-
2
Formalise and get sign-off
Readable models, numbered requirements, explicit approval by business owners. Implicit approval always turns against the project at acceptance time.
-
3
Support the change
A delivered specification changes nothing by itself. We stay through acceptance, training and the adjustments that appear on contact with reality.
What you get
- AS-IS and TO-BE process maps
- Functional specification pack
- Requirements traceability matrix
- Acceptance test plan and test data
- Training and change management material
Frequently asked questions
Do you use a particular notation?
BPMN for processes, use cases or user stories depending on how the project is run. The notation is chosen for whoever has to review it, not for methodological preference.
Can you step in before a project starts?
Yes, and it is often the best moment. Analysis done before a tool is chosen avoids buying a solution to a badly stated problem.
Do you also run acceptance testing?
Yes. Writing requirements then leaving before acceptance is the surest way never to learn whether they were right.
Let's talk about your project
Tell us about your situation and we will come back with a first reading and the questions that matter.
Contact us