XXX < the process/project/system name – if this is to be developed from a process model then use the hi-

level process name>

Document Type: Business Rules Document

<TEMPLATE INSTRUCTIONS: REMOVE ALL TEXT IN THIS STYLE AFTER YOU HAVE COMPLETED THE
SECTION. REPLACE ALL TEXT IN NORMAL STYLE. THE INDEX UPDATES AUTOMATICALLY UPON
RIGHT CLICK, UPDATE FIELD. COPYRIGHT IN THIS TEMPLATE REMAINS WITH CRAG SYSTEMS>

<The change log should be updated for every significant change made to the document. Use the format n.m
for the version number>

Version Description Changed By Date

1.0 First draft Fred Bloggs 1/1/00

<For detailed guidelines on how to use this template, see the Business Analysis Stage of the CRaG Systems
Software Development Process>

Index
Index .................................................................................................................................................................... 1
References .......................................................................................................................................................... 1
BR 1 ..................................................................................................................................................................... 2
BR 1.1 .............................................................................................................................................................. 2
BR 2 ..................................................................................................................................................................... 2
BR 2.1 .............................................................................................................................................................. 2

<Business rules will normally begin life as textual notes in the process model. This is because they will be
gathered during a process development workshop and written straight into the process model. Once the
process model is stable, then business rules should be formalised in this Business Rules Document and
given a unique reference number within the hi-level process/project/system model from which they have been
derived.

Once formalised, the business rule reference in the form BR n[.m] should replace the textual note in the
process model from which it has been derived.

Note that a single business rules may apply across multiple processes in the process model, also to data in
the business data (conceptual) model and to statecharts for entities in the business data model. Where it is
realised that the rule applies in more than one place, the reference to the rule, in the form BR n[.m], should
also be made in the textual note property of each element. The elements could be entities, attributes, roles
and relationships in the business data model, or states, events, transitions and conditions in the business
state model>

References
<Add reference to the process model, hi-level process, business (conceptual) data model and/or glossary in
which these business rules will be referenced or upon which they will depend. Use hyperlinks if possible.>

Author: <the author’s name> Page 1 of 2 Printed: 02/12/2018 11:45

XXX < the process/project/system name – if this is to be developed from a process model then use the hi-
level process name>
Document Type: Business Rules Document

Index

BR 1
Constraint/Computation/Action: xxxxxxxxx
<Define the business rule using a single sentence as a declaration. It must have a subject, a verb and an
object. Ensure that the language used is both unambiguous and easy to understand. The words used must
have unique meanings within the business domain. If they are nouns, then they should appear in the
Business Data (conceptual) Model as business entities or attributes. If they are verbs then they will most likely
also appear in the Business Data Model as part of the names of relationships between entities. If there is no
Business Data Model then the Glossary must be started and maintained as part of the business analysis
stage (see Gathering Requirements Stage).

Use a number that is unique within the hi-level process/project/system model to identify the rule. Numbers
should be in Heading1 Style. Do not attempt to add a name for the rule. If a rule is a sub-rule of another rule
then use hierarchic numbering and Heading 2 Style for the number. Each rule sentence should begin with one
of Constraint/Computation/Action: in order to define the rule type. See ‘Define Business Rules Task
Guidelines for a more detailed description of different types of business rule and how to write them.>

BR 1.1
Constraint/Computation/Action: xxxxxxxxx
<Write sub-rules in exactly the same way as their parents>

Index

BR 2
Constraint/Computation/Action: xxxxxxxxx
<Add further rules as required. Do not be tempted to re-organise the order of the rules and re-number them
once any rules at all have been referenced back in the business model. It simply isn’t worth the hassle trying
to sort out the mess.>

BR 2.1
Constraint/Computation/Action: xxxxxxxxx
<Write sub-rules in exactly the same way as their parents>

Author: <the author’s name> Page 2 of 2 Printed: 02/12/2018 11:45