Requirements Specification vs. Functional Specification: Difference, Content, and Template

The requirements specification (Lastenheft) describes, from the client's point of view, what is to be built and for what purpose. The functional specification (Pflichtenheft) sets out, from the contractor's point of view, how and with what these requirements are implemented. In short: the customer delivers the requirements specification, the service provider responds with the functional specification.

What Is the Difference Between a Requirements Specification and a Functional Specification?

The core difference lies in authorship and perspective: the requirements specification comes from the client and describes the requirements (the what and why), the functional specification comes from the contractor and describes the technical solution (the how and with what). Both terms are defined in DIN 69901-5 (2009).

Criterion	Requirements Specification	Functional Specification
Who creates it?	Client (customer)	Contractor (service provider)
Perspective	What & why	How & with what
Content	Requirements, goals, scope	Implementation specs, solution
Timing	First (before the tender)	Afterward (after the order is clarified)
Function	Basis for the proposal	Response to the requirements specification
Standard reference	DIN 69901-5, VDI 2519 Sheet 1	DIN 69901-5, VDI 2519 Sheet 1

What Is a Requirements Specification?

A requirements specification (Lastenheft) is, according to DIN 69901-5 (2009), the "entirety of requirements set by the client for the deliverables and services of a contractor within an order." So it describes what and for what purpose something is to be built.

The requirements specification formulates the client's point of view. It records which problem is to be solved and which goals the project must achieve, without prescribing the specific technical implementation. This keeps the solution space open, and the contractor can bring in their own expertise.

In practice, the requirements specification is the basis for the tender and the proposal. A client who specifies cleanly receives comparable offers and reduces the risk of misunderstandings and costly change requests later on.

What Is a Functional Specification?

A functional specification (Pflichtenheft), according to DIN 69901-5 (2009), comprises the "implementation specifications worked out by the contractor based on the realization of the requirements specification set by the client." So it describes how and with what the requirements are implemented.

The functional specification is the contractor's answer to the requirements specification. It links the customer's requirements to concrete technical implementation specs, including details on the operating and maintenance environment as well as the inclusion and exclusion of specific cases. In practice, every requirement in the requirements specification is linked to one or more concrete deliverables in the functional specification, so that no requirement remains unanswered.

This makes the functional specification the binding blueprint: it makes measurable what the service provider actually delivers and how the result will later be accepted.

Who Creates What, and in What Order?

The order is clear: first the client creates the requirements specification, then the contractor works out the functional specification. Only after the requirements specification has been created can the contractor draw up the functional specification (DIN 69901-5, 2009).

1. Requirements specification (client): defines requirements and goals, serves as the basis for the tender and the proposal.
2. Proposal and clarification: the contractor calculates the offer based on the requirements specification.
3. Functional specification (contractor): describes the concrete technical implementation.
4. Confirmation: the functional specification created by the contractor is usually confirmed by the client at the contractor's request.

Important: in practice, the requirements specification and the proposal often form the contractual basis; including both documents in the contract is advisable. The functional specification created by the contractor is usually confirmed by the client at the contractor's request (see Wikipedia, "Pflichtenheft," referencing DIN 69901-5, 2009).

What Content Belongs in a Requirements Specification?

A requirements specification typically contains the project context, the current and target state, interfaces, and functional and non-functional requirements. VDI 2519 Sheet 1 (issued 12/2001) provides a proven structure for this.

• Introduction / project context: starting situation and project goal.
• Current state: existing processes and systems.
• Target concept / goal definition: what is to be achieved.
• Interface description: connection to existing systems.
• Functional requirements: the business functions.
• Non-functional requirements: usability, reliability, efficiency, maintainability.
• Scope of delivery and acceptance criteria: what is delivered and when it counts as fulfilled.

What Content Belongs in a Functional Specification?

A functional specification describes the system-technical solutions for every requirement in the requirements specification. The functional-specification part of VDI 2519 Sheet 1 (12/2001) covers exactly this technical implementation level.

