Functional decomposition is the classical design methodology in software engineering. Functional decomposition proposes that the way to build a software system, whether large or small, is to break the original task into subtasks, break each subtask into smaller subtasks, and continue the process until each component can be straightforwardly implemented. It further proposes that at each level the definition of a subtask states what is to be done rather than how it is to be done.
The central role of functional decomposition in the history of the discipline can best be understood by realizing how deeply the discipline was influenced by military procurement practices. The need to apportion defense systems and their subsystems among contractors and subcontractors led naturally to corresponding structures in software requirements specifications, and for many years the military was by far the most important sponsor of large-scale software systems. Functional decomposition was used not just as an organizing principle for software systems but also for the requirements documents that stated what those systems were supposed to do.
In this fine book, Kovitz opens his discussion of software requirements by arguing that the usefulness of functional decomposition is a myth--that it provides virtually no helpful guidance either in figuring out how to build a system or in stating the requirements for building one. Indeed, the focus of the software industry on producing commercial software, especially mass-market software, has made the imperative to employ functional decomposition largely irrelevant.
In a field that has been driven by rigid methodologies, it is a pleasure to read a book that takes a practical, undogmatic approach to developing the requirements for a software system. Kovitz’s approach is based to a large extent on Michael Jackson’s methods but does not follow them slavishly. The emphasis is on design patterns--using existing systems as suggestive prototypes for new ones. Kovitz also argues that the separation of “what” from “how”--a central tenet of functional decomposition--is based on a distinction that is far too vague to be useful in practice. “In fact, everything in engineering is what and everything is how,” he says.
Kovitz defines his subject as being how to write two kinds of documents: a requirements document that describes the desired effects to be produced by software and a program specification that describes the outward behavior of the computer producing those effects. The book has three major parts: “Groundwork,” which presents the underlying principles that distinguish requirements, interface design, and program design; “Content,” which describes what belongs in each of those documents; and “Style,” which gives detailed advice about how to present those documents. Each of these parts contains several chapters.
A nice feature of the book that relates principles to reality is the fourth part, “Examples,” which presents the requirements and user interface documents for an actual program: a bug log that records bugs found in a software project, answers queries about the bugs, and notifies users when they are responsible for performing a task related to a bug. The example is large enough not to be a toy, yet small enough so that one can read and understand the relevant documents without becoming lost in a mass of detail.
The book’s approach is pragmatic and helpful. For instance, in chapter 5 Kovitz describes five problem frames that are useful in formulating requirements: information problems, control problems, transformation problems, workpiece problems, and connection problems. He suggests that one or more of these models usually provides a good framework for specifying requirements, but goes on to say that occasionally none of them really fits well. He describes the use of Jackson diagrams but advises that they be used as a tool of thought rather than as a rigid methodology. The chapters on style include some nice sections on English usage and effective typography.
The book is well organized, literate, and readable. In a field where rigid prescriptions of methodology are the norm, a relaxed yet eminently useful approach to creating software requirements and specifications is a delightful discovery.
