Lesson 2 of 3
The diagram is a requirements source
A well-built BPMN diagram is not just a communication tool — it is a structured database of business requirements waiting to be extracted. Every element in the model corresponds to one or more BA artefacts. The extraction is systematic, not creative.
Element-to-deliverable mapping
| BPMN element | BA deliverable | What to extract |
|---|---|---|
| Task | User story or functional requirement | Actor (from the Lane), action (from the task name verb), object (from the task name noun) |
| Exclusive Gateway | Business rule | The decision logic: what condition determines each outgoing path |
| Timer Boundary Event | SLA / service level requirement | The time limit and what happens when it is breached |
| Data Object | Data requirement | What information is needed, by whom, at what point in the flow |
| Message Flow | Integration requirement | What system or organisation sends/receives, what data is exchanged |
| Lane | Role definition or RACI entry | Who is responsible for which tasks |
| End Event | Acceptance criterion | What constitutes a successful or unsuccessful process outcome |
| Sub-process | Functional specification | A candidate for a more detailed requirements section or separate diagram |
| Collapsed external Pool | Stakeholder or integration dependency | An external participant the solution must interact with |
Exercise
Take your Invoice Approval model and extract one requirement from each element type in the table above. You should be able to produce 8 to 12 requirements directly from the diagram without inventing anything that was not already visible. If you cannot extract a requirement from an element, either the element is unclear or it should be removed.
Worked example: Exclusive Gateway → Business Rule
Consider an Exclusive Gateway labelled 'Invoice amount above limit?' with outgoing flows labelled 'Yes, > £5,000' and 'No, ≤ £5,000'.
Extracted business rule: 'Invoices with a gross amount exceeding £5,000 must be approved by a Finance Manager before payment processing. Invoices at or below £5,000 may be approved by a Finance Clerk.' This rule was already in the diagram. It did not need to be written separately — it needed to be read from the model.
Cross-checking requirements against the model
The extraction technique works in both directions. Once you have a requirements list, check that every requirement has a corresponding element in the model. If a requirement has no element, either the model is incomplete or the requirement does not belong in this process. If a model element has no corresponding requirement, ask why it is in the diagram.
This two-way traceability — from model to requirements and back — is one of the most valuable quality assurance techniques a BA can apply to their own work.
✓ When to use
- After completing or reviewing any process model — extract requirements as a standard step
- In requirements workshops to structure the conversation using the diagram
- Use the reverse check (requirements back to model) to identify gaps in either direction
✗ When not to use
- ✕Don't extract requirements before the model is stable — a diagram still being iterated will produce a moving requirements target
- ✕Don't treat the extracted list as final without stakeholder validation