System Analysis and Design

Decision Tables

Introduction To Decision Tables

One of the major challenges for a “Systems Analyst” is to effectively communicate the system requirements to a diverse audience. Quite often this task is prepared by the collecting the facts, harvested from stakeholders and presenting them in a readable form, with enough detail to facilitate testing and other downstream activities.

Supplemental specifications and Use Cases, along with their supporting artifacts (Data Definition, Messages, User Interface, or Prototype, etc.) can be an effective way to communicate the non-functional and functional requirements but are not sufficient for making a system wide policy that can be followed as constraint to the system development.

Also we can describe a system in “Structured English” which can be used to describe business rules. By “Structured English” we mean a commonly used language which can describe the business rules, regulations and specifications which is commonly the native language in which the business is being operated. Most often it is English language.

However, when business rules get complicated, “Structured English” begins to break down. So in order to provide more efficient description, the Analyst can describe complicated business logic by way of decision tables and/or decision trees. This way the Analyst can provide specifications about the project in semi-technical way which is understood by the business owner and the system developer equally.

What is Decision Table?

Definition 1:

A decision table is a tabular form that presents a set of conditions and their corresponding actions.

Definition 2:

A decision table is a two-dimensional matrix with one row for each possible action and one row for each relevant condition and one column for each combination of condition states.

A “Decision Table” can very concisely and rigorously show complex conditions and their resulting actions while remaining comprehensible to a human reader.

Decision Tables Methodology:

The most common tool for the creation of decision tables is spreadsheet software, such as “Microsoft Excel”. Although this is really quite sophisticated software, it is affordable, readily available, and has a large base of trained users. Because of the ubiquity and sophistication of this software, it is quite easy to create additional software that can read decision tables created in the spreadsheet, understand the semantics therein contained, and take action to implement the logic expressed in the table like Microsoft Project and Microsoft Visio and IBM Rational Rose etc.

Following is the methodology adopted for the creation of “Decision Tables”:

1. Identify Conditions & Values

Find the data attribute each condition tests and all of the attribute's values.

2. Compute Max Number of Rules

Multiply number of values for each condition data attribute by each other.

3. Identify Possible Actions

Determine each independent action to be taken for the decision or policy.

4. Enter All Possible Rules

Fill in values of condition data attributes in each numbered rule column.

5. Define Actions for each Rule

For each rule, mark the appropriate actions with an X in the decision table.

6. Verify the Policy

Review completed decision table with end system users.

7. Simplify the Table

Eliminate and/or consolidate rules to reduce the number of columns.

Such simple methodology in the system development can finally allow the removal of the “3^rd Man” in the system analysis process, allowing an analyst or even a logic-savvy policy expert to proceed himself directly or guide a team to create the executable code required to implement system policy specifications using the “Decision Tables”.

Important Sub-Topics

1. Why to Choose Decision Tables?

2. How to Construct the Decision Tables?

3. Policy Specifications.

4. Decision Making Process.

5. Structured Policy Selection Methods.

6. Structured Language vs. Computer Based Languages.

1. Why to Choose Decision Tables?

“Decision Tables” are used to lay out all the possible situations, in a tabular form, which a business decision maker or a system analyst may encounter in a system, and also specify which action is required to be taken in each of the listed situations.

We use them in our projects to clarify complex decision making situations and they are found useful in our work as a system developer and system project manager.

2. How to Construct Decision Tables?

Example:

Let us consider the following example, which describes the calculation of shipping charges.

Company Provided Business Rule:

1. An Outdoor Shipping Company has just announced that it will offer free shipping for all orders over $250.00.

2. Shipping charges for all other orders will be charged accordingly.

3. For orders less than $250.00, the shipping charge will be calculated as follows:

1. If the number of items is 3 or less:

Delivery Day	Shipping Charge
Next Day	$35.00
2nd day	$15.00
Standard	$10.00

2. If the number of items is 4 or more:

Delivery Day	Shipping Charge, N = number of items
Next Day	N * $7.50
2nd day	N * $3.50
Standard	N * $2.50

