Business analysis cheat sheet
Business analysis on a few screens: which elicitation technique to use when, process modelling and BPMN symbols, how to write requirements, user stories and acceptance criteria, traceability, UAT and change. Keep it open in workshops and while you write requirements.
If you see X, reach for Y
Most failed projects had the requirements wrong, not the code. Each row is a cheap step that catches the problem early.
| You see | Reach for first | Then, if needed | Lessons |
|---|---|---|---|
| The request is a solution ("we need a new screen") | Ask why five times; write the business need | A one-line problem statement signed off by the sponsor | The BA role |
| Stakeholders disagree on what is needed | A stakeholder map and one workshop with the deciders | Write the open decisions down with an owner and date | Elicitation |
| People describe the process differently | Observe the work, then draw the as-is process | Walk the diagram with each group and fix it | Elicitation, Process models |
| Long waits and rework in a process | Mark handoffs, waits and rework loops on the as-is map | Value stream: time working vs time waiting | Process models, Value streams |
| Requirements say "fast", "easy", "user-friendly" | Make them measurable: "under 2 seconds for 95% of scans" | Add how it will be tested | Requirements |
| Developers keep finding gaps mid-sprint | Acceptance criteria with edge cases and errors | Example tables (Given, When, Then rows) | Stories and criteria |
| Nobody knows which requirement a change affects | A traceability matrix: need to requirement to test | Link stories to requirement ids in the tracker | Requirements |
| Scope keeps growing | A signed-off scope with "out of scope" listed | Change requests with impact on cost and date | Change and UAT |
| Users reject the system at the end | UAT with real users on real scenarios, planned early | Pilot in a few stores before rollout | Change and UAT, Bugs and UAT |
| The new system is live but staff use paper | Find the reason: training, fit, trust or habit | Champions in each store; retire the old way | Change and adoption |
| The same data is entered in two systems | Name the system of record for each data item | An integration, not a second form | Systems of record |
Elicitation: which technique when
Combine at least two techniques: what people say and what they do often differ (Elicitation).
| Technique | Best for | Tip | Lesson |
|---|---|---|---|
| Interview | Goals, pain points, history, politics | Ask about the last real case, not the general rule | Elicitation |
| Workshop | Agreement across teams, prioritising, process walk-throughs | Agenda, decider in the room, decisions written live | Elicitation |
| Observation (job shadowing) | Real steps, workarounds, the environment | Stand in the store's back room during a delivery | Elicitation |
| Document analysis | Current rules, forms, policies, old specs | Collect real filled-in forms, not blank templates | Elicitation |
| Survey | Many people, simple questions, rough numbers | Short; test it on three people first | Elicitation |
| Prototype | Screens and flows people struggle to describe | Paper or clickable; ask them to do a task | AI prototypes |
| Data analysis | How often, how long, how many errors | Pull a month of records before the workshop | Asking questions |
Stakeholder map
Place each stakeholder by influence and interest, then plan how to engage them (Elicitation, Stakeholders).
| Low interest | High interest | |
|---|---|---|
| High influence | Keep satisfied: short updates, ask before decisions (for example finance) | Manage closely: workshops, sign-off, regular one-to-ones (for example head of stores) |
| Low influence | Monitor: newsletter or release notes | Keep informed: demos, pilots, feedback channels (for example store receivers) |
Process models and BPMN basics
Draw the as-is process first, agree it with the people who do the work, then draw the to-be. Keep one level of detail per diagram (Process models).
| BPMN element | Looks like | Means |
|---|---|---|
| Pool and lanes | Large rectangle split into horizontal bands | An organisation (pool) and the roles or systems inside it (lanes) |
| Start event | Thin circle | What triggers the process ("delivery truck arrives") |
| End event | Thick circle | How the process finishes ("GRN posted") |
| Task | Rounded rectangle | One piece of work, named verb plus noun ("Scan cases") |
| Exclusive gateway | Diamond (often with an X) | Exactly one path is taken ("Count matches order?") |
| Parallel gateway | Diamond with a + | All paths run, then join |
| Sequence flow | Solid arrow | Order of steps inside a pool |
| Message flow | Dashed arrow | Communication between pools (Mangrove and a supplier) |
| Intermediate timer event | Double circle with a clock | A wait ("wait 24 hours for supplier credit note") |
Other models worth knowing
Pick the model that answers the question in front of you (Process models, Capability maps).
| Model | Answers | Lesson |
|---|---|---|
| SIPOC | Suppliers, inputs, process, outputs, customers: the scope of a process on one page | Process models |
| Swimlane flowchart | Who does which step, and where handoffs happen | Process models |
| Context diagram | Which people and systems the solution talks to | Requirements |
| Use case | An actor's goal and the main and alternate flows to reach it | Requirements |
| State diagram | The states an object moves through (order: placed, picked, delivered) | Requirements |
| Entity relationship diagram | The data items and how they relate (store, delivery, GRN line) | Data modeling |
| Capability map | What the business does, independent of org chart or systems | Capability maps |
| Value stream | The stages that deliver value to a customer, with time and handoffs | Value streams |
Requirement types
Write each requirement once, with an id, a source and a way to test it (Requirements).
| Type | Example at Mangrove | Lesson |
|---|---|---|
| Business requirement | Cut receiving time per delivery from 51 to 30 minutes within 6 months | Requirements |
| Stakeholder (user) requirement | Receivers need to see shortages before the driver leaves | Requirements |
| Functional requirement | FR-12: The Store app shall compare scanned cases with the purchase order and list differences | Requirements |
| Non-functional requirement | NFR-3: Scans are saved offline and sync within 5 minutes of the network returning | Requirements |
| Transition requirement | Open paper GRNs from the last 7 days are entered before go-live | Change and UAT |
| Business rule | A shortage over $50 needs the store manager's approval | Requirements |
A good requirement is…
Check each one against this list before review (Requirements).
- Necessary: traces to a business need; delete it if nothing would break without it.
- Unambiguous: one reading only; avoid "fast", "simple", "etc.", "and/or".
- Testable: someone can write a pass or fail test for it.
- Atomic: one requirement per sentence; split anything with "and".
- Feasible: possible with the budget, time and systems.
- Solution-free where possible: says what and why, leaves how to the team.
- Prioritised: MoSCoW (Must, Should, Could, Won't this time) or a rank.
User stories and acceptance criteria
A story is a placeholder for a conversation; the acceptance criteria are what makes it testable. Cover the happy path, the edge cases and the errors (Stories and criteria, Stories and AC).
Output
Story: As a store manager, I want to approve large shortages,
so that only real shortages are claimed from suppliers.
AC1 Given a GRN with a shortage of $62.00
When the receiver taps Finish
Then the GRN status is "Waiting for approval" and the manager is notified
AC2 Given a GRN with a shortage of $12.00
When the receiver taps Finish
Then the GRN is posted with no approval step
AC3 Given the manager rejects the shortage
When they add a reason
Then the GRN returns to the receiver with the reason shown| Story splitting pattern | Split by… | Example |
|---|---|---|
| Workflow steps | Each step of the process | Scan cases; mark damaged; sign off |
| Business rules | Simple rule first, exceptions later | Shortages under $50 first; approvals next |
| Data variations | One kind of data at a time | Cases with barcodes first; loose items later |
| Happy path, then errors | Main flow first, failures next | Online first; offline sync as its own story |
| Interface | One channel at a time | Handheld scanner first; tablet later |
Definition of ready and done
Agree both with the team and keep them on the board (Stories and criteria).
| Ready (before the sprint) | Done (before the demo) |
|---|---|
| Story has a clear user, need and value | All acceptance criteria pass |
| Acceptance criteria written and reviewed with QA | Tests written and passing in CI |
| Designs or examples attached | Reviewed by another developer |
| Dependencies known; data available | Product owner or BA has accepted it |
| Small enough to finish in a few days | Help text, release notes or training updated |
Traceability matrix
One row per requirement. It answers "what breaks if this changes?" and "is everything tested?" (Requirements).
| Need | Requirement | Story | Test |
|---|---|---|---|
| BR-1 Faster receiving | FR-12 Compare scans with order | STORE-210 | UAT-04, UAT-05 |
| BR-1 Faster receiving | NFR-3 Offline scans sync in 5 min | STORE-214 | UAT-09 |
| BR-2 Fewer corrected GRNs | BRULE-4 Approve shortages over $50 | STORE-221 | UAT-11, UAT-12 |
UAT in one breath
User acceptance testing asks real users to confirm the system supports their work, using realistic scenarios and data. Plan it from the start: who tests, which scenarios, the entry criteria (system tested, data loaded, users trained), the exit criteria (no open critical defects, agreed pass rate) and who signs off. Log defects with steps, expected and actual results, and severity. At Mangrove, run UAT in a pilot store during a real delivery, not only in a meeting room (Change and UAT, Bugs and UAT).
Change and adoption
A system nobody uses delivers nothing. Plan the people side with the same care as the build (Change and UAT, Change and adoption).
- Impact assessment: for each group, what changes in their day, and what they stop doing.
- Communicate why before how: the problem, the benefit for them, the date.
- Train on their real tasks, close to go-live; give a one-page guide at the workstation.
- Champions in each store answer questions and report problems.
- Measure adoption by work done in the new system, and switch off the old way on a set date.
- Change requests after sign-off: describe the change, its reason, impact on scope, cost, time and risk, and who approves.
Glossary
Plain definitions of the terms used most in business analysis.
- Acceptance criteria
- Conditions a story must meet to be accepted, often in Given, When, Then form. Stories and criteria
- As-is and to-be
- The process as it works today and as it should work after the change. Process models
- Backlog
- The ordered list of stories and work the team has not done yet. Stories and criteria
- BPMN
- Business Process Model and Notation: a standard set of symbols for drawing processes. Process models
- Business case
- The argument for a change: costs, benefits, risks and options. Business cases
- Business rule
- A policy the system must enforce, such as an approval limit. Requirements
- Change request
- A formal request to change agreed scope, with its impact and an approver. Change and UAT
- Definition of done
- The team's shared checklist for when a story is truly finished. Stories and criteria
- Elicitation
- Drawing out needs and knowledge from stakeholders through interviews, workshops and observation. Elicitation
- Functional requirement
- What the system must do. Requirements
- Gap analysis
- Comparing the current state with the target state to list what must change. Process models
- Gherkin
- The Given, When, Then format for writing examples that can also become automated tests. Stories and criteria
- MoSCoW
- Prioritising as Must have, Should have, Could have, Won't have this time. Requirements
- Non-functional requirement
- How well the system must work: speed, availability, security, usability. Requirements
- RACI
- A table of who is Responsible, Accountable, Consulted and Informed for each task. The BA role
- Requirements traceability
- Linking each need to its requirements, stories and tests. Requirements
- Scope creep
- Uncontrolled growth of what the project must deliver. Change and UAT
- SIPOC
- A one-page view of suppliers, inputs, process, outputs and customers. Process models
- Sponsor
- The senior person who owns the business need and the budget. The BA role
- Stakeholder
- Anyone affected by or able to affect the change. Elicitation
- Swimlane
- A band in a process diagram that holds the steps of one role or system. Process models
- UAT
- User acceptance testing: real users confirm the system supports their work. Change and UAT
- Use case
- A description of how an actor reaches a goal with the system, with main and alternate flows. Requirements
- User story
- A short need written as "As a…, I want…, so that…". Stories and criteria
Courses on Kolom
- Business Analysis: the BA role, elicitation, process models, requirements, stories, UAT and change.
- From Spec to Launch: specs and stories from the product side, and working with engineers and vendors.
- Internal Tools, Operations & Platforms: frontline design, systems of record and adoption.
- Business and Enterprise Architecture: capability maps, value streams and roadmaps above single projects.
- Software Testing and QA: test design, bug reports and UAT from the tester's side.
- Product Discovery: interviews and field research that sharpen elicitation.
What to read next
- A Guide to the Business Analysis Body of Knowledge (BABOK Guide) from IIBA, at iiba.org. The reference framework of BA tasks and techniques.
- Software Requirements by Karl Wiegers and Joy Beatty. A practical, thorough book on writing and managing requirements. Pairs with Requirements.
- User Story Mapping by Jeff Patton. Laying out stories along the user's journey to plan releases. Pairs with Stories and criteria.
- The BPMN specification from the Object Management Group at omg.org/spec/BPMN. The full notation, when you need more than the basics. Pairs with Process models.