Spec generator

Guide: the route from requirements spec to quote

Overview: the route in five stepsFrom the client’s requirements spec to a binding quote, step by step. Requirements spec or functional spec?The basics: who writes what and what comes first. Step 1: Check the requirements specWhat goes in it and whether it is enough for a fixed price. Step 2: Requirements analysisBreak the spec into epics and work packages you estimate one by one. Steps 3 and 5: Indicative quoteName a price before the functional spec is done. Step 5: when it becomes binding. Step 4: Functional specClarify and write it after the award, including the sections that are often missing.
ExampleBroker portal: from requirements spec to quoteThe fictional case from the book. Steps 1 to 4 on one line: “multilingual”.See the example →
GuideOverview: the route in five stepsRequirements spec or functional spec?1Check the requirements spec2Requirements analysis3Indicative quote4Functional specExample: broker portal
Requirements managementHomeTemplates
MoreThe bookWhat is Leadtime?
Functional spec generator
A woman reads an open reference book at her desk, next to notes and a closed laptop.

Managing requirements: the essentials in five steps

From the client’s requirements spec to a quote that holds. Each step has its own page with a checklist or template.

By Lukas Ebner, founder of Leadtime · Updated: November 2026

Requirements management means capturing requirements, clarifying them, writing them down and tracking them through to acceptance. For IT service providers and agencies, it decides whether a fixed price holds. The usual route takes five steps, from the client’s requirements spec via an indicative quote and the functional spec to a binding quote.

The problem

One line in the spec, 82 hours of work.

Requirements specs are usually written on the side, by people who rarely write one. “The platform must be multilingual” sounds clear. For the service provider it hides twelve questions, six of which change the effort: which languages? What gets translated? Who translates? If you don’t ask before you quote, you sell the work at a fixed price without knowing what it involves.

Fictional case from the book “Projects that pay off.” (chapter 7): the insurance group Auenhof commissions the service provider Hanselink to build a broker portal. 82 hours if the provider coordinates the translations, 16 hours less if the client supplies them. The full example →

  1. 1line“multilingual”
  2. 6questionsthat change the effort: languages, areas, who translates …
  3. 4packageswork packages, each with a testable result, estimated one by one
  4. 82hoursquoted: 0 hours

Step by step

From requirements to a quote that holds.

Five steps, in this order. This is how it usually goes: the client wants a price before the functional spec exists. So an indicative quote comes first, and the functional spec only after the contract is awarded. Each step has its own page with a checklist or template.

  1. 1

    Check the requirements spec

    Ten questions show whether it is enough for a fixed price. Every no becomes an assumption in the quote.

    Requirements checklist →
  2. 2

    Break it into packages

    First epics, the big themes of a project. Below them, work packages: parts with a testable result that are estimated one by one.

    Requirements analysis →
  3. 3

    Give an indicative quote

    A first price before the functional spec, not yet binding. Every item gets a status: firm, based on assumptions, range or open.

    Indicative quote →
  4. 4

    After the award, clarify and write the functional spec

    Short calls per package or epic, with minutes. They feed the functional spec, including the sections that are often missing: exclusions, client responsibilities, assumptions, acceptance criteria.

    Functional spec →
  5. 5

    Give a binding quote

    Once the functional spec is approved, the price usually becomes binding. Anything beyond it goes through as a change.

    From indicative to binding quote →

Read on

All articles at a glance.

One article on the basics and one for each step, plus the worked example. In the order of the route, each stands on its own.

  1. BasicsRequirements spec or functional spec?The difference in one table: who writes what and what comes first.
  2. Step 1The requirements specWhat goes in it and who writes it. With a checklist: is it enough for a fixed price?
  3. Step 2Requirements analysisHow wishes become requirements you can estimate: first call, breakdown into packages, clarification calls.
  4. Steps 3 and 5Indicative quoteName a price before the functional spec is done: each item firm, based on assumptions, a range or open. And when it becomes binding.
  5. Step 4The functional specThe ten sections, including the ones often missing, and how to write it in three steps.
  6. Example, steps 1 to 4Broker portal: from requirements spec to quoteSteps 1 to 4 on the fictional case from the book: the insurance group Auenhof commissions the service provider Hanselink to build a broker portal.
Lukas Ebner sits at his desk in the office, screens behind him.

If you ask the right questions early, you get better information and come across as more competent.

Lukas EbnerFounder of Leadtime, in the book “Projects that pay off.”

In brief

Four terms, one process.

They often get mixed up. This is how they fit together.

Requirements management
Looking after requirements throughout the project: agreeing them, managing changes and versions, tracking what has been delivered. Up to acceptance and beyond.
Requirements Engineering
The term used in textbooks and standards, and the broader one: eliciting, documenting, validating and managing requirements. Requirements management is the managing part. In everyday use, both mean much the same.
Requirements analysis
The step that turns wishes into testable requirements: what exactly is meant, how much of it, and how will you know it has been met?
Requirements spec and functional spec
The two documents. The client writes the requirements spec (German: Lastenheft): what they want. The service provider writes the functional spec (German: Pflichtenheft): how they will deliver it. The difference in detail →

What is different

Agile delivery, fixed quote.

“We work in an agile way” does not answer the client’s question about price and date. For service providers running several client projects, a middle way usually works: plan precisely up to the approved functional spec, then deliver flexibly within that scope. New wishes go through as change requests.

How this middle way shows up in a quote: Indicative quote →

Plan precisely

fixed scope, fixed price
  1. Requirements spec
  2. Clarify questions
  3. Functional spec approved
binding quote

Deliver flexibly

order flexible, scope fixed
  1. New
  2. In progress
  3. Feedback
  4. Done

Frequently asked questions

What people often ask.

What typically goes wrong with requirements?

The specialist literature on requirements engineering names three risks: requirements are missing, they are misunderstood, or they change without anyone managing the change. The line “The platform must be multilingual” contains the first two at once. The third starts on day one of the project.

Is requirements engineering the same thing?

In everyday use, yes. Strictly speaking, requirements engineering is the broader term, and requirements management is the part that looks after requirements throughout the project: changes, versions, traceability.

Who is responsible for it?

On the client side, a project lead who writes the requirements spec. On the provider side, the project lead who writes the functional spec and manages changes. In small firms that is often the managing director.

Which standards apply?

In Germany, DIN 69901-5:2009 (project management, project management systems, part 5: terms) defines Lastenheft and Pflichtenheft. It does not prescribe a structure. For automation projects, the guideline VDI/VDE 3694 covers both documents in more detail. Internationally, ISO/IEC/IEEE 29148 describes requirements engineering for systems and software. A good spec needs none of them; a clear structure is enough.

How often do requirements change during a project?

All the time. Christof Ebert gives an average of 1 to 5 per cent a month, relative to the project effort, observed in hundreds of projects across many industries. In projects for individual clients, he says, requirements almost always change. He therefore advises working from exactly one approved baseline on which the estimate and the plan are based. Every change is assessed and decided before anyone works on it, including the small one agreed over the phone.

When are the requirements precise enough?

When everyone involved understands the goal and the requirements in the same way and you can stand behind the effort for every package. No project is fully clarified before it starts. The specialist literature warns against analysing until nothing is left open. Take anything disputed out, or carry it forward as an open point, rather than holding up the start. In the indicative quote, such a point gets the status open.

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.

Create a functional specTalk to Lukas Ebner instead