“Our little systems have their day.”

— Alfred, Lord Tennyson
In Memoriam, 1850

1. How to write structured English process specifications;
2. How to write process specifications with pre/post conditions;
3. How to use decision tables to write process specifications; and
4. When to use alternative specification tools.

• The process specification must be expressed in a form that can be verified by the user and the systems analyst. It is precisely for this reason that we avoid narrative English as a specification tool: it is notoriously ambiguous, especially when describing alternative actions (decisions) and repetitive actions (loops). By its nature, it also tends to cause great confusion when expressing compound Boolean conditions (i.e., combinations of the Boolean operators AND, OR, and NOT).
• The process specification must be expressed in a form that can be effectively communicated to the various audiences involved. While it will typically be the systems analyst who writes the process specification, it will usually be a diverse audience of users, managers, auditors, quality assurance personnel, and others who must read the process specification. A process specification could perhaps be expressed in predicate calculus, or in Pascal, or in a formal diagramming approach such as Higher Order Software’s USE-IT [1]; but if the user community refuses to look at such specifications, they are worthless. The same may turn out to be true of decision tables, structured English or other specification tools, too; it is very much a function of the personality, background, and attitude of the users you deal with.

1. The widget factor is not produced as the result of a single calculation. In fact, we have to begin by making a guess. The user has told us that he is particularly fond of 14 as a first guess.
2. Then we make another guess. We do this by dividing our current guess into the number, x, that we started with.
3. We then take the result of this calculation and subtract it from the current guess.
4. We then take the result of step 3, and divide it in half. This becomes our new guess.
5. If the new guess and the current guess are pretty close to each other, say, within 0.0001, then we can stop; the new guess is the widget factor. Otherwise, go back to step 2 and do it all over again.

widget-factor₀ = 14

REPEAT for N = 0 in steps of 1

widget-factor_N+1 = (widget-factor_N - (X/widget-factor_N))/2

UNTIL |widget-factor_N+1 - widget-factor_N| < 0.0001

PRECONDITION
There exists a number X that is nonnegative.

POSTCONDITION
A widget-factor is produced such that
X = widget-factor * widget-factor

• Structured English
• Pre/post conditions
• Decision tables

11.1 STRUCTURED ENGLISH

Structured English, as the name implies, is “English with structure.” That is, it is a subset of the full English language with some major restrictions on the kind of sentences that can be used and the manner in which sentences can be put together. It is also known by such names as PDL (for program design language) and PSL (for problem statement language or problem specification language). Its purpose is to strike a reasonable balance between the precision of a formal programming language and the casual informality and readability of the English language.

A sentence in structured English may consist of an algebraic equation, for example

X = (Y*Z)/(Q+14)

or a simple imperative sentence consisting of a verb and an object. Note that this sentence does not have the semicolon that terminates a programming statement in many different programming languages; it may or may not terminate with a period (“.”), depending on your taste in such things. Also, note that sentences describing computations can be prefixed with the verbs COMPUTE, ADD, SET, and so on; thus, we could have written the above example as

COMPUTE X = (Y*Z)/(Q+14)

and we can have structured English computations like the following ones:

SET TAX-RATE TO 13
ADD 3 TO X
MULTIPLY UNIT-PRICE BY QUANTITY
DIVIDE CURRENT-ASSETS BY CURRENT-LIABILITIES.

Verbs should be chosen from a small set of action-oriented verbs such as:

GET (or ACCEPT or READ)
PUT (or DISPLAY or WRITE)
FIND (or SEARCH or LOCATE)
ADD
SUBTRACT
MULTIPLY
DIVIDE
COMPUTE
DELETE
FIND
VALIDATE
MOVE
REPLACE
SET
SORT

Most organizations find that 40 to 50 verbs are sufficient to describe any policy in any process specification.

Objects (the subject of the simple imperative sentences) should consist only of data elements that have been defined in the data dictionary or local terms. Local terms are terms (words) that are explicitly defined within an individual process specification; they are only known, relevant, and meaningful within that process specification. A typical example of a local term is an intermediate calculation, which is used to produce the final output of the process [5]. For example, the structured English process specification below examines a series of order records in an ORDERS store to compute a daily total:

daily-total = 0
DO WHILE there are more orders in ORDERS with Invoice-date = today’s date
READ next order in ORDERS with Invoice-date = today’s date
DISPLAY to Accounting invoice-number, customer-name, total-amount
daily-total = daily-total + total-amount
ENDDO
DISPLAY to Accounting daily-total

Finally, structured English allows sentences to be combined in a few limited ways; these are taken from the familiar structured programming constructs [6].

