Structured Analysis

8/17/2015 Chapter 11 Structured Analysis Wiki

http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_11&printable=yes 1/30

Chapter 11From Structured Analysis Wiki

Contents

1 Process Specifications1.1 STRUCTURED ENGLISH1.2 PRE/POST CONDITIONS1.3 DECISION TABLES1.4 OTHER PROCESS SPECIFICATION TOOLS

1.4.1 Graphs and Charts1.4.2 Narrative English1.4.3 Flowcharts1.4.4 NassiShneiderman Diagrams

1.5 SUMMARY1.6 REFERENCES1.7 QUESTIONS AND EXERCISES1.8 ENDNOTES

Process Specifications

“Our little systems have their day.”

Alfred, Lord Tennyson In Memoriam, 1850

IN THIS CHAPTER, YOU WILL LEARN:

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.

In this chapter, we explore the process specification, the description of what’s happening inside eachbottomlevel, primitive bubble in a dataflow diagram. Various textbooks, including [DeMarco, 1978], and[Gane and Sarson, 1977] also use the term minispec (as an abbreviation for miniature specification) as an



alternative for process specification. Regardless of its name, the purpose of a process specification is quitestraightforward: it defines what must be done in order to transform inputs into outputs. It is a detaileddescription of the user’s business policy that each bubble carries out.

As we will see in this chapter, there is a variety of tools that we can use to produce a process specification:decision tables, structured English, pre/post conditions, flowcharts, NassiShneiderman diagrams, and soon. While most systems analysts favor structured English, you should remember that any method can beused, as long as it satisfies two crucial requirements:

The process specification must be expressed in a form that can be verified by the user and thesystems analyst. It is precisely for this reason that we avoid narrative English as a specificationtool: it is notoriously ambiguous, especially when describing alternative actions (decisions) andrepetitive actions (loops). By its nature, it also tends to cause great confusion when expressingcompound Boolean conditions (i.e., combinations of the Boolean operators AND, OR, andNOT).The process specification must be expressed in a form that can be effectively communicated tothe various audiences involved. While it will typically be the systems analyst who writes theprocess specification, it will usually be a diverse audience of users, managers, auditors, qualityassurance personnel, and others who must read the process specification. A processspecification could perhaps be expressed in predicate calculus, or in Pascal, or in a formaldiagramming approach such as Higher Order Software’s USEIT<ref>For more information onUSEIT, see James Martin and Carma McClure’s Structured Techniques for Computing.(Englewood Cliffs, N.J.: PrenticeHall, 1986).</ref>; but if the user community refuses to lookat 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.

As mentioned above, most systems analysts use structured English as their preferred method of writingprocess specifications. It is perhaps more important to point out that most systems analysts, and mostorganizations, use one tool for writing all of their specifications.<ref>This is often caused by theintroduction of an entire set of structured analysis standards in the organization. While the standards are anadmirable effort to combat sloth, ignorance, and total anarchy, they often go too far and prescribe a rigidlyregimented solution to all problems. As a common saying goes, “If your only tool is a hammer, all theworld looks like a nail.”</ref> This is, in my opinion, a major mistake: you should feel free to use acombination of specification tools, depending on (a) the user’s preference, (b) your own preferences, and(c) the idiosyncratic nature of the various processes.

A good process specification tool should have a third characteristic, too: it should not impose (or imply)arbitrary design and implementation decisions. This is often very difficult, because the user, on whom wemust depend for a statement of the “policy” carried out by each bubble in the DFD, is prone to describe thepolicy in terms of the way he carries it out today. It is your job as a systems analyst to distill from thispresentation the essence of what the policy is, not how the policy is carried out today.

Consider the following example: the systems analyst is discussing a small fragment of a system, asillustrated by Figure 11.1. He wants to develop a process specification for the bubble labeled COMPUTEWIDGET FACTOR. Since the systems analyst is entirely unfamiliar with the application, he has



interviewed the user and has learned that the policy for computing widget factors for any value of the inputdata element, x, is as follows:

1. The widget factor is not produced as the result of a single calculation. In fact, we have to beginby 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, thatwe 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 overagain.

Figure 11.1: Computation of widget factor; source:File:Figure111.graffle

You might argue that this process specification is difficult to read and understand because it is written innarrative English. Indeed, the following description is much more compact (note that the vertical bars “|” inthe UNTIL clause mean “absolute value of” the enclosed expression):

