Business Analysis Session 3 Business Rules, Data Dictionary

Front 1

What was discussed in Session 3?

Back 1

Business Needs , Stakeholder List Roles and Responsibilities..

Front 2

What were the key learning objectives for session 3?

Back 2

Learning Objectives
Getting stakeholder and solution requirements stated by

Approaching Business Rules Analysis with confidence by making use of document analysis using mind-mapping to elicit them, and verifying them using decision trees and decision tables

Clarifying stated requirements by making use of techniques such as data dictionary, data modeling, and the possibilities table

Front 3

What is the definition of Business Rules?

Back 3

To define rules that govern decisions in an organization and that define, constrain, or enable organizational operation. (BABOK guide)

Business rules should be:
Stated in appropriate terminology
Documented independently of how they will be enforced.
Stated at the detailed level.
Separated from processes that rule support or constrains.
Maintainable.

Front 4

What is the Hierarchy of business rules?

Back 4

A business Policy is a non-actionable directive that supports a business goal.
E.g. “XYZ company

A business Rule is a specific, actionable, testable directive that is under the control of an organization and that supports a business policy.
E.g. “product descriptions must state the % of recycled material included in the product “.

Front 5

What are the Business Rules Elements?

Back 5

Operative Rules: rules to be used for enforcing policy matters. A guide for people working in the organization. e.g. “Personal accounts with a balance of $0 which have had no customer activity for a twelve months, will be closed”.

Structural Rules: rules to determine if something is or is not true. Describe categorizations that may change over time. E.g. “In order for an account to have no customer activity for 12 months, the activity log for “last12months” must give a zero count.

Front 6

What are some key terms for Business Rules Overview?

Back 6

Use a defined glossary of terms and understanding of the relationships between them.

Make no dependencies on other information.

Do not include any assumptions.

Use tools like Decision Tables, Data Dictionary and Data Modeling to document Business Rules.

Front 7

What is a practical approach for Business Rules?

Back 7

Review, Group, Consult, Categorize, and Check.

Front 8

What are some of the steps for Business Rules testing and verification?

Back 8

You need to verify the adequacy of business rule definitions before enforcing.

Create decision table and decision tree
Try few different scenarios:
Check for positive and negative cases

Document the outcomes

Ask a SME or an expert to verify your outcomes

You may seek legal advice in some cases
Make adjustments if necessary

Front 9

What is a Decision table?

Back 9

A table created to link observable conditions ( its raining) to necessary actions ( take an umbrella)

Very useful in Business Analysis for capturing and clarifying business rules that apply in the business area

Using a decision table enables the BA to ensure that all condition states( the forecast says it will rain) and all action states ( put umbrella in car) are clearly defined.

Front 10

How many quadrants does a decision table have?

Back 10

A decision table has 4 quadrants:

Conditions
Condition alternatives
Actions
Action entries

Front 11

Decision Table Usage?

Back 11

You can use Decision Tables in:
Business Analysis
Programming
Testing
Hardware Design

Decision Tables are also a way to represent Business Rules !

Front 12

Creating Decision Tables

Back 12

What questions need to be answered before you can determine what to do ?
What are the different values each of these can take?
What are all the possible outcomes of this process ?
What actions could the business take?
Calculate numbers of distinct scenarios and assign a column for each
Complete entries so that each column shows a distinct set of values
Document each required action with an “X” in the appropriate action cell

Front 13

What is Document Analysis?

Back 13

The systematic examination of existing documentation to discover information, issues, or to understand policies, procedures and business rules.

Front 14

Why is Document analysis an important technique for business analysis?

Back 14

Provides access to prior knowledge on a wide variety of relevant areas that have already been documented.

Prompts for questions that the BA needs to find answers to.

Gives clues to requirements which appear as either explicit conditions that must be met or implicitly as desired outcomes in plans, policies, procedures and forms.

Front 15

Features and Benefits of document analysis?

Back 15

Especially useful
Look carefully at the dates
Complements other elicitation techniques
Takes Time

Especially useful: In situations where the project involves an update to an existing solution and the Subject Matter Experts for the existing solutions are no longer available to the project.

Look carefully at the dates. Regardless of the type of documents studied, such as business plans, market studies, RFP, training guides, current guidelines and procedures, existing system specifications, it is important to keep in mind that they must be as most up to date as possible. Check the dates and ask if there were more recent versions created, even if these were drafts.

Complements other elicitation techniques. Findings from this process can validate requirements obtained from other elicitation techniques.

Takes time. Studies of such vast amount of materials are likely to cost Business Analysts a lot of their valuable time.

Front 16

What are some of the document analysis steps?

Back 16

1) Prepare
2) Conduct
3) Follow Up

Prepare. Catalogue the existing system and business documentation. Ask stakeholders “ What documents would be useful for me to review to better understand the business goals, process and current systems in this area, and where can I get hold of a copy ?”.
Go quickly through all sources of information available to determine what is relevant and suitable to be reviewed in detail.

Conduct. Review the materials and identify and record relevant business details. These details should be documented along with questions intended for subject matter experts.

