Good Points:

• the book is written in an engaging style
• its emphasis on the importance of good, and life-cycle-based, requirements definition is sound
• its emphasis on the importance of holistic (my word) and life-cycle-based development of solution is sound
• its inclusion in solution alternatives to be considered of bringing about redefinition of requirements is unusual in SE texts, but welcome
• its advocacy of the practice of defining verification requirements along with system requirements is very appropriate and welcome.

General Criticisms:

1. Use of Language

The book murders the English language, in its use of terms such as requirements, design, designer, function, performance.

The consequence for the reader is likely to be confusion and miss-communication with others concerned with projects and engineering, in turn leading to errors, rework and compromised outcomes.

2. “The System” as a Bounded Entity

The book lacks the concept of a given system or subsystem as a bounded entity defined by a set of required and desired characteristics.

This flaw is seen frequently in the aircraft examples, for example “length of runway” in the (so called) RBS for the aircraft, rather than reference to the maximum take-off distance as a measure and value of performance of the aircraft function “take-off”.

The aircraft refueling example, as another example giving rise to this criticism, muddles up requirements on the aircraft with requirements on other elements of the “making money from air transportation system”.

The likely consequences for anybody who was to treat this content of the book seriously are profound – un-implementable (out of boundary) requirements, requirements placed in the wrong requirements specification, and general confusion amongst participants.

3. Expression of User Requirements

The book represents Operational Concept Descriptions (OCDs) and Concept of Operations (CONOPS) as representative forms of expression of user requirements. In doing so, the book ignores the traditional and widely understood scope and purpose of OCDs and CONOPS:

• OCD – a system-centric description of the intended users of a system (and their characteristics), what the system is to be used for, how the system is to be used, and the anticipated external conditions during use, all for the purpose of providing a context (why) for the system requirements;
• CONOPS – a statement of the Commander’s intent regarding the deployment and interaction of forces and elements of technology to produce a military outcome.

These artifacts, although serving different purposes, provide valuable references for requirements validation. Neither is, or should be, a requirements specification.

The consequence of the book misrepresenting or redefining OCD and CONOPS to be a user requirements specification is to force “extrapolation through a point” in developing requirements for a system, rather than developing requirements on all elements of a solution, including the “system of interest”, as an output of a sound problem-solving process.

This issue of the inadequacy of an OCD for a system as the primary source of input in developing requirements for a system is discussed in more detail in the paper “Process Issues in the Development of Solutions to Problems: Relationships Between Key Documents and the Development Process”, PPI document number P045-003358.

4. User Versus System Requirements

The book represents user requirements and system requirements as being somehow different, failing to recognize that user requirements are system requirements (on which one or more systems is always a question to be answered). The book lacks the concept of distinction between classification of requirements by owner, versus classification of requirements by object (for system requirements, the system to which the requirement applies), every requirement on an object having one or more owners.

The consequence of this flaw is ineffective validation of user requirements, and inability to use sound problem-solving processes to derive solutions to users’ needs.

5. “Then a Miracle Occurs” Process

The book lacks the concept of a “missions system”, “capability system” or similar which encapsulates the whole of the solution to the whole of the problem. Accordingly, requirements on a materiel item are created as the result of a miracle (Figure 2.5 page 44 and para 2.4.2 page 47), rather than being the product of a sound, problem-solving process.

The consequences of this omission are profound to the user of the book – poor and incomplete requirements on materiel items, the satisfaction of which is inconsistent with the satisfaction of need.

6. Misunderstanding of Functional Analysis

The book shows a lamentable ignorance of the two widespread uses of functional analysis, and the methods related to each. The uses I am referring to are firstly, in problem domain capture and validation of requirements, and secondly, in functional design. This ignorance first becomes apparent in “What is a System” on page 2, and is compounded in Chapter 2, where requirements analysis and design are treated as synonymous. The illustrations of the design application of functional analysis are unconvincing, with, for example, events e.g. “aircraft lands” muddled up with functions e.g. “conduct refuelling” – page 70.