4. For orders over $250.00, the shipping charge will be calculated as follows:

1. If the number of items is 3 or less:

Delivery Day	Shipping Charge
Next Day	$25.00
2nd day	$10.00
Standard	N* $1.5

2. If the number of items is 4 or more:

Delivery Day	Shipping Charge, N = number of items
Next Day	N * $6.00
2nd day	N * $2.50
Standard	Free

Structured English Equivalent (Business Rule):

	If Purchase Amount > $250.00
			If number of items < 4 then
				If delivery date is next day then Delivery charge = $25.00 Else if delivery date is 2nd day then Delivery charge is $10.00 Else if delivery date is standard then Delivery charge is $1.50 per item. End If
			Else
				If delivery date is next day then Delivery charge is $6.00 per item Else if delivery date is 2nd day then Delivery charge is $2.50 per item Else Delivery is free of charge End If
			End If
	Else
			If number of items < 4 then
				If delivery date is next day then Delivery charge = $35.00 Else if delivery date is 2nd day then Delivery charge is $15.00 Else if delivery date is standard then Delivery charge is $10.00 End If
			Else
				If delivery date is next day then Delivery charge is $7.5 per item Else if delivery date is 2nd day then Delivery charge is $3.50 per item Else Delivery is $2.50 per item End If
			End If
	End if

Decision Table Equivalent:

3. Policy Specifications

Policy specifications mean the overall system rules and regulations that are required to be implemented even if those are not common in other businesses.

Common business needs are the priority to be implemented in any system development because it is the primary purpose for its construction, to help the business make its processes more stream line, more affective and make these more profitable for the company, while continue to provide the excellent environment for both the company workers and the customers. To do so every business or commercial organization create company policies which help them day to day working activities and accord them to given set of rules and regulations.

As described earlier that the “Decision Tables” are the most common way to generate the system requirements from the system policy specifications. Even if some companies do not have a pre-defined system policy, but during the system inception phase it is being constructed by interviewing the senior officials, managers and owners of the company.

Decision tables are easy to read and implement that’s why after a successful and clear construction of these, any automated development software tool can process those to create the specification of that system or at least construct a scaffold for the system being developed which can help finish the development process quickly.

4. Decision Making Process

Decision:

A decision is a choice about a “course of action”. A course of action may include many individual actions. A decision may be characterized on a continuum from unstructured to structure.

There are two types of decision making:

1. Unstructured Decisions:

Unstructured decisions are generally one-time propositions taken in emergency situations, i.e. a set of conditions are unique and there are no fixed rules for the course of action to take based on the conditions. The possible courses of action need not be finite.

Making an unstructured decision is therefore heuristic. Automating such decisions involves the use of “Decision Support Systems (DSS)”, which attempt to obtain and organize as much relevant information as possible for presentation to the decision maker. The decision maker then applies whatever heuristics he considers appropriate to come up with a course of action.

2. Structured Decisions

Structured decisions are predictable, i.e. given a particular set of conditions; the course of action to be taken is clear and definable. The choice is which actions to take among a predefined, finite collection of actions.

Making a structured decision is therefore algorithmic. There are three common methods of expressing these algorithms. Note that all three of these methods are capable of dealing with multivariate, not merely binary conditions.

So “Decision Tables” can ease the process of “Structured Decision” making, making possible for the organizations to approach the system development.

5. Structured Policy Selection Methods

Let us suppose that we have:

• A method of expressing policy that is:

  • Concise

  • Comprehensive

  • Rigorous

  • Easy to use and understand

  • A mechanism for machine translation directly from this expression to executable code that implements the policy.

How do we get from the messy real world of policy to a nice, neat, unambiguous decision table in a spreadsheet ready for machine translation?

Step 1: Determine Policy Scope

A project without a predefined scope is subject to peril in the forms of:

• Scope Creep

• Project goals will naturally expand without anything to constrain them. Because of human nature and project politics, more and more desired results will find their way under the project umbrella.

• Lack of Definition of Project Completion Criteria

