Dependability of cyber-physical systems rests crucially on the fidelity of formal models to their real-world physical subject matter; yet little explicitly focused research has been devoted to this concern. This talk sketches the concern and commends it as a focus for future research in the RE community.

The proper treatment and expression of system requirements has been a topic of interest for more than twenty years. This talk proposes that they should be understood as desired properties and effects of the behaviour of the system. A discipline to support that understanding is presented, and a brief account of the principles that underpin it.

This paper reports on our experience of investigating the role of software systems in the power blackout that affected parts of the United States and Canada on 14 August 2003. Based on a detailed study of the official report on the blackout, our investigation has aimed to bring out requirements engineering lessons that can inform development practices for dependable software systems. Since the causes of failures are typically rooted in the complex structures of software systems and their world contexts, we have deployed and evaluated a framework that looks beyond the scope of software and into its physical context, directing attention to places in the system structures where failures are likely to occur. We report that (i) Problem Frames were effective in diagnosing the causes of failures and documenting the causes in a schematic and accessible way, and (ii) errors in addressing the concerns of biddable domains, model building problems, and monitoring problems had contributed to the blackout.

Abstract Software development is increasingly concerned with maintaining and extending existing software systems to meet the evolving user requirements. Many of these systems are feature‐rich and are developed incrementally. As structures of existing software systems—in addition to the user requirements—influence the specifications, specifying these systems poses unique challenges. This paper reports on our experience of applying an engineering approach to specifying an evolving feature‐rich television software system. In this approach, features are specified modularly by first fitting their problems to known problem patterns, and then analyzing typical concerns—meaning the potential causes of errors—associated with those patterns. In cases where the existing design poses difficulties when fitting problems to patterns, we transform its structure using known design mechanisms so that the problems fit the patterns. After deriving specifications of individual features, possible interactions between features are detected, before declaratively specifying resolutions to undesired interactions. As the concerns of features and their composition are addressed separately, the specifications derived are modular, thus, providing rich treaceability to their requirements. As well as discussing how features may be specified using natural language, we also show how their descriptions may be formalized using a form of temporal logic called the Event Calculus, and prove their correctness using an off‐the‐shelf tool. Copyright © 2009 John Wiley & Sons, Ltd.

In welcoming this issue of Expert Systems, I would like to take the opportunity to remark on a relationship between the problem frames approach to software engineering and some practices of established engineering branches. Common use of the phrase ‘software engineering’ dates from 1967, when a NATO Science Committee Study Group recommended the holding of a working conference by that name. The name was deliberately provocative ‘in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines that are traditional in the established branches of engineering’. The proposed conference was held in 1968, and a follow-up conference in 1969. In some respects software has made huge strides in the past 40 years, and software systems are available today that would have been scarcely thinkable in 1967. But in some other respects the original motivation of the NATO conferences has been neglected. Software development has learned remarkably little from the established branches of engineering. Indeed, their proffered lessons were ignored even in the two NATO conferences themselves: a scan of the conference reports shows that with one possible exception – Doug McIlroy's plea for standard, off-the-shelf software components – no substantial attention was paid either to their theoretical foundations or to their practical disciplines. The problem frames approach to software development could be regarded as an attempt, both in original intention and in the path taken by subsequent work on the topic, to learn at least one lesson from the established engineers. This lesson is the importance of what Walter Vincenti calls normal design. An engineer practising normal design already knows the standard form of the device or product to be designed, how its parts fit together, and the operational principle by which it will achieve its purpose. By faithfully following normal practice the engineer can have a good degree of confidence that the result will be successful. In the software context, the standard subproblem classes proposed by the problem frames approach – workpieces, information display, required behaviour and so on – can be regarded similarly, as categories of objects of normal design in which well-established and well-understood precedents can govern both the form of the product and the development practices from which it emerges. Failure is a matter to which established engineering branches pay a great deal of attention. Success comes from experience, it is said, and experience comes from failure. One vital aspect of normal design practice is a twofold approach to the avoidance of failure. First, the standard normal design itself embodies important lessons from past failures. Even when awareness of particular dramatic failures has faded in the collective consciousness of the design engineers, the design choices devised to avoid those failures remain part of the normal product design, and work to prevent a repetition. Second, normal design practice specifically includes knowledge of respects in which designs of the product class in question can still be liable to fail. For example, ever since the dramatic collapse of the Tacoma Narrows Bridge in 1940, designers of suspension bridges are very well aware of the danger of failure due to vertical oscillation of a shallow and narrow roadbed: they do not regard their design work as complete until this danger has been explicitly considered and excluded. In a similar fashion, the repertoires of subproblem and composition concerns identified in the problem frames approach point up likely possibilities of failure, and demand to be explicitly addressed as an integral part of the design work. The four papers in this journal issue relate problem frames to four very different technologies of software engineering. Each is worth careful reading in itself as an individual contribution. Further, their variety offers some confirmation that the ideas underlying the problem frames approach have a broad import, and augurs a fruitful future.

