Learning outcomes

  • Explain what a specification is and how it differs from a requirements document

  • Write a requirement with a scenario that can be checked

  • Explain why a precise statement of intent became the scarce resource

  • Say what stays frozen and what stays alive, and why both are needed

  • Explain what a Lastenheft and a Pflichtenheft are, who writes each, and which parts of them survive in this course

  • Name the seven chapters of a Pflichtenheft, separate functional from non-functional requirements, and say what a Kriterienkatalog is for

The scarce resource moved

Producing code used to be the bottleneck. It is not any more: a competent agent turns a precise description into a working implementation faster than you can type it. What it cannot do is decide what should be true.

Cheap now Still expensive

writing the implementation

saying exactly what it must do

producing an explanation of anything

deciding which behaviour is correct here

generating tests that pass

knowing which behaviour must never break

A specification is where that decision is written down — in a form precise enough to build from and to check against.

Lastenheft and Pflichtenheft

Before comparing them with specifications, the two documents themselves. They are the classical pair of the German-speaking engineering world, they are what a client, a tender and the Manz textbook will call things, and DIN 69901-5 defines both.

Lastenheft Pflichtenheft

Written by

the client (Auftraggeber)

the contractor (Auftragnehmer)

Answers

what is needed and what for

how and with what it will be realised

Written when

before the tender, before any offer

after the contract is awarded, before building

Serves as

the basis for the tender and for comparing offers

the basis of the contract and of the acceptance

Contains

requirements from the user’s world, no technology

realisation requirements: functions, data, interfaces, quality, test cases

The order is the point: Anforderungserhebung → Lastenheft → offer → Pflichtenheft → build → acceptance against the Pflichtenheft. The client says what they need; the contractor answers with what they will build, in enough detail that both sides can later agree on whether it was delivered.

What a Pflichtenheft contains

The structure below follows the Manz textbook (chapter 7, lesson 2). Read it as one argument in seven steps: where the client stands, what they already have, what they want, what the system must do, how much of it, how an offer is to be handed in, and what is agreed around all of that.

Nr. Kapitel Inhalt

1

Beschreibung der Ausgangslage

kind and size of the organisation, locations, products and services, customer structure, how IT is organised, and the reasons for the procurement

2

Ist-Zustand

only the parts the project touches: Aufbauorganisation, Ablauforganisation with its business processes and the applications in use, the existing system platform

3

Zielsetzung

the goals with priorities, realistic and checkable — nutzenrelevante Ziele, Systemziele, Vorgehensziele

4

Anforderungen (Soll)

at the application software, at the system platform, and at the supplier

5

Mengengerüst

data movements, data volumes, number of concurrent users

6

Aufbau und Inhalt der Offerte

only in a tender: how an offer must be structured so that offers can be compared at all

7

Administratives

confidentiality, copyright, distribution list, budget, dates

The chain from chapter 1 to chapter 4 is what makes the document readable: an initial situation, the problem it produces, and only then the task derived from it. A requirement whose origin you cannot trace back to chapters 1 to 3 is usually somebody’s private wish.

Two chapters are regularly skipped and both are expensive. Ist-Zustand: the system is built into an organisation that already works somehow, and whatever it does today is what people will compare yours with. Mengengerüst: 30 members and 30 000 are not the same system, and you find that out either here or in production.

Functional and non-functional live in chapter 4

Chapter 4 carries two kinds of requirement, and telling them apart is the skill:

Art Was darin steht

funktional

the professional workflow and the data fields — what the system does

nichtfunktional

Effizienz, Leistung, Zuverlässigkeit, Robustheit, Benutzerfreundlichkeit, Datenschutz — how well it has to do it

A functional requirement you either implemented or you did not. A non-functional one only becomes a requirement once it carries a number or an observable condition: "fast" is not a requirement, "the attendance list of a group of 30 opens in under a second on the lab laptops" is.

Requirements are numbered, and that is not decoration. Numbering is what makes a requirement referable: a test case, a review comment and an acceptance protocol can all point at the same number and mean the same sentence. That is exactly the job a requirement id in openspec/specs/ does today.

The catalogue of non-functional characteristics: ISO/IEC 25010

"Non-functional" is a wastebasket word until you have a list. ISO/IEC 25010 is that list — the product quality model, nine characteristics, each with its sub-characteristics. Use it as a checklist when writing chapter 4: go through the nine, and for each one decide whether it matters here and what the measurable condition is. Most will not matter; the two or three that do are the ones that would otherwise have been discovered in production.

The colours in the diagram group the nine: the top row is what the user experiences, the middle row is how the system behaves and protects, the bottom row is what the developer lives with — plus safety, which sits with the protecting ones.

iso 25010 product quality

Own diagram; the characteristic names follow the current edition (ISO/IEC 25010:2023) as published at iso25000.com. The 2011 edition had eight characteristics: Usability has become Interaction capability, Portability has become Flexibility and gained scalability, and Safety is new. Older material — including much of what you will find while searching — still shows the eight.

