Business Rule Fields

1. Description

• What it’s for: The rule statement — a clear, specific description of the constraint or policy the solution must enforce.

• What to include:

  • Write as a specific, testable constraint: state the condition and the required behaviour.
  • Avoid vague language like “users should not be able to misuse the system” — instead: “A user may not approve a transaction raised by themselves.”
  • One rule per record — if a statement contains multiple constraints joined by “and”, consider splitting into separate rules.
  • Focus on what must be enforced, not how the solution enforces it — implementation detail belongs in design decisions, not the rule statement.

• Examples:

  • "Invoices over £10,000 require approval from two Finance Managers before payment is released."
  • "Customer personal data must not be stored or processed outside the United Kingdom."
  • "A purchase order may not be raised and approved by the same individual."

2. Source

• What it’s for: The authority for this rule — the document, regulation, policy, or person that is the origin of the constraint.

• What to include:

  • Reference the specific document and section where possible (e.g. “Finance Policy FP-14, Section 3”).
  • If the rule was agreed verbally or in a workshop, record who agreed it and when (e.g. “Agreed with CFO in requirements workshop, 12 March 2025”).
  • For regulatory rules, cite the specific regulation and article (e.g. “GDPR Article 44 — Transfers to third countries”).
  • Leave blank if the source is not yet known — and consider raising an assumption or issue to track the need to establish it.

• Examples: "Finance Policy FP-14", "GDPR Article 44", "Section 3.2 of the Master Services Agreement", "Confirmed by Head of Compliance in workshop 7 Feb 2025"

Relationships