Modeling Method, Style, Verification and Validation
Scope
Method and style rules that make models readable and fit for purpose, plus the verification/validation distinction the exam tests directly.
Core rules
- Model levels: descriptive (Level 1, communication), analytical (Level 2, enough detail to analyse or simulate), executable (Level 3, all attributes an engine needs). Decide the level before drawing.
- Style rules: one start event at top level; labelled start and end events naming trigger and outcome; verb-noun task names such as 'Check credit limit'; explicit gateways instead of implicit splits and merges; avoid crossing sequence flows; left-to-right flow; decompose when a diagram passes roughly 10-15 activities; consistent lane meaning.
- Verification asks whether the model was built right: syntactic correctness, conformance to the BPMN metamodel, naming and style conventions, largely tool-checkable.
- Validation asks whether the right model was built: fidelity to the real process and usefulness to stakeholders, checked by domain experts, walkthroughs, simulation and operational data.
Worked example
A reviewer finds an XOR gateway whose two outgoing flows are 'approved' and unlabelled. The tool accepts it, so a colleague calls the model verified. Both claims fail: the unlabelled branch is an undefined split, a style and verification defect; and nobody has confirmed with the business that approval is binary, so validation is incomplete. Reasoning: verification is rule-based and internal, validation is stakeholder- and reality-based.
Traps that cost marks
Defining verification as 'the business agrees'. Treating tool warnings as proof of semantic correctness. Mixing executable attributes into a Level 2 model. Leaving gateways unnamed.