Business systems and processes function according to business rules and regulations from within a specific business domain. The dynamic nature of every business environment consists of internal and external influences, such as keeping up with competition and changes in laws and regulations. That’s why it’s vital for business analysts, project managers, and key decision-makers to understand the variety of ways in which logic modeling and structured programming can work to improve business operations.
How? By creating and producing process specifications, an organization is able to obtain a precise description of how it’s doing today, and what needs to be accomplished. These specifications also validate the system design (including data flow diagrams and the data dictionary), and reduces process ambiguity.
The methods available for documenting and analyzing the logic of structured decisions include structured English, decision tables and decision trees. Business analysts may use these methods to identify the requirements of current and future business stakeholders and convert these requirements into specifications that will guide the construction of IT-based business solutions. Let’s take a look.
Logic Modeling
A logic model presents a picture or a narrative of how processes communicate with one another. In other words, it’s an illustration of a sequence of cause-and-effect relationships that are both going down the same path to achieve the same end results. The purpose of logic modeling is to communicate the underlying theory or set of assumptions that a program may conclude regarding why the program will work or why the solution being used is the best solution to the identified problem or issue. Whether a logic model depicts itself through diagrams, flow sheets, graphically, or through a narrative, each form conveys relationships between contextual factors and programmatic inputs, processes and outcomes.
Logic models can be used to show why an initiative is important, what results it will produce, and what actions and causes are expected to lead to the desired results. This all serves as the basis for determining whether planned actions are likely to lead to the desired results.
Don’t Confuse a Logic Model with an Action Plan
It is very common for people to confuse logic models with action plans. While the differences are subtle, they are also very important to understand and identify. An action plan is a team leader or manager’s guide for carrying out a project; a logic model illustrates the changes or effects that may occur as a result of the originally structured plan or recreation of the plan. Action plans are used to show a set of program objects and a timeline or projected outline, such as a launch media campaign or some type of outreach project. Basically, an action plan is a guide for the actual implementation and running of a project that is created after the logic model is in place.
Process Specification
Process specifications are the methods available for documenting and analyzing the logic of structured decisions. This includes structured English, decision tables and decision trees. Process specifications are created for primitive processes and some higher-level processes on a data flow diagram. (These can also be referred to as minispecs because they are a small portion of the total product specifications). Process specifications reduce process ambiguity, allow an individual or an organization to obtain a precise description of what is accomplished, and validate the system design, including data flow diagrams and the data dictionary.
Process specifications are not created for physical input or output processes, processes that represent simple data validation, or for processes in which prewritten code already exists. Process descriptions may exist on a form or within a computer-aided software engineering (CASE) tool repository. Specifications explain the decision-making logic and formulas that transform process input data into output. Process logic is best represented through structured English, decision tables, decision trees, through specified formulas or algorithms, or through any combination of the above.
Modeling Logic with Structured English
Structured English is based on structured logic. It is used when process logic involves formulas or iteration, or when structured decisions are not too complex. Structured English is used to express all logic in terms of sequential structures, decision structures, iterations and case structures. This modified form of English is used to specify the logic of information processes by using a subset of English vocabulary to express process procedures. There are no specific standards set to carry out a structured English model. Usually, each analyst or project lead will have its own methodology, but every model consists of action verbs and noun phrases with no adverbs or adjectives.
Structured English is used to represent processes in a shorthand manner that is relatively easy for users and programmers alike to read and comprehend. Sequence, condition and repetition are all included in the process of creating a structured English model. Structured English is a technique used to describe algorithmic procedures and may sometimes be an alternative to flow charts. It is an effective communication tool that is used to clarify the logic and relationships found among human languages.
Modeling Logic with Decision Tables
A decision table is best used for complicated decision-making because it specifies the possible conditions and their resulting actions through a matrix representation of the logic of a decision. Decision tables consist of rows and columns that are separated into four different sections, or quadrants, and are designed to illustrate complex decision rules. Decision tables use condition stubs, action stubs and predefined rules during the process of creation. Condition stubs list conditions that are relevant to a decision while action stubs are actions that result from a given set of conditions. The implemented rules are used to specify which actions should be followed for a given set of conditions and their resulting actions.
The decision table process presents the determination of the number of conditions or inputs that affect a specific decision. The set of possible outcomes or actions must also be determined. The procedure used to create a decision table begins with naming a condition and linking this condition to its appropriately assumed values while naming all possible actions that may occur during this process. All rules must be listed and the actions for each rule are defined before the table can be simplified.
Decision tables ensure completeness by reducing the amount of condition testing that must be conducted and by checking for any possible errors, contradictions and redundancies.
Modeling Logic through the Creation of Decision Trees
Decision trees are a graphical representation of specific decision situations that are used when complex branching occurs in a structured decision process. A decision tree is a predictive model based on a branching series of Boolean tests which use specific facts to make more generalized based conclusions. The main components of a decision tree involve decision points represented by nodes, actions thatare represented by ovals and specific choices from a decision point are represented by arcs. Each node corresponds to a numbered choice on a legend and all possible actions are listed on the far right of the model. Each rule within a decision tree is represented by tracing a series of paths from root to node to the next node and so on until an action oval is reached.
A decision tree is helpful when a certain order for a series of decisions must be maintained. They are useful when it is essential to keep a string of decisions on the same track of a particular sequence. When creating a decision tree, all conditions and actions must have an identified set of orders and timing, based on the critical need of each condition and action. Decision trees ensure that the order of checkingconditions and executing actions is immediately noticeable. When comparing decision trees to decision tables, a decision tree allows for a more readily understood structure by others from within the organization.
Selecting the Right Structured Decision Analysis Technique
When comparing the use of each decision technique it is important to keep in mind which structure will provide the best process and outcome. When there are repetitive actions or when communicating with the end use is of vital importance, structured English should be used as a tool for representing steps in logical processes and in data flow diagrams. Decision tables should be used when a complex combination of conditions, actions, and rules are found or when a method that effectively avoids impossible situations, redundancies, and contradictions are found. Decision trees should be used when the sequence of conditions and actions are critical or when not every condition is relevant to every action, meaning the branches are different. Both decision tables and decision trees should be used to represent logical choice in condition statements.