Modelling Decisions

Method & Style

Modelling Decisions

  • What decision are we modelling?

  • What outcome does it yield?

  • What factors affect the decision?

  • What rules apply?

Don’t forget to test the resulting model(s) thoroughly (and, preferably, automatically)!

The Decision

  • Start with the root decision

  • Naming decisions

    • Activity style: determine this or that ← use in task that calls it!

    • Output style: this or that, recommended

    • Question style: which do we need? ← unnecessarily long, useful for gateway after

The Outcome

  • What is the primary result of the decision?

  • Defines the outcome(s) that the root decision will produce

  • Single value, structured data, collections…​

The Inputs

  • Start creating the requirements with a DRD

  • Which factors / inputs / data points determine the outcome of the decision?

  • Which values do they allow?

  • Are there supporting decisions?

    • Drill down following the same approach

    • Keep decomposing until there are only input data elements

The Rules

  • Define the Hit Policy of each decision

  • Define the inputs and input expressions, combined as AND

  • Input entries for each rule

  • (Output(s))

  • Output entries for each rule

  • Annotations for rules

Best Practices when Modelling

  • Top-down is the end result, but you may need to get there by going bottom-up first and then around again

    • This is not that different from process modelling

  • Decision logic is not dependent on a process model!

    • More of an implementation detail if the business decision is evaluated over time, really

  • Create stateless decisions (service of collaborating decisions )

  • Consider defining terms in a glossary (DDD)

Best Practices for Requirements

  • Decomposition is your friend

    • Think of decisions as functions: too many parameters or too broad scope is a sign to decompose further

    • Don’t use too many inputs for a single (supporting) decision (1-5 is okay)

  • Make sure inputs are independent: you can refer to other inputs, but then they are apparently dependent. Move this to a supporting decision

  • It is fine to not use spaces in variable names, to avoid issues. Make sure to stick to a standard.

    • Holes on Par → HolesOnPar / Holes_On_Par / holes-on-par

Best Practices for Decision Logic

  • Use simple datatype inputs - variable names (avoid creating mind benders)

    • Split needed results out instead of diving into expression of complex expression

    • Point notation on an object is allowed (Car.Mileage.Reported)

    • Move to supporting decisions as literal expressions

Best Practices for Decision Tables

  • Rules as Rows is the most intuitive layout for tables

  • Contract tables when possible

  • Tables should be complete for acceptable inputs

  • Single-hit? Unique is preferred hit policy

  • Ordering matters for visual reference