Lecture Note 10 Describing Process Specifications and Structured Decisions

1. Part III: The Analysis Process Lecture Note 10Describing Process Specificationsand Structured Decisions Systems Analysis and Design Kendall & Kendall Sixth Edition

2. Major Topics • Process Specifications • Business Rules • Structured English • Decision Tables • Decision Trees • Horizontal Balancing

3. Process Specifications What occurs within a process? How are the input data converted to the output information? Since DFD are not really designed to show the detailed logic of process. • Process specifications (說明書) are created for processes and some higher level processes on a DFD. They are also called minispecs. • Explain : • the Decision-Making Logic, • Business Logic and • Formulas that will transform process input data into output. • Each derived (衍生) element must have process logic to show how it is produced from the base elements. 1 ?

4. Goal of Creating Process Specifications • To reduce the ambiguity (不明確) of the process. • Compels (強迫) the SA to learn details about how the process works. • Any vague (模糊不清的) areas should be noted, written down, and consolidated (統一) for all process specifications. • To obtain a precise (精確的) description of what is accomplished (完成). • To validate (確認) the system design, including data flow diagrams and the data dictionary. • Ensures (確保) that a process has all the input data flow necessary for producing the output. • All input and output must be represented on the DFD.

5. Process specifications are not created for: • Processes that represent physical input or output, e.g. read, write. (Require only simple logic). • Processes that represent simple data validation (easy to accomplish). The edit criteria (條件) are included in the data dictionary and incorporated (合併) into the computer source code. • Processes that use prewritten (預先寫好) code (included in a system as subprograms and functions). E.g. validating a date or a check digit.

6. Data Flow Diagram and Process Specifications The system analyst approaching process specifications and structured decisions has many options for documenting and analyzing them. The methods available for documenting and analyzing the logical of decisions include Structured English, Decision Tables and Decision Tree.

7. Process Specification Format • Process specifications link the process to the DFD and the data dictionary. Each process specification should be entered on a separate form. (or into a case tool screen such as the one used for Visible Analyst) • The following information should be entered: • The process number, which must match the process ID on the DFD. This specification allows SA to work on or review any process and easily locate the DFD containing the process. • Process name, the same as the name displayed within the process symbol on the DFD. • A brief description of what the process accomplishes.

8. A list of input and output data flow, using the names found on the DFD. Data names used in the formula or logic should match those in the data dictionary to ensure consistency and good communication. • The Output data flows, using DFD and data dictionary names. • An indication if the type of process: Batch (一批), On-line or Manual. All on-line processes require screen designs, and all manual processes should have well-defined procedures for employees performing (實行) the process tasks. • If the process uses prewritten code, include the name of the subprogram or function containing that code. • Data names used in the formulae or logic should match the data dictionary, for consistency and good communication.

9. A description of the process logic that states policy and business rules, not computer language pseudocode. Common business rule formats include the following: • Definitions of business terms • Business conditions and actions • Data integrity constraints • Mathematical and functional derivations • Logical inferences • Processing sequences • Relationships among facts about the business • If there is not enough room on the form for a complete structured English description or if there is a Decision Table or Decision Tree depicting(描述) the logic, include the corresponding table or tree name. • List any unresolved issues(問題), incomplete portions of logic or other concerns. These issues form the basis (基本) of the questions used for follow-up interviews.

10. Process Specification Example 1

11. Structured English • It is special form of spoken English analyst use to illustrate the logic of processes depicted in DFD. • It is based on structured logic, or instructions organized into nested and grouped procedures, sequence, conditional statement, repetition, and simple English statements. • It is primarily a communication technique for analysts and user. • It is an appropriate technique for analyzing the system when structured decisions are not complex. Iteration Structure Sequence Structure Selection Structure

12. Steps to Use Structured English • The following steps are needed: • Express all logic in terms of sequential structures, decision structures, case structures, or iterations. • Use and capitalize accepted keywords such as IF, THEN, ELSE, DO, and PERFORM. • Indent(縮排)blocks of statements to show their hierarchy (等級)(nesting) clearly. • Underline words or phrases used have been defined in a data dictionary to signify that they have a specialized, reserved meaning. • Be careful when using “AND" and “OR ". • Avoid confusion(糊塗) when using logical comparisons such as "greater than" and "greater than or equal to” and “Like” relationships. So clarify the logical statements now rather than waiting until the program coding stage.

14. A Structured English Example 1: Structured English Statements The VERIFY ORDER process description includes logical rules and a structured English version of the policy. Notice the alignment and indentation of the logic statements.