The consequence of this muddled thinking are likely to be severe – poorly defined and unvalidated user requirements, and no conduct whatsoever, as the recipient of requirements, of requirements analysis (the analysis of requirements) to ensure that they are adequate. With requirements problems demonstrably the single biggest cause of project failures and other problems, the book makes an unfortunate contribution to continuation of this unsatisfactory but avoidable situation.

The book adds further confusion by contradictory coverage of function between Chapters 1 and 2. Chapter 1 represents a functional view of a system as just functional requirements, and a physical view as a set of components. This is not in itself wrong, but it omits the functional view that is so fundamental to the engineering of complex systems, namely the functional design view. Chapter 2, however, contains a basic description of decomposition of functions to allocatable, solution-level functions, which is, of course a functional design view of the system. The whole relationship between problem and solution, however, is very, very poorly explained in the book. Statements like “system requirements analysis therefore represents the core of the functional design activities” can only cause confusion followed by project disasters. If “requirements analysis” means “design”, what words are available to describe the analysis of requirements?

7. “Requirements Breakdown Structure”

The book advocates what it calls a “requirements breakdown structure”, to become the basis of the requirements specification for the system of interest (in the book, the aircraft). I cannot imagine a less appropriate basis!

The requirements breakdown structure seems to be an invention of the authors. There would be nothing wrong with this if the structure were useful, however, the structure seems to be designed to create confusion, being a set of headings and subheadings with names of incongruous things that could have come from a mind-mapping exercise. The structure mixes up attributes (e.g. temperature), with out of boundary functions (e.g. mission), with system functions, with logical solutions (e.g. hardware functions), with out-of-boundary objects (e.g. facilities), with functions of enabling systems (e.g. training), with interfaces, with concepts (e.g. occupational health), with development function (e.g. verification), with allocations (e.g. verification responsibilities).

“Functions are allocated to the appropriate group of the RBS”. “Higher-level requirements flow down to lower-level requirements”.

The inevitable consequence of such ill-disciplined and ill-conceived mind-mapping is confusion, followed by error, followed by compromised project outcomes.

8. Confusion between MOEs and TPMs

The book muddles up the distinction between Measures of Effectiveness (MOEs) and Technical Performance Measures (TPMs). MOEs are measures of goodness of a solution beyond compliance with requirements, and are used in evaluating and selecting between feasible solution alternatives, and in design optimization. TPMs, as the book points out, are product or process measures that are selected because of their relationship to risk, for progressive measurement of accomplishment during a system development. The accomplishment is compared against a planned profile of accomplishment, giving early warning of things going wrong. Thus TPMs serve an engineering management purpose. Often TPMs are derived from key requirements for which there is risk. Thus TPMs may have no relationship to MOEs. In practice, some MOEs may also be TPMs.

The book, having appropriately defined TPMs, then goes on to muddle them up with MOEs.

This cannot help the user of the book!

9. Life Cycle Model

The life cycle model used is inappropriate and counter-productive. It is quite at odds with the recursive application of basic processes to objects at progressively lower physical levels. Despite claims in the book to the contrary, the model does not accommodate the critically important development styles of Incremental, Evolutionary and Spiral. The model is also at odds with the enormously beneficial practice of performing design of an object, at levels of abstraction of architecture and detail, the requirements on subsystems being the major product of this design activity.

The impact of this flaw on the user of the book is profound. Most practical defense projects necessitate significant amounts of incremental development, and many necessitate evolutionary development. All would benefit from application throughout the project of “spiral” (stage-based, stage-gate, risk and opportunity-driven development).

10. United States DoD Orientation

The book throughout advocates a range of poorly conceived practices having their origins in the U.S. DoD, many of which even the U.S. DoD has abandoned. Mr. Mark Shaeffer, until recently head of systems engineering in the office of the Secretary of the United States Department of Defense, stated in 2006 that the U.S. DoD had twice tried to apply systems engineering to its own business, and had twice failed.

The consequences to the user of following a book which advocates failed practices are self-evident.