Roadmap

The BABOK counts six knowledge areas. We seriously cover two. Here is where we stand, what comes next, and what we will not build.

Where we stand

Meeting preparation

Elicitation and Collaboration, 4.1 Prepare for Elicitation

Techniques 10.50 Workshops, 10.25 Interviews and 10.43 Stakeholder List, Map, or Personas.

User stories

RADD, 7.1 Specify and Model Requirements

Techniques 10.48 User Stories and 10.1 Acceptance and Evaluation Criteria. INVEST and Gherkin come from the Agile Extension v2 (§7.21 and §7.2), not from BABOK v3.

Process modelling

RADD, 7.1 Specify and Model Requirements

Technique 10.35 Process Modelling, BPMN notation, with a 2.0 export already laid out.

Consistency across deliverables

5.1 Trace Requirements

Traceability that does not yet say its name, still missing the matrix.

Challenge mode

10.37 Reviews, 7.2 Verify, 7.3 Validate

The critique of a finished deliverable, not yet separating verification from validation.

What comes next

In rough order of value. No dates: a dated roadmap is a promise, and we would rather ship than promise.

  1. 1

    Use cases and scenarios

    10.47 Use Cases and Scenarios

    This is our biggest gap. Many BAs, in banking, insurance and the public sector, write use cases rather than user stories. Today, we do not speak to them.

  2. 2

    Non-functional requirements

    10.30 Non-Functional Requirements Analysis

    The classic omission, and the one that costs the most late. Performance, security, availability, compliance: nobody reminds you when it would still be cheap.

  3. 3

    Business rules and decision modelling

    10.9 Business Rules Analysis, 10.17 Decision Modelling

    Business rules sit scattered across documents and are rarely formalised. DMN is an OMG standard, exactly like BPMN: the same product pattern as our current export.

  4. 4

    Traceability, named and tooled

    5.1 Trace Requirements, 7.4 Define Requirements Architecture

    Our consistency check already does the hard part. What it lacks is the matrix linking a requirement to its story, its process step and its acceptance criterion.

  5. 5

    Document analysis

    10.18 Document Analysis

    A BA never starts from nothing: they start from specs, minutes, contracts. Elicira does start from nothing. That is inconsistent, and fixing it would also feed the project context.

  6. 6

    Strategy analysis

    6.1 Analyze Current State, 6.2 Define Future State, 10.40 Root Cause Analysis

    The upstream work that separates the senior BA from the story writer. It would move Elicira from help writing to help thinking, and it is the area we ignore the most.

What we will not build

The BABOK lists fifty techniques. Some of them an AI should not touch, and pretending otherwise would only make the rest less credible.

Observation (10.31)

You have to be in the room. An AI will not be.

Estimation (10.19) and financial analysis (10.20)

Language models are unreliable on numbers, and these techniques need your real data. A confidently invented figure would be worse than an empty field.

Benchmarking (10.4) and vendor assessment (10.49)

Requires current market data we do not have.

Data mining (10.14)

This is not a language model’s job. Other tools do it better.

IIBA professional development hours

The certification handbooks require a human facilitator and an assessment. No software alone can grant them, and we will never claim otherwise.

References point to the BABOK Guide v3, still the current edition, and to the Agile Extension v2 where the agile techniques actually live. Elicira is not affiliated with, nor endorsed by, the IIBA.