Clarity first, code second
Most IT projects that go wrong were unclear long before they were late. Our analysts turn business needs into requirements your teams can build, test and defend, in words both business and IT understand.
A vague requirement is the most expensive line in the budget
Budgets are under scrutiny, experienced profiles are scarce, and NIS2, DORA and the EU AI Act expect organisations to explain how their systems behave. There is less room than ever for building the wrong thing.
Rework is a hidden cost
A misunderstanding found in testing or in production is paid for twice: once to build it, once to undo it.
Regulators ask why
When an auditor asks what a system does and on which rule, traced requirements and dated decisions give you the answer.
Knowledge walks out the door
Business rules that live in a few heads or in legacy code turn every departure and every migration into a risk.
What we do
Business analysis and process mapping
Understanding the processes, the people involved and the rules in force, as close to the field as possible, and drawing the process as it really runs.
Requirements
Stating what the solution must do, with concrete examples rather than long descriptions, and separating what is essential from what is nice to have.
Specifications
Precise acceptance criteria that developers can implement, suppliers can quote on and tests can verify.
Acceptance testing
Checking with users that what is delivered matches what was expected, before it reaches production.
Expertise & technologies
- Business and functional analysis
- Process mapping
- Requirements and user stories
- Acceptance criteria and test scenarios
- Data and integration analysis
- Peppol and e-invoicing flows
- Power Platform and Dataverse
- AI use-case scoping
How we work
- 01
Ask
A missing business rule is a question to ask the people who own it, never an assumption to make on their behalf.
- 02
Illustrate
Every requirement rests on real, numbered examples that become the test cases, so business and IT read the same thing.
- 03
Trace
Every decision is written down and dated, so that later on everyone knows why the system does what it does.
What changes for you
Decisions on solid ground
Scope, priorities and trade-offs are set out in business terms, so you decide with the facts on the table.
Fewer surprises at delivery
The examples written at the start become the tests run at the end, so what is built matches what was agreed.
A system you can explain
To an auditor, a regulator or a new colleague: the reason behind each rule is written down and dated.
Call us when
- A project is late and nobody agrees on what done means
- Business and IT describe the same need in two different ways
- You are replacing a legacy system whose rules nobody fully remembers
- An audit or a NIS2 or DORA review asks how a process really works
- Your developers are ready to build but the backlog is not
Two ways to work together
An analyst in your team
A business analyst or product owner embedded in your organisation, your tools and your rituals, for as long as you need them.
A turnkey analysis phase
A framed scope, a specification package and acceptance criteria, delivered ready for your developers or your supplier.
Questions we are often asked
Why pay for analysis when we could start building straight away?
Because changing a sentence costs less than changing a system. Analysis moves the hard questions to the moment they are cheapest to answer.
Do your analysts work in agile teams?
Yes. They write user stories with acceptance criteria, refine the backlog with the team and can take the product owner role. The method follows your organisation, not the other way round.
Can you analyse a system you did not build?
It is a frequent case. We rebuild the business rules from the people, the documents and the existing behaviour, then write them down so they no longer depend on anyone's memory.
How does analysis help with NIS2, DORA or the EU AI Act?
These frameworks expect you to know and document how your processes and systems work. Traced requirements and dated decisions provide that documentation as part of the project. They support your compliance work, they do not replace legal or audit advice.
A need that is still blurry?
Let's put it in writing before the first line of code is written.