Follow-up. Confirm significant details with subject matter experts or from other sources, where these are not available.

Front 17

What are some document sources?

Back 17

Training Manuals
Regulations
Maintenance guides
Job Aids
System documentation
Manual Forms
Products Catalogues and other relevant Customer Information

Front 18

What are some other things we can do to clarify requirements?

Back 18

1) Possibilities Table
2) Data Dictionary and glossary
3) Data modeling

During elicitation we may collect statements and document them at “face value”. We need to clarify them and ensure they are as complete as we can make them. Several techniques exist to assist us

We can analyze stated requirements to see if they would be more usefully expressed in more general or more specific terms. This is the Possibilities Table.
We can create an organized and cross-referenced repository of terms to ensure the terms used are correct. This is the Data Dictionary and Glossary.

We can define the interrelationships between entities. This is accomplished by Data Modeling.

Front 19

How sift stakeholder input (possibilities table)

Back 19

Sifting Stakeholder Input

Any given statement from a stakeholder is likely to be in the "right ballpark" but may not be "on base".

Aspects of it may be either more specific than is strictly necessary of not specific enough. For instance there may be additional factors and exceptions that need to be stated.

One way to "process" each statement is to break it down into parts and systematically test each part using a technique known as a Possibilities Table (aka an abstraction table).

Front 20

Possibilities Table-Example of Initial Stakeholder Statement

Back 20

"An email must be sent to the assigned service provider as soon as a service ticket is raised by a user".



Can we see aspects that could be too limiting or too vague? If so analyze !

Front 21

Glossary - Keeps everyone on the "same page"

Back 21

Glossary

Front 22

What is the definition of data dictionary and glossary?

Back 22

Definition:
Centralized repository of information about data.

A file that defines the basic organization of a database.

A database that contains definitions of all data items defined during analysis.

A document or system that characterizes the data content of a system.

A tool that provides metadata or information about data. A data dictionary describes the definitions, attributes, and context (e.g. proprietorship, business rules) of data elements within a data set.

Front 23

More on Data Dictionary and Glossary.

Back 23

A data dictionary or glossary defines key terms and data relevant to a business domain

For example : Client, Customer, Patient- Does it matter ? Which is which ?

A person buying products or services from a business.

A person retaining a professional to protect their interests

A person receiving or registered to receive medical treatment

Front 24

What is the purpose and usage of data dictionaries / glossary?

Back 24

To define key terms and data relevant to a business domain.

To give you everything you would want to know about the project.

To formally identify and define all terminology used by the organization within the scope of analysis

To ensure all stakeholders are in agreement on the
format and content of relevant information.

Front 25

What are some types of data models?

Back 25

1) Entity-relationship model or Class Diagram
2) Geographic data model
3) Generic data model
4) Semantic data model

Front 26

What is an Entity-Relationship Model?

Back 26

Relationships between Customers, Orders and Order Items

Also shows Cardinality- the number of occurrences of one entity that are linked to a second entity

May indicate a Primary Key- which uniquely identifies an occurrence of each entity, is generated by an internal ( customer #) or external system ( e.g. Postcode)

Front 27

What is cardinality in ER Diagrams?

Back 27

Types : One-to-One, One-to-Many, Many-to-Many

Legend : 0, 1 or < (Many) on the line indicates the allowable range of occurences

Again read left to right

See previous diagram

“ One customer may have between Zero & Many orders”

“One order may have between One & Many order items”

( Interpretation : A customer has an account and so may not have an order in system right now, but if they do have a order its because they are purchasing one or more items currently)

Front 28

ERD Insurance Example

Back 28

Interpretation for stakeholder
Each underwriter approves zero or more amendments
Each amendment is approved by one underwriter

Is anything missing from this diagram ? If so, what ?

Front 29

Creating an Entity-Relationship Model

Back 29

Identify Entities (from Glossary) that have more than one attribute (things to track about them)

Write each entity in capitals (name it in the singular)

Draw a box around each entity. List candidate attributes for each entity ( look at output documents)

Define a Primary Key for each Entity ( identifier that distinguishes instances of this entity from other occurrences of same entity).

Identify relationships among entities (see next page)

Front 30

How to find the relationships?

Back 30

Look up on page 53.

Identify where relationships exist among entities ( Can <Entity Name 1> exist without <Entry Name 2 > ? . If yes, there is no relationship. If no, then draw a connecting line.

Analyze the nature of the linkage. What is the verb that links ? “Customer places order”
Write it above the line. Then write the inverse relationship in the passive voice and put below line. “Order is placed by Customer”.

Determine and map the cardinality ( Can an occurrence of Entity A be related to one or more than one occurrence of Entity B ? And vice-versa). Review one-to-one relationships carefully as experts say these are rare in practice.

Adopt a Data Model with built-in relationships. In some cases there is a quicker way to identify the relationships because they are defined by the Glossary, are pre-determined or follow physical laws.

Front 31

Class diagram (UML)

Back 31

Insurance example, page 59