Business Rules
What Is a Business Rule in ArchRepo?
A Business Rule is a constraint, policy, or condition that the business operates under or that the solution must enforce. Business Rules define the boundaries within which the solution must operate — not what it does, but what it must always respect.
Examples of Business Rules:
- “Invoices over £10,000 must be approved by two Finance Managers before payment is released.”
- “Customer personal data must not be stored or processed outside the UK.”
- “A purchase order cannot be raised if the requestor is the same person as the budget approver.”
- “All supplier contracts must reference the current approved standard terms.”
Business Rules are referenced using the prefix RUL- — RUL-1, RUL-2, and so on.
Business Rules vs Business Requirements
Business Requirements describe what the solution must do — capabilities and behaviours the business needs.
Business Rules describe what the solution must enforce or respect — constraints, policies, and conditions that apply regardless of what the solution does.
A rule often generates one or more requirements. For example:
- Rule (RUL-12): “Users may only approve transactions up to their delegated authority limit.”
- Requirement (FR-34): “The solution must prevent a user from approving a transaction that exceeds their delegated authority limit.”
The rule is the authority — the business constraint that exists regardless of the solution. The requirement is the derived capability — what the solution must do to comply with the rule. Keeping them separate makes it clear why a requirement exists and which business policy it enforces.
Source
Each Business Rule records a Source — the document, regulation, policy, or person that is the authority for the rule. Recording the source:
- Makes it possible to trace rules back to their authority, so changes to the source (e.g., a regulatory update) can be assessed for impact
- Provides evidence that the rule is a real business constraint, not an assumption
- Helps stakeholders understand where the rule came from and who can authorise changes to it
Examples: “Finance Policy FP-14”, “GDPR Article 44”, “Agreed with CFO in workshop 12 March 2025”, “Section 3.2 of the service contract”
Approval
Business Rules support formal approval. In compliance-driven or contractual contexts, it is often necessary to obtain sign-off that the documented rule set is correct and complete — from the business owner, a regulator, or the customer.
Use the approval workflow to record that a rule has been reviewed and agreed, providing an audit trail for the rule register.
Acceptance Criteria
Two types of acceptance criteria can be linked to each rule:
| Type | Purpose |
|---|---|
| Acceptance Criteria | Business-level criteria: defines how the business will verify that this rule is being enforced correctly |
| Implementation Acceptance Criteria | Technical criteria: defines how the delivery team will verify that the rule has been implemented correctly |
The Business Rules v Acceptance Criteria collection view provides a completeness check — any rule without linked acceptance criteria has no defined test for compliance.
Categories
Rules can be assigned to categories to group them by domain or theme — for example, Financial Controls, Data Governance, Security, Regulatory Compliance. The Rules by Category view organises the full rule set into its categories, providing a structured view that is easier to review with stakeholders and business owners than a flat numbered list.
Fields Reference
See Business Rule Fields for a description of each field and guidance on what to record.