widgetfactor0 = 14

REPEAT for N = 0 in steps of 1

http://yourdon.com/strucanalysis/wiki/index.php/File:Figure111.jpg

http://yourdon.com/strucanalysis/wiki/index.php/File:Figure111.graffle



widgetfactorN+1 = (widgetfactorN (X/widgetfactorN))/2

UNTIL |widgetfactorN+1 widgetfactorN| < 0.0001

However, even this is flawed: it describes the policy in terms of a particular procedural implementation.The policy, as may have been evident (but equally likely, may not have been evident), is the NewtonRaphson algorithm for approximating a square root.<ref>Try the algorithm out on a couple of test cases.You’ll find that it converges fairly quickly.</ref> The following process specification describes the samepolicy, but leaves the designer/programmer complete freedom to choose her own algorithm:

PRECONDITIONThere exists a number X that is nonnegative.

POSTCONDITIONA widgetfactor is produced such thatX = widgetfactor * widgetfactor

The programmer may indeed choose to use the user’s algorithm for calculating the square root, but sheshould not be constrained to do so by the systems analyst. Indeed, the extravagant attention to theprocedural algorithm, especially in the first version of the specification above, entirely obscured what theprocess really was!

Before we explore the various process specification tools, we should emphasize one point: processspecifications are only developed for the bottomlevel processes in a leveled set of dataflow diagrams. Aswe can see in Figure 11.2, all the higherlevel processes are defined by the next lowerlevel network ofprocesses. In other words, the process specification for a higherlevel bubble is the lowerlevel DFD. Towrite an additional process specification in structured English would not only be superfluous, it would beredundant; that is, it would create a specification that would be more difficult to keep up to date.<ref>Notwithstanding this warning, we should point out that you will sometimes be required, as a systemsanalyst, to produce a written process specification for higherlevel processes. This will happen if the userdecides that he wants to show the specification to his boss and is concerned that the boss won’t tolerate theidea of leveled DFDs. Thus, the user will say to you, “Look, I know that you don’t need a processspecification for these toplevel bubbles, but I’d appreciate it if you would write them anyway so that theboss can understand what the system is all about.” You’ll have to deal with this problem with the samediplomatic skills that you use to solve all other political problems in your project.</ref>



Figure 11.2: Process specifications for bottomlevel bubbles; source:File:Figure112.graffle

We will concentrate on three major process specification tools in this chapter:

Structured EnglishPre/post conditionsDecision tables

We will also comment briefly on a number of other less commonly used specification tools: narrativeEnglish, flowcharts, and Nassi–Shneiderman diagrams.





STRUCTURED ENGLISH

Structured English, as the name implies, is “English with structure.” That is, it is a subset of the full Englishlanguage with some major restrictions on the kind of sentences that can be used and the manner in whichsentences can be put together. It is also known by such names as PDL (for program design language) andPSL (for problem statement language or problem specification language). Its purpose is to strike areasonable balance between the precision of a formal programming language and the casual informality andreadability 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 thesemicolon that terminates a programming statement in many different programming languages; it may ormay not terminate with a period (“.”), depending on your taste in such things. Also, note that sentencesdescribing computations can be prefixed with the verbs COMPUTE, ADD, SET, and so on; thus, we couldhave written the above example as

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

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

SET TAXRATE TO 13ADD 3 TO XMULTIPLY UNITPRICE BY QUANTITYDIVIDE CURRENTASSETS BY CURRENTLIABILITIES.

Verbs should be chosen from a small set of actionoriented verbs such as:

GET (or ACCEPT or READ)PUT (or DISPLAY or WRITE)FIND (or SEARCH or LOCATE)ADDSUBTRACTMULTIPLYDIVIDE



COMPUTEDELETEFINDVALIDATEMOVEREPLACESETSORT

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

Objects (the subject of the simple imperative sentences) should consist only of data elements that have beendefined in the data dictionary or local terms. Local terms are terms (words) that are explicitly definedwithin an individual process specification; they are only known, relevant, and meaningful within thatprocess specification. A typical example of a local term is an intermediate calculation, which is used toproduce the final output of the process.<ref>Local terms are defined within the process specification wherethey occur and arenot defined in the data dictionary. They are often derived (directly calculated) from termsthat are already in the data dictionary, so it would be redundant to add the local terms. Also, by definition,the local terms are only known within a local context (i.e., inside a bubble in a dataflow diagram). Theyshould not appear as a flow on the DFD, and they are usually not part of the normal vocabulary ofapplicationoriented words used by the user.</ref> For example, the structured English processspecification below examines a series of order records in an ORDERS store to compute a daily total:

dailytotal = 0DO WHILE there are more orders in ORDERS with Invoicedate = today’s date

READ next order in ORDERS with Invoicedate = today’s dateDISPLAY to Accounting invoicenumber, customername, totalamountdailytotal = dailytotal + totalamount

ENDDODISPLAY to Accounting dailytotal

Finally, structured English allows sentences to be combined in a few limited ways; these are taken from thefamiliar structured programming constructs.<ref>If you are not familiar with structured programming,consult any of the standard texts on the subject, or see some of the early papers on the subject collected in[Yourdon, 1979].</ref>

The IFTHENELSE construct is used to describe alternative sentences that are to be carriedout based on the result of a binary decision. The IFTHENELSE construct can take either ofthe following two forms:



IF condition1

sentence1

ENDIF

or

IF condition1

sentence1

ELSE

sentence2

ENDIF

Thus, the systems analyst may write:

IF customer lives in New York

add customer to MARKETINGPROSPECTS

ENDIF

or

IF customerage greater than 65

set billingrate to seniorcitizenrate

ELSE

set billingrate to normalrate

ENDIF

The CASE construct is used to describe alternative sentences to be carried out based on theresults of a multivalued decision (as compared to the binary decision that takes place with an



IFTHEN construct). The CASE construct takes the general form:

DO CASECASE variable = value1sentence1

CASE variable = valuensentencenOTHERWISEsentencen+1ENDCASE

Thus, the systems analyst might write:

DO CASECASE customerage < 13set billingrate to childrateCASE customerage ≥ 13 and customerage < 20set billingrate to teenagerateCASE customerage > 20 and customerage < 65set billingrate to adultrateOTHERWISEset billingrate to seniorcitizenrateEND CASE

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

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

Note that the "OTHERWISE" clause is often used to catch situations that the user forgets to specify and thatthe 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 thefollowing example:

DO CASECASE paymenttype = “cash”set discountrate to 0.05CASE paymenttype = “creditcard”set discountrate to 0.01OTHERWISEset discountrate to 0END CASE

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

The DOWHILE construct is used to describe a sentence that is to be carried out repetitivelyuntil some Boolean condition is true. It takes the general form:

DO WHILE condition1

sentence1

ENDDO

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

For example, the systems analyst might write:

DO WHILE there are more items in the customerorder

extendedprice = unitprice * unitquantity

ENDDO

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



REPEAT

sentence1

UNTIL condition1

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

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

sentence1sentence2sentencen

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

IF condition1

sentence1sentence2

ELSE

sentence3sentence4sentence5

ENDIF

or

DO WHILE condition1

sentence1sentence2sentence3



ENDDO

2. A simple IFTHENELSE construct is considered structurally equivalent to a single, simple sentence.This allows IFTHENELSE structures to be nested within other IFTHENELSE structures, or withinDOWHILE structures, or within CASE structures. For example:

IF condition1

sentence1IF condition2

sentence2sentence3

ELSE

sentence4sentence5

ENDIFsentence6

ELSE

sentence7IF condition3

sentence8

ENDIFsentence9

ENDIF

3. A simple DOWHILE structure is considered structurally equivalent to a simple, single sentence. Thisallows DOWHILE structures to be nested within other DOWHILE structures, or within IFTHENELSE structures, or within CASE structures. Thus, we might have a structured English specification of thefollowing nature:

grandtotal = 0DO WHILE there are more orders to process

invoicetotal = 0READ next order from ORDERSDO WHILE there are more items in the order



invoicetotal = invoicetotal + itemamount

ENDDODISPLAY invoicenumber, invoicetotalgrandtotal = grandtotal + invoicetotal

ENDDODISPLAY grandtotal

4. A simple CASE structure is considered structurally equivalent to a simple, single sentence. This allowsCASE structures to be nested within other CASE structures, or within IFTHENELSE structures, orwithin DOWHILE structures.

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

1. Restrict the structured English process specification to a single page of text (e.g., 8by11 sheetof paper, 66 lines of text on a word processing system, or 24 lines on a computer screen). If thespecification 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., thebubble within the DFD) is too complex and should be split into a network of lowerlevel,simpler processes.

