req42 is Peter Hruschka and Markus Meuten's framework for pragmatic, agile requirements: a template of twelve sections that mirrors arc42, from business goals and stakeholders to quality requirements, roadmap and risks. Business goals are written in PAM form, Purpose, Advantage and Metric, and the product backlog runs top-down from epics through features to user stories. It is distributed as a free AsciiDoc template under CC BY-SA 4.0 and pairs with arc42.

req42 Requirements Framework

Details
Full Name

req42 — Framework for Pragmatic, Agile Requirements

Also known as

the requirements companion to arc42

Core Concepts:

Twelve "drawers"

A lightweight template of twelve sections, deliberately mirroring arc42’s structure, for capturing agile requirements without drifting into heavyweight specification. Fill only the drawers a project actually needs.

01 Business Goals

Why the product exists and what success looks like

02 Stakeholders

Who has an interest in the system and what they expect

03 Scope

What is in and out — the system boundary

04 Product Backlog

Features, user stories, and product ideas

05 Supporting Models

Diagrams and models that clarify the requirements (context, data, processes)

06 Quality Requirements

Quality goals and scenarios — the focus that sets req42 apart from pure backlog management

07 Constraints

Conditions that limit design and implementation decisions

08 Domain Terminology

Shared vocabulary; a glossary

09 Assets

Existing things to reuse or protect

10 Teams

Who builds the product

11 Roadmap

Planned sequence of delivery over time

12 Risks / Assumptions

Open risks and the assumptions the plan rests on

Goals in PAM form

The template recommends writing each business goal as PAM: Purpose (what the product should achieve), Advantage (the benefit for stakeholders — "at least as important as the P"), and Metric (how you know the goal is reached; the tips also say "Measure"). A goal that is not measurable is not a goal. Keep to a handful of goals, one to five. If writing all three is too much, write down at least the purpose and talk through advantage and metric with the stakeholders and the team. Sources: chapter 1 of the template; tips A-1-03, A-1-10, A-1-11 and B-05.

Top-down from vision to story

req42 presents requirements top-down: vision and goals in chapter 1, scope in chapter 3, and in chapter 4 a product backlog of epics that contain features that contain user stories. Explain and communicate top-down, but work in whatever order the situation needs (tip B-04). Separate vision from goals only in large projects, where a long-range vision is refined into measurable goals per year and per release (A-1-06, A-1-07). Without goals, a team risks finding out too late that its individual activities were not goal-oriented (A-1-01).

Pairs with arc42

req42 documents the requirements (the "what" and "why"); arc42 documents the architecture (the "how"). The two share authorship, structure, and tooling, so they combine seamlessly.

Docs-as-code

Distributed as an AsciiDoc template built with the arc42 generator; version-controllable, diffable, and toolchain-friendly. Licensed CC BY-SA 4.0 (free and open source).

Key Proponents

Dr. Peter Hruschka and Markus Meuten (https://req42.de). Hruschka is a principal of the Atlantic Systems Guild, IREB founding member, and co-creator of arc42; req42 also draws on the Volere requirements tradition.

When to Use:

  • Documenting requirements in an agile context without abandoning structure

  • Giving a product backlog a frame for quality requirements, constraints, and risks — not just user stories

  • Pairing a requirements document with an arc42 architecture document so both share structure and tooling

  • Lightweight, docs-as-code requirements that live next to the code in version control

Current Status:

  • Far less widely known than its sibling arc42. An LLM recognizes "req42" mainly because of arc42’s name and structure; the training-data prior on req42’s own twelve-section content is thin, so the model may extrapolate from arc42 rather than recall req42 accurately. Verify section names against the source (https://docs.req42.de, https://github.com/Hruschka/req42-framework) rather than trusting recall.

  • Actively maintained as a free, open-source template (CC BY-SA 4.0) on GitHub, with section-level guidance at https://docs.req42.de — the same docs-as-code model as arc42.

  • A prior test on 2026-10-15 confirmed the thin prior and lowered the tier to ★★☆. The weak tier does not recognise "req42" and names no creator; a mid-tier model credits Hruschka and Gernot Starke, the arc42 pair. Only the strong tier turned "use req42" into goals in PAM form. The bare acronym "PAM" returns Privileged Access Management on every tier. Naming both works on every tier, the weak one included: "write them as PAM goals, as req42 recommends". In prompts, write Purpose / Advantage / Metric out or name PAM together with req42. See the prior-test register.