Michael Jackson, Independent Consultant, UK
Problem frames

Abstract. This short talk explains a particular view of software development and its relationship to the notion of a problem frame. This view is based on certain principles: a sharp focus on the phenomena of the problem world; a problem decomposition approach guided by a corpus of known problem classes into which identified subproblems must fall; and an untraditional separation of subproblem concerns from concerns arising from the interactions among subproblems.

Presentation

Neil Maiden, City University, London
Rethinking patterns - the good, the bad and the beautiful

Presentation   Presentation in black and white

Anthony Hall, Praxis Critical Systems, UK
Software requirements are system requirements

Paper   Presentation

Abstract. Requirements engineering principles and practice are equally applicable to systems engineering and software engineering.There is,however,a belief among systems engineers and software engineers that the others 'discipline is irrelevant or even contradictory.This belief is harmful.Each discipline can learn from the other when doing requirements engineering.

Alistair Sutcliffe UMIST, UK
On the inevitable intertwining of system and software requirements

Paper   Presentation

Martin Glinz, University of Zurich, Switzerland
Why decomposition and abstraction matters in requirements engineering

Abstract. After some remarks about abstraction and decomposition in general, I will argue that hierarchical (whole-part) decomposition, using information hiding criteria, is vital for mastering large requirements models. However, hierarchical decomposition has been neglected so far in object-oriented requirements specification. I will briefly demonstrate the difficulties of decomposing class models and show how the problems can be solved when using models of abstract objects instead of classes. Finally, I will discuss some problems that come along with decomposition.

Presentation

Betty Cheng, Michigan State University, USA
Integrating informal and formal approaches to requirements engineering

Abstract. Studies have shown that errors are most likely to be introduced in the requirements phase of a development effort. This problem is largely due to prose descriptions that are ambiguous or inconsistent. One potential solution to this problem is to capture requirements information in the form of formal specifications that can be checked for consistency and completeness using automated techniques. However, during the initial phases of a project, it may be difficult to construct formal specifications directly. In contrast, many developers find it more intuitive to create diagrams to model their systems. As a means to bridge the gap between formal and informal approaches to software development, we have developed a general framework for formalizing a commonly used object-oriented modeling notation, Unified Modeling Language (UML). The formalization of UML enables the automated generation of formal specifications of the diagrams that can then be analyzed using simulation and model checking. In addition, it is important for there to be some type of interpretation of the analysis of data via visualizations. These visualizations can be in the form of direct feedback in terms of the original UML diagrams, or they can be newly generated visual representations, such as report-based documents or additional UML diagrams. This entire requirements engineering process, that is, diagram construction, specification generation, and visualization, must be supported by tools in order to enable an efficient development process. We have applied the framework to a number of industrial case studies from the automotive and information systems domains.

Presentation

Colin Potts, Georgia Institute of Technology, USA
All a requirements engineer ever wanted to know about cognitive linguistics (but was afraid to ask)

Presentation

Dan Berry, University of Waterloo, Canada
Natural language and requirements engineering - nu?

Abstract. I argue that RE is where the formal meets the informal. I argue that it is inevitable that natural language be used for requirements. I discuss the the tradeoff between natural language and formal languages in ambiguity and readability. I argue that the traditional approach of solving this problem by trying to get everybody to be formal is doomed, that we should focus instead on doing a better job in natural languages.

Presentation