Business analysis
Discover the right needs.
Deliver the right outcomes.
Requirements decomposed, prioritised and traced — to the projects and cases that carry them, the clauses they satisfy and the changes they cause — as records, not documents.
In one sentence
AlignX Business Analysis connects business needs and requirements to strategy, processes, systems, delivery, testing and outcomes, keeping traceability from the original problem to the measurable result.
The problem
Not a requirements problem. A connection problem.
Each of these is answerable — just not from a spreadsheet and a Word file that were both out of date before the review.
- Requirements live in documentsA spreadsheet and a Word file, both already out of date.
- No line to strategyNobody can say which objective a requirement actually serves.
- Traceability is a manual matrixRebuilt by hand for every audit and every release.
- Acceptance is a paragraphUntestable, so nobody can prove the requirement was met.
- Options are assertedBuild versus buy decided on instinct, with no numbers attached.
- Change consequences surface lateWhat a change touches is discovered during delivery.
- Scope creeps invisiblyAssumptions and constraints buried in free text nobody rereads.
The analysis lineage
From business need to measurable result.
Seven steps, each one a record that keeps what it was decided on.
- 01The needThe real problem, before any solution.
- 02Current stateHow it works today, and what hurts.
- 03RequirementsDecomposed, prioritised, owned.
- 04OptionsCompared on cost, value and risk.
- 05ImpactWhat a change will touch, across the estate.
- 06ApprovalBaselined with rationale and change control.
- 07VerificationAcceptance met, outcome measured.
Eight surfaces, one thread from need to result.
The need at one end, the measured outcome at the other, and every requirement in between kept as a record that stays connected.
Six levels from epic to detail, nested as deep as the work needs — and a register that shows each requirement’s state, level, MoSCoW band, type, parent and case at a glance.
Who it is for
Built for the people who own this work.
The roles
What they use it for
- Define business problems, desired outcomes and stakeholder context.
- Capture and prioritise business, functional and non-functional requirements.
- Create testable acceptance criteria.
- Compare build, buy and extend solution options.
- Assess change impacts across processes, applications, data, technology and vendors.
- Trace requirements to delivery items, controls, tests and outcomes.
- Manage requirements review, approval and change.
The impact
Analysis that survives delivery.
- Requirements that stay connectedFrom the need that raised them to the outcome they produced.
- Traceability without the rebuildThe matrix is the model, not a document you assemble.
- Acceptance you can testGiven, when, then, with a method, on every requirement.
- Recommendations that holdNumbers, weights and a stated switching point.
- Fewer late surprisesThe estate a change touches is visible before you commit.
- Outcome, not outputDelivered against the need, measured after the fact.
Six questions
Worth asking of whatever you run today.
Where do requirements currently live, and which version is trusted?
In one register, as records rather than documents. A requirement has a state, an owner and a history, so the trusted version is the record and the changes are on it.
Can each requirement be traced to the objective and business need it supports?
A requirement links upward to its parent and to the objective and business need it serves, and downward to its children, across six levels of decomposition.
How long does it take to determine the impact of a requirement change?
The requirement's links to its children, its delivery items and the applications it touches are on the record, so the impact of a change is read there rather than rebuilt in a matrix.
Are acceptance criteria structured so delivery can prove they were met?
Acceptance criteria are written given-when-then on the requirement, so each one is a testable statement rather than a paragraph.
How are requirements baselined, approved and changed?
A requirement moves from draft to review to approved through the workflow, with the approver and the date recorded, and a change after approval is a new version on the same record.
If a strategic objective changes, can you identify every affected requirement, system and test?
Because objectives, requirements and applications are one model, the requirements under a changed objective and the systems they touch are a query of the objective, not a search of the documents.
From requirement to real outcome.
It runs inside your Microsoft environment, on your data, under your controls.