req42 ist das Framework von Peter Hruschka und Markus Meuten für pragmatisches, agiles Requirements Engineering: ein Template aus zwölf Abschnitten, das die Struktur von arc42 spiegelt, von Geschäftszielen und Stakeholdern bis zu Qualitätsanforderungen, Roadmap und Risiken. Geschäftsziele stehen in PAM-Form, also Purpose, Advantage und Metric, und das Product Backlog verläuft top-down von Epics über Features zu User Stories. req42 ist ein freies AsciiDoc-Template unter CC BY-SA 4.0 und ergänzt arc42.

req42 Requirements Framework

Details
Vollständiger Name

req42 — Framework für pragmatisches, agiles Requirements Engineering

Auch bekannt als

das Requirements-Gegenstück zu arc42

Kernkonzepte:

Zwölf "Schubladen"

Ein leichtgewichtiges Template aus zwölf Abschnitten, das bewusst die Struktur von arc42 spiegelt, um agile Requirements zu erfassen, ohne in eine schwergewichtige Spezifikation abzudriften. Nur die Schubladen füllen, die ein Projekt wirklich braucht.

01 Business Goals

Warum das Produkt existiert und woran sich Erfolg misst

02 Stakeholders

Wer ein Interesse am System hat und was er erwartet

03 Scope

Was drin und was draußen ist — die Systemgrenze

04 Product Backlog

Features, User Stories und Produktideen

05 Supporting Models

Diagramme und Modelle, die die Requirements verdeutlichen (Kontext, Daten, Prozesse)

06 Quality Requirements

Qualitätsziele und -szenarien — der Fokus, der req42 vom reinen Backlog-Management unterscheidet

07 Constraints

Randbedingungen, die Design- und Implementierungsentscheidungen einschränken

08 Domain Terminology

Gemeinsames Vokabular; ein Glossar

09 Assets

Vorhandenes, das wiederverwendet oder geschützt werden soll

10 Teams

Wer das Produkt baut

11 Roadmap

Geplante Reihenfolge der Auslieferung über die Zeit

12 Risks / Assumptions

Offene Risiken und die Annahmen, auf denen der Plan ruht

Ziele in PAM-Form

Das Template empfiehlt, jedes Geschäftsziel als PAM zu formulieren: Purpose (was das Produkt erreichen soll), Advantage (der Nutzen für die Stakeholder — „mindestens so wichtig wie das P“) und Metric (woran man erkennt, dass das Ziel erreicht ist; in den Tipps auch „Measure“). Ein Ziel, das nicht messbar ist, ist kein Ziel. Nur eine Handvoll Ziele, eins bis fünf. Sind alle drei zu viel, mindestens den Zweck aufschreiben und Nutzen und Messbarkeit mit Stakeholdern und Team besprechen. Quellen: Kapitel 1 des Templates; Tipps A-1-03, A-1-10, A-1-11 und B-05.

Top-down von der Vision zur Story

req42 stellt Anforderungen top-down dar: Vision und Ziele in Kapitel 1, Scope in Kapitel 3 und in Kapitel 4 ein Product Backlog aus Epics, die Features enthalten, die User Stories enthalten. Top-down erklären und kommunizieren, aber in der Reihenfolge arbeiten, die die Lage verlangt (Tipp B-04). Vision und Ziele nur in großen Vorhaben trennen; dort wird eine langfristige Vision in messbare Ziele je Jahr und je Release verfeinert (A-1-06, A-1-07). Ohne Ziele läuft ein Team Gefahr, zu spät zu merken, dass seine einzelnen Aktivitäten nicht zielgerichtet waren (A-1-01).

Passt zu arc42

req42 dokumentiert die Requirements (das "Was" und "Warum"), arc42 die Architektur (das "Wie"). Beide teilen Autorenschaft, Struktur und Tooling und lassen sich daher nahtlos kombinieren.

Docs-as-Code

Verteilt als AsciiDoc-Template, gebaut mit dem arc42-Generator; versionierbar, diff-fähig und toolchain-freundlich. Lizenziert unter CC BY-SA 4.0 (frei und Open Source).

Schlüsselvertreter

Dr. Peter Hruschka und Markus Meuten (https://req42.de). Hruschka ist Principal der Atlantic Systems Guild, Gründungsmitglied des IREB und Mitentwickler von arc42; req42 greift zudem auf die Volere-Tradition zurück.

Wann zu verwenden:

  • Requirements im agilen Kontext dokumentieren, ohne Struktur aufzugeben

  • Einem Product Backlog einen Rahmen für Qualitätsanforderungen, Constraints und Risiken geben — nicht nur User Stories

  • Ein Requirements-Dokument mit einem arc42-Architekturdokument paaren, sodass beide Struktur und Tooling teilen

  • Leichtgewichtige Docs-as-Code-Requirements, die neben dem Code in der Versionsverwaltung leben

Verwandte Anker:

Aktueller Status:

  • Deutlich weniger bekannt als das Schwester-Framework arc42. Ein LLM erkennt "req42" vor allem wegen des Namens und der Struktur von arc42; der Trainingsdaten-Prior zu req42s eigenem Inhalt der zwölf Abschnitte ist dünn, sodass das Modell eher von arc42 extrapoliert als req42 korrekt abruft. Abschnittsnamen gegen die Quelle (https://docs.req42.de, https://github.com/Hruschka/req42-framework) prüfen, statt auf das Gedächtnis zu vertrauen.

  • Aktiv gepflegt als freies, quelloffenes Template (CC BY-SA 4.0) auf GitHub, mit Hinweisen auf Abschnittsebene unter https://docs.req42.de — dasselbe Docs-as-Code-Modell wie arc42.

  • Ein Prior-Test am 15.10.2026 bestätigte den dünnen Prior und senkte das Tier auf ★★☆. Die schwache Stufe erkennt "req42" nicht und nennt keinen Urheber; ein Modell der mittleren Stufe nennt Hruschka und Gernot Starke, das arc42-Paar. Nur die starke Stufe machte aus "use req42" Ziele in PAM-Form. Das nackte Akronym "PAM" liefert auf jeder Stufe Privileged Access Management. Beides zusammen genannt wirkt auf jeder Stufe, auch der schwachen: "write them as PAM goals, as req42 recommends". In Prompts deshalb Purpose / Advantage / Metric ausschreiben oder PAM zusammen mit req42 nennen. Siehe Prior-Test-Register.