This part settles which requirements an architecture decision actually needs.

• Separating architecturally significant requirements (ASR) from all the others
• The roles around requirements: business analyst, requirements engineer, product owner
• Just-in-time requirements: eliciting only what the next decision needs
• Quality criteria per ISO 29148 and the Volere quality gateway as the check

This part is about the handover that modern approaches no longer have.

• Design thinking, design sprints and lean startup as cooperative product development
• Three amigo sessions with product owner, development and test
• The twin peaks model: requirements and architecture grow together
• Traceability to architecture, code and tests, and what it costs in effort

This part settles what has to be clear before the first detailed requirement.

• Phrasing vision and business goals with SMART or PAM
• Identifying stakeholders and telling their value propositions apart
• Setting the scope and drawing the system context
• Personas and user journey maps as the way into the requirements work

The longest part of the curriculum: 300 minutes of teaching and exercises on functional requirements.

• Hierarchies from epic through feature to story, and criteria for breaking them down
• Documenting value-creating processes as a use case or a scenario
• INVEST and the definition of ready as the end of refinement
• Writing acceptance criteria and working with specification by example

This part covers the kind of requirement architectures really fail on.

• Telling quality requirements, constraints and non-functional requirements apart
• Categories of qualities along the Q42 model
• Eliciting quality requirements as scenarios, refining them and giving them acceptance criteria
• Pragmatic alternatives for when detailed acceptance criteria get too expensive

This part brings the requirement and the test into one format.

• The principles of behavior driven development and the settings it suits
• Given-when-then as the structure for acceptance criteria
• Gherkin and Cucumber as examples of executable specifications
• Automated tests as a by-product of precisely phrased requirements

New in curriculum 2026.1: large language models in requirements work.

• Where they help, from preparing interviews to generating requirements
• Placing hallucinations, bias and non-deterministic output
• The tacit knowledge no model draws from context
• Human-in-the-loop: reviewing AI output and protecting confidentiality

This part puts requirements into an order you can defend.

• Telling kinds of business value apart and ranking requirements by them
• MoSCoW and WSJF as prioritisation procedures
• Estimating with affinity estimation, story points and function points
• Spotting contradictory requirements and resolving them with the people involved

Here you place tool categories rather than learning individual products.

• Cards, wikis, modelling tools and issue trackers compared
• Heuristics for which kind of tool suits which kind of system
• The strengths and weaknesses of the categories, not of the products

To close, you assess requirements, the good ones and the bad ones.

• At least one example of well-formulated architecturally significant requirements
• Counter-examples: ambiguous, inconsistent and contradictory requirements
• The curriculum deliberately leaves the choice of examples open