2,537 $−254 $2,283 $
What this module delivers.
How the training runs
- Method
- Eliciting, sharpening and prioritising requirements in exercises
- Basis
- Official iSAQB curriculum 2026.1
- Outcome
- 30 credit points: 20 methodical, 10 communicative, no course exam
Dates & booking
Choose a date that fits
6 dates
Sessions with this symbol offer up to 25% group discount. Click “Details & Registration” to learn more.
2,826 $−283 $2,543 $
2,537 $−254 $2,283 $
2,826 $−283 $2,543 $
2,537 $−254 $2,283 $
2,826 $−283 $2,543 $
No dates match this selection.
Dates are still available. Reset the filters to see them.
Fit
Who this module is designed for
Typical roles
- You make architecture decisions from requirements somebody else wrote.
- You work out with product owners, business analysts and testers what a system has to do.
- You turn vague quality wishes into acceptance criteria that can be checked.
Prerequisites
No prerequisites
You can start right away. Helpful: hands-on experience with backlogs, stories or requirements documents, design decisions of your own in at least two systems.
Consider instead AGILA Gives 300 of its 1080 minutes to group decision procedures and architecture decision records, where REQ4ARC works on the requirements themselves.
Curriculum
CPSA® REQ4ARC Course in Detail
Curriculum 2026.1 splits REQ4ARC into ten parts with 705 teaching minutes and 375 minutes of exercises. It starts at architecturally significant requirements and the cooperation between roles. From there it runs through the clean start to functional and quality requirements, and ends at prioritisation, tools and examples.
01Introduction and Motivation
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
02Cooperation between Roles
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
03Clean Start
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
04Handling Functional Requirements
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
05Handling Quality Requirements and Constraints
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
06Behavior Driven Development
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
07AI in RE
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
08Prioritization and Estimation of Requirements
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
09Tools for Requirements Engineering
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
10Example
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
Outcome
What you will be able to do afterwards
- 01
You separate architecturally significant requirements from the rest and call them in just in time.
- 02
You set the vision, business goals and system scope, and name the stakeholders behind them.
- 03
You break epics down into stories and test them against INVEST and the definition of ready.
- 04
You phrase quality requirements as measurable scenarios instead of a wish list.
- 05
You write acceptance criteria in given-when-then form and judge where BDD pays off.
- 06
You check AI-generated requirements for hallucinations, bias and missing tacit knowledge.
- 07
You prioritise requirements with MoSCoW or WSJF and resolve the contradictions between them.
Credit points toward CPSA-A
- Methodical competence
- 20
- Technical competence
- 0
- Communicative competence
- 10
30 of 70 points toward CPSA-A admission
Certificate of participation
The tecnovy certificate of participation records your attendance of the REQ4ARC training, not a passed examination.
Open the Certificate Showroom tecnovy →≥80%attendance
Why tecnovy
What you get on top with us
01
iSAQB® Accredited Provider
We are an officially accredited Training Provider of the International Software Architecture Qualification Board.
02
Certificate Showroom
Get your certificate of participation and, if you have one, add your exam certificate from E-Learning. Fully automated, beautifully designed. Just for you, only at tecnovy.
03
No Slideshow, Hands-On!
Promised: no PowerPoint marathon. We work in groups, tie theory to practice, and you get real project examples from our experienced trainers plus the exchange with like-minded people.
04
Attend Twice, Pay Once
You are welcome to attend the training online again within a year as a refresher.
05
Learn from Authors
Your instructors are not just trainers, but the authors of the preparatory literature for the iSAQB CPSA-F certification exam and at the same time an active member of the iSAQB Foundation group.
06
Flexible Date Change
If you are not able to attend the course, you can rebook your training free of charge up to one week before the start of the training.
FAQs
Frequently asked questions
01Do I need CPSA-F to attend the tecnovy REQ4ARC training?
02Is there a REQ4ARC examination?
03How many credit points does REQ4ARC carry?
04How does the CPSA-A certification work?
05How long is the REQ4ARC training?
06What is the difference between REQ4ARC and AGILA?
07Does REQ4ARC cover the use of AI in requirements engineering?
08Is REQ4ARC worth it when product owners or business analysts write the requirements?
09Do I get the flipcharts from the REQ4ARC training?
What does your training at tecnovy look like?
