Business Rules versus Acceptance Criteria

Update: This post is from April 2012 and has been superseded by one from July 2016: Decision models, user stories and acceptance criteria

One of my readers contacted me recently to ask whether business rules and user story acceptance criteria could be considered the same thing.

Acceptance criteria are the requirements that have to be met for a user story to be assessed as complete.

The Business Rules Group defines a business rule as follows:

  • A statement that defines or constrains an aspect of the business. It is intended to assert business structure, or to control or influence the behaviour of the business.

Business rules are normally defined at the organisational or enterprise level rather than the software level for the following reasons:

  • Not all of a business’s rules are implemented by a single software application
  • Not all of a business’s rules are implemented by software at all (e.g., some business rules govern what an employee should do and it is down to the employee to decide whether to do A or B, based on the rule)

Looking deeper into the first point above, two different software systems might not implement the business rule equally. A concrete example would be the following business rule:

  • Details of any bank account may be provided only to the following:
  1. The verified account holder
  2. Any verified authorised signatory of that account

This is a realistic rule for a bank which could apply to:

  • The bank’s staff in any branch (executed by humans)
  • The bank’s call centre staff (executed by humans)
  • The bank’s call centre software (executed by software)
  • The bank’s website (executed by software)

Imagine, however, that the website (let’s call it BOL for “Banking On Line) will not be capable of handing authorised signatories until a future release, so point 2 above will not apply to BOL yet, even though it currently applies to other areas of the business. The business rule is valid regardless of the release plan for BOL, so the rule should not be edited to fit into that plan. What should be adjusted is the relevant acceptance criterion relating to a user story for BOL.

When we look at this from the point of view of acceptance criteria for the next release of BOL, we might document an acceptance criterion as follows:

  • Details of any account are provided only to the verified account holder

So while the acceptance criterion and the business rule are clearly related, they are not the same. They are different in two ways:

  1. The AC is effectively a subset of the BR
  2. The grammatical structure (this is not a trivial point, precise use of English is very important in documenting clearly and unambiguously)

It is not correct, therefore, to simply transcribe acceptance criteria and label them business rules.

People often confuse “business rules” with expectations of how the To Be system will behave. The former can govern the latter, but that does not make them the same.

Kind regards,

Declan Chellar

Related posts:

LinkedIn
Follow by Email
RSS

2 comments to Business Rules versus Acceptance Criteria

  • Andrei

    Sir, do you agree that in the context of a software system every business rule can be formulated as one or more acceptance criteria? If you agree, do you think that acceptance criteria are more appropriate for documenting one specific software system, just because they are specifically designed for testing?

    • Declan Chellar

      Hello, Andrei.

      Thanks for taking the time to read and comment. I wrote that particular blog post in 2012 but since 2013 I’ve been building decision models, rather than documenting individual business rules. This different approach has an impact on acceptance criteria. See this new post on decision models, user stories and acceptance criteria: http://www.chellar.com/AnalysisFu/?p=2249

      Kind regards.

      Declan

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>