Our Blog Excerpts Savings Contact


Dorset House Publishing
High-Quality Books on Software Engineering and Management.  Since 1984.
dorsethouse.com > features
Features       Excerpts       Interviews


iDH Sign-Up

Get Our e-News
Delivered by FeedBurner


by Derek J. Hatley and Imtiaz Pirbhai

Adapted from Strategies for Real-Time System Specification. Reprinted by permission. All rights reserved. See below for copyright notice.

For more than a decade, there has been growing dissatisfaction with conventional strategies for systems development, and an increasing number of proposals for replacing them with new, more formal approaches. The problem is that conventional development methods cannot cope with the size and complexity of the systems we are now able to implement. These system characteristics are possible because of the ever-increasing capacity and capability of computer hardware. Systems having up to a million lines of high-order source code are already commonplace, and others are on the horizon that will require ten or more times that amount.

The inadequacies of the development methods were first apparent in large business and commercial systems, but as digital technology came into use in real-time embedded systems, they too became subject to the same problems. We are past the stage of wondering whether formal development methods are really needed. The question is, Can we keep pace with the capabilities of the technology using the methods we already have? What further extensions and improvements can we make to them? Can we devise better and more comprehensive methods?

A problem with past system specification methods has been that they each tend to address only one aspect of the system, whereas systems actually have many aspects, all of which need to be addressed. The methods described in this book seek to overcome this problem by addressing a number of these aspects in an integrated manner. From the functional requirements point of view, they address the aspects of processing, control, and timing. From the physical requirements point of view, they address the architectural specification of the system, and most importantly, they take account of the hierarchical and iterative nature of systems and of systems development. Figure 1.1 illustrates how the whole universe may be thought of as a hierarchy of systems. Any individual system may itself be expressed as such a hierarchy, and the progression down through its levels involves defining the requirements for the level below, then making decisions on the architecture or design of that level to meet those requirements, then repeating this procedure for the next level down, and so on. This perspective makes clear the adage that one person's requirements are another person's design: a cause of considerable confusion in earlier development methods, but an integral part of the methods addressed here.

Before we delve into the details of the methods, we will give a brief historical account of their development. This will help you understand the situations that create the need for such methods, and will give you some insight into what it might take to introduce them into your own organization.

1.1 The Birth of the Requirements Model

The requirements specification model described in this book evolved at a major avionics systems development company. This evolution started in late 1982, and culminated two years later in the successful Federal Aviation Administration certification of a complex real-time, embedded avionics system for a commercial airliner. The system is now in widespread use in the airline industry.

At the time, the development effort was the largest we had ever undertaken. Previously, we had been without formal procedures for integrating the efforts of our system and software developers: We had depended on their individual communications with each other, and on the abilities of a few overworked lead engineers, in order to keep the various subsystems consistent.

There comes a point at which this just won't do, a point at which the interactions between the subsystems are at least as complex as the subsystems themselves. Faced with this dilemma, and with the very real threat of a major disaster if we did not improve our performance, we investigated the formal development methods that already existed. We found a fairly mature set of methods that had been developed in the 1970s for large mainframe business applications, and that had been successfully applied in that field.

Several of the existing requirements definition methods were capable of representing the information processing parts of our systems, but they could not handle the complex control structures that large real-time systems also typically include. Since these control structures can be represented using finite state machinery theory, we decided that we needed to integrate an established requirements definition method with finite state machine theory in a unified structure, and to do it so as to retain the benefits of both.

The requirements definition method that seemed to have the most merit was DeMarco's structured analysis [4], so we chose this as the starting point. One of the greatest merits of the DeMarco method is its attention to human readability and understandability through the use of graphics. In addition, it shares with most other requirements definition methods the attributes of information abstraction, built-in self-consistency checking, and the ability to be self-indexing.

Because the project was already underway, we needed a requirements definition method immediately. During just two weeks of brainstorming and trial and error, we found the approach we were looking for—a way to partition a large finite state machine into pieces corresponding to the pieces of a structured analysis—and the requirements model described in this book was born. One week later, a group of development engineers took the first class in the new method. That first teaching effort was not a polished presentation, but the substance was there. As we gained experience in its use, we made some further improvements in our emerging method, but, surprisingly, it has never needed any fundamental changes.

