IREB and BABOK: two compasses to structure your analytical practice

Countless projects go off the rails not because of technical issues, but because of things way upstream: a poorly understood need, a requirement never explicitly stated, an "of course" that no one had written down. This observation has been documented since the 1980s, and while the exact multipliers are debated, the trend has never wavered: the later a requirement error is detected, the more expensive it is to correct—in production, we're talking about an order of magnitude more than at the scoping stage. And yet, analysis is still often carried out "by instinct," each person using their own vocabulary and habits.

The good news is that this work has been mapped out. Two international standards are authoritative: the’IREB, on the requirements engineering side, and the BABOK, On the business analysis side. If you are starting out as a business analyst, product owner or MOA, this article gives you a map of these two areas: what they contain, what distinguishes them, and which one to start with.

IREB: Requirements Engineering

L'’IREB (International Requirements Engineering Board) is a non-profit association founded in 2006 in Germany by software engineering practitioners and academics. Its purpose is not to sell a method, but to define a common knowledge base for the’requirements engineering (requirements engineering), disseminated in the form of public syllabi and a certification, the CPRE (Certified Professional for Requirements Engineering).

The original culture is evident: IREB comes from the world of software and systems engineering, with a strong taste for precision. requirement It is rigorously defined as a documented need or constraint that a system must satisfy. The framework covers the entire requirements lifecycle—the current syllabus addresses it through nine fundamental principles, work products, and associated practices—from which four core activities can be identified:

• Elicitation : to bring out the requirements. The word is chosen deliberately — requirements are not "collected" like mushrooms are picked: they are brought into being through active techniques: interviews, observation, workshops, prototypes, analysis of existing documents.
• The documentation : formulate them unambiguously. The IREB describes the possible forms — controlled natural language (the famous sentence templates), graphic models, use cases — and the quality criteria of a requirement: verifiable, unambiguous, necessary, feasible.
• Validation and negotiation : verify with stakeholders that the documented requirements are correct, arbitrate conflicts between them — because two sincere stakeholders may want incompatible things.
• Requirements management : keeping them alive over time — prioritization, traceability, change management, versions.

An example is worth a thousand words. "The system must be fast" is not a requirement: nothing about it is verifiable. Filtered through the IREB criteria, it becomes, for example: "For 95% of searches, the system displays results in less than two seconds." The entire difference between a wish and a testable commitment lies in this reformulation.

The strength of the IREB lies in this rigorous vocabulary. When a team shares these definitions, entire families of misunderstandings disappear: a wish is no longer confused with a requirement, nor a solution with a need.

Regarding certification, one sentence suffices here: the CPRE exists in three levels (Foundation, Advanced, Expert), the Foundation being quite accessible through self-study from the syllabus, which can be downloaded for free from the IREB website (in English and several other languages).

The BABOK: the corpus of business analysis

THE BABOK (Business Analysis Body of Knowledge) is published by the’IIBA (International Institute of Business Analysis), an association founded in 2003 in Canada. Its current version, BABOK v3 (published in 2015), is the reference corpus for the profession of business analyst.

The change in perspective compared to IREB is immediate: where requirements engineering starts from a system to be specified, business analysis starts from a company that seeks to create value. Software is only one of the possible answers; sometimes the right solution is a change in organization, processes, or… doing nothing.

The BABOK organizes the trade by six areas of knowledge :

1. Planning and monitoring of business analysis — organize your own analysis work: which stakeholders, what governance, what deliverables.
2. Elicitation and collaboration — to obtain information and maintain stakeholder engagement (this includes elicitation from the IREB, extended to all collaboration).
3. Requirements lifecycle management — to trace, prioritize, approve, and reuse requirements over time.
4. Strategy analysis — understanding the current state, defining the future state, assessing the risks: this is the most "upstream" area, the one that links the analysis to the company's objectives.
5. Requirements analysis and design definition — to structure, model, specify requirements and outline solutions.
6. Solution evaluation — to measure whether the delivered solution actually produces the expected value, and to recommend improvements.

In addition, there is a gallery of about fifty techniques (SWOT analysis, process modeling, workshops, user stories, business rule analysis…) and a cross-functional model, the Business Analysis Core Concept Model, which links six concepts: change, need, solution, stakeholder, value, context.

Here too, one sentence about certifications: the IIBA offers three, tiered according to experience — ECBA for beginners, CCBA then CBAP for experienced practitioners.

The bridge: two focal points on the same work

These two frameworks are not competing: they look at the same work from two different perspectives. The BABOK framework takes a broad view—from corporate strategy to evaluating the value delivered. The IREB framework zooms in on the core segment—transforming needs into actionable requirements for a development team—and addresses it with a depth that the BABOK framework does not achieve.

Over the course of a project, their areas of intervention overlap at the center:

flowchart LR
    A[Strategy] --> B[Needs analysis]
    B --> C[Requirements]
    C --> D[Solution design]
    D --> E[Delivery]
    E --> F[Value evaluation]
    subgraph BABOK
      A
      B
      F
    end
    subgraph SHARED[BABOK + IREB]
      C
    end
    subgraph IREB
      D
    end

In practice, the two vocabularies coexist very well: a program can be framed using the BABOK domains, and when specifying them, the IREB quality criteria and templates can be applied. It's even the most convenient combination I know: the BABOK tells you what to watch and why, IREB tells you how to write it unambiguously.

Where to begin?

If you're a beginner, my advice has three parts:

1. Start with the IREB CPRE Foundation syllabus. It is free, short, and it establishes the basic vocabulary — the difference between need, requirement and solution is worth the read alone.
2. Continue with the BABOK diagonally. Don't read it like a novel: browse the six areas to situate your current position, then pick from the techniques when a concrete need arises.
3. Apply immediately to a real subject. Take a current request in your team and reformulate it with the IREB quality criteria: the exercise is more instructive than any reading.

Certifications will come later, if your context values them — they are a good pretext for serious study, not an end in themselves.

These frameworks are about twenty years old, but they've never been more relevant: formulating a need unambiguously is precisely the skill required when working with generative AI. This is also the theme of another post on this blog, where the IREB serves as a guardrail for an AI that codes too fast. BiblioCQRS – Episode 2: Putting AI back in the classroom (IREB).