• Technical implementation: architecture, technologies, data model.
• Mapping to requirements: every requirement from the requirements specification is linked to concrete deliverables.
• Operating and maintenance environment: where and how the solution runs.
• Inclusion and exclusion: which cases are covered, and which are deliberately not.
• Acceptance and test criteria: how fulfillment is verified.

This creates a seamless trail from the requirement to the verifiable deliverable, the basis for a clean acceptance.

Requirements and Functional Specifications in a Software Project: Example and Structure

In software projects, the process typically runs as follows: the customer describes in the requirements specification, "We need a customer portal with login and an invoice overview," and the service provider responds in the functional specification with architecture, technology stack, and acceptance tests. This exact process shapes every structured SaaS development project.

Internationally, this requirements specification corresponds to the Software Requirements Specification (SRS). The earlier IEEE 830-1998 was replaced by ISO/IEC/IEEE 29148:2011 (updated 2018); IEEE 830 has officially been withdrawn but is still often referenced by name in practice.

A lean template structure for a software requirements specification: 1. objective, 2. current state, 3. functional requirements, 4. non-functional requirements, 5. interfaces, 6. acceptance criteria. The functional specification mirrors these points and adds the technical solution for each requirement.

Do I Need Both Documents, and Which Standards Apply?

In classic projects, both documents count as standard practice: the requirements specification creates comparability between proposals, the functional specification makes the deliverable binding. The central reference documents are DIN 69901-5 (2009) and VDI 2519 Sheet 1 (12/2001).

In agile projects, the strict separation is often softened: instead of extensive documents, product backlogs, user stories, and acceptance criteria take their place. The underlying idea remains the same, though: first the requirement (what), then the solution (how). How much depth makes sense depends on project size, budget, and risk.

FAQ: Common Questions About Requirements and Functional Specifications

What comes first, the requirements specification or the functional specification?

The requirements specification comes first. The client creates it as the basis for the tender and the proposal; only afterward does the contractor work out the functional specification (DIN 69901-5, 2009).

Who creates the functional specification?

The contractor (service provider) creates the functional specification. It contains their implementation specifications for realizing the requirements specification set by the client (DIN 69901-5, 2009).

Are the requirements and functional specifications part of the contract?

In practice, the requirements specification and the proposal often form the contractual basis; including both documents in the contract is advisable, though not mandatory. The functional specification created by the contractor is usually confirmed by the client at the contractor's request (see Wikipedia, "Pflichtenheft"). This is general information, not legal advice.

What is the difference in one sentence?

The requirements specification describes, from the client's point of view, the what and why; the functional specification describes, from the contractor's point of view, the how and with what.

Is there an international standard for software requirements?

Yes. The Software Requirements Specification (SRS) used to follow IEEE 830-1998; this was replaced by ISO/IEC/IEEE 29148:2011 (rev. 2018). IEEE 830 has been withdrawn but is still often mentioned.

Do I even need a requirements specification in agile projects?

Not necessarily in the classic form. There, requirements are captured through the product backlog, user stories, and acceptance criteria, but the separation of requirement and solution still remains.

Who is liable if the result does not fit?

That depends on the contract. For exactly that reason, the requirements and functional specifications should be part of the contract, with the approved functional specification defining the owed deliverable. This is general information, not legal advice.

Sources

• DIN 69901-5 (2009), definition of Lastenheft, cited via Wikipedia, "Lastenheft"
• DIN 69901-5 (2009), definition of Pflichtenheft, cited via Wikipedia, "Pflichtenheft"
• VDI 2519 Sheet 1, procedure for creating requirements and functional specifications (12/2001)
• IEEE SA, IEEE 830 standard page (withdrawn, replaced by ISO/IEC/IEEE 29148:2011, rev. 2018)

Note: this article is general information about project documents and does not constitute legal advice. As of June 2026, author: Alexander Weipprecht.