Problem Orientation is gaining interest as a way of approaching the development of software intensive systems and yet a significant example that explores its use is missing from the literature. In this paper, we present the basic elements of Problem Oriented Software Engineering (POSE) which aims to bring both non-formal and formal aspects of software development together in a single framework. We provide an example of a detailed and systematic POSE development of a software problem, that of designing the controller for a package router. The problem is drawn from the literature, but the analysis presented here is new. The aim of the example is twofold: to illustrate the main aspects of POSE and how it supports software engineering design, and to demonstrate how a non-trivial problem can be dealt with by the approach.

The established branches of engineering are characterised by a focus on the physical world and by intense specializations. These practices are already found in some areas of software engineering, but a wider and fuller adoption could be beneficial. In particular, specialisation could help in dealing with a major challenge of software engineering - with the non-formal and heterogeneous nature of the physical problem world. The interplay between the quasi-formal computing machine and the non-formal problem world has many very different manifestations, each one demanding and meriting the attention of computer scientists no less than of software engineering practitioners.

Software-intensive systems are those in which the computer executing the software is only one of the parts of the system. Problem frames offer a conceptual structure for the development of such systems: that is, a coherent way of analysing the problem to be solved, identifying the concerns and difficulties that it poses, and working towards a solution. This tutorial present the basic ideas of problem frames, illustrating them in the context of a small software-intensive system. The basic ideas of the approach are: 1. to attend both to the hardware/software machine, which is to be developed, and to the other system parts, which constitute the problem world; 2. to distinguish the given properties of the problem world from the requirements, which are the properties that the machine must establish and maintain in the world; 3. to pay careful attention to the phenomena of the problem world; 4. to structure the development problem as a set of subproblems, and to consider each subproblem in isolation before considering the composition of the subproblems and their solutions; 5. so far as possible, to recognise each subproblem as a member of a recognised class for which a solution method is known and whose most important concerns have been identified. Problem frames are not a notation or a calculus or a formalism; nor are they a development method or a process. They can fit with, into, or around specific techniques (such as agile or RUP) and specific notations (such as UML, Petri nets, or DFDs). Problem frames do not promise a prescription for every problem; nor do they promise a complete prescription for any problem. They remind you of things you know already, but may not always pay enough attention to.

A key challenge for software engineering is to learn how to reconcile the formal world of the machine and its software with the non-formal real world. In this paper, we discuss elements of problem oriented software engineering (POSE), an approach that brings both non- formal and formal aspects of software development together in a single theoretical framework for software engineering design. POSE presents development as the representation and step-wise transformation of software problems. It allows for the identification and clarification of system requirements, the understanding and structuring of the problem world, the structuring and specification of a hardware/software machine that can ensure satisfaction of the requirements in the problem world, and the construction of adequacy arguments, convincing both to developers and to customers, users and other interested parties, that the system will provide what is needed. Examples are used throughout the paper to illustrate how formal and non-formal descriptions are reconciled under POSE.

Developing a software-intensive system is engineering in the traditional sense: creating an artifact which transforms the physical world to meet some recognised need. The artifact is the hardware-software machine; the physical world is the system's environment; and the recognised need is the requirement. For a successful development the entailment must hold: "machine, environment, requirement". By formalising the requirement and relevant environment properties, we may hope to bring the whole development within the ambit of formal development methods, improving our ability to produce a machine that will reliably ensure satisfaction of the requirement. This hope is appealing, but too simple. The nature of software-intensive systems poses rich challenges that cannot be addressed by formal reasoning alone but demand sharply focused practical disciplines. Discrete complexity, proliferation of interacting features and interoperation between disparate systems must all be reconciled with high levels of reliability, safety and security, in the context of systems that combine formal software with a non-formal environment in a tight cooperation. They challenge us to evolve rigorous and effective treatments of their non-formal worlds and of the interactions of those worlds with the formal artifacts we build. Here there is much to be learned from the established branches of engineering. The most conspicuous characteristic of the established branches of engineering is their specialised nature. For each class of artifact, the creation and gradual enrichment of a particular specialism, over many years, has allowed engineers to address both the positive and the negative requirements of the class. Positive requirements embody desired system functionality and efficiency, and evolve by invention and improved technology. Negative requirements embody the avoidance or mitigation of defects and failures that have manifested themselves in the past or can be foreseen. The non-formal world furnishes unbounded possibilities of failure. Because every formalisation is in some degree incorrect or unreliable, and its alphabet inevitably excludes phenomena that may yet prove disastrously significant, negative requirements can never be exhaustively enumerated. Dependability in addressing negative requirements is improved chiefly by the experience, recognition, and analysis of failures. To avoid repeating those failures engineers need a structure of concepts and practice that allows the lessons to be recorded, disseminated, and applied. Specialisation is the sine qua non of such a structure. For each class of artifact and system it nourishes the creation and growth of a sharply focused normal design discipline, in which the design engineer knows at the outset how the system must work at every level, what features it must have, and how its parts are to be configured. Such a standardised design explicitly satisfies the positive requirements and implicitly satisfies the currently known negative requirements. Further, practice of the design discipline directs the engineer's attention to specific concerns that are known or expected to merit special care if failure is to be avoided. Specialisation and normal design have enabled the established engineering branches to deal increasingly successfully with the non-formal physical world. Software engineering must similarly identify the dimensions of specialisation that will improve system dependability. Approaches based on erecting a specification firewall to isolate the formal software world of computer science from its non-formal environment cannot succeed. In a software- intensive system, interaction at the interface between the machine and its environment darts back and forth along the arcs of a dependency graph that embraces both machine and environment, and frustrates the desire for a total separation of concerns between the formal and the non-formal. This challenge to software engineering can be met only by sharply focused specialisms practising highly developed normal design disciplines, analogous to those that characterise the established engineering branches.