2. Don’t allow more than three levels of nesting (i.e., three levels of nested IFTHENELSEstructures, or three levels of CASE structures, etc.). Particularly in the case of IFTHENELSE structures, more than even two levels of nesting is a strong indication that a decisiontable 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 automatedsupport to develop the process specifications (even something as simple as a standard wordprocessing system). If the process specifications are being typed manually by a clerical personwho is not familiar with structured programming or structured analysis, you will have toexplain very carefully what kind of indentation you want; you should also proofread theresulting 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 specificationwritten in structured English. My experience has been almost uniformly positive in this area: users can readstructured English, with the following provisos:

1. You will have to walk through the document once or twice to ensure that they understand theformat and the various constructs. On the first reading, it may well look like a legal document,especially if you have “highlighted” the IFTHENELSE construct, and the like.



2. Don’t refer to the process specification as “structured English.” If necessary, refer to it as “aformal description of your business policy for carrying out this activity.”

Pay careful attention to the overall format and layout of the document; the indentation of nested blocks oflogic is especially important. Some users prefer an outline style of indentation, that is, where indentedlevels 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.

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 usefulapproach 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 beused.

3. The systems analyst wants to let the programmer explore several such algorithms, but does notwant to get involved in such details himself, and especially does not want to engage inarguments 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:

Figure 11.3: A pre/post condition specification

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

http://yourdon.com/strucanalysis/wiki/index.php/Appendix_F




Preconditions describe all the things (if any) that must be true before the process begins operating. It’ssometimes convenient to think of the process as a “sleeping princess,” and the preconditions represent the“magic kiss” that will awaken the process and set it to work. Alternatively, you can think of thepreconditions as a guarantee from the user: “I guarantee that when this process is activated the followingthings 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, asshown on the dataflow diagram. Note that there may be cases where there are several flowscoming into a process, but only one of the flows is a necessary precondition to activate theprocess. For example, if we saw a specification that began with

Preconditiondata 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 necessaryfor the process to begin doing its work.

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



Figure 11.4: A DFD with inputs X,Y, andZ; source: File:Figure114.graffle

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 betrue.” Postconditions typically describe the following:

The outputs that will be generated or produced by the process. This is the most common formof postcondition (e.g., “An invoice will be produced”).The relationships that will exist between output values and the original input values. This iscommon for the situation where an output is a direct mathematical function of an input value.Thus, a postcondition might say, “The invoicetotal will be calculated as the sum of unititemprices plus shippingcharges.”The relationships that will exist between output values and values in one or more stores. This iscommon when information is to be retrieved from a store and used as part of an output of theprocess. For example, a process specification might have as a postcondition the followingstatement: “The onhandbalance in the INVENTORY store will be increased by amountreceived, and the new onhand balance will be produced as output from this process.”The changes that will have been made to stores: new items added, existing items modified, orexisting items deleted. Thus, we might see statements like “The order will be appended to theORDERS 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/storagerelationships) 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 thestores have been modified. After the normal processing situations have been described, you should includeappropriate preconditions and postconditions for error cases and abnormal cases. Consider the pre/postcondition specification shown in Figure 11.5(b) that would be developed for a new system from thenarrative specification in Figure 11.5(a).





Figure 11.5(a): An example of narrative specifications

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 timeswhen it may not be appropriate. The lack of intermediate steps between the inputs (preconditions) and theoutputs (postconditions) is deliberate and conscious — but it may make the specification hard to understandif the reader cannot visualize some kind of procedure that will lead from inputs to outputs. Also, if there arecomplex relationships between inputs and outputs, it may be easier to write the specification usingstructured English. An example of a precondition/postcondition specification that is probably toocomplicated is shown in Figure 11.6.

Figure 11.6: An overly complicated pre/post condition specification


http://yourdon.com/strucanalysis/wiki/index.php/File:Figure115a.jpg

http://yourdon.com/strucanalysis/wiki/index.php/File:Figure115b.jpg



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

DECISION TABLES

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

As shown in Figure 11.7, a decision table is created by listing all the relevant variables (sometimes knownas conditions or inputs) and all the relevant actions on the left side of the table; note that the variables andactions have been conveniently separated by a heavy horizontal line. In this example, each variable is alogical 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 (truefalse) variables, butdecision tables can also be built from multivalued variables; for example, one could build a decision tablewith a variable called “customerage” 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 istypically called a rule. A rule describes the action (or actions) that should be carried out for a specificcombination of values of the variables. At least one action needs to be specified for each rule (i.e., for eachvertical column in the decision table), or the behavior of the system for that situation will be unspecified.