15. A Structured English Example 2: • We process all of our claims(索賠) in this manner (方式). • First we determine (決定) whether the claimant (索賠者) has ever sent in a claim before; if not, we set up a new record. The claim totals for the year are then updated. • Next we determine if a claimant has policy A or policy B, which differ (不同) in deductibles (扣除條款) and co-payments (the percentage of the claim claimants pay themselves). For both policies, we check to see if the deductible has been met ($100 for plan A and $50 for plan B). If the deductible has not been met, we apply the claim to the deductible. • Another step adjusts (調整) for the co-payment; we subtract (減) the percentage the claimant pays (40% for plan A and 60% for plan B) from the claim. • Then we issue (發出) a check if there is money coming to the claimant, print a summary of the transaction (交易), and update our accounts. We do this until all claims for that day are processed. The example demonstrates how a spoken procedure for processing medical claims in transformed into structured English.

16. Advantages of Structured English • Clarifying the logic and relationships found in human languages • An effective communication tool, and easy to teach and understand. • Structured English might look familiar to programming students because it resembles pseudo code, which is used in program design.

17. Data Dictionary and Structured English • All computer programs may be coded using the three basic constructs: sequence, selection and iteration. The data dictionary indicates which of these constructs must be included in the process specification. • The data dictionary is a starting point for creating structured English: • Sequenced data dictionary entries become simple structured English statements. • Selection [] entries become IF..THEN...ELSE statements. • Iteration { } entries become DO WHILE, DO UNTIL, or PERFORM UNTIL structured English statements.

19. Decision Tables • It is graphical methods for representing process logic. • It provide a way to examine, describe, and document decisions using a table. • They are used to: • Describe the conditions. • Identify possible decision alternatives. • Indicate actions should be performed. • Describe actions. • The standard format used for presenting a decision table.

20. Decision Table Example 1 Rule 3: says If N (the total sale is NOT under $50) AND If Y (the customer paid by check and had two forms of ID ) AND If N (the customer did not use a credit card) THEN DO X ( call the supervisor for approval) Decision alternatives conditions Actions

21. Developing Decision Tables • Determine the number of conditions that may affect(影響) the decision. Combine (合併) rows that overlap (重疊). • Determine the number of actions that can be taken. • Determine the number of condition alternatives (Y, N) for each condition. • Calculate the maximum number of columns in the decision table by multiplying (乘) the number of alternatives for each condition. Condition 1: 2 alternatives Condition 2:  2 alternatives Condition 3:  2 alternatives Condition 4: 2 alternatives 24 =16 possibilities

22. Condition 1: YY Condition 2: YN Action 1: XX  Condition 1: Y Condition 2:  Action 1: X Condition 1: YYYYYYYYNNNNNNNN  Condition 1: YYYYYYYYNNNNNNNN Condition 2: YYYYNNNNYYYYNNNN Condition 3: YYNNYYNNYYNNYYNN Condition 4: YNYNYNYNYNYNYNYN • Fill in the condition alternatives. Start with the 1st condition and divide the number of columns by the number of alternatives for that condition. • Complete the table by inserting an X where rules suggest actions. • Combine rules where it is apparent (明顯的) that an alternative does not make a difference in the outcome (結果). 8. Check the table for any impossible situations, contradictions (矛盾), and redundancies (多餘). 9. Rearrange (再安排) the conditions and actions if this makes the decision table more understandable.

23. Creating the Decision Table Example 1 Structured English Statements For each ORDER IF CUSTOMER STATUS CODE = Y and IF PRODUCT DETAIL = OK Output ACCEPTED ORDER ELSE Output REJECTED ORDER 1 Four columns = (2 alternatives × 2 alternatives) 2 3 4 1. Place the name of the process in a heading at the top left. 2. Enter the conditions under the heading, with one condition per line, to represent the customer status and available of products. 3. Enter the potential combinations of Y/N for the conditions. Each column represents a numbered possibility called a rule. 4. Place an X in the action entries area for each rule to indicate whether to accept or reject the order.

24. Decision Table Example 2 This tables an illustration of a decision table. The company is trying to maintain a meaningful mailing list of customers. The objective is to send out only the catalogs from which customers will buy merchandise. A decision table is constructed for three conditions, each having two alternatives (Y or N). Three actions can be taken. The regular decision table has six rows (3 conditions and 3 actions) and eight columns (2 alternatives × 2 alternatives2 ×alternatives).

25. Rules 2,4,6 and 8 can be combined because they all have two things in common: • They instruct us to send out this year’s Christmas catalog. • The alternative for Condition 3 is always N

26. Suppose the rule is: IF the customer did not order more than $50 THEN do not send any catalogs

27. Checking for Completeness and Accuracy • Decision tables help analysts ensure completeness and accuracy. • Four main problems that can occur in developing decision tables: • Incompleteness. • Impossible situations. • Contradictions (自相矛盾). • Redundancy.