Ten years ago, our paper described how a very small system might be developed to control a coin-operated turnstile in a zoo [1]. It arose out of our efforts to understand how requirements, domain knowledge and specifications fit together, and how specifications could be derived systematically. A particular goal was to understand requirements and specifications for telecommunication systems well enough to handle the feature interaction problem that plagues telecommunication software.A year later we published a more comprehensive version of our requirements framework [3], and began to develop the Distributed Feature Composition (DFC) architecture for telecommunication services [2]. We continued to work on it together until mid-2002. DFC has proven successful in practice, and is now being used in a commercial voice-over-IP service.Since publishing the requirements framework, we have worked on different kinds of system, and have been confronted with important differences in how its principles apply. It has taken all this time to achieve the goal of understanding requirements for telecommunication services and other connection services. In this domain, requirements are heavily influenced by the fact that services are assemblies of components added to a basic network infrastructure. Our work in another direction has led to a focus on system interaction with the human and physical world, recognising the varying roles of formalisation and formal reasoning in problems of different kinds, and the need for a stronger grip on the relationship between engineering of software and engineering in the world.The common lesson of these experiences is that the requirements framework of ten years ago is a good generalization, but specific domains and situations require their own specializations of it.

We are developing an approach using Jackson's Problem Frames to analyse security problems in order to determine security vulnerabilities. We introduce the notion of an anti-requirement as the requirement of a malicious user that can subvert an existing requirement. We incorporate anti-requirements into so-called abuse frames to represent the notion of a security threat imposed by malicious users in a particular problem context. We suggest how abuse frames can provide a means for bounding the scope of security problems in order to analyse security threats and derive security requirements.

Previous work in distributed feature composition architecture has shown that a modular, compositional architecture of feature logic can lead to successful management of feature interaction. It can also promote rapid deployment of new services and third party innovation in a communication network. ECLIPSE is an implementation of DFC that focuses on voice over IP (VoIP) and multimedia over IP. In ECLIPSE, the signaling messages traverse units of feature logic (feature boxes), but by necessity the media data have to take a separate and more direct path. This paper describes a scheme in which the feature boxes can cooperatively control the flow of media in an optimal path, while still maintaining the benefits of the DFC architecture. This scheme supports any desired media connectivity, and is independent of VoIP protocols (e.g. SIP and H.323), or the underlying media switch fabric implementation. This result is also applicable to other component architectures for communications. Comparison is made with other schemes proposed in the literature.

Problem frames provide a means of analyzing and decomposing problems. They emphasise the world outside of the computer, helping the developer to focus on the problem domain, instead of drifting into inventing solutions. However, even modestly complex problems can force us into detailed consideration of the architecture of the solution. This is counter to the intention of the problem frames approach, which is to delay consideration of the solution space until a good understanding of the problem is gained. We therefore extend problem frames, allowing architectural structures, services and artifacts to be considered as part of the problem domain. Through a case study, we show how this extension enhances the applicability of problem frames in permitting an architecture-based approach to software development. We conclude that, through our extension, the applicability of problem frames is extended to include domains with existing architectural support.

Distributed Feature Composition (DFC) is a new technology for feature specification and composition, based on a virtual architecture offering benefits analogous to those of a pipe-and-filter architecture. In the DFC architecture, customer calls are processed by dynamically assembled configurations of filter-like components: each component implements an applicable feature, and communicates with its neighbors by featureless internal calls that are connected by the underlying architectural substrate.

