Requirements analysis: turning wishes into requirements you can estimate
By Lukas Ebner, founder of Leadtime · Updated: November 2026
Requirements analysis turns a client’s wishes into testable requirements: what is meant, how much of it, and how will you know it has been met? For a service provider it starts with the first call and ends with work packages: parts with a testable result that can each be estimated. The result is written up in the functional specification (German: Pflichtenheft).
In brief
A wish becomes a requirement once it can be tested.
Clients describe what they want in their own words. Requirements analysis translates that into the language of delivery. Afterwards it is clear what is meant, how much of it is needed and how you will know it has been met. Asking like this before quoting avoids misjudgements and gets you the information needed for a sound quote. An example from the fictional case in the book, in which the insurance group Auenhof commissions the service provider Hanselink to build a broker portal:
The client’s wish
“Brokers should find everything in one place.”
Requirement
“Document storage per broker, filterable by company and line of business, access via the broker role.”
And requirements engineering? How requirements analysis, requirements engineering and requirements management fit together is explained in the guide. Four terms →
To take away
Ten questions for the first call.
For the first conversation with a client, before you check a requirements specification (German: Lastenheft) or name a price. The answers show what the client is really after and who decides in the end. Already have the requirements spec? Go straight to the breakdown or the guide for clarification calls.
- What should be different after the project compared with today? How will you notice?
- Why now? What happens if the project comes six months later?
- Who will use the result, and how many of them are there?
- Which systems does the result have to work with, and who looks after those systems?
- What data already exists, and where is it?
- What have you already tried, and why was it not enough?
- Who decides, who pays, who accepts the result?
- Which deadline is fixed, and why?
- What matters most to you: deadline, budget or quality?
- What must we not get wrong under any circumstances?
How to ask: Christof Ebert advises keeping questions as open as possible, so that they cannot be answered with yes or no. Only then do you hear how the client thinks and what they take for granted. What-if questions are productive too: what would be dropped if the budget were smaller? What if a particular requirement cannot be delivered? The answers reveal priorities that no requirements spec contains. To close, he recommends three questions: are you the right person for this topic? Who else should we talk to? Is there anything we have not asked about?
No sign-up. The questions come from appendix A2 of the book “Projects that pay off.”
What is different
Estimate from the bottom up: break it down into three levels.
Nobody can say with confidence how long “setting up the platform” will take. But almost anyone on the team can say how long it takes to create and test a role with twelve permissions. So break the project down into parts that can be estimated one by one. Breaking it down also shows you what you do not know yet. The three levels follow the book. In Scrum, an epic is similarly a large unit that is broken down into smaller user stories. Here the smaller units are called work packages, and they are what gets estimated and quoted.
-
Level 1
Epic
A big theme of the project, such as languages or data migration. An epic is not estimated. Its effort is the sum of its packages.
ExampleLanguages
-
Level 2 · estimated here
Work package
The unit you estimate, quote and describe in the functional spec. It has a testable result: “broker role created and tested”, not “roles”.
ExampleSet up languages, 18 hrs
-
Level 3
Task
The steps the team works through, later the ticket on the board. Tasks do not appear in the quote. They are the team’s business.
ExampleAdd French, Italian, English
Five rules for a good work package are on the functional spec page: a testable result, one owner, an estimate you can stand behind, clear to the client, and it recurs. Five rules →
Tip from the book: break it down in pairs. One person does the breaking down, the other asks for every package: “How will we know it is finished?” and “What do we need to know from the client for it?” The answers to the second question become your questions for the client.
How the packages go into the functional spec is explained on the page Functional specification →
What it looks like
Requirement, questions, options, effort: the “multilingual” example.
Between a requirement and an estimate there are two steps. First the requirement becomes questions: what do you need to know to deliver this line? Then the questions become options, and each option has an effort. In the fictional case from the book, the line “The platform must be multilingual.” hides twelve questions. Six of them change the effort.
- Requirement“The platform must be multilingual.”
- Question“Who translates?”
- OptionsThe client supplies finished translations. The provider coordinates a translation agency. Machine translation, checked by the client.
- EffortIf the client supplies them, it is almost nothing. If the provider coordinates, it costs a few hours of coordination per language, and a new package is added.
In the case, the six questions lead to four work packages totalling 82 hours, and none of them had been quoted. All the questions, answers and packages are in the full example. See the breakdown in the example →
Fictional case from the book “Projects that pay off.” (chapters 3 and 7). The full example from requirements to quote →
Step by step
Guide for clarification calls: one hour per package or epic.
You close the gaps in the requirements spec in short video calls with a shared screen. Each call is about one work package or epic, with the people on the client side who know about it. If it concerns an interface, the client’s own service provider joins the call. You write the questions in advance and record the answers on the spot. After each call, short minutes go to the client with a request for approval.
- 1
5 minutes
Clarify the goal
“What should be different for you after this package compared with today?”
- 2
10 minutes
Have them show the current state
The client shares their screen and shows how it works today. This is where you find half the answers before you ask.
- 3
25 minutes
Go through the prepared questions
One question after another. Write the answer down straight away and read it back.
- 4
10 minutes
Quantities and exceptions
“How many?”, “Are there cases where it works differently?”, “What happens if …?”
- 5
5 minutes
Record client responsibilities
“What do we need from you, by when, and from whom?”
- 6
5 minutes
Summarise
Three sentences on what has been agreed and what remains open.
The problem
Dependencies belong in the functional spec, with names.
Breaking things down reveals packages that cannot start until another one is finished. The templates can only be translated once the client has approved the German versions. Data migration can only run once the roles are in place. The CRM integration can only be tested once the client’s own service provider has delivered their part.
Write each one into the functional spec: who delivers what by when? Dependencies on the client are the dangerous ones, because they are outside your planning. If the spec says when the client delivers and what happens if it does not arrive, waiting turns into a change request.
What you deliberately leave rough
- What you have done many timesIf a package always took between 14 and 18 hours for the last twenty clients, one package of 16 hours is enough. You do not need ten sub-packages.
- What you cannot know yetFor an interface without a description, a detailed breakdown would be false precision. A separate “analysis” package with a fixed effort works better. Its result is a description you can use to estimate the actual package.
- What the team decides for itselfHow the developers build a feature technically does not belong in the breakdown for the quote. That is settled when packages become tasks.
Covered in detail in chapters 7 and 8 of “Projects that pay off.” About the book →
Frequently asked questions
What people often ask.
What is the difference between requirements analysis and requirements engineering?
Requirements engineering is the broader term: eliciting, documenting, validating and managing requirements throughout the project. Requirements analysis is one part of it. It elicits requirements and clarifies them until they can be tested and estimated. In everyday use, the two terms are often used interchangeably. More in the guide.
How long does requirements analysis take?
It depends on the scope and on how well the client takes part. Two reference points from the fictional case in the book: a single line such as “multilingual” can be broken down in under an hour, and a clarification call on one package or epic takes about an hour. Where the functional spec is sold as a separate service on larger projects, the book mentions two to four weeks of clarification.
Who does the requirements analysis?
On the provider side, the project lead who will later write the functional spec, ideally in a pair: one breaks things down, the other asks questions. On the client side, the people who know the topic in question. For interfaces, the service provider who looks after the other system joins in.
Which methods are there?
The usual ones are the interview, such as a first call with a fixed set of questions, and the workshop with several people involved. Having the client show you on screen how things work today is very productive. Then there is working through existing documents such as the requirements spec, forms and reports. For real unknowns, a small prototype helps. More important than the method is that every answer is recorded straight away and approved by the client.
The specialist literature advises combining methods, because each one on its own leaves blind spots. An interview mainly brings out what the client knows consciously. What they take for granted, and therefore never mention, you are more likely to see by watching them at work.
What is the result of requirements analysis?
A structure of epics and work packages, each package with a testable result and an effort. On top of that come assumptions, exclusions, client responsibilities and dependencies. Written up, that is the functional spec. The binding quote follows from it, often preceded by an indicative quote: a first price, not yet binding, with a status for each item.
Is there an example of requirements analysis?
Further up this page: the route from “multilingual” via questions and options to effort. All the questions and packages, and the whole route from requirements spec to quote, are in the software project example.
Read on
Where to go next.
Next step
Got a requirements spec from a client? Turn it into a functional spec.
Upload the requirements spec and answer ten questions at most, only the ones that change the effort. You get a structured draft functional spec with your logo, as Word and PDF. Anything still unclear is marked as open. You estimate the hours yourself.
- Freeno account, email address optional
- 10 questions at mosteverything else is marked as open in the spec
- Word and PDFwith your logo and colour