• The IF-THEN-ELSE construct is used to describe alternative sentences that are to be carried out based on the result of a binary decision. The IF-THEN-ELSE construct can take either of the following two forms:

  IF condition-1
  sentence-1
  ENDIF
  
  or
  
  IF condition-1
  sentence-1
  ELSE
  sentence-2
  ENDIF

Thus, the systems analyst may write:

IF customer lives in New York
add customer to MARKETING-PROSPECTS
ENDIF

or

IF customer-age greater than 65
set billing-rate to senior-citizen-rate
ELSE
set billing-rate to normal-rate
ENDIF

• The CASE construct is used to describe alternative sentences to be carried out based on the results of a multivalued decision (as compared to the binary decision that takes place with an IF-THEN construct). The CASE construct takes the general form:

  DO CASE
  CASE variable = value-1
  sentence-1
  
  CASE variable = value-n
  sentence-n
  OTHERWISE
  sentence-n+1
  ENDCASE

Thus, the systems analyst might write:

DO CASE
CASE customer-age < 13
set billing-rate to child-rate
CASE customer-age ≥ 13 and customer-age < 20
set billing-rate to teenage-rate
CASE customer-age > 20 and customer-age < 65
set billing-rate to adult-rate
OTHERWISE
set billing-rate to senior-citizen-rate
END CASE

Or, as another example, consider the following portion of a structured English process specification:

DO CASE
CASE state = “NY”
set salestax to 0.0825
CASE state = “NJ”
set salestax to 0.07
CASE state = “CA”
set salestax to 0.05
OTHERWISE
set salestax to 0
END CASE

Note that the OTHERWISE clause is often used to catch situations that the user forgets to specify and that the systems analyst forgets to ask about; it will often prompt some discussions between user and systems analyst that would otherwise not take place until after the system had been put in operation. Consider the following example:

DO CASE
CASE payment-type = “cash”
set discount-rate to 0.05
CASE payment-type = “credit-card”
set discount-rate to 0.01
OTHERWISE
set discount-rate to 0
END CASE

The user might question this process specification and ask why the systems analyst included the OTHERWISE clause; the systems analyst might respond by asking about payments by check, traveler’s check, gold coins, and barter.

• The DO-WHILE construct is used to describe a sentence that is to be carried out repetitively until some Boolean condition is true. It takes the general form:

  DO WHILE condition-1
  sentence-1
  ENDDO

The test (“condition-1” in the example above) is made before sentence-1 is carried out; thus, if the condition is not satisfied, it is possible that sentence-1 will be carried out zero times.

For example, the systems analyst might write:

DO WHILE there are more items in the customer-order
extended-price = unit-price * unit-quantity
ENDDO

Many organizations include another structure that carries out a specified sentence at least once before making a test to see if it should be repeated. This variation, usually known as the REPEAT-UNTIL construct, has the following form:

REPEAT
sentence-1
UNTIL condition-1

Compound sentences can be built from combinations of simple sentences and the simple structures presented above, according to the following rules:

1. A linear sequence of simple sentences is equivalent (structurally) to a simple sentence. Thus, the sequence

sentence-1
sentence-2
sentence-n

is structurally equivalent to a single, simple sentence and can be substituted wherever a simple sentence is expected. This allows us to build structures like this:

IF condition-1
sentence-1
sentence-2
ELSE
sentence-3
sentence-4
sentence-5
ENDIF

or

DO WHILE condition-1
sentence-1
sentence-2
sentence-3
ENDDO

2. A simple IF-THEN-ELSE construct is considered structurally equivalent to a single, simple sentence. This allows IF-THEN-ELSE structures to be nested within other IF-THEN-ELSE structures, or within DO-WHILE structures, or within CASE structures. For example:

IF condition-1
sentence-1
IF condition-2
sentence-2
sentence-3
ELSE
sentence-4
sentence-5
ENDIF
sentence-6
ELSE
sentence-7
IF condition-3
sentence-8
ENDIF
sentence-9
ENDIF

3. A simple DO-WHILE structure is considered structurally equivalent to a simple, single sentence. This allows DO-WHILE structures to be nested within other DO-WHILE structures, or within IF-THEN-ELSE structures, or within CASE structures. Thus, we might have a structured English specification of the following nature:

grand-total = 0
DO WHILE there are more orders to process
invoice-total = 0
READ next order from ORDERS
DO WHILE there are more items in the order
invoice-total = invoice-total + item-amount
ENDDO
DISPLAY invoice-number, invoice-total
grand-total = grand-total + invoice-total
ENDDO
DISPLAY grand-total

4. A simple CASE structure is considered structurally equivalent to a simple, single sentence. This allows CASE structures to be nested within other CASE structures, or within IF-THEN-ELSE structures, or within DO-WHILE structures.