A system to be developed can be regarded as a machine in an environment. Software engineering is surely concerned with the machine - the computer and its programs. Is it also concerned with the environment? If so, to what extent and in what way? And, is this concern with the system’s environment merely a collection of disparate specialized applications such as banking, switching, or avionics? Or does it have important aspects that transcend individual applications? This talk argues that there are such transcendent aspects, and that we have paid too little attention to them. They center on the problems of formalizing the informal real world. The need for formalization merits a discipline in its own right. Elements of such a discipline are sketched, and it is claimed that this discipline must be an integral part of a full software engineering education.

An approach to problem analysis is described, based on the notion of a problem frame. Problem frames are intended to capture classes of recognisable and soluble problems. Because problems are located in the environment, not in the machine to be built, problem frames are characterised by environment properties and structures. Useful frames are necessarily very narrow: realistic problems are regarded as parallel superimpositions of subproblems. Problem complexity arises from the interactions of these subproblems and of their solutions.

In engineering the requirements for a telecommunications system, the greatest obstacle to be overcome is the sheer complexity of the required behavior. We present several ways of managing and minimizing this complexity, all of proven effectiveness. Most of the specification techniques result from specific application of general requirements principles to the telecommunications domain.

Research in requirements engineering has produced an extensive body of knowledge, but there are four areas in which the foundation of the discipline seems weak or obscure. This article shines some light in the “four dark corners,” exposing problems and proposing solutions. We show that all descriptions involved in requirements engineering should be descriptions of the environment. We show that certain control information is necessary for sound requirements engineering, and we explain the close association between domain knowledge and refinement of requirements. Together these conclusions explain the precise nature of requirements, specifications, and domain knowledge, as well as the precise nature of the relationships among them. They establish minimum standards for what information should be represented in a requirements language. They also make it possible to determine exactly what it means for requirements and engineering to be successfully completed.

Proposes a technique to help people organize and write complex specifications, exploiting the best features of several different specification languages. Z is supplemented, primarily with automata and grammars, to provide a rigorous and systematic mapping from input stimuli to convenient operations and arguments for the Z specification. Consistency analysis of the resulting specification is based on the structural rules. The technique is illustrated by two examples, a graphical human-computer interface and a telecommunications system.

As software developers we are engineers because we make useful machines.We are concerned both with the world, in which the machine serves a useful purpose, and with the machine itself.The competing demands and attractions of these two concerns must be appropriately balanced.Failure to balance them harms our work.Certainly it must take some of the blame for the gulf between researchers and practitioners in software development.To achieve proper balance we must sometimes fight against tendencies and inclinations that are deeply ingrained in our customary practices and attitudes in software development.In this paper some aspects of the relationship between the world and the machine are explored; some sources of distortion are identified; and some suggestions are put forward for maintaining a proper balance.

A requirement is a desired relationship among phenomena of the environment of a system, to be brought about by the hardware/software machine that will be constructed and installed in the environment.A specification describes machine behaviour sufficient to achieve the requirement.A specification is a restricted kind of requirement all the environment phenomena mentioned in a specitlcation are shared with the machinq the phenomena constrained by the speciilcation are controlled by the machine; and the specified constraints can be determined without reference to the future.Specflcations are derived from requirements by reasoning about the environtnen~using properties that hold independently of the behaviour of the machine.These ideas, and some associated techniques of description, are illustrated by a simple example.

Requirements, specifications, and programs are distinguished by the phenomena they concern. Requirements are about phenomena of the application domain and describe properties of the domain that the machine is required to bring about and maintain. The application domain is informal, and serious difficulties are encountered both in describing it and in reasoning about it. Requirements are complex, so they must be decomposed. Decomposition is based on the recognition of simple subproblems, characterised by problem frames.

Ideas about the meaning of descriptions, aimed at clarifying the relationship between a formal specification and the domain of the system to be specified, are introduced. Understanding of specifications must rest on explicit statements of what they are about and what they assert. The authors argue that current formal specification techniques are inadequate in this respect, and therefore cannot offer a satisfactory foundation for automated support of software development. An approach that offers a possible basis for effective reuse of descriptions generally, and of partial specifications in particular, is discussed.>

Partial specifications written in many different specification languages can be composed if they are all given semantics in the same domain, or alternatively, all translated into a common style of predicate logic. The common semantic domain must be very general, the particular semantics assigned to each specification language must be conducive to composition, and there must be some means of communication that enables specifications to build on one another. The criteria for success are that a wide variety of specification languages should be accommodated, there should be no restrictions on where boundaries between languages can be placed, and intuitive expectations of the specifier should be met.

No abstract available.

No abstract available.