Diagram is not for document decoration. Good diagrams help the team respond quickly:
- Where does the process go from here to where?
- Who does which step?
- Which systems are involved?
- How does the status change?
- Which API/service calls which service?
- In case of error, which way should you go?
BAs do not need to become solution architects, but Software BAs should know how to choose the right type of diagram to reduce misunderstandings.
1. When is BPMN used?
BPMN is suitable when you need to describe a business process with many actors, many steps, and many decision branches.
For example:
- Insurance claim approval process.
- Customer onboarding process.
- Examination appointment booking process.
- Refund processing process.
- KYC verification process.
According to OMG, BPMN is the standard notation to describe business processes using Business Process Diagram, easy enough for business to understand but still accurate enough for technical users.
BAs should use BPMN when the main question is: how does the business operate?
2. When is UML used?
UML has many types of diagrams. BA usually only needs a few types:
| Diagram | Use when |
|---|---|
| Use case diagram | Need to identify main actor and capability |
| Activity diagram | Need to describe a simpler processing flow, with less notation than BPMN |
| Sequence diagram | Need to describe interactions between user, UI, API, service, external system |
| State diagram | Need to describe the status lifecycle of order, ticket, claim, booking |
| Class/domain model | Need to unify entities, attributes and business relationships |
BAs should not draw UML just because it feels "professional". Choose the diagram according to the question you need to answer.
3. For example: appointment scheduling feature
BPMN level business
Goal: business understands the end-to-end process.
Patient -> Search doctor -> Select slot -> Submit booking
System -> Check slot availability
Gateway:
- Slot available -> Create appointment -> Send confirmation
- Slot unavailable -> Show alternative slots
Clinic staff -> Review appointment list
At this level, the BA should demonstrate:
- Pool/lane: Patient, System, Clinic staff.
- Gateway: slots available/unavailable.
- Event: booking submitted, confirmation sent.
- Exception: payment failed, slot expired, doctor unavailable.
Sequence diagram level software
Goal: Dev understands how the system interacts.
User -> Web App: Submit booking
Web App -> Booking API: POST /appointments
Booking API -> Schedule Service: reserveSlot(slotId)
Schedule Service -> Database: lock slot
Booking API -> Notification Service: send confirmation
Booking API -> Web App: appointmentId + status
At this level, the BA does not need to decide on the architecture, but needs to indicate:
- Which external system is involved?
- What data is sent.
- Which error does the business need to handle?
- Which response the UI needs to display.
State diagram level lifecycle
Goal: unify sales status.
Draft -> Pending Confirmation -> Confirmed -> Checked In -> Completed
Confirmed -> Cancelled
Pending Confirmation -> Expired
Confirmed -> No Show
With each transition, the BA needs to ask:
- Who can change status?
- What are the transfer conditions?
- Is there an audit log?
- Are there any notifications?
- Are there any refunds or fees?
4. Diagram must be accompanied by text
Diagram alone is often not enough. Each diagram should have:
- Purpose: what question does this diagram answer?
- Scope: in-scope/out-of-scope.
- Legend: special symbol if any.
- Assumptions.
- Related business rules.
- Open questions.
- Version and owner.
For example:
Diagram: Appointment Booking BPMN v1.2
Purpose: Align future-state booking workflow before sprint planning.
Scope: Online booking for outpatient consultation.
Out of scope: Insurance claim, offline booking, recurring appointment.
Owner: BA + Clinic Ops Lead
Approved by: Product Owner
5. Checklist review diagram
Before sending the diagram, check yourself:
- Does the diagram have a clear purpose?
- Is actor/lane enough?
- Is there a start/end event?
- Does the Gateway have clear conditions?
- Is exception flow represented?
- Does state transition have a guard condition?
- Is the diagram too detailed for the reader?
- Is there mapping to user stories/SRS?
- Is there a version and update date?
- Can business stakeholders understand without needing a BA to explain?
6. Common errors
Error 1: One diagram tries to answer every question
BPMN helps business understand the process. Sequence diagram for technical team to understand interaction. State diagram to understand lifecycle. Don't force one diagram to do it all.
Error 2: Drawing happy path, forgetting exception
Software bugs often lie in exceptions: slot has just been reserved by someone else, payment timeout, user closes browser, external API down.
Error 3: Diagram does not sync with requirements
If user stories say one way, BPMN says one way, test cases say another, the team will lose trust in BA documents. Diagram needs to be traced or at least reviewed with SRS/backlog.
Full package model example
Feature: reschedule consultation.
BPMN summary
Customer lane:
Open appointment detail -> Click Reschedule -> Select new slot -> Confirm
System lane:
Validate owner -> Validate appointment status -> Validate cutoff -> Validate slot
Gateway:
All valid -> Update appointment -> Release old slot -> Lock new slot -> Send notification
Invalid owner -> Return 403
Cutoff expired -> Show hotline message
Slot unavailable -> Show alternative slots
CSKH lane:
Handle exception for cutoff-expired case if customer calls hotline
State transition
| From | Events | Conditions | Big |
|---|---|---|---|
| Confirmed | Customer reschedules | Owner, >= 4 hours, new slots available | Confirmed |
| Confirmed | Customer cancels | Owner, >= 4 hours | Cancelled |
| Confirmed | Time passes | Appointment time reached, customer absent | NoShow |
| Confirmed | Consulting completes session | Session done | Completed |
Sequence summary
Customer -> Web App: confirm reschedule(new_slot_id)
Web App -> Appointment API: PATCH /appointments/{id}/reschedule
Appointment API -> Auth Service: check owner
Appointment API -> Schedule Service: reserve new slot + release old slot
Appointment API -> Audit Log: write old_slot/new_slot
Appointment API -> Notification Service: send reschedule email
Appointment API -> Web App: updated appointment
This diagram package helps each team read their part correctly: business sees BPMN, Dev sees sequence/API touchpoint, QA sees state transition and exception path.
Practice exercises
Select a process such as refund, schedule or review. Create:
- A future-state BPMN with at least 2 lanes and 2 gateways.
- A state diagram for the main object.
- A sequence diagram for the happy path.
- List of 5 unclear exception flows that need to be asked by stakeholders.
Reference source
- OMG BPMN Specification: https://www.omg.org/spec/BPMN
- OMG BPMN overview: https://www.omg.org/bpmn/
- OMG UML Specification: https://www.omg.org/spec/UML/
- IIBA BABOK Guide: https://www.iiba.org/standards-and-resources/babok/
Conclusion
A good diagram is not the most beautiful diagram, but the diagram that helps the right people make the right decisions. BA should use BPMN to align business, UML just enough to describe system behavior, and always connect diagrams with requirements, rules, and test cases.