As you can see, this allows us to construct arbitrarily complex descriptions of business policy, while maintaining strict control over the vocabulary, organization and structure of the description. However, this arbitrary complexity is also the major disadvantage of structured English: if the systems analyst composes a process specification that is too complex for the user to understand and verify, he has failed. This can usually be prevented by adhering to the following three guidelines:

1. Restrict the structured English process specification to a single page of text (e.g., 8-by-11 sheet of paper, 66 lines of text on a word processing system, or 24 lines on a computer screen). If the specification takes more than one page, then the systems analyst (with the help of the user) should think of an entirely different way of formulating the policy (i.e., pick a different, simpler algorithm). If that cannot be done, then it is possible that the process itself (i.e., the bubble within the DFD) is too complex and should be split into a network of lower-level, simpler processes.
2. Don’t allow more than three levels of nesting (i.e., three levels of nested IF-THEN-ELSE structures, or three levels of CASE structures, etc.). Particularly in the case of IF-THEN-ELSE structures, more than even two levels of nesting is a strong indication that a decision table specification would be preferable; this is discussed in Section 11.3.
3. Avoid confusion about levels of nesting by using indentation, as shown in the examples above. This can be accomplished and controlled very easily if you are using any kind of automated support to develop the process specifications (even something as simple as a standard word processing system). If the process specifications are being typed manually by a clerical person who is not familiar with structured programming or structured analysis, you will have to explain very carefully what kind of indentation you want; you should also proofread the resulting text very carefully to see if it is correct.

Many systems analysts ask whether the user can be expected to read and understand a process specification written in structured English. My experience has been almost uniformly positive in this area: users can read structured English, with the following provisos:

1. You will have to walk through the document once or twice to ensure that they understand the format and the various constructs. On the first reading, it may well look like a legal document, especially if you have “highlighted” the IF-THEN-ELSE construct, and the like.
2. Don’t refer to the process specification as “structured English.” If necessary, refer to it as “a formal description of your business policy for carrying out this activity.”
3. Pay careful attention to the overall format and layout of the document; the indentation of nested blocks of logic is especially important. Some users prefer an outline style of indentation, that is, where indented levels are numbered 1.1, 1.1.1, 1.1.1.1, and so on.

Several examples of structured English process specifications are shown in the case study in Appendix F.

11.2 PRE/POST CONDITIONS

Pre/post conditions is a convenient way of describing the function that must be carried out by a process, without saying very much at all about the algorithm or procedure that will be used. It is a particularly useful approach when:

1. The user has a tendency to express the policy carried out by a bubble in terms of a particular, idiosyncratic algorithm that he or she has been using for decades.
2. The systems analyst is reasonably sure that there are many different algorithms that could be used.
3. The systems analyst wants to let the programmer explore several such algorithms, but does not want to get involved in such details himself, and especially does not want to engage in arguments with the user about the relative merits of such algorithms.

An example of a process specification written with the pre/post condition approach is shown in Figure 11.3:

PROCESS SPECIFICATION 3.5: COMPUTE SALES TAX

Precondition 1
SALE-DATA occurs with ITEM-TYPE matching an
ITEM-CATEGORY in TAX-CATEGORIES
Postcondition 1
SALES-TAX is set to SALE-AMOUNT * TAX-RATE

Precondition 2
SALE-DATA occurs with ITEM-TYPE that does not
match an ITEM-CATEGORY in TAX-CATEGORIES
Postcondition 2
ERROR-MESSAGE is generated

Figure 11.3: A pre/post condition specification

There are two main parts of the specification: pre conditions and post conditions. In addition, such specifications can contain local terms, as defined in Section 11.1 (see also footnote 5).

Preconditions describe all the things (if any) that must be true before the process begins operating. It’s sometimes convenient to think of the process as a “sleeping princess,” and the pre-conditions represent the “magic kiss” that will awaken the process and set it to work. Alternatively, you can think of the preconditions as a guarantee from the user: “I guarantee that when this process is activated the following things will be true.” Typically, the preconditions will describe the following:

• What inputs must be available. These inputs will arrive via a flow connected to the process, as shown on the dataflow diagram. Note that there may be cases where there are several flows coming into a process, but only one of the flows is a necessary precondition to activate the process. For example, if we saw a specification that began with

  Precondition
  data element X occurs

associated with the dataflow diagram shown in Figure 11.4, we would interpret it as follows: the arrival of data element X is the activating stimulus that makes the process begin its work. As part of its work, it seeks input from dataflow Y or Z, or both, but Y and Z are not necessary for the process to begin doing its work.

