Analyzing Business Rules

Introduction

I decided to write this (allegedly) short book because I see business analysts (BA’s) struggling with business rules all the time.

But what is a BA?  For my purposes here, a BA is someone who helps a business stakeholder clarify their needs or understand whether a particular solution will meet those needs.

This means that my BA may or may not have the job title of BA. It also means that I am ignoring a lot of the work a professional BA does. Rather, my audience is anyone working on:

Clarifying a problem or opportunity and turning that into a vision for a potential project;

Creating a requirements document as part of a project;

Working in an agile development team and producing stories for a project; or

Working with production users and trying to understand their issues with an existing system.

But why do business rules matter?

Business rules are the constraints that an organisation places on potential solutions and on the behaviour of its staff, clients and stakeholders.

If we do not understand those constraints then we do not really understand the context in which we are building a solution.

Similarly, if we do not understand those constraints we may not be able to expose and exterminate stupid rules. And stupid rules are imposed on people all the time.

But why another book on business rules?

There is some surprisingly rich material around on how to write business rules (for example – just google the term rulespeak and explore what you find). There are also a lot of books on business analysis in general. But I could not find a good book on how to explore and uncover business rules and then document or model them.

So this book aims to provide a simple toolkit that can be used to understand, uncover and then communicate business rules.

Oh, and the other reason – I have always wanted to be an author and suddenly I find myself getting older with no great novel or world-shattering philosophical tome coming out on the horizon. So I thought if I publish a book on business rules then I can introduce myself as an author rather as another consultant.

But is this book useful or did you just want to be an author?

Hmmm ... this is the structure that I hope will be useful.

Firstly I will define what a business rule is and explain why I think you should capture them in a separate form to (other) requirements. Next I will run through some basic suggestions on how to capture or document rules. Then I will run through some models that can be used to explain rules where the text for rules is getting too complex. Finally I will run through some approaches that I believe will help you uncover business rules