The existing and widely used structured design method [11,19] was applicable (with very little modification) to the design definition of our real-time systems.

Introducing the model

The approach we took to introduce our new methods was contrary to that advocated by methods experts, who advise that methods be introduced on a small, low-visibility project. We did not have (and have never had) such a project, and in fact introduced the method on the largest, most critical project we had ever undertaken. To offset the risks in this situation, we established a Methods Team—a group of six people whose sole role was to make the methods work. The team members prepared and taught classes, provided consultation, solved problems as they arose, made improvements to the methods, and investigated ways to automate them.

If critical projects are the only kind your shop, too, ever has to work on, and you are about to introduce revolutionary new development methods, we recommend this approach of dedicating a team to support them.

It would be misleading to suggest that the requirements and design definition methods alone were responsible for the success of the project. We made a number of other changes at the same time: For example, a large scientific computer was dedicated to the project; each system and software engineer was provided with an interactive terminal; an efficient, modular working environment was installed; we scaled the project using the Putnam model [15]; and we used a more detailed and comprehensive progress tracking procedure than we had ever used before. The relative contributions of the individual factors are hard to judge, but their combined effect was greatly improved productivity.

One of the earliest decisions made with regard to the requirements model was to make it freely available to anyone wishing to use it, rather than to copyright it, or treat it as proprietary information. Our rationale was first, that our business is avionics, not development methods; second, that it would be to our advantage to have the rest of the industry follow our lead; and further, that it would be particularly advantageous to have automated tool developers embed our methods in their tools. As a result of this early decision (and because of the success of the requirements model in its first application), the method has become widespread in the industry. Many diverse companies are using it, and there are currently at least six automated CASE tool developers [21] supporting it (some more completely than others—we neither endorse nor recommend against these or any other CASE tools; you must evaluate them relative to your own needs and environment). In addition, there are seminars [20] available giving instruction in the use of both the requirements and the architecture models'. This popularity has given rise to constant demands for more available information on the method, and those demands provided our principal motivation for writing this book.

1.2 The Birth of the Architecture Model

While this change in approach to the development of one major avionics system was taking place, the airframe manufacturer that needed the system was wrestling with an even broader problem—that of multiple system integration. Because land-, sea-, air-, and space-based vehicles are now filled with complex interacting systems, the problems of handling this complexity have moved up a level from subsystems within a system to systems within a vehicle.

The issues at this level have a different nature, however. The total vehicle with all its embedded systems may be considered to be one supersystem. The power of modern technology can allow unconventional partitionings of this supersystem. Many previously separate functions might be included in one system, or functions that traditionally have been performed by analog processing might now be done digitally. The resulting systems must fit into a well-defined physical structure, interconnected by communication buses with rigid protocols, and they must meet many requirements beyond their basic functionality, such as safety, reliability, and maintainability. Frequently, the systems will be developed by different contractors, so the issue of precise interface definition becomes paramount.

This scenario, in which functional requirements at one level must be rigorously allocated to a physical structure with nonfunctional requirements added, gave rise to the architecture model, described in Parts IV and V.

1.3 Compatibility of the Models

The requirements and architecture models complement each other well. Processes in the requirements model can be allocated to slots in the architecture model, and this procedure can be repeated many times over going down through increasing levels of detail. Similarly, in the upward direction, the vehicle itself may be considered to be just one system within a network of systems, such as the air traffic control for a region. Again, the functional requirements for this larger system may be defined using the requirements model, and then allocated to the physical communications network using the architecture model. This leveled repetition of functional requirements definition, followed by physical allocation, is fundamental to the nature of large systems development.

1.4 Applicability of the Models

Although the methods were developed around avionics systems, the technology explosion has reached all areas of the industry, and systems of unprecedented complexity are appearing in manufacturing, process control, and even in the very business applications in which the original methods were first applied. The methods described in this book are applicable in any of these areas, and indeed have gained acceptance in applications including communications, instrumentation, medical systems, process control, and military systems. The need for the methods is much more a function of size and complexity than of application area.

1.5 The System Life Cycle

Before studying the requirements and architecture methods, we must understand what purpose they serve. One way to illustrate this is to look at what the methods do and where they fit in the total system life cycle. This is shown in Figure 1.2 in which the development levels correspond to the hierarchical levels of Figure 1.1.