• What relationships must exist between inputs or within inputs. Quite often a precondition will specify that two inputs with matching fields must arrive (e.g., order details and shipping details with the same account number). Or the precondition may specify that one component of an input data element be within a certain range (e.g., “an order with a delivery date more than 60 days in the future occurs”).
• What relationships must exist between inputs and data stores. A precondition might stipulate that there be a record within a store that matches some aspect of an input data element (e.g., the precondition might say, “There is a customer-order with customer-account-number matching a customer-account-number in the customers store”).
• What relationships must exist between different stores or within a single store. Thus, the precondition might say, “There is an order in the orders store whose customer-account-number matches the customer-account-number in the customers store.” Or the precondition might say, “There is an order within the orders store with a shipping-date equal to the current date.”

Figure 11.4: A DFD with inputs X,Y, and Z

Similarly, the postconditions describe what must be true when the process has finished doing its job. Again, this can be thought of as a guarantee: “I guarantee that when the process is finished the following will be true.” Postconditions typically describe the following:

• The outputs that will be generated or produced by the process. This is the most common form of postcondition (e.g., “An invoice will be produced”).
• The relationships that will exist between output values and the original input values. This is common for the situation where an output is a direct mathematical function of an input value. Thus, a postcondition might say, “The invoice-total will be calculated as the sum of unit-item-prices plus shipping-charges.”
• The relationships that will exist between output values and values in one or more stores. This is common when information is to be retrieved from a store and used as part of an output of the process. For example, a process specification might have as a postcondition the following statement: “The on-hand-balance in the INVENTORY store will be increased by amount-received, and the new on-hand balance will be produced as output from this process.”
• The changes that will have been made to stores: new items added, existing items modified, or existing items deleted. Thus, we might see statements like “The order will be appended to the ORDERS store” or “The customer record will be deleted from the CUSTOMERS store.”

When building a pre/post condition specification, begin by describing the normal processing situations first. There may be several different normal situations (e.g., unique combinations of valid input/storage relationships) each of which is expressed as a distinct, separate precondition. For each such precondition, you should then describe the condition of the process bubble when the outputs have been produced and the stores have been modified. After the normal processing situations have been described, you should include appropriate preconditions and postconditions for error cases and abnormal cases. Consider the pre/post condition specification shown in Figure 11.5(b) that would be developed for a new system from the narrative specification in Figure 11.5(a).

If a customer tells me that he’s a “charge” customer when he comes to the cash register to check out, I look up his account in my file. If I can find his account, and if it’s not marked “suspended” or “canceled,” then I write up the charge slip with the account number and the amount of the sale. Otherwise, I tell the customer that he'll have to pay cash or talk to the manager.

Figure 11.5(a): An example of narrative specifications

Precondition 1
Customer arrives with account-number matching an account number in ACCOUNTS, whose status-code is set to “valid.”

Postcondition 1
Invoice is produced containing account-number and amount-of-sale.

Precondition 2
Precondition 1 fails for any reason (account-number can’t be found on ACCOUNTS or status-code is not equal to “valid”).

Postcondition 2
Error message is produced.

Figure 11.5(b): An example of pre/post conditions

Though the pre/post condition approach is quite useful and has a number of advantages, there are times when it may not be appropriate. The lack of intermediate steps between the inputs (preconditions) and the outputs (postconditions) is deliber
ate and conscious — but it may make the specification hard to understand if the reader cannot visualize some kind of procedure that will lead from inputs to outputs. Also, if there are complex relationships between inputs and outputs, it may be easier to write the specification using structured English. An example of a precondition/postcondition specification that is probably too complicated is shown in Figure 11.6.

DETERMINE LOAN RATE BASED ON CUSTOMER FACTORS

Precondition 1

loan-application occurs
and years-employed > 5 or net-worth > loan-amount
and monthly-expenses < 0.25 * loan-amount
or collateral-guarantee > 2 * loan-amount and age > 25
or collateral-guarantee > loan-amount and age > 30
or years-employed > 2 and net-worth > 2* loan-amount
and age > 21 and monthly-expenses < 0.5 * loan-amount

Postcondition 1

approved-amount = loan-amount

Figure 11.6: An overly complicated pre/post condition specification

As with all the forms of process specification, you should let your own judgment and the user's reactions guide you; if the user finds it difficult to read the precondition/postcondition specification, choose another format. The precondition/postcondition approach are shown in the case study in Appendix G; the alternative structured English approach is used in the case study in Appendix F. Look carefully at both case studies to determine the suitability of these two process specification tools.

11.3 DECISION TABLES

There are situations where neither structured English nor pre/post conditions are appropriate for writing process specifications. This is particularly true if the process must produce some output or take some actions based on complex decisions. If the decisions are based on several different variables (e.g., input data elements), and if those variables can take on many different values, then the logic expressed by structured English or pre/post conditions is likely to be so complex that the user won’t understand it. A decision table is likely to be the preferred approach.