If there are N variables with binary (truefalse) values, then there will be 2N distinct rules; thus, if there are3 conditions, there will be 8 rules, and if there are 7 conditions, there will be 128 rules. Enumerating all therules is a fairly straightforward process: by treating the Yes (or T) as a binary zero, and the No (or F) as a

http://yourdon.com/strucanalysis/wiki/index.php/File:Figure117.gif



binary one, it is easy to generate a sequence of 000, 001, 010, 011, 100, 101, and so forth until all 2Ncombinations have been generated.<ref>Of course, there will be situations where the decision tableconditions are not binary in nature, but are capable of taking on several values (e.g., an insuranceapplication might involve customerage and might use the values “under 18 years,” “18 through 64,” and“65 or over” ). To determine the total number of rules in such a decision table, we must multiply thenumber of values that variable 1 can take on by the number of values that variable 2 can take on by ... thenumber of values that variable N can take on. Thus, if we have an application where variable 1 can take on3 values, variable 2 can take on 5 values, and variable 3 can take on 4 values, we will need 3 x 5 x 4 = 60distinct rules.</ref>

You must discuss each rule with the user to ensure that you have identified the correct action, or actions, foreach combination of variables. It is quite common, when doing this, to find that the user has never thoughtabout certain combinations of variables or that they have never occurred in his or her experience.<ref>There are guidelines for simplifying decision tables and combining several rules into composite rules,but we will not cover them in this book. See [Yourdon, 1976] for details.</ref> The advantage of thedecision 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 ofimplementation. That is, when the systems analyst delivers the decision table (along with the DFDs, etc.) tothe designer/programmer, there is a tremendous freedom of choice in terms of implementation strategy: thedecision table can be programmed with nested IF statements, with a CASE construct or a GO TODEPENDING ON construct in COBOL; in the extreme case, a decision table code generator canautomatically generate code from the decision table. Thus, decision tables are often referred to as anonprocedural system modeling tool, for they do not require any specific procedural algorithm to carry outthe 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 eachvariable can take on.

2. Calculate the number of combinations of conditions. If all the conditions are binary, then thereare 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.

OTHER PROCESS SPECIFICATION TOOLS

Graphs and Charts



In some cases, it may be appropriate to express a process specification as a graph or a chart. Indeed, theuser 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 theprogrammer translate the graph directly into COBOL, Visual Basic, or some other programming languagewhen it is time to implement the system.

Consider, for example, a process specification that determines a customer’s insurance premium as afunction of age. The user has told us that the current business policy is to determine the premium from thegraph 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 theinsurance 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.

Narrative English

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

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




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

Flowcharts

We have avoided the use of flowcharts thus far in our discussion, but that is a reflection of currentdisinterest in flowcharts rather than an indictment of them.<ref>However, it is interesting to note thatflowcharts may be about to experience a rebirth. Recent work by David Scanlan at California StateUniversity in Sacramento has shown that programming students strongly prefer flowcharts as the preferredmethod of learning about algorithms. If this is true for programming students, maybe it will be true forusers, too. For more on this, see Scanlan’s paper entitled “A Niche for Structured Flowcharts,” Proceedingsof the 1987 ACM Computer Science Conference.</ref> Much of the criticism of flowcharts has resultedfrom their misuse in the following two areas:

1. As a highlevel 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 toolfor 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.

http://yourdon.com/strucanalysis/wiki/index.php/Chapter_9



Figure 11.9: An unstructured flowchart; source:File:Figure119.graffle

However, if the flowchart is only used to describe detailed logic, and if the systems analyst restricts himselfto flowcharting symbols equivalent to the structured English constructs described in Section 11.1, thenthere is nothing wrong with their use. To create a structured flowchart, the systems analyst must organizehis or her logic with nested combinations of the flowchart symbols shown in Figure 11.10.<ref>For moreinformation on structured flowcharts, see the classic paper [Böhm and Jacopini, 1966].</ref>





Figure 11.10: The BöhmJacopini structured flowchart symbols; source: File:Figure110.graffle

An alternative is the use of NassiShneiderman diagrams, discussed in Section 11.4.4. However, it shouldbe 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 Acould be used to create and maintain flowcharts, the simple truth is structured English, decision tables, andpre/post condition specifications are easier to create and maintain.

