Steve Easterbrook

Software technology now penetrates almost every aspect of our lives in complex ways. The reality of 21st century software development is that software itself is but one part of a complex system-of-systems that includes a broad technological infrastructure along with a wide set of human activities. The technological systems and the human activity systems have a symbiotic relationship - each shapes the other in complex ways, such that neither can be understood in isolation. A recent report from the SEI on Ultra-Large Scale (ULS) Systems accurately characterized the nature of these systems-of- systems: they have no centralized control; experience normal failures and continual evolution of heterogeneous elements; and their requirements are inherently conflicting, diverse and often unknowable. For design purposes, the boundary between people and software disappears - design is as much about shaping the human activities as it is about constructing the software.

In this talk, I will argue that these challenges are now true of most software development. The engineering approaches we use today for software development only work when we take a very narrow view of the requirements, as well-defined sets of features and interfaces, which can be fully specified. This approach helps us to build components that conform (in a narrow sense) to their specifications. But we cannot tell in advance whether they will be any use in any of the many different systems-of-systems in which they may be deployed. Our engineering techniques rapidly break down when we attempt to scale up our design ambitions. The result is a growing gap between expectations and practice in the software industry. We can build very reliable software at the small scale, for tightly constrained problems. But we cannot build reliable software for complex socio- technical domains.

To make progress on these challenges we need to abandon the idea that we can write complete, consistent specifications. Instead, we need to capture the multiple, conflicting requirements for each software component that arise from its different contexts of use. We need to be able to express our partial understandings of the broader systems- of-systems in which our components will be deployed. And we need to be able to reason about the properties, and end-to-end behaviours of these systems, without resolving all the unknowns and inconsistencies in our models. I will end the talk with a survey of recent research in requirements engineering that tackles these challenges. In particular I will discuss techniques for managing large, evolving collections of fragmentary requirements models, and show how it is possible to tolerate inconsistency when we reason about the properties of these models.