As shown in Figure 11.7, a decision table is created by listing all the relevant variables (sometimes known as conditions or inputs) and all the relevant actions on the left side of the table; note that the variables and actions have been conveniently separated by a heavy horizontal line. In this example, each variable is a logical variable, meaning that it can take on the value of true or false.

In many applications, it is easy (and preferable) to express the variables as binary (true-false) variables, but decision tables can also be built from multivalued variables; for example, one could build a decision table with a variable called “customer-age” whose relevant values are “less than 10,” “between 10 and 30,” and “greater than 30.”

Figure 11.7: A typical decision table

Next, every possible combination of values of the variables is listed in a separate column; each column is typically called a rule. A rule describes the action (or actions) that should be carried out for a specific combination of values of the variables. At least one action needs to be specified for each rule (i.e., for each vertical column in the decision table), or the behavior of the system for that situation will be unspecified.

If there are N variables with binary (true-false) values, then there will be 2^N distinct rules; thus, if there are 3 conditions, there will be 8 rules, and if there are 7 conditions, there will be 128 rules. Enumerating all the rules is a fairly straightforward process: by treating the Yes (or T) as a binary zero, and the No (or F) as a binary one, it is easy to generate a sequence of 000, 001, 010, 011, 100, 101, and so forth until all 2N combinations have been generated. [7]

You must discuss each rule with the user to ensure that you have identified the correct action, or actions, for each combination of variables. It is quite common, when doing this, to find that the user has never thought about certain combinations of variables or that they have never occurred in his or her experience [8]. The advantage of the decision table approach is that you can concentrate on one rule at a time.

Another advantage of the decision table approach is that it does not imply any particular form of implementation. That is, when the systems analyst delivers the decision table (along with the DFDs, etc.) to the designer/programmer, there is a tremendous freedom of choice in terms of implementation strategy: the decision table can be programmed with nested IF statements, with a CASE construct or a GO TO DEPENDING ON construct in COBOL; in the extreme case, a decision table code generator can automatically generate code from the decision table. Thus, decision tables are often referred to as a nonprocedural system modeling tool, for they do not require any specific procedural algorithm to carry out the required actions.

To summarize, we must go through the following steps to create a decision table for a process specification:

1. Identify all the conditions, or variables, in the specification. Identify all the values that each variable can take on.
2. Calculate the number of combinations of conditions. If all the conditions are binary, then there are 2N combinations of N variables.
3. Identify each possible action that is called for in the specification.
4. Create an “empty” decision table by listing all the conditions and actions along the left side and numbering the combinations of conditions along the top of the table.
5. List all the combinations of conditions, one for each vertical column in the table.
6. Examine each vertical column (known as a rule) and identify the appropriate action(s) to be taken.
7. Identify any omissions, contradictions, or ambiguities in the specification (e.g., rules in the decision table for which the specification does not indicate that actions should be taken).
8. Discuss the omissions, contradictions, and ambiguities with the user.

11.4 OTHER PROCESS SPECIFICATION TOOLS

11.4.1 Graphs and Charts

In some cases, it may be appropriate to express a process specification as a graph or a chart. Indeed, the user may already have a graph or a chart that is currently used to carry out that part of the application. If so, use it! There is no need for the systems analyst to translate a graph into structured English; instead, let the programmer translate the graph directly into COBOL, Visual Basic, or some other programming language when it is time to implement the system.

Consider, for example, a process specification that determines a customer’s insurance premium as a function of age. The user has told us that the current business policy is to determine the premium from the graph shown in Figure 11.8.

Figure 11.8: Insurance premium as a function of age

Assuming that the policy is not going to change when a new system is built, and assuming that the insurance premium is only a function of age, there is no need for the systems analyst to do any further work. Figure 11.8 is the process specification.

11.4.2 Narrative English

As we have implied several times in this chapter, narrative English is not a recommended tool for writing process specifications. This is because:

• An unrestricted vocabulary (i.e., indiscriminate use of nouns, verbs, and adjectives) makes it likely that the process description will include terms that are not in the data dictionary and whose meaning is not clear.
• Alternative actions (i.e., decisions) are often expressed in a clumsy, ambiguous fashion. This becomes even more dangerous when nested decisions are expressed.
• Repetitive actions (i.e., loops) are also expressed in a clumsy, ambiguous fashion. Nested loops are extremely dangerous when expressed in colloquial English.
• The concept of block structures can only be expressed with indentation or an outline-style presentation; if one is willing to go this far, one might as well use the formal structured English notation.

If, for some reason, you are forced to use narrative English, you should at least maintain some of the advantages of the highly partitioned structured analysis approach that we have discussed throughout this book. That is, under no circumstances should you allow yourself to be forced into the position of writing a 2000 page monolithic Victorian novel specification. At the very least, you should partition the specification into small pieces, so that you can write 2000 independent “short stories.”