NassiShneiderman Diagrams

When structured programming first became popular in the mid1970s, NassiShneiderman diagrams wereintroduced as a structured flowcharting technique; see [Nassi and Shneiderman, 1973] and [Chapin, 1974].A typical NassiShneiderman 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); therectangle can also be used to represent a block of sequential statements. The binary IFTHENELSEconstruct is represented by the graphic notation shown in Figure 11.12(b); and the repetitive DOWHILEconstruct is represented by the graphic notation shown in Figure 11.12(c).

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





Figure 11.11: A typical NassiShneiderman diagram

Figure 11.12(a):Representation of asequential statement

Figure 11.12(b): Representationof an IFTHENELSEconstruct

http://yourdon.com/strucanalysis/wiki/index.php/File:Figure1112b.gif


http://yourdon.com/strucanalysis/wiki/index.php/File:Figure1112a.gif



Figure 11.12(c): Representation of aDOWHILE 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 NassiShneiderman diagramsover pseudocode when learning about complex algorithms; although this does not agree with the typicalnegative reaction of experienced programmers toward flowcharts, Scanlan’s conclusions are based oncareful factoranalytic studies of several hundred students. While end users do not necessarily have thesame preferences as computer science students, there is at least the possibility that they would prefer agraphical representation of a process specification than a narrative/textual represenation.

SUMMARY

The purpose of this chapter has been to show you that there are many different ways to describe the detaileduser policy inside each primitive bubble in a dataflow diagram. While structured English is the mostcommonly 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 asystem model; there may be hundreds or even thousands of process specifications, and each one may be apage in length. Because of the amount of work involved, you may want to consider the topdownimplementation approach discussed in Chapter 5: begin the design and implementation phase of yourproject 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 dataflowdiagrams that have already been developed. You may discover that the process specification needsadditional input dataflows or that it produces additional output dataflows (i.e., flows that were not shown onthe DFD). And as you write the process specification, you may find that additional functions are needed; forexample, as you write the process specification for a function that adds a new record to the CUSTOMERSstore, 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 basedon the detailed work of writing the process specifications.

REFERENCES

http://yourdon.com/strucanalysis/wiki/index.php/File:Figure1112c.gif

http://yourdon.com/strucanalysis/wiki/index.php/Chapter_5



1. Tom DeMarco, Structured Analysis and Systems Specification. Englewood Cliffs, N.J.: PrenticeHall,1979.

2. Chris Gane and Trish Sarson, Structured Systems Analysis: Tools and Techniques. Englewood Cliffs,N.J.: PrenticeHall, 1978.

3. Edward Yourdon, Techniques of Program Structure and Design. Englewood Cliffs, N.J.: PrenticeHall,1976.

4. James Martin and Carma McClure, Diagramming Techniques for Software Engineering. EnglewoodCliffs, N.J.: PrenticeHall, 1985.

5. Victor Weinberg, Structured Analysis. Englewood Cliffs, N.J.: PrenticeHall, 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. 366371. Also reprinted in Classics in Software Engineering (op. cit.).

8. I. Nassi and B. Shneiderman, “Flowchart Techniques for Structured Programming,” ACM SIGPLANNotices, Volume 8, Number 8 (August, 1973), pp.1226.

9. Ned Chapin, “New Format for Flowcharts,” Software Practice and Experience, Volume 4, Number4 (OctoberDecember 1974), pp. 341357.

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.: PrenticeHall, 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, December5, 1987.

QUESTIONS AND EXERCISES

1. Consider the following specification, provided to you in a narrative form. Which of the specificationtools 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 becausethey’ve been temporarily “blacklisted” because of poor quality. But the real work that I do is topick the optimal supplier from those that qualify the one that will deliver our order in theshortest amount of time. My boss had a system for estimating delivery time, and he taught it tome, 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 noteven 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 DOWHILE construct and a REPEATUNTIL 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)?

Question 26(a)

Question 26(b)

27. Which of the above two examples do you think is easiest to understand? Why?28. Research Project: Construct several examples similar to that in question 26, and conduct a survey

among your users to see which version they prefer.29. What three guidelines should be followed to ensure that a structured English specification will be

readable?30. Do you think that three levels of nested IF constructs in a structured English specification are OK?

Why or why not?31. 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, howmany levels the users in your organization are willing to accept.

