Deficiencies of Less Formal Approaches 1

25.1.1 Deficiencies of Less Formal Approaches 1

The methods discussed for analysis and design in Parts Three and Four of this book made heavy use of natural language and a variety of graphical notations. Although careful application of analysis and design methods, coupled with thorough review can and does lead to high-quality software, sloppiness in the application of these methods can create a variety of problems. A system specification can contain con- tradictions, ambiguities, vagueness, incomplete statements, and mixed levels of

Although a good abstraction. document index

Contradictions are sets of statements that are at variance with each other. For cannot eliminate

example, one part of a system specification may state that the system must monitor contradictions, it can

help to uncover them. all the temperatures in a chemical reactor while another part, perhaps written by Spend the time to

another member of staff, may state that only temperatures occurring within a cer- create a

tain range are to be monitored. Normally, contradictions that occur on the same page comprehensive index

of a system specification can be detected easily. However, contradictions are often for specifications and

other documents. separated by a large number of pages. Ambiguities are statements that can be interpreted in a number of ways. For exam- ple, the following statement is ambiguous:

The operator identity consists of the operator name and password; the password consists of six digits. It should be displayed on the security VDU and deposited in the login file when an operator logs into the system.

In this extract, does the word it refer to the password or the operator identity? Vagueness often occurs because a system specification is a very bulky document.

“Making mistakes is Achieving a high level of precision consistently is an almost impossible task. It can human, Repeating

lead to statements such as “The interface to the system used by radar operators should ‘em is too.”

be user-friendly” or “The virtual interface shall be based on simple overall concepts

Malcolm Forbes

that are straightforward to understand and use and few in number.” A casual perusal of these statements might not detect the underlying lack of any useful information.

Incompleteness is probably one of the most frequently occurring problems with system specifications. For example, consider the functional requirement:

The system should maintain the hourly level of the reservoir from depth sensors situated in the reservoir. These values should be stored for the past six months.

1 This section and others in the first part of this chapter have been adapted from work contributed by Darrel Ince for the European version of the fourth edition of Software Engineering: A Practi- tioner's Approach.

This describes the main data storage part of a system. If one of the commands for the system was

Effective use of formal The function of the AVERAGE command is to display on a PC the average water level for a technical reviews

particular sensor between two times.

during specification can eliminate many of

Assuming that no more detail was presented for this command, the details of the these problems.

command would be seriously incomplete. For example, the description of the com- However, some will

mand does not include what should happen if a user of a system specifies a time that not be uncovered.

Therefore, be on the was more than six months before the current hour. lookout for deficiencies

Mixed levels of abstraction occur when very abstract statements are intermixed ran- during design, code,

domly with statements that are at a much lower level of detail. For example, state- and test.

ments such as The purpose of the system is to track the stock in a warehouse. might be intermixed with When the loading clerk types in the withdraw command he or she will communicate the

order number, the identity of the item to be removed, and the quantity removed. The sys- tem will respond with a confirmation that the removal is allowable.

While such statements are important in a system specification, specifiers often man- age to intermix them to such an extent that it becomes very difficult to see the over- all functional architecture of a system.

Each of these problems is more common than we would like to believe. And each represents a potential deficiency in conventional and object-oriented methods for specification.