System Analysis Example: From Problem to Requirements
9 min read
System analysis is the disciplined way to take a messy, emotional, contradictory problem and turn it into clear system requirements you can build, test, and ship. In this worked system analysis example, I will show the exact artifacts I use in real projects: current state map, future state, use cases, data flows, and acceptance criteria that stop scope creep.
What a system analysis example actually includes (and why most fail)
A good system analysis example is not a diagram dump. It is a traceable chain: problem statement - stakeholders - current state - constraints - future state - requirements - acceptance criteria.
Most analyses fail for one of two reasons. First, they skip the uncomfortable part: writing down the messy reality (workarounds, shadow spreadsheets, missing fields, ambiguous ownership). Second, they jump to solutions too early, which is how you get a feature list instead of a system.
A practical check: if you cannot point to a requirement and say, “This exists because in the current state, step X breaks for user Y,” your analysis is not doing its job.
When teams get stuck here, it is often analysis paralysis: you keep interviewing and collecting notes because you do not have a structure to force decisions. A decision board that compares options side-by-side can break that loop. Lucid is built for that kind of clarity, but the foundation still starts with the same system analysis artifacts.
System analysis example scenario: “Refunds are chaos”
Let’s use a realistic scenario from ecommerce operations.
Messy problem (verbatim from stakeholders):
“Refunds are chaos. Customers complain, finance says we lose money, support is drowning, and nobody trusts the numbers.”
That statement is useful because it contains symptoms and conflict, but it is not buildable. The system analyst’s job is to turn it into a scoped system problem.
Tight problem statement (what we will analyze):
“Refund requests are processed inconsistently across channels, causing delayed customer resolution, inaccurate financial reporting, and rework between Support and Finance.”
Success metric (so we can stop arguing later):
Reduce median refund resolution time from 6 days to 2 days while keeping refund leakage under 0.5% of refunded GMV.
Current state (as-is): map the reality, not the org chart
Current state is where you earn trust. You are not designing yet. You are documenting what happens when real humans do the work.
Here is the current state we typically uncover after two short shadowing sessions and one data pull:
Step
Actor
Input
Tool used
Output
Common failure
1
Customer
Refund request
Email, chat, marketplace portal
Ticket created
Missing order ID
2
Support agent
Ticket
Helpdesk
Manual lookup in order system
Wrong order matched
3
Support lead
Escalation
Spreadsheet tracker
“Approved/Denied” note
Duplicate rows, stale status
4
Finance
Approved list
CSV export
Accounting system entry
Amount mismatch vs order
5
Support agent
Finance confirmation
Helpdesk
Customer notified
No SLA, customer chases
Two things matter here.
First, you can already see the system boundary: helpdesk, order system, spreadsheet, accounting system, and marketplace portals.
Second, you can see the real constraint: the spreadsheet is acting as a workflow engine. That is not “bad behavior.” It is a missing system.
When you document current state, ask the analysis questions that expose hidden rules: “What makes you deny a refund?”, “What exceptions happen weekly?”, “Which field do you always have to retype?”, “Where do you wait on someone else?”
Future state (to-be): define the outcome and the constraints
Future state is not “we build a refunds tool.” It is a description of how work should flow, including what must stay true.
Future state definition:
“Refund requests enter a single intake, are automatically enriched with order data, follow a consistent approval workflow with SLAs, and write back to both customer communications and finance records with a shared refund ID.”
Constraints you want explicit:
Finance needs auditability (who approved what, when, and why).
Support needs speed and templates.
Ops needs visibility (queue, SLA breaches).
Legal needs retention rules.
This is where scenario analysis becomes practical. You do not need 20 scenarios. You need the ones that change the system behavior:
Scenario
What changes
Why it matters to requirements
Partial refund
Amount differs from line item totals
Requires item-level data model
Refund after shipment
Return status affects eligibility
Requires shipping/return integration
Marketplace order
Refund must be initiated in portal
Requires channel-specific actions
Fraud suspicion
Manual review and evidence
Requires “hold” state and notes
One standalone sentence I use to keep teams aligned: If a scenario changes the workflow, it deserves a requirement.
Use cases: turn “needs” into testable interactions
Use cases are where stakeholders start nodding because they recognize their day-to-day work.
Write them in plain language, then attach system behavior.
Use case 1: Support creates a refund request
Primary actor: Support agent
Trigger: Customer asks for refund via any channel
Outcome: Refund case created with required fields, linked to order, SLA started
Key rules:
Order ID is required, but the system can suggest matches by email and date.
If order cannot be matched, case enters “Needs info” and sends a template.
Use case 2: Finance approves and posts refund
Primary actor: Finance analyst
Trigger: Refund case enters “Ready for finance”
Outcome: Refund is posted to accounting system and marked “Completed” with audit trail
Key rules:
Approval thresholds (example): over $500 requires Finance lead approval.
Every refund must have a reason code.
Use case 3: Customer gets status updates
Primary actor: Customer
Trigger: Status changes
Outcome: Customer notified with consistent language and expected timelines
At this stage, teams often get pulled into solution debates. When that happens, I use a lightweight decision making matrix to compare options like “build workflow in helpdesk” vs “new internal tool” vs “outsourced refunds platform.” The trick is to score only against constraints you already agreed on.
If you prefer a more visual approach, a board-style comparison is faster than a spreadsheet. Lucid’s decision board is designed for that, and it keeps the decision logic consistent as you add new constraints.
Data flows: show what moves, where it moves, and what must be true
Data flows stop “integration surprises.” If you cannot draw the flow, you do not understand the system yet.
For our refunds system, the minimum viable data flow looks like this:
Data object
Source of truth
Consumed by
Must include
Notes
Order
Order system
Refund service, Support UI
Order ID, items, totals, payment method
Enrichment step
Refund case
Refund service
Support, Finance, Analytics
Refund ID, status, reason, timestamps
New shared identifier
Accounting entry
Accounting system
Finance reporting
Refund ID, amount, ledger codes
Must reconcile
Customer messages
Helpdesk or messaging service
Customer
Status, ETA, next steps
Templates + localization
A common failure mode: teams let each system invent its own refund identifier. Then reconciliation becomes detective work. Make the Refund ID a first-class field everywhere.
If you want a strong reference for how Google thinks about documenting systems and requirements quality, their guidance on clear documentation and testing principles is scattered, but Google Search Central documentation standards is a surprisingly good model for “unambiguous, testable statements.” Different domain, same rigor.
Requirements + acceptance criteria: make it buildable and verifiable
This is where your analysis becomes engineering-ready. Requirements without acceptance criteria are just wishes.
I write requirements in a simple format: “The system shall…” paired with “We will accept this as done when…”
Requirement (system shall)
Acceptance criteria (done when)
Create a refund case from any channel intake
Given a customer email and order ID, when a case is created, then required fields are validated and SLA timer starts within 5 seconds
Enrich refund case with order details
Given an order ID, when enrichment runs, then item list, totals, and payment method are attached and visible to Support
Support can move case through workflow states
Given a case, when Support updates status, then transitions follow allowed state rules and are timestamped
Finance approval thresholds are enforced
Given a refund amount over $500, when approval is attempted, then Finance lead approval is required before posting
Post refund to accounting with shared Refund ID
Given an approved case, when posted, then accounting entry contains Refund ID and amount matches case amount
Customer receives status notifications
Given a status change to “Approved” or “Denied,” when it occurs, then a message is sent within 2 minutes using the correct template
Two external references I point teams to when defining “testable” are the classic definition of acceptance criteria in agile and requirements quality. The Wikipedia overview of acceptance tests is basic but gets everyone aligned fast. For requirements quality, the IEEE guidance on SRS structure is the gold standard even if you do not adopt it fully.
If you want to prevent the most common failure (requirements that conflict), add a final artifact: a decision flowchart for edge cases. Example: “If refund requested after 30 days, route to manual review.” That flowchart becomes the tie-breaker when stakeholders disagree later.
Next step: turn your messy notes into an options board in 10 minutes
Take one real problem you are overthinking and write it as a single sentence with a measurable outcome. Then draft the current state table and three scenarios that change the workflow. If you want to move faster, drop your raw notes into Lucid and let it generate an options map you can refine in Grid, Table, or Focus view. Start with creating a Lucid account and build your first decision board from the exact artifacts you saw above.
Frequently Asked Questions
System Analysis Example: From Problem to Requirements | Lucid
