This paper presents an overview of the field of software systems requirements engineering (RE). It describes the main areas of RE practice, and highlights some key open research issues for the future. 1

A dynamic system is one which changes its configuration as it runs. It is a system into which we can drop new components which then cooperate with the existing ones. Such systems are necessarily built from reusable components, since as soon as the system is reconfigured to use some new components, those new components must reuse the existing, still running, ones. Design of reusable components in this context is an important problem. We suggest three laws which such reusable components might be required to obey, if dynamic systems are to be effective and to be economically built. We illustrate our conjecture that the laws are effective by describing a generic architecture based on the familiar registry services of OLE or CORBA and by describing a simple point-of-sale system built according to this architecture. We conclude, of course, that some interesting open questions remain. But we suggest that an approach to reuse based on refining the three laws is a promising direction for system...

We reconsider the concept of specification in order to bring new insights into the debate of formal versus non-formal methods in computer science. In our view, the correctness of a useful program corresponds to an objective fact, which must have a simple, precise, and understandable formulation. As a consequence, a specification can (and must) only make precise the link existing between the program (formality) and its purpose (informality). Moreover, program correctness can be argued only by means of non-formal reasonings, which should be as explicit as possible. This allows us to explain why specifications cannot be written in a strictly formal language. Our view of specifications does not imply a rejection of all ideas put forward in the literature on formal methods. On the contrary, we agree with the proponents of formal methods on most of their arguments, except on those following from the assumption that specifications could (or should) be formal. Finally, we examine why...

A dynamic system is one that changes its configuration as it runs. It is a system into which we can drop new components that then cooperate with the existing ones. We are concerned with formally defining architectures for such systems and with realistically validating designs for applications that run on those architectures. We describe a generic architecture based on the familiar registry services of CORBA, DCOM and Jini. We illustrate this architecture by formally describing a simple point-of-sale system built according to this architecture. We then look at the sorts of global properties that a designer of applications would wish a robust system to have and discuss variations on the architecture which make validation of applications more practical. Keywords Architecture Modelling, Dynamic Systems, Reconfigurable Systems, Formal Models, Validation 1

The way we have come to expect computer systems to behave is that we can simply add a new component to a running system and then this new component will begin to interwork with the running system without interuption of service. Describing and validating such systems of dynamic, reconfigurable components presents a challenge for contemporary methods of formal description. Milner's pi-calculus goes some way towards addressing this issue. In this short paper we show that the pi-calculus is particularly good at describing the behaviour of components of a distributed system. We give a pragmatic introduction to the picalculus and illustrate this conjecture, using an example of clients and servers collaborating on the Web. The formalisation gives us the capability to define distributable components and to formulate properties of systems built from such components. The formalisation is different from, and probably complementary to, object-oriented formulations of such components. We describe h...

Abstract. In earlier work, we have introduced Secure Tropos, a requirements engineering methodology that extends the Tropos methodology and is intended for the design and analysis of security requirements. This paper briefly recaps the concepts proposed for capturing security aspects, and presents an implemented graphical CASE tool that supports the Secure Tropos methodology. Specifically, the tool supports the creation of Secure Tropos models, their translation to formal specifications, as well as the analysis of these specifications to ensure that they comply with specific security properties. Apart from presenting the tool, the paper also presents a two-tier evaluation consisting of two case studies and an experimental evaluation of the tool’s scalability.

This paper describes RolEnact: a process-modelling notation used to provide enactable models of process instances. The paper shows how RolEnact models may be produced which are equivalent to role activity diagrams (RADs). This allows the modeller to describe processes in a notation (RADs); which can be understood both by process consultants and process users, whilst retaining the ability to generate enactable process scenarios. # 1998 Elsevier Science B.V. Keywords: Business process modelling; Role-based models; Role activity diagram; Enaction; Condition--action models 1. Introduction The focus of this paper is the use of notations and tools to improve business processes. However, in describing approaches to business process modelling it is difficult to ignore the impact which software process modelling and the study of software process has had upon the discipline [1]. Many of the notations and tools used for business process modelling were originally developed for study of the soft...

Formal methods are a nice idea, but the size and complexity of real systems means that they are impractical. We propose that a reasonable alternative to attempting to specify and verify the system in its entirety is to build and evaluate an abstract model(s) of aspects of the system that are perceived as important. Using a model will not provide proof of the system, but it can help to find shortcomings and errors at an early stage. Executing the model should also give a measure of confidence in the final product. Many systems today are built from communicating components so that the task of the developers is becoming fitting these components together to form the required system. We show how a formal model can be sympathetic to this type of architecture using our tool, RolEnact and explain how this may be related to a COM implementation. 1 Introduction Nobody would deny that widespread use of formal methods in software development would lead to a great improvement in quality and reli...

Abstract.. Using formal languages to specify system requirements guarantees the correctness of systems specifications. However, having correct specifications does not guarantee such specification matching user requirements. To guarantee such matching, users are required to validate formal specifications. This is a difficult task because, usually, users are unaware of notations. This work focus on this problem, in particular the validation of formal specifications of complex coordinated systems. To make the user’s validation easier, a new graphic technique to represent the dependencies in a coordinated environment is proposed. This graphic (and visual) technique increases users ’ understanding whilst lack of precisions is avoided. In fact, the proposed graphics correspond with visual representations of formal Maude specifications. Besides, taking advantage of the features of Maude, the system simulation is supported by the execution of Maude specifications. Thus, users are allowed to check whether the system produces the expected results. 1.

Advances in computer science have enabled the development of more and more complex systems. One of the most powerful tools to manage these systems is coordination models and languages. However, a serious limitation of these models, with regard to their usability, is that they do not provide support to manage the coordination constraints from the early stages in the software life cycle. Indeed, while these models provide suitable support to structure the applications giving a separate treatment to coordination patterns and functional components at the implementation phase, they provide little support to deal with adequate treatment of such concerns in the requirements definition. Coordination models should be encompassing a methodology supporting the separation of concerns throughout the whole software development process. An example of such methodology is presented in this paper providing a graphic technique, a method of generating formal interpretable specifications for the reproduction of coordinated environments and an accordance checker to verify the system formal representation with regard to the graphic one. The method is based on the use of the formal language Maude (as a simulation tool) and Coordinated Roles as a coordination model.