****************REQUIREMENTS ENGINEERING NEWSLETTER******************** No. 36. Contents 1. Message from the Moderator! (Anthony Finkelstein) 2. RE95 Doctoral Consortium Papers 3. IFIP WG2.9 Software Requirements Engineering 1-pagers 4. RE95 Paper Abstracts 5. RENOIR: Network of Excellence in RE - A Guide to European RE Research 6. A Guided Tour through the ICARUS Project (Axel van Lamsweerde) If you have questions about particular items appearing in the newsletter - send them to the originators. If you wish to contribute send your material to: re-list@doc.ic.ac.uk (will be moderated). Subscription or Removal requests should be sent to: re-request@doc.ic.ac.uk Back issues can be obtained via anonymous ftp from ftp-host: dse.doc.ic.ac.uk (IP number: 146.169.2.20). Directory: requirements. Files are called renl1, renl2, etc. If you cannot use ftp then you can get any back issues using email. Send email containing the following to ftpmail@doc.ic.ac.uk open dse.doc.ic.ac.uk cd requirements get quit The Requirements Engineering Newsletter and its archive is also accessible through WWW. The URL is: http://web.doc.ic.ac.uk/req-eng/index.html You may wish to link any Internet software engineering information resource you maintain to this and/or notify the manager of your local Web server by passing this message on to them. If you wish your requirements or software engineering ftp archive to be linked to the RE Newsletter archive please inform me. If you are unfamiliar with WWW you may wish to obtain a copy of the Mosaic public domain internet browser which is available for X-Windows, Macintosh or Microsoft Windows. The RE Newsletter can be conveniently accessed through the Imperial College, Department of Computing, United Kingdom, WWW Home Page (http://www.doc.ic.ac.uk/). Requirements Engineering Newsletter is published solely as an educational service. Copyright (c) 1994, Anthony Finkelstein; All Rights Reserved. ********************************************************************** From: acwf@cs.city.ac.uk (Anthony Finkelstein) Subject: Message from the Moderator! First, for those of you to whom this newsletter comes as a surprise, I have taken the liberty of subscribing the attendees at RE95 who were not already recipients of this newsletter. I have in addition reconciled this list with Annie Anton's RE students list. Instructions on how to unsubscribe are given above. Mail me if you receive duplicate copies. This is a BUMPER issue with lots of real material. In addition to much usual content it includes: pointers to the papers from the RE95 Doctoral Consortium; titles and abstracts of the papers from RE95; pointers to short position statements (with references) from the key players in IFIP WG2.9 - Software Requirements Engineering; the announcement of the WWW version of the RENOIR proposal which provides a guide to RE research in Europe and links to many of the key groups in the area. I hope that everybody enjoyed RE95 as much as I did. Best wishes to John Mylopoulos and Connie Heitmeyer who are Programme Chair and General Chair of RE97. ********************************************************************** Subject: RE95 Doctoral Consortium Papers The following papers appeared in the RE95 Doctoral Consortium. They are available by ftp from dse.doc.ic.ac.uk in /requirements/doctoral. File names appear beside the papers. Supporting Social Science Input to Requirements Engineering for Safety-Critical & Cooperative Systems Stephen Viller Formally Modelling the WinWin Requirements Negotiation System Ming June Lee CUSTARD: a participatory approach to usability requirements synthesis and representation Eamonn O'Neill Cognitive Issues in Requirements Engineering Geoff Beckworth Building Traceability into Requirements Specifications Paul Richards Automating Requirements-Based Testing for Hardware Design Steve Frezza An Approach to the Control of Completeness in the LESD Project Jordi Alvarez Canal A Grounded Theory of Software Requirements Specification Quality Norah Power Usage-Oriented Requirements Engineering Bjorn Regnell ********************************************************************** Subject: IFIP WG2.9 Software Requirements Engineering 1-pagers Participants in the IFIP WG2.9 Software Requirements Engineering meeting were asked to produce a one page statement covering their interests and recent publications in RE. Many (but not all) of these are available by ftp from dse.doc.ic.ac.uk in /requirements/ifip. File names appear beside the papers. They form a very good source of references and a concise account of ongoing research. Annie Anton [USA] anton.ps Dan Berry [Israel] berry.ps Alex Borgida [USA] borgida.ps Janis Bubenko [Sweden] bubenko.ps John Dobson [UK] dobson.ps Eric Dubois [Belgium] dubois.ps Steve Easterbrook [UK] easterbrook.ps Martin Feather [USA] feather.ps OR feather-a4.ps Anthony Finkelstein [UK] finkelstein.ps Carlo Ghezzi [Italy] ghezzi.txt Michael Goedicke [Germany] goedicke.ps Orlena Gotel [UK] gotel.txt Paul Gough [UK] gough.ps Sol Greenspan [USA] greenspan.ps Hisayaki Horai [Japan] horai.ps Daniel Jackson [USA] djackson.ps Michael Jackson [UK] mjackson.ps Jeff Kramer [UK] kramer.ps Axel Van Lamsweerde [Belgium] vanlamsweerde.ps Julio Leite [Brazil] leite.ps Peri Loucopoulos [UK] loucopoulos.ps Bashar Nuseibeh [UK] nuseibeh.ps Shari Pfleeger [UK] pfleeger.txt Klaus Pohl [Germany] pohl.ps Colin Potts [USA] potts.ps Howard Reubenstein [USA] reubenstein.ps Suzanne Robertson [UK] srobertson.txt Bill Robinson [USA] robinson.ps Collette Rolland [France] rolland.txt Kevin Ryan [Ireland] ryan.txt George Spanoudakis [UK] spanoudakis.ps Alastair Sutcliffe [UK] sutcliffe.txt Jim Woodcock [UK] woodcock.ps Pamela Zave [USA] zave.ps ********************************************************************** Subject: RE95 Paper Abstracts The following papers were presented at RE95. Proceedings of the 2nd IEEE International Symposium on Requirements Engineering. March 27th-29th 1995, York, UK. IEEE CS Press. IEEE CS Press Order No: PR07017 ISBN: 0-8186-7017-7 Orders: csbooks@computer.org For convenience in obtaining supplementary information I have included email addresses of authors wherever possible. Problems and Requirements M.A. Jackson mj@doc.ic.ac.uk 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 sub-problems, characterised by problem frames. Scenarios--An Industrial Case Study and Hypermedia Enhancements P.A. Gough, F.T. Fodemski, S.A. Higgins, and S.J. Ray gough@prl.philips.co.uk A study of requirements elicitation and validation within an industrial environment is reported The key features in this part of the requirements process are: scenarios, as the prime means of elicitation; identification of domain objects, to capture the language of the domain and Fagan inspections for scenario validation by stakeholders. The process has been evaluated from both the requirements engineer s perspective and the viewpoint of the various stakeholders. The findings highlight a number of issues, both positive and negative, which are discussed. The deficiencies identified have stimulated our research. In particular, it is our contention, that requirements documentation needs to break away from the fixation with purely textual documents to ones that are media rich. Examples of this research, such as our hypermedia Scenario Manager, will be described A Task Centered Approach to Analysing Human Error Tolerance Requirements R.E. Fields, P.C. Wright, and M.D. Harrison {bob pcw mdh}@minster.york.ac. uk. In this paper we put forward an approach to deriving and applying human error tolerance requirements. Such requirements are concerned with the response of a system to errors introduced by human operators. The approach provides a means by which operators' tasks can be described and analysed for likely errors and the impact of these errors on system safety can be explored. The approach, based on previous work by the same authors, uses a software engineering notation to provide the bridge between operator models and systems engineering concerns. In this paper the approach is extended to include a more refined understanding of the processes that contribute to human error. The operators' process in achieving goals is understood in terms of structured tasks. With this additional apparatus we are able to capture a more complex set of human error forms. Presenting Ethnography in the Requirements Process J. Hughes, J. O'Brien, T. Rodden, M. Rouncefield, and l. Sommerville {soaOlO,soajeo,soaO31}@centl.1ancs.ac.uk; {tom,is)@comp.lancs.ac.uk In this paper we argue that the industrial development of interactive systems has to recognise the social dimension of work if these systems are to fully meet the real needs of their users. Under current approaches this depends on whether an individual requirements engineer implicitly applies a user-centred approach, recognises the importance of cooperation and is sufficiently sympathetic and intuitive to understand the work and reflect this in the system requirements. We wish to move beyond this by allowing for the provision of a more systematic incorporation of the social dimensions of work. To this end we focus on developing a novel approach to the presentation of ethnographic material. Our approach is based on the use of number of viewpoints and is embodied within a general hypertext tool. Improving the Use Case Driven Approach to Requirements Engineering B. Regnell, K Kimbler, and A. Wesslen bjornr@tts.lth.se This paper presents the idea of Usage Oriented Requirements Engineering, an extension of Use Case Driven Analysis. The main objective is to achieve a requirements engineering process resulting in a model which captures both functional requirements and system usage aspects in a comprehensive manner. The paper presents the basic concepts and the process of Usage Oriented Requirements Engineering, and the Synthesized Usage Model resulting from this process. The role of this model in system development, and its potential applications are also discussed. Managing Inconsistencies in an Evolving Specification S. Easterbrook and B. Nuseibeh easterbrook@cogs.susx.ac.uk; ban@doc.ic.ac.uk In an evolving specification, considerable effort is spent handling recurrent inconsistencies. Detecting and resolving inconsistencies is only part of the problem: a resolved inconsistency might not stay resolved. Frameworks in which inconsistency is tolerated help by allowing resolution to be delayed. However, evolution of a specification may affect both resolved and unresolved inconsistencies. We address these problems by explicitly recording relationships between partial specifications (ViewPoints), representing both resolved and unresolved inconsistencies. We assume that ViewPoints will often be inconsistent with one another, and we ensure that a complete work record is kept, detailing any inconsistencies that have been detected, and what actions, if any, have been taken to resolve them. The work record is then used to reason about the effects of subsequent changes to ViewPoints, without constraining the development process. Consistency Checking of SCR-Style Requirements Specifications C. Heitmeyer, B. Labaw, and D. Kiskis heitmeye@itd.nrl.navy.mil This paper describes a class of formal analysis called consistency checking that mechanically checks requirements specifications, expressed in the SCR tabular notation, for application-independent properties. Properties include domain coverage, type correctness, and determinism. As background, the SCR notation for specifying requirements is reviewed. A formal requirements model describing the meaning of the SCR notation is summarized, and consistency checks derived from the formal model are described. The results of experiments to evaluate the utility of automated consistency checking are presented. Where consistency checking of requirements fits in the software development process is discussed. A Field Study of Requirements Engineering Practices in Information Systems Development K. El Emam and N.H. Madhavji kelemam@process.cs.mcgill.ca To make recommendations for improving requirements engineering processes, it is critical to understand the problems faced in contemporary practice. In this paper, we describe a field study whose general objectives were to formulate recommendations to practitioners for improving requirements engineering processes, and to provide directions for future research on methods and tools. The results indicate that there are seven key issues of greatest concern in requirements engineering practice. These issues are discussed in terms of the problems they represent, how these problems are addressed successfully in practice, and impediments to the implementation of such good practices. Specification of Customer and User Requirements in Industrial Control System Procurement Projects P. Forsgren and T. Rahkonen pafo@incosys.kth.se, tir@incosys.kth.se An appropriate industrial control system is a prerequisite for being competitive in the process, manufacturing, and power industries. As for most software systems, the technical possibilities provided by industrial control systems have grown dramatically during the last ten years. However, the techniques to specify customer and user requirements in terms of functionality, performance, etc. are not very well developed. This often leads to systems which do not fulfill user needs and customer expectations, and/or which are unnecessarily expensive. In this paper, guidelines for specification and follow-up of requirements on industrial control systems are given. The guidelines are based on an extensive study of experiences from a number of major users and vendors of these kinds of computer systems. They should be useful for customers and consultants working in procurement projects. Implementing Requirements Traceability: A Case Study B. Ramesh, T. Powers, C. Stubbs, and M Edwards ramesh@nps.navy.mil Many standards that mandate requirements traceability as well as current literature do not provide a comprehensive model of what information should be captured and used as a part of a traceability scheme. Therefore, the practices and usefulness of traceability vary considerably across systems development efforts, ranging from very simplistic practices just aimed at satisfying the mandates to very comprehensive traceability schemes used as an important tool for managing the systems development process. In this paper we present a case study of a systems development organization employing a comprehensive view of traceability A model describing the traceability practice in the organization, perceived benefits of such a scheme and lessons learnt from implementing it are presented. Contribution Structures O. Gotel and A. Finkelstein oczg@doc.ic.ac.uk; acwf@cs.city.ac.uk The invisibility of the individuals and groups that gave rise to requirements artifacts has been identified as a primary reason for the persistence of requirements traceability problems. This paper presents an approach, based on modelling the dynamic contribution structures underlying requirements artifacts, which addresses this issue. It shows how these structures can be defined, using information about the agents who have contributed to artifact production, in conjunction with details of the numerous traceability relations that hold within and between artifacts themselves. It further outlines how the approach can be implemented, demonstrates the potential it provides for "personnel-based" requirements traceability, and discusses issues pertinent to its uptake. A Client Oriented Requirements Baseline J.C.S.P. Leite and A.P. Oliveira julio@inf.puc-rio.br Traceability, a major issue in software engineering, is seldom present at the initial requirements engineering process. This paper reports on a proposal for organizing requirements statements as a model, where change and evolution are taken in consideration. The model uses natural language statements as its basic representation, which helps the communication between clients and software engineers. The model is supported by a customized software system for which a prototype was built and used in an industrial setting. Requirements Traceability in an Integrated Development Environment I.A. Macfarlane and I. Reilly ian@bnr.ca; iwreilly@bnr.ca Good development environment support is essential for good requirements traceability. This paper describes how requirements traceability is supported in Bell-Northern Research's Integrated Development Environment, an internally developed version control and configuration management environment. Emphasis is given to the way in which requirements traceability interacts with the key features of the environment: generic (tool independent), fine-grained design information management that permits users to quickly integrate new tools, and version control I configuration management. Using Non-Functional Requirements to Systematically Support Change L. Chung, B.A. Nixon, and E. Yu chung@utdallas.edu Non-Functional requirements (or quality requirements, NFRs) such as confidentiality, performance and timeliness are often crucial to a software system. Our NFR Framework treats NFRs as goals to be achieved during the process of system development. Throughout the process, goals are decomposed, design trade-offs are analysed, design decisions are rationalised, and goal achievement is evaluated. This paper shows how an historical record of the treatment of NFRs during the development process can also serve to systematically support evolution of the software system. We treat changes in terms of (i) adding or modifying NFRs, or changing their importance, and (ii) changes in design decisions or design rationale. This incremental approach is illustrated by a study of changes in banking policies at Barclays Bank. Requirements Monitoring in Dynamic Environments S. Fickas and M.S. Feather fickas@cs.uoregon.edu; feather@isi.edu We propose requirements monitoring to aid in the maintenance of systems that reside in dynamic environments. By requirements monitoring we mean the insertion of code into a running system to gather information from which it can be determined whether, and to what degree, that running system is meeting its requirements. Monitoring is a commonly applied technique in support of performance tuning, but the focus therein is primarily on computational performance requirements in short runs of systems. We wish to address systems that operate in a longlived, ongoing fashion in non-scientific, enterprise applications. We argue that the results of requirements monitoring can be of benefit to the designers, maintainers and users of a system alerting them when the system is being used in an environment for which it was not designed, and giving them the information they need to direct their redesign of the system. Studies of two commercial systems are used to illustrate and justify our claims. How People Categorise Requirements for Reuse: A Natural Approach N.A.M. Maiden, P. Mistry, and A.G. Sutcliffe N.A.M.Maiden@city.ac.uk This paper reports a knowledge acquisition exercise which elicited experienced software engineer's knowledge about domains for which requirements engineering takes place. Card sorts were used to acquire software engineers' mental categorisations of these domains to inform categorisation of a set of formal, reusable problem abstractions intended to assist requirements engineers. Challenges in Requirements Engineering J.A. Bubenko, Jr. janis@sisu.se We discuss a number of essential problems of requirements engineering related to management, organisations, users, stakeholders, methodology, tools, and education. Most of the problems seem to have their roots in how requirements engineering is appreciated at the business management and IT-management levels. Enhancing Soft Systems Analysis with Formal Modelling D.W. Bustard and P. J. Lundy dw.bustard@ulst.ac.uk Broadly, this paper argues for a soft systems approach to initial requirements definition and for the use of formal techniques as a means of strengthening that approach. In detail, the paper looks specifically at the means and implications of combining Checkland and Wilson's Soft Systems Methodology (SSM) with formal specification in LOTOS. Formal descriptions give precise meaning to the largely informal SSM models and help establish a bridge to traditional computing-oriented analysis techniques. The use of tools to support the development, linking and maintenance of SSM and LOTOS models is also examined The discussion is illustrated with a simple book-ordering data processing example. Overall, this work is part of a larger research effort into the development of RACE, a new requirements engineering method for software. An Evaluation of Inquiry-Based Requirements Analysis for an Internet Service C. Potts, E Takahashi, J. Smith, and K Ota potts@cc.gatech.edu; {kt,sumisu,ota}@nttspe.slab.nttjp The Inquiry Cycle is a generic process model for conducting requirements elaboration. It consists of three activities: requirements expression, discussion and commitment. This paper describes an evaluation of the Inquiry Cycle model and a support tool, Tuiqiao, in the requirements analysis phase of a real project, a proposed commercial consumer information service based on Internet. The extent to which the discussion of requirements follows the Inquiry Cycle is analyzed using quantitative measures and qualitative classification schemes, and effects of adopting an inquiry-based strategy on patterns of collaboration among the team members are analyzed. The project gradually shifted from synchronous meetings to asynchronous and individual workpatterns. A shift also occurred from an emphasis on discussion to an emphasis on commitment and expression. The requirements elaboration process was consistent with most aspects of the Inquiry Cycle, but analysts did not record reasons for requirements. The paper concludes with some recommendations for tool support. Trading Legibility Against Implementability in Requirement Specifications: An Experimental Assessment J.-P. Jacquot and A. Valdenaire {jacquot, valden}@loria.fr Ideally, a requirement specification language should lead to highly readable texts while being implementable. Unfortunately, current technology does not offer good support for features which enhance legibility such as elisions, flexible syntaxes, and more generally incomplete texts. GLIDER's designers have deliberately included those features in the language, thus forbiding some texts to be processed. This study is a rigourous assessment, both qualitative and quantitative, of this decision on the first step of processing: the parsing of terms. Goal-Directed Elaboration of Requirements for a Meeting Scheduler: Problems and Lessons Learnt A. van Lamsweerde, R. Darimont, and P. Massonet {avl, rd, phm}@info.ucl.ac.be Recently a number of requirements engineering languages and methods have flourished that do not only address what questions but also why, who and when questions. The objective of this paper is twofold: (i) to assess the strengths and weaknesses of one of these methodologies on a non-trivial benchmark, and (ii) to illustrate and discuss a number of challenging issues that need to be addressed for such methodologies to become effective in supporting real, complex requirements engineering tasks. The problem considered here is that of a distributed meeting scheduler system; the methodology considered is the KAOS goal-directed language and method. The issues raised from this case study include goal identification, the "deidealization" of unachievable goals, the handling of interfering goals, the impact of early formal reasoning, the merits of early reuse of abstract descriptions and categories, requirements traceability and the need to link requirements to retractable assumptions, and the potential benefits of hybrid acquisition strategies. Measuring the Success of Requirements Engineering Processes K El Emam and N.H. Madhavji kelemam@process.cs.mcgill.ca Central to understanding and improving requirements engineering processes is the ability to measure requirements engineering success. This paper describes a research study whose objective was to develop an instrument to measure the success of requirements engineering processes. The instrument developed consists of 32 indicators that cover the two most important dimensions of requirements engineering success. These two dimensions were identified during the study to be: quality of requirements engineering products and quality of requirements engineering service. Evidence is presented demonstrating that the instrument has desirable psychometric properties, such as high reliability and validity. Also some short papers associated with the following: Panel 1: The Next 25 Years: New Customers, New Environments, New Requirements Moderator: Sol Greenspan Panel 2: Let's Have More Experimentation in Requirements Engineering Moderator: Kevin Ryan Panel 3: Integrating Requirements Analysis and Safety Analysis Moderators: Joanne M. Atlee and John McDermid Mini Tutorial 1: Applications of Normative Reasoning Marek Sergot Mini-Tutorial 2: Ethnography by Video for Requirements Capture M. Jirotka. C. Heath, and P. Luff Working Group 1: Education in Requirements Engineering Moderator: John Mylopoulos Working Group 2: Invented Requirements and Imagined Customers: Requirements Engineering for Off-the-Shelf Software Moderator: Colin Potts Working Group 3: What Is Missing in Requirements Engineering Research? Moderator: Pamela Zave ********************************************************************** Subject: RENOIR: Network of Excellence in RE - A Guide to European RE Research RENOIR (Requirements Engineering Network of International Cooperating Research Groups) a network of excellence proposed as an accompanying measure within the European Union Framework Programme IV in Information Technologies. The objectives of RENOIR are: to provide a framework for coordinated joint research in requirements engineering related to industrial needs; to support the diffusion of requirements engineering research; to provide requirements engineering research training; to support technology transfer in requirements engineering. To this end RENOIR brings together most of the key European research teams from industry, academia, and research centres. RENOIR as outlined in the proposal consists of 64 nodes. THE RENOIR PROPOSAL AND SUPPORTING ANNEX INCLUDES LISTINGS OF RESEARCH INTERESTS, RESEARCH GROUP PROFILES AND KEY REFERENCES. WE HAVE MADE IT AVAILABLE THROUGH WWW AND HAVE INSERTED LINKS TO THE HOME PAGES OF MANY OF THE PARTICIPATING NODES. This is available from: http://src.doc.ic.ac.uk/req-eng/renoir/cover.html ********************************************************************** From: avl@info.ucl.ac.be (A. van Lamsweerde) Subject: A Guided Tour through the ICARUS Project The following report is available by ftp from: ftp://dse.doc.ic.ac.uk/requirements as OR A Guided Tour through the ICARUS Project E. Dubois (Facultes Universitaires de Namur, edu@info.fundp.ac.be), J. Hagelstein (SEMA Group, hagelste@sema.be), A. van Lamsweerde (Universite Catholique de Louvain, avl@info.ucl.ac.be), F. Orejas (Universidad Politecnica de Catalunya, orejas@lsi.upc.es), J. Souquieres (CRIN Nancy, souquier@loria.fr), P. Wodon (SEMA Group, wodon@info.ucl.ac.be) This report aims to provide an overview of the main directions and achievements of the Icarus project (1989-1994). This project was undertaken under the ESPRIT II program of the Commission of the European Communities. Icarus stands for Incremental Construction and Analysis of Requirements Specifications. The general objective of the project was to study formal methods for building requirements specifications. To that effect a number of languages, methods and tools had to be developed for capturing specification products (that is, descriptions of the required features of the desired system and its environment), specification processes (that is, the compositions of activities by which specifications are produced), and specification rationales (that is, the goals and strategies underpinning the application of specific processes). The assessment of those languages, methods and tools had to performed throughout the project by means of realistic case studies provided by the industrial partners. The presentation follows the different streams in which the work of the project was organised - namely, the product, process, tools and case study streams. For each stream, the main objectives are recalled first; then the main results, successes and failures are discussed; a few suggestions concerning further advances in the field are also made. Our objective is not to provide an in-depth, technical review of all contributions; references to relevant technical reports and publications will be given wherever appropriate. **********************************************************************