Structured English is a very limited, highly restricted subset of the English language used to plan, design, or document program routines, modules, and manual procedures.
Structured English is useful for planning or designing program routines, modules, and manual procedures. It resembles a programming language, so programmers find it easy to understand. The base for structured English is, of course, English, so users find it easy to follow, too.
Structured English is excellent for describing an algorithm, particularly when user communication is essential. If the main concern is communication with the programmers, however, pseudocode may be a better choice. Structured English is not a good choice for describing a high-level control structure or an algorithm in which numerous decisions must be made; logic flowcharts, decision tables, and decision trees are better for such tasks.
Before writing structured English, the designer must understand the algorithm or procedure. The necessary information might be compiled from direct observation, extracted from existing documentation, or derived from the problem definition (Part II) and/or analysis (Part IV) stages of the system development life cycle.
Other tools for documenting or planning routines or processes include logic flowcharts (# 55), Nassi-Schneiderman charts (# 56), decision trees (# 57), decision tables (# 58), pseudocode (# 59), and input/process/output (IPO) charts (# 64). A pseudocode routine usually exists in the context of a larger program. Tools for documenting or planning program structure include structure charts (# 63) and HIPO (# 64). The basic software logic blocks are defined in # 62.
There are several variations of structured English, none of which can be considered a standard. Consequently, view this # as a guideline.
A good structured English statement reads like a short imperative sentence. By convention, only key words such as IF, THEN, SO, REPEAT, UNTIL, DO, and so on are capitalized; data names and the general English needed to complete a sentence or a phrase are lower case. Many sources recommend that a data name defined in a data dictionary be underlined, and that convention will be followed in the examples shown below.
Sequence statements begin with commands such as MOVE, GET, WRITE, READ, or COMPUTE followed by the name or names of the associated data elements or data structures. For example,
It is often convenient to group several structured English statements into a block, assign a name to the block, and reference the block by coding a single sequence statement. For example, all the instructions required to compute gross pay might be grouped in a block under the name compute gross pay. Subsequently, the statement
references the entire block.
Note that a block can contain any combination of code, including decisions, repetitive logic, and even other blocks. Indentation should always be used to show the relationship between the parts of a block.
Decision (or selection) logic follows an IF-THEN-ELSE structure:
The key word IF is followed by a condition. If the condition is true, the block following THEN is executed. ELSE identifies the negative of the condition. SO precedes the block to be executed if the initial condition is false. For example,
Indenting makes the IF-THEN-ELSE logic easier to read. (Note: The negative condition following ELSE is often assumed and not explicitly coded.)
Nested decisions are also supported:
Note that any or all of block-a, block-b, or block-c could contain yet another decision.
Repetitive (or iterative) logic defines a block of structured English that is executed repetitively until a terminal condition is reached. For example, such instructions as:
imply both repetitive logic and the condition used to terminate that logic.
Few software tools are designed to produce structured English. Word processors and text editors are sometimes used.