Among systems engineers, this book is now known as "the green book", which may give you some idea of its enduring appeal.

In contrast to books such as Kotonya and Sommerville's Requirements Engineering, Stevens' Systems Engineering looks at the place of requirements in a world which consists of complex systems in a highly competitive marketplace. This may be the commercial world or equally the military-industrial world in which systems must literally do battle with their rivals.

Stevens and his co-authors (two of them from the UK's Defence Evaluation and Research Agency) know that in this environment, many systems fail, very often because they were inadequately thought out, and often also because their development projects were poorly managed. Chapter 1 begins "The world is currently gripped by changes more intense and rapid than those triggered by the ndustrial revolution..." : we are at once swept into the rich, complex, and dangerous life of real system development.

For Stevens, the problem in systems engineering is (Herbert Simon style) complexity, and its mastery is, as the subtitle implies, the key to success. The design of complex systems demands hierarchy - of organisations, of projects, of contracts, of documents. Hierarchy implies interfaces: if you split a system into three, you probably create three interfaces between the component subsystems. Interfaces in turn imply specialisation: someone develops the hardware; someone else, the software. Similarly, someone (the customer) writes the requirements specification, while someone else (the developer) tries to meet those requirements. This, like the prime contractor - subcontractor relationship, consists of a customer and a supplier: the marketplace reaches right into the core of system engineering.

The book therefore covers a startling breadth of subjects, but always with the same practical vision and with the same conceptual tools. The first few chapters broadly follow the European Space Agency's now-classical PSS-05 software engineering standard life-cycle phases: user requirements, system requirements, architectural design, integration (of subsystems) and verification, management.

(Requirements are involved in every one of these phases.) Once the reader is grounded in the basics, the next chapter discusses how to tailor the simple life-cycle just presented. A tell-tale section entitled 'smaller systems' gives the game away: the systems in the authors' minds are a great deal larger than the PC 'systems' beloved of advertising copywriters.

The second part of the book (chapter 8 onwards) starts by looking at more realistic life-cycles, based on the management of risk: when is it sensible to go ahead with something? The answer is, when success can be assured even if the bad risks materialize. That can only be guaranteed if the risks have been quantified. Concepts of requirement priority and benefit, risk, and cost loom much larger in the marketplace than technical issues.

The remaining chapters examine management in multi-level projects (hierarchy again), software and systems, prototyping (to control risk), information modeling, projects and the enterprise, a chapter on how to improve and a summary.

Each chapter consists of a double-page title/table of contents, overlaid on some crisp pencil artwork on the theme of engineering progress (from Leonardo's hang-glider to an agile jet). The text is broken up by plenty of simple flow diagrams illustrating life-cycles, trade-offs, business processes and information models, as well as short summaries of what the most important system documents should contain. Key points are highlighted or bulleted within the text. The chapters end with a page or two of realistically tricky exercises: the answers cannot be coded in C.

The helpful appendices include a list of websites. Students will find the glossary helpful and comprehensive. There is an extensive list of very varied references, and a detailed index.

This book is a carefully worked out description of the process of developing any large, complex, and risky system. The book can also be read as a polemic: an impassioned plea for the discipline to graduate from its narrow roots, whether in academia or in quality control. The concluding paragraphs make it clear that system engineering is a human process, a 'game' in which there are losers as well as winners, something that can be played well, and that absolutely must be played better to limit the risks and losses that are still all too common.

Readers may feel like challenging some of the propositions in this thought-provoking account. Is it necessarily true, for instance, that firms must compete in a marketplace: what will happen if we end up with only one major aircraft manufacturer in the world, say? And is a Darwinian-capitalist worldview the only option? If it melted away like its old cold-war rival, what could we create to replace it? Whatever the reader's position, Systems Engineering is a powerfully stated argument which fills a major gap in the RE literature: all future texts will have it in mind. The role of requirements engineering within the industrial context is especially well expounded, and from a point of view that is both practical and quite unlike any other RE text. The book will be of interest to several quite different communities: in particular development managers, clients having large systems developed, and students of system and software engineering will all find much that is of interest here. The book may also be a useful supplement (or perhaps an antidote) to the academic perspective on RE. All requirements engineers should have access to a copy.

© Ian Alexander 1998, 2004, 2009

You may also like: