Turning a vague business problem into requirements a delivery team can actually build against.
Most delivery failures are requirements failures wearing a different costume. The team built what was asked for, on time, to specification — and nobody had checked whether that was the problem worth solving. By the time this becomes visible, the budget is spent and the conversation has moved on to who is at fault.
Certified Business Analyst Plus assesses the practice that prevents it. Eliciting what people mean rather than what they say. Modelling a requirement so its ambiguity becomes visible before the build rather than during it. Validating with the people who will live with the outcome rather than the people who commissioned it.
The scenarios are drawn from where analysis actually gets difficult. A stakeholder who describes a solution and calls it a requirement. Two departments with incompatible definitions of the same term, both convinced theirs is obvious. A requirement that is perfectly clear and quietly impossible. A sponsor who wants the analysis phase shortened because the answer is already known — and is wrong about that.
The paper tests one thing above all: whether you can hold the gap between a stated want and an actual need open long enough to understand it, under pressure from people who would rather you closed it immediately. That is uncomfortable work and it is what separates an analyst from a note-taker.
The credential sits at Professional tier in the Specialised Practice track.
It sits in the Specialised Practice track at Professional tier, and is issued with a unique credential ID, a two-year validity period and an independently hosted digital badge.
Business analysts, product-adjacent practitioners, and project managers who carry the analysis themselves because there is no separate BA — which describes a great many delivery environments.
It suits anyone whose job includes turning an ambiguous business problem into something a delivery team can build against: process analysts, systems analysts, service designers, and delivery leads in organisations where requirements arrive as a paragraph and a deadline.
Professional-level experience is assumed. You should have run elicitation with real stakeholders rather than documented requirements handed to you, because the paper is largely about the conversations rather than the artefacts. Someone who has only maintained a requirements catalogue will find the scenarios unfamiliar.
No particular modelling notation is required. The paper assesses whether your model makes the ambiguity visible, not whether you drew it in a specific notation.
The paper is weighted across five domains. Weightings show how much of the examination each area accounts for, so preparation can be planned against them.
| Domain | Weighting | |
|---|---|---|
| 01 | Delivery planning and scope control | 25% |
| 02 | Stakeholder engagement and governance | 20% |
| 03 | Risk, issue and dependency management | 20% |
| 04 | Schedule, cost and resource discipline | 20% |
| 05 | Closure, benefits and lessons learned | 15% |
Business analysis is one of the most portable skills in delivery. Every sector needs it, the shortage is consistent, and the practice transfers between domains far better than most people assume — the hard part is the reasoning, not the industry knowledge.
That portability is also the problem at application stage. Because the skill is general, it is difficult to evidence, and BA roles attract applications from a very wide pool of people who have done some analysis at some point. An assessed credential is a straightforward way to separate demonstrated practice from adjacent experience.
It also supports a move in either direction. Analysts moving toward delivery management find it pairs naturally with Certified Project Manager Plus; those moving toward product find that assessed requirements judgement is the part of the skillset product hiring managers most often probe and most rarely find evidenced.
Inside a role, it changes how your analysis is received. Pushing back on a stated requirement is easier when your judgement about requirements has been externally tested.
No. The paper assesses whether a model makes ambiguity visible and supports a decision, not whether it was drawn in BPMN, UML or anything else. Notation is a tool; the reasoning is what is examined.
Yes. A large proportion of analysis is done by project managers, product people and delivery leads in organisations with no separate BA role. The paper asks what you would do, not what your job title is.
Professional-level. You should have run elicitation with real stakeholders rather than only documented requirements passed to you, because most of the marks sit in the conversations rather than the artefacts.
Five weighted domains, with requirements elicitation, stakeholder engagement and validation carrying the heaviest weighting. Scope control and benefits are assessed through the lens of requirements.
No. The scenarios span process change, service design and systems work. Analysis practice is the same whether the outcome is a system, a process or a policy.
No. We assess and credential; we do not train. The assessment domains and weightings are published so you can prepare against the real paper using whatever route suits you.
Two years from issue. The expiry date appears on the certificate and the public verification record, so a lapsed credential is visibly lapsed.
One proctored examination attempt, the certificate with credential ID and QR code, the digital badge, and the public register entry. Nothing further to buy.
A domain-level breakdown is issued with the result, and a retake can be booked from your dashboard at a reduced fee with no waiting period.
By entering the credential ID on our public register or scanning the QR code on the certificate. The digital badge carries its own independent verification page.