11.4.3 Flowcharts

We have avoided the use of flowcharts thus far in our discussion, but that is a reflection of current disinterest in flowcharts rather than an indictment of them [9]. Much of the criticism of flowcharts has resulted from their misuse in the following two areas:

1. As a high-level systems modeling tool, flowcharts suffer badly. A flowchart shows sequential, procedural logic; as we have seen in Chapter 9, a dataflow diagram is a more appropriate tool for modeling a network of asynchronous, communicating processes.
2. There is nothing to prevent the systems analyst from creating an arbitrarily complex, unstructured flowchart of the sort shown in Figure 11.9.

Figure 11.9: An unstructured flowchart

However, if the flowchart is only used to describe detailed logic, and if the systems analyst restricts himself to flowcharting symbols equivalent to the structured English constructs described in Section 11.1, then there is nothing wrong with their use. To create a structured flowchart, the systems analyst must organize his or her logic with nested combinations of the flowchart symbols shown in Figure 11.10. [10]

Figure 11.10: The Böhm-Jacopini structured flowchart symbols

An alternative is the use of Nassi-Shneiderman diagrams, discussed in Section 11.4.4. However, it should be pointed out that very few systems analysts use flowcharts for process specifications (nor, for that matter, are they frequently used for program design either). Though the automated tools described in Appendix A could be used to create and maintain flowcharts, the simple truth is structured English, decision tables, and pre/post condition specifications are easier to create and maintain.

11.4.4 Nassi-Shneiderman Diagrams

When structured programming first became popular in the mid-1970s, Nassi-Shneiderman diagrams were introduced as a structured flowcharting technique; see [Nassi and Shneiderman, 1973] and [Chapin, 1974]. A typical Nassi-Shneiderman diagram has the form shown in Figure 11.11.

Note that a simple imperative statement is represented by a rectangle, as shown in Figure 11.12(a); the rectangle can also be used to represent a block of sequential statements. The binary IF-THEN-ELSE construct is represented by the graphic notation shown in Figure 11.12(b); and the repetitive DO-WHILE construct is represented by the graphic notation shown in Figure 11.12(c).

The Nassi-Shneiderman diagrams are generally more organized, more structured, and more comprehensible than the typical flowchart; for that reason, they are sometimes preferred as a tool for creating process specifications. However, they do still require a nontrivial amount of graphics, and it is not clear that the graphics add that much value. As many systems analysts have been heard to mutter after spending an hour creating a Nassi-Shneiderman diagram, “This is just structured English with some boxes drawn around the statements!”

Figure 11.11: A typical Nassi-Shneiderman diagram

Figure 11.12(a): Representation of a sequential statement

Figure 11.12(b): Representation of an IF-THEN-ELSE construct

Figure 11.12(c): Representation of a DO-WHILE construct

On the other hand, recent research conducted by David Scanlan at California State University ([Scanlan, 1987]) shows that 75% to 80% of computer science students strongly prefer Nassi-Shneiderman diagrams over pseudocode when learning about complex algorithms; although this does not agree with the typical negative reaction of experienced programmers toward flowcharts, Scanlan’s conclusions are based on careful factor-analytic studies of several hundred students. While end users do not necessarily have the same preferences as computer science students, there is at least the possibility that they would prefer a graphical representation of a process specification than a narrative/textual represenation.

11.5 SUMMARY

The purpose of this chapter has been to show you that there are many different ways to describe the detailed user policy inside each primitive bubble in a dataflow diagram. While structured English is the most commonly used technique at the present time, you should consider the use of decision tables, flowcharts, pre/post conditions, or any other approach that can be verified and communicated easily to your users.

Keep in mind that the process specifications represent the largest amount of detailed work in building a system model; there may be hundreds or even thousands of process specifications, and each one may be a page in length. Because of the amount of work involved, you may want to consider the top-down implementation approach discussed in Chapter 5: begin the design and implementation phase of your project before all the process specifications have been finished.

Keep in mind also that the activity of writing process specifications serves as a “sanity test” of the dataflow diagrams that have already been developed. You may discover that the process specification needs additional input dataflows or that it produces additional output dataflows (i.e., flows that were not shown on the DFD). And as you write the process specification, you may find that additional functions are needed; for example, as you write the process specification for a function that adds a new record to the CUSTOMERS store, you may notice that the DFD does not have a bubble that modifies or deletes a record from that store. Thus, you should expect that changes, revisions, and corrections to the DFD model will be required based on the detailed work of writing the process specifications.

REFERENCES

