Software Engineering and Engineering   (papers)
The NATO Conferences of 1968 and 1969 were motivated by the belief that software development should be "based on the types of theoretical foundations and practical disciplines that are traditional in the established branches of engineering." Surprisingly the conferences did not discuss what these foundations and disciplines were, or how they could be emulated. There has been little discussion of this topic in the intervening forty years and more. Some important lessons have been neglected.

Problem Frames   (papers)
Problem frames characterise classes of simple problems. They are based on analysis and structuring of the requirement and of the environment in which the requirement is located, and can help to identify issues and difficulties. Individually, problem frames are too simple to fit any realistic problem. But realistic problems are compositions of elementary problems. Practical problem analysis and structuring is based on recognising the elementary subproblems of which a realistic problem is composed, and the concerns that must be addressed to solve each subproblem.

Problem Frame Composition   (papers)
The composition of subproblems itself raises fresh issues and difficulties, both in analysing problems and in constructing solutions. Identifying these difficulties, and developing a standard repertoire of techniques to overcome them, is the classic process by which traditional engineering disciplines and their products become mature and reliable. This process depends on a high degree of specialisation.

Relating Problems and Solutions   (papers)
Problem frames bring together requirements concerns and software structure concerns at a useful intermediate level of abstraction and granularity. Each problem frame has essentially three parts: a problem domains part, corresponding to the part of the world where the problem is located; a requirement part, corresponding to the behaviour that the customer demands in the problem domain; and a machine part, corresponding to the software/hardware machine that will ensure that the requirement is satisfied. Software architecture, or solution structuring, can take as its starting point the need to compose subproblem machines.

Extending the Problem Frames Approach   (papers)
The basic ideas of problem frames can be extended in a number of directions. One is into the structuring of socio-technical systems. Another is to consider specialisations of the machine. The machine in a problem is usually supposed to be a general-purpose computer with no special properties. Instead we may specialise the problem frame by preselecting at the outset a particular class of behaviour (for example, reactiveness, in which the machine returns to a quiescent state before handling the next input), or a particular architecture (such as pipe-and-filter or blackboard). Preselecting a behaviour class can lighten the burden of requirement description. Preselecting an architecture (elaborating the problem frame into an AFrame) pairs problem and solution in a way that is characteristic of established engineering branches.

Requirements and Specifications   (papers)
Description is the fundamental activity in software development, especially in requirements and specifications. But it has received surprisingly little explicit attention from researchers and practitioners in the field. Important concerns in description include: the choice of phenomena to provide the ground terms of a description; distinguishing definition from description; distinguishing given properties of the environment from the properties to be imposed by the machine to be built; and the simple but often ignored need to distinguish the machine to be built from the environment or problem world. I have worked on this topic since about 1984. It formed a significant part of the earlier work with Pamela Zave on specifying telecommunications systems. The beginnings of many of the ideas I have worked on are presented in my book Software Requirements & Specifications.

Telecommunications System Architecture   (papers)
I worked for a dozen years (until 2002) with Pamela Zave of AT&T Research on specifying telecommunications systems. This work resulted in the Distributed Feature Composition (DFC) abstract architecture for specifying systems in a modular way that addresses the feature interaction problem effectively. The approach has now been used in commercial products, and is the subject of several patents. Pamela continues to work on deepening and extending the DFC ideas.

Information System Development   (papers)
From the late 1970s to the second half of the 1980s I worked with John Cameron and others on the JSD Method of analysis and design for information systems. The method is based on separating the construction of a model (for example, in a database) of the real world from the construction of the information functions that extract and display the necessary information from the model. The model focuses chiefly on the behaviours of real-world entities over their lifetimes, representing each entity as one or more sequential processes: the local variables of these processes form the data part of the model of the entity. The method is described in my book System Development.

Sequential Program Design   (papers)
From the mid-1960s to the late 1970s I worked with Barry Dwyer, Brian Boulter and other colleagues on the JSP Method of program design. The method bases the program's structure on the structures of its input and output streams. Because the notion of a stream fits any ordered set of messages or records, the method is quite widely applicable. It can be applied, for example, to a sequence of calls of a procedure, and to a sequence of interrupts received by an interrupt handler. Two very effective parts of the method are a systematic way of dealing with structure clashes and a transformation that allows a process to be easily cast in the form either of a 'main program' or of a stateful procedure to produce or consume records of a stream. The method is described in my book Principles of Program Design.