Requirements analysis includes a preliminary acquisition step where a global model for the specification of the system and its environment is elaborated. This model, called requirements model, involves concepts that are currently not supported by existing formal specification languages, such as goals to be achieved, agents to be assigned, alternatives to be negotiated, etc. The paper presents an approach to requirements acquisition which is driven by such higher-level concepts. Requirements models are acquired as instances of a conceptual meta-model. The latter can be represented as a graph where each node captures an abstraction such as, e.g., goal, action, agent, entity, or event, and where the edges capture semantic links between such abstractions. Well-formedness properties on nodes and links constrain their instances - that is, elements of requirements models. Requirements acquisition processes then correspond to particular ways of traversing the meta-model graph to acquire approp...

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 engineering to be successfully completed.

Abstract. Requirements engineering is concerned with the identification of high-level goals to be achieved by the system envisioned, the refinement of such goals, the operationalization of goals into services and constraints, and the assignment of responsibilities for the resulting requirements to agents such as humans, devices and programs. Goal refinement and operationalization is a complex process which is not well supported by current requirements engineering technology. Ideally some form of formal support should be provided, but formal methods are difficult and costly to apply at this stage. This paper presents an approach to goal refinement and operationalization which is aimed at providing constructive formal support while hiding the underlying mathematics. The principle is to reuse generic refinement patterns from a library structured according to strengthening/weakening relationships among patterns. The patterns are once for all proved correct and complete. They can be used for guiding the refinement process or for pointing out missing elements in a refinement. The cost inherent to the use of a formal method is thus reduced significantly. Tactics are proposed to the requirements engineer for grounding pattern selection on semantic criteria. The approach is discussed in the context of the multi-paradigm language used in the KAOS method; this language has an external semantic net layer for capturing goals, constraints, agents, objects and actions together with their links, and an inner formal assertion layer that includes a real-time temporal logic for the specification of goals and constraints. Some frequent refinement patterns are highlighted and illustrated through a variety of examples. The general principle is somewhat similar in spirit to the increasingly popular idea of design patterns, although it is grounded on a formal framework here. Keywords: Goal-driven requirements engineering, refinement,

Current research in specifications is emphasizing the practical use of formal specifications in program design. One way to encourage their use in practice is to provide specification languages that are accessible to both designers and programmers. With this goal in mind, the Larch family of formal specification languages has evolved to support a two-tiered approach to writing specifications. This approach separates the specification of state transformations and programming language dependen-cies from the specification of underlying abstractions. Thus, each member of the Larch family has a subset derived from a programming language and another subset independent of any programming languages. We call the former interface languages, and the latter the Larch Shared Language. This paper focuses on Larch interface language specifications. Through examples, we illustrate some salient features of Larch/CLU, a Larch interface language for the programming language CLU. We give an example of writing an interface specification following the two-tiered approach and discuss in detail issues involved in writing interface specifications and their interaction with their Shared Language components.

When a complex system is to be realized as a combination of interacting components, development of those components should commence from a specification of the behavior required of the composite system. A separate specification should be used to describe the decomposition of that system into components The first phase of implementation from a specification in this style is the derivation of the individual component behaviors implied by these specifications. The virtues of this approach to specification are expounded, and specification language features that are supportive of it are presented. It is shown how these are incorporated in the specification language Gist, which our group has developed. These issues are illustrated in a development of a controller for elevators serving passengers in a multistory building.

The success of large software engineering projects depends critically on the specification, which must represent the requirements of a large number of people with widely differing perspectives. Conventional approaches to software engineering do not address the process of identifying and integrating these perspectives, but instead concentrate on the maintenance of a single consistent description. This results in a specification which represents only one point of view, often the analyst's, excluding suggestions which do not fit with this view. The processes which led to the adoption of this point of view will go unrecorded, making any rationale attached to such a specification incomplete. Other participants will not be able to validate it properly, as it does not relate to their requirements. This thesis integrates ideas drawn from the study of knowledge acquisition, computer-supported co-operative work and negotiation into a model of the specification activity which allows the capture ...

Formal specifications have been a focus of software engineering research for many years and have been applied in a wide variety of settings. Their industrial use is still limited but has been steadily growing. After recalling the essence, role, usage, and pitfalls of formal specification, the paper reviews the main specification paradigms to date and discuss their evaluation criteria. It then provides a brief assessment of the current strengths and weaknesses of today's formal specification technology. This provides a basis for formulating a number of requirements for formal specification to become a core software engineering activity in the future.

The potential of the action-oriented paradigm has been explored in the development of a new specification language DisCo, which can be characterized as both action-oriented and object-oriented. Its possibilities are introduced by contrasting them to the more familiar process-oriented approaches. Its execution model is state-based and leads to direct application of temporal logic in formal reasoning. Action-orientation allows a natural support for such forms of modularity that cut across process boundaries. At the same time, process-oriented abstractions are retained by object-orientation and the use of hierarchical statechart structures. The novel aspects of modularity are illustrated by a protocol example. The language is semi-executable, with properties that prevent automatic code generation in the general case. An experimental environment is available for simulation and animation of specifications. Keywords: executable specifications, inheritance, joint action systems, modularity, ...

Early performance estimates for a new software system aid the design process by providing feedback when design decisions can be easily revised. Unfortunately, constructing a performance model of a distributed and concurrent software system can require significant effort. An automated performance model generation technique is described that reduces the model building effort by providing: easy specification of performance experiments, empirical estimates for model parameters, automated model generation, and support for different types of models. A prototype is used to describe a software system, from which causal traces (angio traces) are recorded during execution. These traces are then processed into sequences of resource demands (workthreads), aggregated into system execution descriptions (workthread classes), and combined to generate a performance model. The technique can also be applied at other stages of the development process, including the redesign of existing software. Page ii...

this paper and in Reference 3, the simulator/assertion checker responds to single-step commands from the user in real-time