The figure illustrates that the requirements and architecture models apply throughout all levels of systems development and both are applied at each level. A set of requirements is generated at a given level, using the requirements model. These requirements are allocated to physical units or modules using the architecture model. The requirements for each unit are then expanded to more detail, and the whole process is repeated at the next level.

Of course, most projects will only deal with perhaps one or two of these iterative cycles, but on the other hand, most projects fit into a larger picture—they may be part of a complete aircraft, or of a manufacturing plant, or of a communication network—in which many more cycles will occur. It is good to have an understanding of the larger framework in which your project fits.

The final level, at which implementation is to take place, may require modification to the architecture model, or may require a language-dependent representation (Ada PDL, for example), depending on the language or implementation needs.

While we do not address testing activities in this book, we have found that structured development proves to be very beneficial in this area. Having the system defined both functionally and physically in a layered hierarchy of processes and units leads to a similar organization of the test procedures. The testing can proceed very methodically from the bottom up, verifying the functionality and the structure at each level up to the top.

Some caveats

Some key points illustrated in Figure 1.2 need to be emphasized:

The life cycle does not end at the point of system delivery, as is so often implied: It continues on into the service phase, usually for much longer than the development and build phases. It is customary for modifications and upgrades to occur while the system is in service. This is illustrated in Figure 1.2 via the loop from System in Service through Deploy System and Field Issues and back to the development cycle. These changes, together with the system maintenance cost, can make the cost during the service much higher than during development. The benefits of formal methods are most obvious at the development phase, but in fact, their benefits can be multiplied many times over during the service phase because of the ease with which changes can be made after the original developers are gone.

Contrary again to common misconceptions, the development does not occur in simple sequential steps. There is extensive overlap, feedforward, and feedback between each phase and its neighbors. The process is, in fact, iterative, both within each phase and over multiple phases. The requirements and architecture models record their respective definitions regardless of the order in which they are done. As we shall show in the chapters that follow, everything is traceable between levels and between phases so risk of confusion due to iterative updates is minimized.

In large, software-intensive systems, the activities of defining the requirements, the architecture, and the hardware and software design are (or should be) much more extensive than the actual implementation. In fact, with the advent of tools that will generate code automatically from requirements statements, we are rapidly approaching the point at which, for all intents and purposes, the definition is the implementation. The two methods exist specifically to support this front-end definition activity.

Systems themselves, and the process of developing them, are leveled hierarchies. In the extreme, we can consider the whole universe, the elementary particles of which it is composed, and every structure in between, as one huge leveled hierarchy of systems, as was shown in Figure 1.1. The particular systems in which we are interested fall somewhere in this range, and the points we choose to call "top level" and "implementation" are quite arbitrary. This perspective makes it clear why there is so much confusion over the definitions of "requirements" and "design." The fact is that one person's requirement is another person's design, depending on the particular interests of those people relative to hierarchy. The methods exactly reflect this hierarchical nature of large systems.

AddThis Social Bookmark Button




COPYRIGHT NOTICE: This excerpt from Strategies for Real-Time System Specification [ISBN:0-932633-11-0] appears by permission of Dorset House Publishing. Copyright © 1988 by Derek J. Hatley and Imtiaz Pirbhai. All rights reserved. See http://www.dorsethouse.com/books/strat.html. The material contained in this file may be shared for noncommercial purposes only, nonexclusively, provided that this Copyright Notice always appears with it. This material may not be combined with advertisements, online or in print, without explicit permission from Dorset House Publishing. For copies of the printed book or for permissions, contact Dorset House Publishing, 1-800-342-6657, 212-620-4053, http://www.dorsethouse.com, info@dorsethouse.com, New: 3143 Broadway, Suite 2B, New York, NY 10027 USA. Additional rights limitations apply, as presented in the Legal Disclaimer posted at http://www.dorsethouse.com/legal.html.



New:3143 Broadway, Suite 2B  New York, New York 10027  USA
1-800-DH-BOOKS or 212-620-4053, fax 212-727-1044
Copyright © 1996-2008 by Dorset House Publishing Co., Inc. All rights reserved.
Home | Blog | Savings | Stores | Features | Titles | Authors | Subjects | Orders | About | Contact | Legal