1. Tom DeMarco, Structured Analysis and Systems Specification. Englewood Cliffs, N.J.: Prentice-Hall, 1979.
2. Chris Gane and Trish Sarson, Structured Systems Analysis: Tools and Techniques. Englewood Cliffs, N.J.: Prentice-Hall, 1978.
3. Edward Yourdon, Techniques of Program Structure and Design, Englewood Cliffs, N.J.: Prentice-Hall,1976.
4. James Martin and Carma McClure, Diagramming Techniques for Software Engineering. Englewood Cliffs, N.J.: Prentice-Hall, 1985.
5. Victor Weinberg, Structured Analysis. Englewood Cliffs, N.J.: Prentice-Hall, 1978.
6. Edward Yourdon, Classics in Software Engineering. New York: YOURDON Press, 1979.
7. Corrado Böhm and Guiseppe Jacopini, “Flow Diagrams, Turing Machines, and Languages with Only Two Formation Rules,” Communications of the ACM, Volume 9, Number 5 (May 1966), pp. 366-371. Also reprinted in Classics in Software Engineering (op. cit.).
8. I. Nassi and B. Shneiderman, “Flowchart Techniques for Structured Programming,” ACM SIGPLAN Notices, Volume 8, Number 8 (August, 1973), pp.12-26.
9. Ned Chapin, “New Format for Flowcharts,” Software — Practice and Experience, Volume 4, Number 4 (October-December 1974), pp. 341-357.
10. H. McDaniel, editor, Application of Decision Tables. Princeton, N.J.:, Brandon Systems Press, 1970.
11. S. Pollack, H. Hicks, and W. Harrison, Decision Tables — Theory and Practice. New York: Wiley, 1971.
12. T.R. Gildersleeve, Decision Tables and Their Practical Applications in Data Processing. Englewood Cliffs, N.J.: Prentice-Hall, 1970.
13. David Scanlan, “Cognitive Factors in the Preference for Structured Flowcharts: A Factor Analytic Study,” presented at the First Annual YOURDON Press Author’s Conference, New York, December 5, 1987.

QUESTIONS AND EXERCISES

1. Consider the following specification, provided to you in a narrative form. Which of the specification tools presented in this chapter do you think would be the most appropriate? Why?
   “When I get a purchase order, my job is to pick a supplier from our file of available suppliers. Of course, some suppliers get eliminated right away because their price is too high, or because they’ve been temporarily “blacklisted” because of poor quality. But the real work that I do is to pick the optimal supplier from those that qualify — the one that will deliver our order in the shortest amount of time. My boss had a system for estimating delivery time, and he taught it to me, but at this point I just look at the supplier’s location, the quantity of items being ordered, and the date that we need the goods, and I know which supplier will be the best one. ... I’m not even sure how I do it any more.”
2. What is a process specification? What are its objectives?
3. What are five common tools for modeling process specifications?
4. What are the three requirements that a process specification should satisfy?
5. Should a systems development project use one tool for process specifications? Why or why not?
6. Research Project: Which specification tools are used in your organization? Are there restrictions on which tools are used? Do you think the right tools are in use?
7. Which bubbles in a DFD require process specifications?
8. What are the consequences of writing process specifications for nonatomic (nonprimitive) bubbles?
9. How should the systems analyst determine what the process specifications for a bubble should be?
10. How does it happen that process specifications sometimes impose arbitrary design and implementation decisions? What are the consequences of this?
11. Research Project: Find an example of a process specification in your organization that exhibits arbitrary design or implementation decisions. How would you rewrite it to avoid this problem?
12. Give a definition of the term structured English? What are some synonyms for this term?
13. How many verbs are needed to form structured English sentences? Suggest a list of 20 verbs.
14. Why are algebraic equations usually necessary in a structured English process specification?
15. What characteristics should the objects in a structured English process specification have?
16. What are local terms?
17. Should local terms be included in a data dictionary? Why or why not?
18. Do local terms appear as flows on DFDs?
19. Give a specific example of a local term.
20. What structured programming constructs are used in structured English?
21. What is the purpose of the OTHERWISE clause in structured English?
22. What is the difference between a DO-WHILE construct and a REPEAT-UNTIL construct in structured English?
23. What is a compound sentence?
24. Is the CASE construct necessary in structured English? What are the advantages and disadvantages of the CASE construct?
25. What are the four components of a compound sentence?
26. What is the difference between (a) and (b)?
    (a) IF A THEN
    IF B THEN
    sentence-1
    ELSE
    sentence-2
    ELSE
    sentence-2.
    ( b) IF A AND B THEN
    sentence-1
    ELSE
    sentence-2.
    Which of these two examples do you think is easiest to understand? Why?