• To meet project completion schedules and budget goals, it must be possible to objectively determine whether and when the project is finished. This is only possible if all parties clearly understand beforehand the project completion criteria. Without a clear predefined scope, an objective evaluation of project completion cannot be accomplished.

It is often difficult to define terms for project scope that are unambiguous and easily determinable to meet the needs of all parties. The use of decision tables makes this a very straightforward task.

The scope of a policy project is determined by delineating all the policy that to be implemented. In decision table terms, policy implementation is expressed by actions. The project itself consists of determining and expressing the conditions under which these actions will be taken.

The scope of a decision table-based policy project is determined by enumerating all the actions that may possibly be taken. Such an enumeration is simple, unambiguous and clearly defines the boundaries of the project beyond argument.

Step 2: Determine Policy Authority

What are our policies? Where do we find them? Are they all written in a book somewhere? Is there one person in an office somewhere who knows them all and can explain them on demand?

Mostly the answers of the above questions would be in “No”.

In most organizations every body is not aware of the total of policy, so it is maintained by an intricate network of documentation and subject matter experts. It’s rare to find a single source.

Additionally, personnel come and go. Expertise is gained and lost. Documentation is constantly in a state of flux. New policy is added and old policy is phased out. There is usually a lag time in the maintenance of the corresponding documentation, often with documentation in different locations being updated at different times.

A definitive authority must be established for each area of policy of interest.

This authority would create:

• A Statement of Policy

• Simple, straightforward policy may be interpreted directly without the aid of an subject matter expert. It must not be possible to debate the interpretation of the policy. There must not be different versions of the policy available. If there are different versions, either in different locations or from different points in time, one must be designated as the authority or a definitive version created from the variants.

• A Subject Matter Expert

• If the policy has any ambiguity or is at all subject to interpretation, it is necessary to designate someone as the authority. This authority must have the power to speak for the organization as to the definitive interpretation of the policy.

• A group of subject matter experts

• Commonly, policy crosses boundaries of intra-organizational expertise. It may be necessary to designate a committee with empowered representatives from each area concerned with the policy to represent their areas’ interests in the interpretation of the policy. The committee may debate policy issues as they see fit. As in the case of a single subject matter expert, the committee’s final conclusion must have the authority to make the definitive interpretation of the policy.

The more complex, indefinite, and ambiguous the policy, the more important it is to have properly constituted authority designated to interpret, and if necessary, more rigorously define it. Someone must have the final word.

Fuzzy logic in policy can be dealt with in decision tables as easily as in any other implementation. This is not to be confused with “Fuzzy Policy”, which needs to be clarified by the appropriate authority before any implementation is possible.

6. Structured Language vs. Computer Based Language

“Structured Languages” like English attempt to allow the use of natural language, stripped of ambiguity, to express actions to be taken under particular conditions.”

This is accomplished by:

• Choosing a simple subset of natural language verbs and nouns.

• Defining / Constructing sentences to express:

  • Sequence

  • Selection

  • And Iteration

If this stripping of ambiguity is sufficiently rigorous, then mostly the resulting definition defines an executable programming language.

This was the approach taken in the creation of the original procedural computer language compilers back in the 50s and 60s. These definitions were so complex that programmers required several months of training to acquire competence in the syntax and semantics of the definition for computer programming. This made it almost impossible to combine knowledge of the business domain and technical proficiency in the programming language in one individual.

Less rigorous non-executable “Structured English” definitions are known as “pseudocode” and are used as analytical tools by analysts to create an intermediate specification. This specification is passed to programmers who translate it into actual compiler compliant code. This extra step results in added expense both because of extra specialist personnel and because of the inevitable miscommunications and errors involved in an intermediate translation.

Attempts were made in the 70s and 80s to create “Natural Computer Languages” (e.g. NATURAL ENGLISH) with much looser syntactic and semantic restrictions. The hope was to eliminate the intermediate step by empowering the compiler to successfully interpret the sloppy natural language of the domain expert directly. These efforts met with limited success and are rarely seen today.

© 2005 -2010 MBA-IT.com, All Rights Reserved

Contact us | Privacy | Terms of Use