28. Rule 1 is not feasible, because a person cannot earn greater than $50,000 per year and less than $2,000 per month at the same time. Contradictions often occur of dashes [--] are incorrectly inserted into the table. Redundancy occurs when identical sets of alternatives require the exact same action. The analyst has to determine what is correct and then resolve the contradiction or redundancy.

29. More Advanced Decision Tables • Decision tables can become very big because they grow rapidly as the number of conditions and alternatives increases. • In order to avoid a decision table to grow rapidly, we can use Extended Entries or ELSE rule. • Extended entries: to reduce the possibility of redundancy and contradiction. • Example: C1: Did not order YNNN C2: Ordered once NYNN C3: Ordered twice NNYY C4: Ordered more than twice NNNY  C1: Number of times customer ordered 0 1 2 >2 The number of required columns and rows decreases and the understandability increases. Instead of using four rows for the number of timers a customer orders, only one row is needed.

30. An example of a structured inventory ordering policy.

31. 2. ELSE Rule: to eliminate repetitive rules requiring the exact same action.

32. Decision Trees • Decision tree is a graphical representation of a decision situation. • Decision trees are used when complex branching occurs in a structured decision process. • Trees are also useful when it is essential to keep a string of decisions in a particular sequence. • Decision tree are most often drawn with the root of the tree on the left side and the tree branches out to the right. This orientation allows the analyst to write on the branches to describe conditions and actions.

33. Drawing Decision Trees • First, identify all conditions and actions and the order and timing of these (if they are critical). • Second, begin building the tree from left to right while making sure you are complete in listing all possible alternatives before moving over to the right. • A square node indicates an action (THEN). • A circle to represent a condition (IF). • Numbering the circles and squares sequentially.

34. Decision Tree Example 1 A point-of-sale example was used to determine the purchase approval (批准) actions for a department store. Conditions included the amount of the sale (under $50) and whether the customer paid by check or credit card. The four actions possible were to ring up the sale, look up the credit card in a book, call the supervisor for approval, or call the bank for credit card authorization.

35. Decision Tree Advantages Three advantages over a decision table are: • The order of checking conditions and executing actions is immediately noticeable (顯而易見). • Second, conditions and actions of decision trees are found on some branches but not on others, which contrasts with decision tables, in which they are all part of the same table. Those conditions and actions that are critical are connected directly to other conditions and actions. The tree does not have to be symmetrical (對稱). • Third, compared to decision tables, decision trees are more readily understood by others in the organization.

36. Selecting a Structured Decision Analysis Technique Guidelines are as follows: • Use structured English when there are many repetitious actions or when communication to end users is important. • Use decision tables when complex combination of conditions, actions, and rules are found or you require a method that effectively avoids impossible situations, redundancies, and contradictions. • Use decision trees when the sequence of conditions and actions is critical or when not every condition is relevant to every action (the branches are different).

38. Using Process Specifications • All the process specifications are consolidated (使堅固) for a computer program and are included in the specification packet given to the computer programmer. • Process specifications may be used for generating (產生) computer language source code and for analyzing the system design. • Process specifications are developed on a small scale (規模), one process at a time, each one may be analyzed for complete and correct logic. The logic is easier to understand. • When the SA is finished and corrections are made for all processes within a program, the final program specifications should be complete and accurate.

39. Horizontal (水平的) Balancing • It is used to verify that each process has the required data dictionary entries defined and the formulas and logic necessary to produce the output. • Process specifications may be used to analyze the DFD and data dictionary through a method called horizontal balancing. • Horizontal balancing dictates(規定) that all output data-flow elements must be obtained from the input elements and process logic. • Base elements on an output data flow must be present (出現) on the input flow. • Derived elements on an output flow must be either present on an input data flow or created using the process specifications. • Unresolved areas should be summarized into a series of interview questions.

40. How Structured English can help us complete the DFD.

41. Shows corresponding data dictionary entries for producing the Supplier Sales Receipt.

44. Review Question • List the three reasons for producing process specifications. • What is the advantage of using structured English to communicate with people in the organization? • What three advantages do decision trees have over decision tables? • In which two situations should you use structured English? (when many actions are repeated and when communicating with others is important) • In which two situations do decision tables work best? (When complex combinations of conditions, actions, and rules are found or you require a method that effectively avoids impossible situations, redundancies, and contradictions.) • In which two situations are decision trees preferable? (when the sequence of conditions and actions is critical or not every condition is relevant to every action ) • What four elements must be known for the systems analyst to design systems for structured decisions? (Conditions, Condition Alternatives, Actions, and Action Rules)