32. What is the purpose of indentation in a structured English process specification?33. Why is it important to conduct walkthroughs of a structured English process specification with the

appropriate user?34. What is the purpose of using outlinestyle numbering in a structured English process specification?

http://yourdon.com/strucanalysis/wiki/index.php/File:Quest1126b.jpg

http://yourdon.com/strucanalysis/wiki/index.php/File:Quest1126a.jpg



35. Give a definition of the precondition/postcondition specification technique.36. What is the difference between the structured English specification technique and the

precondition/postcondition technique?37. Under what conditions is the precondition/postcondition specification technique a good one for the

systems analyst to use?38. Give a definition of a precondition.39. What are the four things that a precondition typically describes?40. What is the relationship between preconditions in a process specification and input flows on a DFD?41. What happens if the preconditions of a process specification are not satisfied?42. Give a definition of a postcondition.43. What are the four things that a postcondition typically describes?44. What is the relationship between postconditions and output flows on a DFD?45. If a process specification has four sets of preconditions, how many sets of postconditions should it

have?46. What is the minimum number of preconditions that a process specification could have?47. What are the potential disadvantages of the precondition/postcondition approach?48. Research Project: Find an example of a realworld process specification that would not be well suited

to the precondition/postcondition specification approach. Why is it not well suited?49. Look at Figure 11.6. What would be a better modeling tool for creating a process specification for

this situation?50. Research Project: Find an example of a realworld process specification that would be well suited to

the precondition/postcontion approach. Why is it well suited?51. What is a decision table? What are the components of a decision table?52. Under what conditions is a decision table a good modeling tool for process specifications?53. What is wrong with the following decision table?

54. What is wrong with the following decision table?

55. What is wrong with the following decision table?

http://yourdon.com/strucanalysis/wiki/index.php/File:Quest1153.gif




56. What is the difference between a decision table with binary variables and a decision table withmultivalued variables?

57. If a decision table has N binaryvalued variables, how many rules should it have?58. Under what conditions should the systems analyst use a graph for a process specification?59. What are the advantages of a graph over structured English as a modeling tool for process

specifications?60. What are the four major disadvantages of narrative English as a modeling tool for process

specifications?61. What guidelines should be followed if narrative English must be used as a modeling tool for process

specifications?62. What are the two common criticisms of flowcharts as a modeling tool?63. What are the three components of a structured flowchart?64. 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].65. What is a NassiShneiderman diagram? What is the difference between a flowchart and a Nassi

Shneiderman diagram?66. 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, orcontradictions that you find:

“The Swell Store employs a number of salesmen to sell a variety of items. Most of thesesalesmen earn their income from a commission, paid on the items they sell, but a few aresalarypluscommission employees; that is, they receive a fixed salary, regardless of thequantity or type of items they sell, plus a commission on certain items. The Swell Store sellsseveral different lines of merchandise, some of which are known as standard items (a can oftomato soup, for example) because they are widespread and do not require any creative salestechniques; in addition, there are bonus items that are highly profitable but difficult to sell (agoldplated, diamondstudded Cadillac, perhaps). The standard and bonus items generallyrepresent the low and high ends of the price spectrum, sandwiching a greater number of itemsin the middle of the spectrum.“Customers, also, are categorized. Some are known as regulars, because they do business sooften that no creative selling is required. Most of the customers, however, do a small amount ofbusiness at the Swell Store, and are likely to walk in right off the street, buy something, andthen disappear forever.“The management’s commission policy is as follows: If a nonsalaried employee sells an itemthat is neither standard nor bonus to someone other than a regular customer, he receives a 10percent commission, unless the item costs more than $10,000, in which case the commission is5 percent. For all salesmen, if a standard item is sold, or if any item is sold to a regularcustomer, no commission is given. If a salaried salesman sells a bonus item, he receives a 5percent 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 regularcustomer, he receives a 10% commission, unless the item sells for more than $1,000, in whichcase he receives a flat commission of $75.”

ENDNOTES

<references/>

Retrieved from "http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_11&oldid=3324"Category: Pages with broken file links

This page was last modified on 6 June 2007, at 14:38.This page has been accessed 132,124 times.

http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_11&oldid=3324

http://yourdon.com/strucanalysis/wiki/index.php/Special:Categories

http://yourdon.com/strucanalysis/wiki/index.php?title=Category:Pages_with_broken_file_links&action=edit&redlink=1

Documents

Structured Analysis