Two characteristics carry a warning for school projects. Security is not a feature you add at the end; confidentiality and integrity decide the data model. And Safety only concerns you if your system can cause physical harm — in an attendance app the honest answer is "not applicable", and writing that down is better than inventing a requirement for it.

The Kriterienkatalog is a different document

Alongside the Pflichtenheft the client writes a second paper — for themselves. The Kriterienkatalog is internal, the supplier never sees it, and its purpose is to evaluate the offers that come in.

Kriterium Bedeutung

Muss- oder K.-o.-Kriterium

not met — the offer drops out. No weighting, no discussion

Wunschkriterium (Soll-Kriterium)

the better it is met, the better the offer is rated

Abgrenzungskriterium

informative — what is deliberately not wanted, so the supplier can size the offer correctly

Muss-, Wunsch- and Abgrenzungskriterien are frequently quoted as a section of the Pflichtenheft. They are not. Another document, another addressee, another purpose: the Pflichtenheft describes the system, the Kriterienkatalog evaluates the offers made for it.

What survives in this course

Im Buch In diesem Kurs

Ausgangslage, Ist-Zustand

the corresponding sections of Projektantrag and Projektauftrag — frozen at approval

Zielsetzung

the goals table of the charter, one row per goal with the check next to it

Anforderungen (Soll), funktional

a requirement with its scenarios in openspec/specs/, one file per capability

Anforderungen (Soll), nichtfunktional

the same place — written as a requirement with a measurable scenario, never as an adjective

Mengengerüst

the Mengengerüst section of the charter

Aufbau der Offerte, Administratives

no counterpart: a school project has no tender and no contract

Kriterienkatalog, Abgrenzungskriterien

the non-goals section of the charter

Nothing in that list was abolished. What changed is the form: instead of one document written once, the same content lives in small files that are updated with every change and checked by the build.

Requirements document vs. specification

Pflichtenheft / requirements document specs

written once, before building

written continuously, alongside

prose, hundreds of pages

short, per capability

becomes stale silently

drifts visibly, because the build checks it

"the system should support user management"

a requirement plus scenarios that either hold or do not

The classic requirements document is not wrong; it is unverifiable. Nobody can run it, so nothing tells you when it stopped describing the system.

Shape of a specification

## ADDED Requirements

### Requirement: Bookings are refused for sessions that already started
The system SHALL refuse a booking whose session start time lies in the past.

#### Scenario: Booking a session that started ten minutes ago
- **WHEN** a member books a session whose start time has passed
- **THEN** the booking is refused and the member is offered the next session

Read it as three parts: the requirement says what must hold, the scenario says how you would observe it, and the pair together is what "done" means. Anything you cannot phrase this way is either not yet understood or is a wish.

Frozen and alive, at the same time

frozen and alive

The charter cannot live, or there is nothing to judge against. The specification cannot be frozen, or it stops describing the system within a fortnight. Keeping both, and keeping the difference visible, is the whole arrangement.

Decisions

  • Each team keeps a target state under openspec/specs/, one file per capability.

  • Requirements use SHALL / MUST NOT and carry at least one scenario.

  • The requirements document (Pflichtenheft) is replaced by the specs; the charter is not replaced by anything.

  • A requirement without an observable scenario goes back for rewriting.

Pitfalls

  • Writing specifications that describe the implementation ("the service uses a repository class"). A spec says what must be true from outside.

  • One giant spec file. Then nobody reads it, exactly like the document it replaced.

  • Writing the spec after the code. It then documents what happened rather than deciding what should happen — and the agent had nothing to work from.

  • Believing the spec removes the need to think. It is the thinking; the code is the easy part now.

Terminology

Deutsch English

Lastenheft

customer requirements specification

Pflichtenheft

(system) requirements specification

Kriterienkatalog

evaluation criteria catalogue

Musskriterium, K.-o.-Kriterium

mandatory requirement, knock-out criterion

Wunschkriterium, Soll-Kriterium

desirable requirement

Abgrenzungskriterium

non-goal, exclusion criterion

Ist-Zustand

current state, as-is situation

Mengengerüst

volume estimate, sizing

funktionale / nichtfunktionale Anforderung

functional / non-functional requirement

Spezifikation

specification

Anforderung

requirement

Szenario

scenario

Sollzustand

target state

Further reading

  • Module sdd-openspec-artifacts — the concrete files and their roles

  • Module bridge-charter-to-specs — which charter field maps to which artefact

  • Module governance-requirements-elicitation — where the content of a Lastenheft comes from in the first place

  • Monterail — Software QA standards: ISO 25010 — what the nine characteristics are good for in practice, and how teams prioritise among them

  • iso25000.com — ISO/IEC 25010 — the characteristics and sub-characteristics in their official wording

  • Manz textbook, chapter 7 lesson 2 "Das Pflichtenheft" — the seven-chapter structure and the Kriterienkatalog used above

  • DIN 69901-5 — the definitions of Lastenheft and Pflichtenheft