27. Research Project: Construct several examples similar to that in question 26, and conduct a survey among your users to see which version they prefer.
28. What three guidelines should be followed to ensure that a structured English specification will be readable?
29. Do you think that three levels of nested IF constructs in a structured English specification are OK? Why or why not?
30. Research Project: Make up several examples of structured English process specifications involving two, three, and four levels of nested IF constructs. Conduct a survey to determine, on average, how many levels the users in your organization are willing to accept.
31. What is the purpose of indentation in a structured English process specification?
32. Why is it important to conduct walkthroughs of a structured English process specification with the appropriate user?
33. What is the purpose of using outline-style numbering in a structured English process specification?
34. Give a definition of the precondition/postcondition specification technique.
35. What is the difference between the structured English specification technique and the precondition/postcondition technique?
36. Under what conditions is the precondition/postcondition specification technique a good one for the systems analyst to use?
37. Give a definition of a precondition.
38. What are the four things that a precondition typically describes?
39. What is the relationship between preconditions in a process specification and input flows on a DFD?
40. What happens if the preconditions of a process specification are not satisfied?
41. Give a definition of a postcondition.
42. What are the four things that a postcondition typically describes?
43. What is the relationship between postconditions and output flows on a DFD?
44. If a process specification has four sets of preconditions, how many sets of postconditions should it have?
45. What is the minimum number of preconditions that a process specification could have?
46. What are the potential disadvantages of the precondition/postcondition approach?
47. Research Project: Find an example of a real-world process specification that would not be well suited to the precondition/postcondition specification approach. Why is it not well suited?
48. Look at Figure 11.6. What would be a better modeling tool for creating a process specification for this situation?
49. Research Project: Find an example of a real-world process specification that would be well suited to the precondition/postcontion approach. Why is it well suited?
50. What is a decision table? What are the components of a decision table?
51. Under what conditions is a decision table a good modeling tool for process specifications?
52. What is wrong with the following decision table?
    
53. What is wrong with the following decision table?
    
54. What is wrong with the following decision table?
    
55. What is the difference between a decision table with binary variables and a decision table with multivalued variables?
56. If a decision table has N binary-valued variables, how many rules should it have?
57. Under what conditions should the systems analyst use a graph for a process specification?
58. What are the advantages of a graph over structured English as a modeling tool for process specifications?
59. What are the four major disadvantages of narrative English as a modeling tool for process specifications?
60. What guidelines should be followed if narrative English must be used as a modeling tool for process specifications?
61. What are the two common criticisms of flowcharts as a modeling tool?
62. What are the three components of a structured flowchart?
63. Research Project: Show the same specification to a user in the form of structured English and a flowchart. Which approach is preferred? For more information on this see [Scanlan, 1987].
64. What is a Nassi-Shneiderman diagram? What is the difference between a flowchart and a Nassi-Shneiderman diagram?
65. From Structured Analysis by Victor Weinberg (New York: YOURDON Press, 1978): Write a decision table for the following narrative specification, and indicate any omissions, ambiguities, or contradictions that you find:
    “ The Swell Store employs a number of salesmen to sell a variety of items. Most of these salesmen earn their income from a commission, paid on the items they sell, but a few are salary-plus-commission employees; that is, they receive a fixed salary, regardless of the quantity or type of items they sell, plus a commission on certain items. The Swell Store sells several different lines of merchandise, some of which are known as standard items (a can of tomato soup, for example) because they are widespread and do not require any creative sales techniques; in addition, there are bonus items that are highly profitable but difficult to sell (a gold-plated, diamond-studded Cadillac, perhaps). The standard and bonus items generally represent the low and high ends of the price spectrum, sandwiching a greater number of items in the middle of the spectrum.
    “Customers, also, are categorized. Some are known as regulars, because they do business so often that no creative selling is required. Most of the customers, however, do a small amount of business at the Swell Store, and are likely to walk in right off the street, buy something, and then disappear forever.
    “The management’s commission policy is as follows: If a nonsalaried employee sells an item that is neither standard nor bonus to someone other than a regular customer, he receives a 10 percent commission, unless the item costs more than $10,000, in which case the commission is 5 percent. For all salesmen, if a standard item is sold, or if any item is sold to a regular customer, no commission is given. If a salaried salesman sells a bonus item, he receives a 5 percent commission, unless the item sells for more than $1,000, in which case he receives a flat $25 commission. If a nonsalaried salesman sells a bonus item to someone other than a regular customer, he receives a 10% commission, unless the item sells for more than $1,000, in which case he receives a flat commission of $75.”

FOOTNOTES

1. [1] For more information on USE-IT, see James Martin and Carma McClure’s Structured Techniques for Computing. (Englewood Cliffs, N.J.: Prentice-Hall, 1986).
2. [2] This is often caused by the introduction of an entire set of structured analysis standards in the organization. While the standards are an admirable effort to combat sloth, ignorance, and total anarchy, they often go too far and prescribe a rigidly regimented solution to all problems. As a common saying goes, “If your only tool is a hammer,