Choosing notations for a claims system with a lifecycle and a rule set
An insurer is replacing its claims adjudication system, and two very different behaviours sit inside the same release. First, a claim lifecycle: received, validated, medical review, pending-information, approved, rejected, paid, appealed, closed - with re-entry from appeal back to review and from pending-information back to validated. Second, benefit calculation: a monthly premium is computed from plan type (four values), employee count, region, smoker status and a discount code. The business rules number about 60 and currently exist as prose in a spreadsheet.
The test manager has one modelling tool that supports UML and BPMN; the team has no experience with formal methods. Testers derive cases from the spreadsheet by intuition, and last year two rating errors reached production because a discount-code and region combination was never tried. The regulator requires every business rule to be traceable to at least one test, and the audit is in four months.
1. Recommend a notation for each of the two behaviours and justify the choice in terms of the behaviour being modelled, the team's skill, and the coverage you need to report.
Read the worked answer
Claim lifecycle → UML state machine. The behaviour is event-driven and state-dependent: which events are legal depends entirely on the current state (you cannot pay a claim in medical review). A state machine makes illegal sequences explicit, gives you states and transitions as coverage items, and catches exactly the class of defect where an out-of-order event is accepted. An activity diagram would show the happy flow but would hide the re-entry structure and the guards.
Premium calculation → decision table. The behaviour is a pure function of input combinations with no notion of history. A state machine would be the wrong tool - it would encode combinations as states and explode. A decision table gives one row per rule, makes overlaps and gaps visible, and maps one-to-one onto the regulator's 'every rule traceable to a test' requirement. Each row is a coverage item, so the audit report is a row-coverage table.
Team skill and tool. Both notations are in the existing tool and are the least intimidating of the formal options; the team can be productive in days rather than weeks. If the tool's decision-table support is weak, model rules as a decision table in a spreadsheet-like format and keep the row IDs as the traceability key - the notation matters more than the rendering.
2. Explain how you would make the 60 spreadsheet rules traceable and how don't-care entries in a decision table change the coverage you can claim.
Read the worked answer
Traceability. Give every rule a stable ID (R-001…R-060) before modelling, and keep that ID as an attribute on the decision-table row and on every generated test case. The tool then exports requirement → row → test case → result, which is what the auditor is asking for. Rules that are currently merged in prose must be split until each row expresses exactly one condition combination, otherwise one row hides two rules and the trace is ambiguous.
Don't-cares. A 'don't care' (or 'any') entry means the outcome is independent of that condition. This has two effects. First, it collapses what would be dozens of rows into one, so a 60-rule table may become 40 rows - and covering 40 rows is genuinely equivalent to covering the collapsed space, which is a legitimate claim you could not make about 60 unstructured prose rules. Second, it exposes incompleteness: rows whose condition sets overlap are ambiguous and will produce two different expected results for the same input - that is a specification defect found during modelling, before a single test runs.
What you may not claim: don't-cares do not justify skipping boundary values. If a row contains a numeric condition (employee count, premium threshold), each boundary still needs its own test case, generated as additional data variations behind the same row.
3. List the risks of running both behaviours through a single UML/BPMN tool with an inexperienced team, and how you would de-risk the four-month audit deadline.
Read the worked answer
Risks.
- Notational mismatch. Many UML/BPMN tools have weak or decorative decision-table support; a table that is a picture rather than an executable model cannot generate or report coverage. Verify before committing.
- Semantics not executable. A diagram that renders correctly may have no precise execution semantics, so generation is manual - the cost benefit disappears.
- Skill concentration. With no formal-methods background, the first modeller becomes a single point of failure.
- Scope creep. Trying to model the whole system rather than the two behaviours under regulatory scrutiny.
De-risking. Run a one-week spike on the decision table first, because it is the smaller, more bounded artefact and directly serves the audit. Success test: generate at least one test case per row and export the trace. Choose a subset of the lifecycle (received → validated → review → approved/rejected) for a second spike rather than all nine states. Assign two people to modelling, review each other's models, and write a two-page modelling convention (naming, ID scheme, guard syntax) so the second person can continue. Keep a manual fallback: if generation is not working by week six, the decision-table rows still give the auditor traceability by hand.