****************REQUIREMENTS ENGINEERING NEWSLETTER******************** SPONSORED BY RENOIR: the Requirements Engineering Network of Excellence No. 42. Contents 1. Message from the Moderator! (Anthony Finkelstein) 2. RENOIR is up and running (Stephen Morris) 3. CFP: 3rd IEEE Intl Conf on Requirements Engineering (Dan Berry) 4. CFP: 3rd Intl Wkshp on RE: Foundation for Software Quality (Klaus Pohl) 5. CFP: Workshop on Human Error and Systems Development (Chris Johnson) 6. CFP: 4th ISPE Intl Conf on Concurrent Engineering (Biren Prasad) 7. CFP: 4th Doctoral Consortium on Advanced Info Systems Eng (Andreas Winter) 8. CFP: Designing Interactive Systems (Orlena Gotel) 9. WEB: Software Process 96 Newspaper (Richard Messnarz) 10. JOBS: Openings at GTE Laboratories 11. EVENT: 3rd IEEE Intl Symp on Requirements Engineering (Connie Heitmeyer) 12. EVENT: BCS RESG Programme of Events for 1997 (Orlena Gotel) 13. EVENT: Requirements Engineering - Clapping With One Hand? (Orlena Gotel) 14. ARTICLE: The Perfect Requirement Myth (Geoff Mullery) 15. SUGGESTIONS: Ambiguous Statements (Jeff Gray) 16. QUESTIONNAIRE: Preparing End-Users for Participation (Andrew McAllister) ------------------------------------------------------------------------------- | 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 the moderator at: requirements@cs.city.ac.uk | | | | Subscription (or removal) requests should be sent to: | | requirements-request@cs.city.ac.uk Just send an email message containing: | | | | subscribe
OR unsubscribe
| | | | The Requirements Engineering Newsletter and its archive is also accessible | | through WWW. The URL is: | | | | http://web.cs.city.ac.uk/homes/acwf/rehome.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 pages to be linked to the RE Newsletter page please inform me. | | | | You can access the archive via anonymous ftp: | | | | Ftp-host : ftp.cs.city.ac.uk (IP number: 138.40.91.9) | | Directory : pub/requirements | | Files are called renl1, renl2, etc. | | | | Requirements Engineering Newsletter is published solely as an educational | | service. Copyright (c) 1995, Anthony Finkelstein; All Rights Reserved. | | | ------------------------------------------------------------------------------- ********************************************************************** [1] From: acwf@cs.city.ac.uk (Anthony Finkelstein) Subject: Message from the Moderator! Seasonal Greetings to all. Anthony ********************************************************************** [2] From: sjm@soi.city.ac.uk (Stephen Morris) Subject: RENOIR is up and running RENOIR is up and running ! On June 1st City University, as the coordinating partner, signed a contract with the European Commission which formally brought into being the Requirements Engineering Network Of Internatinal cooperating Research groups (RENOIR). RENOIR will last for three years and the EU will contribute a total of 983,000 ECU (approx. 800,000 GBP) to support this network of research groups, each with established excellence in the area of requirements engineering. The general purpose of RENOIR is to develop the coordination mechanisms and infrastructure for research in requirements engineering. Specific objectives are: to provide a framework for coordinated, joint research related to industrial needs, to support the diffusion of RE research; to provide RE research training and to support technology transfer in RE. RENOIR brings together research teams from industry, academia, and research centres around a set of shared technical goals relating to the: - context in which the requirements engineering process takes place, - groundwork necessary for requirements engineering, - acquisition of the "raw" requirements, - rendering these requirements useable through modelling and specification, - analysis of the requirements, - measurement to control the requirements and systems engineering process, and - communication and documentation of the results of requirements engineering. The sixty eight founding members of RENOIR include almost all the key research teams working in the area of requirements engineering within Europe. The coordinator is the City University in London. Membership is open to any research laboratory or industrial group of researchers in Europe (or in countries with cooperation agreements with the European Union) which has interests in the area of requirements engineering, which subscribes to the aims of RENOIR and is interested in participating in the activities of the network. New applicants for membership are welcome. The Network Programme specifies four roles for RENOIR : - strategic planning and research coodination, - human resources planning, - infrastructure planning, and - dissemination and industrial relations. The full programme, criteria for funding network activities, lists of members, names of national coordinators, information about joining, contact addresses, and more, are all available at the RENOIR web site: http://www.cs.city.ac.uk/project/renoir. Alternatively just mail renoir-direct@soi.city.ac.uk. The Executive Board also met in early November. We'll provide you with more RENOIR news soon. ********************************************************************** [3] From: dberry@csa.CS.Technion.AC.IL (Dan Berry) Subject: CFP: 3rd IEEE Intl Conf on Requirements Engineering (Dan Berry) THIRD IEEE INTERNATIONAL CONFERENCE ON REQUIREMENTS ENGINEERING [ICRE `98] An IEEE Software Technology Transfer Conference April 5-10, 1998 Colorado Springs, Colorado, USA ---------------------------------------------------------------------------- Sponsored by IEEE Computer Society Technical Council on Software Engineering with Fujitsu and MCI ---------------------------------------------------------------------------- CALL FOR PAPERS ICRE '98 is the third in a biennial series of conferences aimed at bringing together practitioners and researchers to discuss software requirements-engineering-related problems and results. Further, as a technology transfer conference, it is designed to provide (1) practitioners with an evaluation of promising requirements research and practice, and (2) researchers with an exposure to real-world requirements problems. PAPERS: Authors are invited to submit papers addressing theory and/or practice. An experience paper evaluates the effectiveness of a requirements engineering technology, which may have begun as a research effort, in a real-world, industrial setting on non-trivial requirements engineering problems, and a research paper describes an innovative requirement engineering technology aimed at cracking previously unsolved problems in requirements engineering and demonstrates, perhaps by application to an exemplar, the usefulness of the technology in solving these problems. Authors are encouraged to focus on one of these two aspects as the primary theme of their contributions. In all cases, practical and near-term applicability of the proposed ideas must be emphasized. Each paper is evaluated according to the standards of its category. Topics include, but are not limited to: * Requirements problems, techniques & tools * Requirements definition, * Defining the system-human analysis & validation interface requirements * Prototyping, animation & * Business process relationship to visualization of requirements system requirements * Non-linear & heterogeneous * Supporting requirements requirements descriptions elicitation & evolution * Requirements engineering as a * Requirements engineering in group activity legacy system migration * Role of software architecture * Advances in formal methods & in requirements their practical use * Lessons from domain-specific * Requirements-based system requirements practices testing * Role of requirements standards EARLY FEEDBACK: All authors are strongly encouraged to submit extended abstracts of from one to three pages by May 19, 1997. In the interest of rapid response, these must be submitted either as a plain text file in ASCII form by e-mail to icre98@cs.technion.ac.il or by fax to Prof. D.M. Berry at +972-4-822-1128, with a preference to e-mail. The feedback will be in the same form in which the abstract was submitted. The abstract should summarize the problems addressed, the plan of the paper, the conclusions, and the contributions. Promising papers will receive early feedback by June 16 that can be applied to improving the full paper. Full papers received by 1 August without a previous extended abstract or for abstracts for which no feedback was given will nevertheless be given full consideration. PANELS: Proposals that focus on requirements engineering controversies are encouraged, especially those that highlight the gulf between requirements research and practice. Preference will be given to panels that present a diversity of views on the topic chosen. Proposals should include the panel's title, a brief description of issues to be debated, the names of prospective panel members, and a description of their roles. SUBMISSION: Full length papers are limited to 6000 words, typeset with enough room for comments by reviewers. They should include a short (150-word) abstract, a list of descriptive keywords, specification of the paper's category (experience / research), and complete contact information for the lead author. Authors should send six hard copies of their papers and panel proposals, in English, to one of the program chairs: From Western Hemisphere: From Eastern Hemisphere: Brian Lawrence Prof. Daniel M. Berry 335 Keeler Court Faculty of Computer Science San Jose, CA 95139 Technion U.S.A. Haifa 32000, ISRAEL INTERNET HOTLINE: Further information on ICRE '98 may be obtained by sending Internet electronic mail to icre98@cs.technion.ac.il, or through the WWW using the URL http://www.cs.technion.ac.il/~icre98/. STEERING COMMITTEE D. Berry B. Lawrence C. Chang N. Mead A. Davis C. Shekaran M. Dorfman J. Siddiqi P. Hsia CONFERENCE CHAIR Nancy Mead (nrm@sei.cmu.edu) PROGRAM CHAIRS: Daniel M. Berry (dberry@cs.technion.ac.il) Brian Lawrence (brianl@netcom.com) PROGRAM COMMITTEE People from Industry as well as Academia! REGISTRATION CHAIR Charlene Rauber TUTORIALS CHAIR J. D. Berdon (jdberdon@mozart.uccs.edu) LOCAL ARRANGEMENTS CHAIR Rick Hubbard (74035.601@compuserve.com) PUBLICITY CHAIR Yahya Al-Salqan (alsalqan@Eng.Sun.COM) ---------------------------------------------------------------------------- The best papers in the conference will be considered for publication in IEEE Software. KEY DATES * Extended abstracts May 19, * Panel proposals August 1, due: 1997 due: 1997 * Feedback to June 16, * Author October 20, authors: 1997 notification: 1997 * Full papers August 1, * Camera-ready December due: 1997 papers due: 29, 1997 ********************************************************************** [4] From: pohl@Informatik.RWTH-Aachen.DE (Klaus Pohl) Subject: CFP: 3rd Intl Workshop on Reqts Eng: Foundation for Software Quality ======================================================================= C A L L F O R P A P E R S R E F S Q ' 9 7 Third International Workshop on Requirements Engineering: Foundation for Software Quality June 16-17 1997 Barcelona, Catalonia (preceding the CAiSE 1997 conference) ====================================================================== P U R P O S E The ultimate measurement for software quality is the degree to which user requirements are fulfilled by a system. Early elicitation and correct definition of requirements prevents costly rework during later development stages and provides the foundation for building high quality systems. Therefore, requirements engineering is considered as a more and more crucial part of the system life cycle. During requirements engineering the user and engineers have to find a way from an initially opaque and diverse system understanding to exact, reconciled and at least partially formalized system specifications. A multitude of methods from software engineering, ethnology, social sciences, and psychology have been adapted to support this process and to achieve a growing quality of the requirements specification as a foundation of higher system quality. Most of these methods are relying on adequate specification languages which are expressive and formal enough so that the represented quality requirements can be verified or validated. At the REFSQ'94 and REFSQ'95 workshops researchers and practitioners from various disciplines presented approaches that focused on the improvement of the definition and implementation of (quality) requirements. The success of REFSQ'94 and REFSQ'95 encouraged us to provide a follow-up workshop REFSQ'97 as a stage for the discussion of quality-related problems in requirements engineering as they have developed over the last year. In particular, we like to encourage people from the software and information systems engineering field to present their approaches to higher software quality and to discuss how requirements engineering can contribute to it. G O A L The main goal of the REFSQ'97 is to bring together people working in the fields of requirements engineering and software (information systems) engineering focussing on the - specification of quality requirements; - their traceability back to user needs and forward to the design; - their realization by SE methods; - the measurement of their achievement, as well as - consolidating the achievements of the two previous REFSQ workshops. T H E M E S REFSQ'97 invites contributions from research and industry within the following four main themes: 1. Embedding RE in the organisational context. (Relevant topics include: change management, procurement, organisational learning, business processes, etc.) 2. Managing the quality of RE processes. (Relevant topics include: traceability, process modelling and monitoring, RE project organisation, quality models of RE and the RE process, environments for supporting RE processes, CAME environments, etc.) 3. Quality assurance and RE. (Relevant topics include: models for quality assurance, considering quality assurance in RE, software quality and RE, specification of software quality requirements, measuring the quality of requirements, etc.) 4. Mapping requirements specifications to software architecture and design. (Relevant topics include: transformation and mapping methods, the interplay between requirements and software quality features, formal representation methods, etc.) Note that the list topics mentioned for each theme is not intended to be exhaustive. High-quality papers on other topics within each of the four themes are welcomed. Papers should emphasize what is new and significant about the chosen approach and adequately compare it with similar work. Integration of the contributions with mainstream RE methods and products (like SA, OMT, ER, and the like) are especially encouraged. P A R T I C I P A T I O N The workshop will be an interactive forum. Each presentation will be summarized by two discussants and followed by a panel discussion between the authors and the audience. Attendance will be limited to around 25 people and all participants must contribute accepted full or position papers. The workshop language is English. The workshop is being organized in conjunction with the CAiSE*97 conference, and all workshop participants are expected to attend the main conference. I N S T R U C T I O N S F O R A U T H O R S Send your full paper (max. 6000 words) or position paper (max. 2000 words) by e-mail or via normal post before March 17th (arrival date) to: REFSQ'97 Department of Information Science University of Bergen N-5020 Bergen Norway email: Andreas.Opdahl@ifi.uib.no Papers will be published in the REFSQ'97 workshop proceedings, and preprints of the papers will be made available for accepted and registered participants at the beginning of the workshop. I M P O R T A N T D A T E S Submission deadline: March 17th 1997 Acceptance notification: April 17th 1997 Camera ready paper due: May 17th 1997 O R G A N I Z A T I O N Eric Dubois Andreas Opdahl Klaus Pohl Dep.of Computer Science Dep. of Inf. Science Informatik V FUND Namur University of Bergen RWTH Aachen Namur N-5020 Bergen D-52074 Aachen Belgium Norway Germany Tel. +32-81-72 41 11 +47-5558-4115 +49-241-80-21512 Fax. +32-81-72 49 67 +47-5558-4107 +49-241-8888-321 email: edu@info.fundp.ac.be Andreas.Opdahl@ifi.uib.no pohl@informatik.rwth-aachen.de ********************************************************************** [5] From: johnson@dcs.gla.ac.uk (Chris Johnson) Subject: CFP: Workshop on Human Error and Systems Development Workshop on Human Error and Systems Development 20th-22nd March 1997, The Senate Room, University of Glasgow http://www.dcs.gla.ac.uk/~johnson/HF_Engineering.html Co-chairs: Nancy Leveson and Chris Johnson Themes: Recent accidents in a range of industries have increased concern over the management and control of safety-critical systems. Much recent attention has focussed upon the role of human error both in the development and in the operation of complex processes. This workshop will, therefore, provide a forum for practitioners and researchers to discuss leading edge techniques that can be used to mitigate the impact of human error on safety-critical systems. Our intention is to focus the workshop upon techniques that can be easily integrated into existing systems engineering practices. With this in mind, each day will have a different theme. The session on Thursday 20th March will focus on accident analysis and risk assessment techniques. Friday, 21st will focus more narrowly upon interface and component design, development, and testing. We also encourage papers that cross these boundaries. Saturday 22nd March will provide the opportunity for informal discussion about the issues raised during the workshop. The day will be spent on the Isle of Arran, off the west Coast of Scotland. Deadlines: Authors should submit extended abstracts (approximately 3 sides of A4) to Chris Johnson, see below, to arrive no later than January 17th, 1997. Authors will be notified of the programme committee's decision and revised full papers must be returned by March 7th for inclusion in the proceedings. Full papers, up to twenty-five pages of A4 will be selected for inclusion in a special edition of Elsevier's Interacting with Computers. Programme Committee: Veronique de Keyser, University of Liege, Belgium. Chris Johnson, University of Glasgow, Scotland. Peter Ladkin, Universitat Bielefeld, Germany. Nancy Leveson, University of Washington, USA. Chris Mitchell, Georgia Institute of Technology, USA. Kim Vicente, University of Toronto, Canada. David Woods, Ohio State University, USA. Further Information: Chris Johnson, Department of Computer Science, University of Glasgow, Glasgow, G12 8QJ, Scotland. johnson@dcs.glasgow.ac.uk tel.: +44 141 330 6053 fax.: +44 141 330 4913 This workshop is organised by the Glasgow Accident Analysis Group, Department of Computing Science, at the University of Glasgow. It is supported by the Human Factors section, IT and Computer Science programme within the UK Engineering and Physical Sciences Research Council. ********************************************************************** [6] From: BPRASAD@CMSA.gmr.com (Biren Prasad) Subject: CFP: 4th ISPE Intl Conf on Concurrent Engineering ISPE/CE97 FOURTH ISPE INTERNATIONAL CONFERENCE ON CONCURRENT ENGINEERING: RESEARCH AND APPLICATIONS Troy, Michigan, U.S.A August 20-22, 1997 FIRST CALL FOR PAPERS ISPE/CE97, Concurrent Engineering: Research and Applications, is a major forum for the international scientific exchange of multi-disciplinary and inter-organizational aspects of concurrent engineering (CE). The focus is on the use of integrated enterprise processes, collaborative work, information sharing, co-locating resources, and integrated frameworks and tools. This conference addresses research and applications issues of CE. This information is available at Web page: http://www.secs.oakland.edu/SECS_prof_orgs/ISPE/CE97.htm CE97 is sponsored by International Journal of Concurrent Engineering: Research & Applications (CERA Journal), the International Society for Productivity Enhancement (ISPE). CE97 is hosted by Oakland University, Rochester, MI 48309, USA. Sponsorships from Chrysler, other professional and Industrial organizations are being sought.. Topics of Interest: Submissions are invited on substantial, original and previously unpublished research in all life-cycle areas of product design, engineering and manufacturing, including, but not limited to: Planning & Scheduling in CE :Enterprise integration, assessing an organization's readiness, CE process characterization, workflow tracking and management, CE assessment models, planning and scheduling of activities, re-engineering enterprise processes, CE metrics, barriers to CE, agile manufacturing, virtual enterprises. Collaborative Decision Making in CE :Cooperative work, team coordination, Decision Support and Design Assessment, monitoring progress of product development, change notification across perspectives, cooperative problem solving, computer support for team structure, Project & Team coordination. Information Modeling in CE : Information modeling and simulation, integrated process capture, design intent capture, data version control and management, PDES/STEP, multi-level user access, capturing corporate history, enterprise multimedia notebooks, design rationale, integrated database and knowledge- base management systems. Teaming and Sharing in CE: Information sharing, Communication tools, computer-based video and audio conferring and consulting, multimedia electronic mail, network-wide sharing of tools, graphical collaborative user interfaces for inter-operability, networked collocation. Networking and Distribution in CE :Integrated frameworks, architectures for building CE systems, CE Languages & Tools, integration of design and manufacturing, knowledge-based integration, virtual team support environments, Tools for multi-media conference on the networks, Distributed Computing Environment. Organization and Management of CE :Principles of CE, emerging standards and practices, Life cycle engineering, design for X, integrated product and process development, environmentally conscious manufacturing, life-cycle cost and quality. Reasoning & Negotiation in CE :Conflict Resolution Techniques, Constraint Management, Negotiation. Blackboard and Agent-based architecture, Corporate Technical Memory. Practical applications of CE :Practical solutions, systematic guidelines, pitfalls and success stories, case studies, lessons learned, etc. Timetable: ========== Authors should submit a full draft paper or extended abstract, not exceeding 10 single spaced pages, to the conference General Chair, no later than January 1, 1997 (preferably by E-mail in plain ASCII or PostScript). Notification of acceptance or rejection will be mailed to the first author (or designated author) on or before February 28, 1997. Final camera-ready versions of the papers must be received by April 15, 1997. The format is the same as the CERA Journal. Conference Proceedings: ======================== Conference Proceedings will be published by Technomic Publishing Corporation as a part of a CE series entitled " Advances in CE "with official congress catalog (ISSN) number. Selected expanded papers will be reviewed for inclusion in a special issue of the international journal, Concurrent Engineering: Research and Application (CERA). For Information about CERA Journal, write to: CERA Managing Editor, Dr. Biren Prasad , Director, CERA Institute, P.O. Box 250254, West Bloomfield, MI 48322, USA. Tel: (810) 696-5487/ Fax: (810) 661-8333, Email: bprasad@cmsa.gmr.com Those, who would like to serve on the conference committee as representative should contact Dr. Subra Ganesan at the above address. A session organizing committee is being formed. Those interested to organize CE sessions related to one or more of the above specialty areas and wish to chair or co-chair sessions should contact Dr. George Dodd or Dr. Subra Ganesan. Conference General Chair: Dr. Subra Ganesan, Professor and Chair, Department of Computer Science and Engineering, Oakland University, Rochester, MI 48309, U.S.A. E-Mail: ganesan@oakland.edu, Tel: (810) 370 2206, Fax: (810) 370 4625 International Co-chair Dr. Pravir K. Chawdhry School of Mechanical Engineering, University of Bath, Bath BA2 7AY, U K E-Mail: P.K.Chawdhry@bath.ac.uk Tel: +44 (1225) 826956, Fax: +44 (1225) 826928 Conference Program Chair: Dr. Shuichi Fukuda, Department of Production, Information and System Engineering, Tokyo Metropolitan Institute of Technology, 6-6, Ashaigaoka, Hino, Tokyo, Japan, Tel: +81-425-83-5111, Fax: +81 425 83-5119 , email: fukuda@mgbfu.tmit.ac.jp Tutorial Chair: Dr. Biren Prasad Director, CERA Institute, EDS, P.O.Box: 250 254, West Bloomfield, MI 48322-0254, USA Phone: 810 696 5487. Fax: 810 661 8333 Email: bprasad@cmsa.gmr.com Panel Session Chair: Dr. George Dodd Director, Michigan Center for Automotive Research, Oakland University Rochester, MI 48309, USA. Email: dodd@oakland.edu Phone: (810) 370 2231. Fax: 810 370 4261. ISPE Representative: Dr. Marek Zaremba, University of Quebec, Canada Dr. Gopalakrishnan, Western Virginia University, Morgantown, WV USA. A current version of a CE97call for papers is available at: < http://ce-toolkit.crd.ge.com/~sobol/CE97.html> and http://www.secs.oakland.edu/SECS_prof_orgs/ISPE/CE97.htm ********************************************************************** [7] From: winter@mailhost.uni-koblenz.de (Andreas Winter) Subject: CFP: 4th Doctoral Consortium on Advanced Info Systems Engineering CALL FOR PAPERS CAiSE'97 4th Doctoral Consortium on Advanced Information Systems Engineering Barcelona June 16-17, 1997 The Doctoral Consortia on Advanced Information Systems Engineering are intended to bring together PhD students within the information systems engineering field and give them the opportunity to present and to discuss their research in a constructive and international atmosphere. The workshop in Barcelona will be the 4th Doctoral Consortium of a series held in conjunction with the CAiSE conferences in Utrecht (1994), in Jyvaskyla (1995), and in Heraklion (1996). The two first days of the CAiSE'97 conference (June 16th and 17th) have been reserved for the Doctoral Consortium. ********************************************************************* CONFERENCE TOPICS ********************************************************************* The CAiSE Doctoral Consortia deal with the topics of the main Conference. In 1997 these topics include but are not restricted to - Business process reengineering - CASE - Conceptual modelling - Distributed IS design - Enterprise modelling - Information systems procurement - Internet-based IS design - Internet-based world-wide IS - Inter-organizational IS - IS support for virtual organizations - IT product definition and competitive advantage - Legacy systems reengineering - Methods engineering - Mobile computing - Object-oriented and rule-based application design - Quality management - Requirements engineering - Reverse engineering - Workflow management The workshop language is english. ********************************************************************* SUBMISSIONS ********************************************************************* To apply for participation at the consortium, you have to provide 5 copies of an abstract of your doctoral work to the workshop organizers. Electronic submissions are strongly encouraged (Postscript only). The abstract (restricted to 5000 words) should: - clearly identify the research question, - outline the significant problems in the field of research and the current solutions, - present the preliminary ideas and state the proposed approach clearly, and - present the contributions of the applicant and the results of the work. Submissions will be judged on orginality, significance, correctness, and clarity. Admission is limited to 20 students. ********************************************************************* ACCOMPANYING PROFESSORS ********************************************************************* The CAiSE'97-Doctoral~Consortium is accompanied by three prominent scientists in the field of information systems which will actively participate and contribute to the discussions. Peri Loucopoulos University of Manchester Institute of Science & Technology, Department of Computation. Arne S¿lvberg Norwegian Institute of Technology, Department of Computer Science. Roel Wieringa Vrije Universiteit De Boelelaan, Faculty of Mathematics and Computer Science. ********************************************************************* IMPORTANT DATES ********************************************************************* Deadline for submission : January 30th, 1997 Notification of acceptance : March 15th, 1997 Camera-ready paper due : April 15th, 1997 CAiSE'97 : June 16th-20th, 1997 ********************************************************************* Contact Address ********************************************************************* Andreas Winter Juha-Pekka Tolvanen University of Koblenz-Landau University of Jyvaskyla Institute for Software Technology Department of Computer Science Rheinau 1, D-56075 Koblenz, and Information Systems Germany P.O. Box 35, SF-40351 Jyvaskyla Finland email: winter@uni-koblenz.de email: jpt@hyeena.jyu.fi Electronic mail concerning the Doctoral Consortium and submissions should be sent to caise97DC@informatik.uni-koblenz.de The Doctoral Consortium's web-pages are located at http://www.uni-koblenz.de/~ist/CAiSE97DC/caise97DC.html ********************************************************************** [8] From: olly@soi.city.ac.uk (Orlena Gotel) Subject: EVENT: Designing Interactive Systems DIS 97 DESIGNING INTERACTIVE SYSTEMS: PROCESSES, PRACTICES, METHODS, AND TECHNIQUES call for participation Sponsored by ACM SIGCHI in co-operation with IFIP WG 13.2 18-20 August 1997 Amsterdam, The Netherlands Co-chairs - Ian McClelland and Gary Olson www.acm.org/dis97/ This Conference Designing is about modifying, adapting and manipulating technologies to meet a particular set of requirements. Designing interactive systems adds human behaviour to the equation and often adds complexity to the challenge of deriving an appropriate solution. Designing interactive systems often involves dealing with the macro, the micro and much that falls between. It is complex and exciting. It is hard work. How we design has a big impact on the quality of what is produced. Many organisations are new to the development of interactive systems. But even the more experienced organisations are only now beginning to understand the skills, resources and processes needed to produce results that please their customer base. companies are also recognising that commercial survival will partly depend on making sure that their products meet the needs of their customers. There has been growing interest, both in companies as well as in academia, in better understanding the processes of designing and in finding ways to improve the result. In 1995 the first DIS set out to address designing as a coherent activity -- technical, cognitive, social, organisational, and cultural. The goal was to come to a better understanding of how designing works in practice and how we can improve it -- by broad-based empirical observations, by formulating theories and perspectives, by developing methods and techniques, and adopting effective practices. For DIS 97 these ambitions remain the same. DIS 97 will provide a forum to discuss the process of designing interactive systems grounded in experiences of real design practice. We want to bring together professional designers, who want to report and reflect on their design practices, and researchers in the fields of design processes, methods and techniques to see how design practice can be improved. The focus of the conference is on designing in the domain of interactive systems, which covers a broad range of artefacts, but perspectives and insights from other design domains are encouraged. The conference will be a single-track program providing common ground among the variety of participants. The primary activity will be discussion, not presentation, based on real-world design practice as illustrated by the submissions. Our aim is to create a definitive report which draws on this discussion, to be distributed after the conference for the benefit of the field. TOPICS Empirical studies of design practices. New design methods; evaluation and comparison of methods. Design support tools and environments. Requirements capture techniques. Design rationale: capture, presentation, and use. Software processes for interactive system design Design approaches: e.g., participatory or scenario-based design. Formal notations and cognitive models for design. New theoretical perspectives. Critiques of existing approaches or perspectives. Case study experiences in specific design situations Experiences, perspectives, and lessons from other design domains. Specifying and evaluating design quality. All submissions should provide insights into the practices of designing that lead to the prospect of improvement. TYPES OF SUBMISSIONS: All submissions should present material grounded in actual design practice. PAPERS. High quality papers which present original work are invited which present perspectives derived from the practice of designing that contribute to a more coherent view of designing. Papers should be at most 12 ACM conference pages (about 6000 words). The title page should include an abstract (no more than 200 words) and keywords. DESIGN CASES. Design Cases should relate actual experiences encountered in the practice of designing from which lessons can be learnt to the benefit of the field. Design cases should focus on concrete detail and should describe the basic design problem, the constraints, the organisational setting of the designers and the lessons learnt. Case descriptions should be 4 pages long (2000 words). PANELS. Proposals for panels that synthesise and orient research in the area, especially across disciplinary boundaries, are particularly encouraged. Panel proposals should define the issues the panel is addressing, list the panel members, their background, and their basic positions. Panel proposals should be two pages long. OTHER FULL SESSION ACTIVITIES. Proposals on how to spend a full session (1.5- 2hrs) on design issues based on actual experience and prompting deep discussions are invited. The proposal should elaborate the issue as well as the session model, list participants involved, their roles in the session, their background, and their basic positions. Full session proposals should be 2 pages long. Examples of what might be proposed include; an actual design exercise, a debate between two opposing views or approaches, analysing a video of a design team session by 3 well known experts. All accepted submissions will be included in the proceedings. At the conference, accepted submissions will be presented as posters, to form the essential grounding for conference discussions and the conference report. PROPOSALS FOR ALL SUBMISSIONS: Please send 5 copies of your proposal to one of the Technical Co-chairs along with a covering letter indicating the primary contact person (including name, affiliation, address, phone number, fax number, and email address). All proposals should follow the CHI conference format as used for the CHI 97 conference (see www.acm.org/sigchi/chi97/call/format/). If this format is unfamiliar to you please contact one of the Technical Co-chairs for further information. The Technical Co-chairs: Austin Henderson, Gerrit van der Veer, Apple Computer, Inc. Department of Computer Science 1 Infinite Loop, MS 301-4UE Vrije Universiteit Cupertino, CA 94020 De Boelelaan 1081 A USA 1081 HV Amsterdam The Netherlands Tel: +1 408 974 8034 Tel: +31 20 444 7764 Fax: +1 408 974-5505 Fax: +31 20 644 1746 Email: henderson@apple.com Email: gerrit@cs.vu.nl IMPORTANT DATES: Deadline for receipt of contributions: Friday 31st January 1997, 5pm local time Notification to contributors: Friday 28th March 1997 Final versions delivered by: Friday 16th May 1997, 5pm local time Conference: Monday 18th - Wednesday 20th August 1997 FOR GENERAL ENQUIRIES: Ian McClelland Manager Applied Ergonomics Philips Corporate Design Building OAN, PO Box 218, 5600 MD, Eindhoven, The Netherlands Tel: +31 40 2733311 Fax: +31 40 2734959 E-Mail: I.McClelland@Design.Corp.Philips.com ORGANIZING COMMITTEE: Ian McClelland Co-chair Gary Olson Co-chair Gerrit vd Veer Co-chair - Technical Programme Austin Henderson Co-chair - Technical Programme Allan MacLean Alistair Sutcliffe Wendy Kellogg John Karat Jack Carroll PROGRAM COMMITTEE: Bob Anderson David Benyon Susanne Bodker Ruven Brooks George Cassaday Gillian Crampton-Smith Ernest Edmonds Gerhard Fischer Paul Gough Ashok Gupta Bill Hefley John Hughes Simon Kaplan Kari Kuutti John Long Marilyn Mantei Wendy Mackay Tom Moran Neville Moray Judith Olson Fabio Paterno Colin Potts Paul Rankin Tom Rodden Mary Beth Rosson John Rheinfrank Tom Stewart Michael Tauber ********************************************************************** [9] From: rmess@ist.tu-graz.ac.at (Richard Messnarz) Subject: WEB: Software Process 96 Newspaper There is a brand new process improvement newspaper on the WWW called "Software Process 96 Newspaper". It has been established by ISCN on behalf of the SP'96 partnership. http://www.iol.ie/~iscn/news/structure/table2.html ********************************************************************** [10] From: Greenspan@gte.com (Sol J. Greenspan) Subject: JOBS: Openings at GTE Laboratories We have several openings at GTE Laboratories, including in my Requirements Engineering group. The openings described below are in the Software Infrastructure Research Department, which does advanced research in the areas described below. If interested, please respond in one of the following ways: - Email to crichards@gte.com - Fax to the attention of C. Richards at 617-890-9320 - Mail to C. Richards, GTE Laboratories Incorporated, 40 Sylvan Road, Waltham, MA 02254 In all correspondence, please include the appropriate Box Code: Box Code SG-1: Interoperability and Workflow Box Code SG-2: Requirements Engineering Research Requirements Engineering Research (Box Code SG-2) We are seeking an individual to participate in the design and development of novel prototype software environments and tools to support requirements engineering, enterprise modeling, and other software engineering applications. Work will involve integration and application of multiple advanced software technologies, including knowledge representation and reasoning techniques, (e.g., constraints, TMS, logic programming), OODBMS, GUI, web-based and other emerging technologies. The objective is to advance the state-of-the-practice in the corporation and the state-of-the-art in the field of Requirements Engineering. The position requires an MS or PhD in Computer Science, proven design and prototyping skills, and expert skills using Lisp, Prolog, Java, KBSs, OODBMSs. Interoperability and Workflow Research (Box Code SG-1) We are staffing two projects to do applied research and proof-of-concept demonstrations in architectures, models, and distributed services for supporting large-scale system integration/interoperation, software evolution, workflow management infrastructure, and/or virtual enterprises/services. Prior R&D work in one or more of the following areas is required: ¡ software architecture ¡ workflow management ¡ distributed systems/databases ¡ data warehouses ¡ object-based systems/databases ¡ nomadic/mobile computing ¡ software engineering technology that promotes these areas SOFTWARE TECHNOLOGY FOR THE FUTURE -- At GTE Laboratories, we have assembled a uniquely talented group of researchers to define and support the future software technology needs of GTE-one of the largest telecommunications companies in the world. As part of the Software Infrastructure Department in the Advanced Systems Laboratory, you will investigate, prototype, and extend emerging software technology for very large-scale, component-oriented, complex information systems. Your vision will guide the future software architecture supporting GTE's advanced telecommunications and internet services. At GTE Laboratories, we offer a unique opportunity to perform research motivated by "real" problems while living and working in the Boston area. Senior positions require a PhD in Computer Science (or equivalent) and involve technical leadership in a team setting to evaluate research opportunities and related GTE needs, set appropriate direction, and make technology recommendations to GTE business units. Active involvement in research community activities is expected. Additional positions require at least an MS in Computer Science and involve participating in research activities and performing proof-of-concept prototype design and development. We offer an outstanding benefits package, including an on-site fitness facility, medical/life/dental and long term care insurance, pension, and 401(k) plan. An Equal Opportunity Employer, M/F/D/V. Visit GTE's web site at www.gte.com or GTE Laboratories web site at info.gte.com. ********************************************************************** [11] From: heitmeye@itd.nrl.navy.mil (Connie Heitmeyer) Subject: EVENT: 3rd IEEE Intl Symposium on Requirements Engineering By now, I hope you have seen the ads for RE '97 in CACM, IEEE Computer, and IEEE Software. Moreover, you can review the WWW pages for RE '97 at http://www.itd.nrl.navy.mil/conf/ISRE97 Also, the IEEE Computer Society is mailing 8000+ copies of the 22-page RE'97 advance program later this week. The RE '97 REGISTRATION FORM and the HOTEL FORM are available over the web. Please take a few minutes to complete the forms (advance registration ends Dec. 1) and send them in, either by regular mail or by fax. As you will note from reviewing the program, this year we have four first-rate keynote speakers and several new events, including a two-day preconference tutorial program and an industrial program featuring presentations by industry on lessons learned and open problems in requirements. The tutorials cover topics where we hope there is broad interest---Making Requirements "Measurable", Requirements and Safety, Requirements Traceability, Object-Oriented Requirements Methods, and the SCR Approach to Requirements. The industrial program also includes a panel on how to achieve technology transfer and presentations by tool vendors and developers. This year, we are especially interested in signing up people for BOTH the technical program and the preconference tutorials. So, PLEASE distribute information about RE '97 to anyone you think might be interested. Let's generate some enthusiasm! Putting together all of the tutorials, the tools exhibit, the keynote speakers, the industrial program, the blurbs on the technical papers, etc., was a tremendous amount of work. A good (even great!) turnout for both the TECHNICAL PROGRAM AND THE PRE-CONFERENCE TUTORIALS makes all that work worthwhile. Note that our program is already beginning to generate enthusiasm in other communities. For example, last week, I received the message below from Charlie Payne. PLEASE HELP MAKE THIS THE BEST REQUIREMENTS MEETING EVER. Thanks in advance for your efforts to make RE '97 a success! ********************************************************************** [12] From: olly@soi.city.ac.uk (Orlena Gotel) Subject: EVENT: BCS RESG Programme of Events for 1997 The Requirements Engineering Specialist Group of the British Computer Society FORTHCOMING EVENTS 19th February 1997 - Second in the Room 101 Series ------------------ Title: Requirements Engineering - Clapping With One Hand? Speaker: Dr. Vic Stenning (Independent Consultant, Anshar Ltd & Visiting Professor, Dept. of Computing, Imperial College) Location: Room 418, Huxley Building, Imperial College, London (2:00 to 4:00pm) Cost: free to members of the RESG & students, 5 GBP to others 26th March 1997 - Half Day Tutorial --------------- Title: Business Specification Patterns Speaker: Haim Kilov (IBM TJ Watson Research Center, New York, USA) Location: Room 418, Huxley Building, Imperial College, London (2:00 to 5:00pm) Cost: 30 GBP to members of the RESG & students, 50 GBP to BCS members, 100 GBP to others 11th June 1997 - Afternoon Panel Session -------------- Title: Requirements for Off-the-Shelf Systems & Software Location: Room 418, Huxley Building, Imperial College, London (2:00 to 5:00pm) Cost: free to members of the RESG & students, 5 GBP to others 10th September 1997 - Evening Panel Session (with BCS Reuse SG) ------------------- Title: Requirements & Domain Modelling Location: UMIST, Manchester (6:00 to 8:00pm) Cost: free to members of the RESG, Reuse SG & students, 5 GBP to others 26th November 1997 - Presentations & Discussion (with BCS Quality SIG?) ------------------ Title: Quality Certification for the Requirements Engineering Process Location: Room 418, Huxley Building, Imperial College, London (2:00 to 5:00pm) Cost: free to members of the RESG, Quality SIG & students, 5 GBP to others 4th February 1998 - Presentations & Discussion ----------------- Title: Industrial Experiences in Requirements Engineering Location: York University (2:00 to 5:00pm) Cost: free to members of the RESG & students, 5 GBP to others Coming in Autumn 1997... --------------------- RE DAY - The Event You Can't Afford to Miss - Free to All! Featuring: keynote speakers, workshops/mini-tutorials, panel discussions, poster sessions, tool demonstrations, a publications stand, a soapbox & introducing "academics on trial" ***** Note that these events & dates are tentative. For more details, contact Dr. Orlena Gotel, Dept. of Computer Science, City University, London EC1V OHB. Fax: 0171 477 8587, email: olly@soi.city.ac.uk or visit http://www.OiT.co.uk/resg Please direct any RESG membership enquiries to Dr. Sara Jones, School of Information Sciences, University of Hertfordshire, Hatfield AL10 9AB. Fax: 01707 284303 or email: S.Jones@herts.ac.uk ********************************************************************** [13] From: olly@soi.city.ac.uk (Orlena Gotel) Subject: EVENT: Requirements Engineering - Clapping With One Hand? The Requirements Engineering Specialist Group of the British Computer Society TOPICS BANISHED TO ROOM 101 - 2nd in a series of controversial talks! TITLE: Requirements Engineering - Clapping With One Hand? SPEAKER:Dr. Vic Stenning (Independent Consultant, Anshar Limited & Visiting Professor, Dept. of Computing, Imperial College) DATE: Wednesday, 19th February 1997, 2:00-4:00pm VENUE: Room 418, Huxley Building, Dept. of Computing Imperial College, 180 Queen's Gate, London SW7 2BZ (South Kensington or Gloucester Road tube) COST: Free to members of the RESG & students 5 pounds sterling to others (BCS members - discounted membership of RESG available) ABSTRACT: Requirements engineering is often regarded as a self-contained activity that can and should be separated from design. Indeed, one of the traditional principles in the requirements arena is that so-called "premature design" must studiously be avoided. We argue that this stance is misguided, and that requirements and design are in fact mutually inter-dependent - solutions govern needs at least as much as needs govern solutions. Rather than attempting to compartmentalise and separate the activities of requirements definition and solution design, we should recognise that both form part of one holistic activity that takes the form of a continuous learning exercise for everybody involved. FOR MORE INFORMATION ABOUT: 1.The meeting, contact Dr. Orlena Gotel, Dept. of Computer Science, City University, Northampton Square, London EC1V OHB Fax: 0171 477 8587 or email: olly@soi.city.ac.uk 2.Membership of the RESG, contact Dr. Sara Jones, School of Information Sciences, University of Hertfordshire, Hatfield AL10 9AB Fax: 01707 284303 or email: S.Jones@herts.ac.uk 3.The RESG or BCS, visit our web home page http://www.OiT.co.uk/resg ********************************************************************** [14] From: gmul@sml.win-uk.net (Geoff Mullery) Subject: ARTICLE: The Perfect Requirement Myth copyright Requirements Engineering Journal (1996) 1: 132-134 (Viewpoints section) Springer-Verlag London Limited The Perfect Requirement Myth by Geoff Mullery There has, for years been a concept of a Project Life Cycle, in which a Requirement Specification phase figures as an early (sometimes the first) stage. The norm has been to attempt a complete, consistent, unambiguous specification of requirement before later stages of the project are allowed to start. The author's personal experience on performing and monitoring projects over more than 20 years has shown that to be unattainable (though there are those who would still argue otherwise). In order to preserve the ideal of perfection in the face of our inability to achieve it the notion of requirement maintenance was introduced. This is normally based on the idea that the original requirement, though appearing largely to meet the goals of perfection had some unforeseen problems at the edges, which required a small maintenance effort to put right. In reality, on the major systems which are so notorious for disastrous failure, an initial near-perfect requirement specification exercise, followed by a minor maintenance activity is a myth which retains credibility through the inability of the development community to recognise that there in no such thing as a single requirement specification. There are at least three overlapping, but mutually conflicting requirement specifications involved in a large, long-running development project - each with built in forces for change ensuring a continuous need to weigh the need for change against its consequences on each specification. It has become fashionable to concentrate on the Domain (or Operational) Requirement, which expresses those aspects of the domain of the proposed system which need support from it. The requirement which was traditionally produced was the Technical (or System) Requirement, which turns an understanding of the Domain Requirement into a specification of what the proposed system must provide in order to realise the Domain Requirement. The requirement which is almost universally ignored, but which severely compromises the quality of the other two is the Contractual Requirement, which expresses the restrictions on time and resources which must/can be used and the legal criteria for acceptance. It is an established fact that introduction of a new element to an environment causes the environment to adapt, eventually to find a new balanced state. This may involve the disappearance of old elements (extinction) or modifications in their structure or behaviour (evolution) or rejection of the new element as unfitted (an evolutionary dead-end). When a Domain Requirement is expressed it is assumed to be in the context of a simple extrapolation of the extant domain. For computer systems the reason for their introduction is frequently to achieve efficiency or cost-effectiveness gains or increased throughput. A problem which is neglected is that the new system is guaranteed to cause the evolutionary perturbances mentioned above. The Domain Requirement as originally expressed, if treated rigidly (as the Contractual Requirement usually demands) is almost guaranteed to be rejected as an evolutionary dead-end, since it cannot adapt to the changed domain behaviour it has itself introduced. Add to that the near certainty that the new system is not the only thing to introduce evolutionary change to the domain (e.g. in the military world, it is not only our side which introduces new weapon systems or sensors) and you see that attempting a basically fixed Domain Requirement with just minor maintenance needed is nonsensical. Another well established fact is that technology changes appear to grow exponentially. The rate of change and the sometimes revolutionary nature of the change causes the same evolutionary pressures to build on the technology available for development of the proposed system - and that can dramatically influence both what is required by the domain and what technology is required to support it. It has frequently been the case that new systems are introduced to service with hardware which is already obsolete or with facilities missing which are critical to the environment as it now is, because other elements of the domain have recognised a radical new technology. This means that the technology available for implementation is guaranteed to change and that its use in the domain will mean that the Domain Requirement changes and thence that the Technical Requirement changes. There is a further fact, which is that if the available technology changes the proposed system support requirements are likely to be subject to pressure for change (e.g. wide band data highways facilitate greater data transfer rates, which means that elements of the environment which were previously assumed to require co-location can now be distributed). These factors apply, not only at an artificial initial requirement phase, but through the development and service life of the system. Relating the Domain Requirement to the Technical Requirement is often attempted - but simplistically, via compliancy tables relating a paragraph in one form to a paragraph in the other form. This takes no account of the scope for change pressures in either of the forms of requirement. Nor does it take into account the impact of known omissions, inconsistencies and ambiguities in the two forms. The forms are assumed to be free of such problems, when in reality the problems are certain to be present - even if their presence is undocumented. A much more comprehensive and realistic approach to specification and inter-relation of specifications is needed than is seen in current practice. From the point of view of technical development staff the Cinderella of the specification process is the Contractual Requirement - yet it is the one which frequently turns the development process into a nightmare of infeasibility and threat of insolvency. While a specification technique may propose the need for completeness, consistency and freedom from ambiguity - and it may even try to define techniques for their achievement - it makes the default assumption that the time needed for its achievement will be taken. The Contractual Requirement specifies the time available for its achievement and may identify penalties for failure to deliver in that time. This means that the specifier must be able to forecast how long it will take to produce a complete, consistent, unambiguous specification - bearing in mind the two types of evolutionary change (Domain and Technical) which are under way, even as the requirement is being produced. The Contractual Requirement is highly likely to place significant difficulties in the path of responses to evolutionary pressure during the initial requirement specification stage and the later development stages - yet the pressure for those changes is guaranteed to occur. This means that, though the changed Domain Requirement may be understood and the resulting Technical Requirement changes may be easy to apply there is likely to be an enforced, extensive contractual negotiation before work can (financially) safely proceed. This can make apparently simple changes become infeasible. Ignoring the contractual implications can mean a build-up of simple changes which makes a feasible project infeasible. The Contractual Requirement typically also constrains the cost and frequently also the types of resource which can/must be used. It also is likely to identify the times at which those resources become available or unavailable. The need for the resources arises based on the progress through the development process - and that may be prescribed by the development method in use and compromised by the fickle finger of fate (staff resignations/sickness, fire at supplier premises, late availability of technology or support software, etc.). Contractually the supplier normally builds in contingency for such factors, but conventionally the contingency is quickly used up because of the genuine contingency features described and the evolutionary pressures arising in the other two forms of requirement. Resource availability/ timescale limitations expressed in a Contractual Requirement are likely to arise from other elements of the Domain, which are also under change and which share resources with the proposed system or which are perhaps to be co-located with the proposed system - thence requiring collaboration during the development and installation process (even though they do not directly communicate with the proposed system). This means that there may be pressures on the Contractual Requirement which arise from without the project for its development. Deadlines may be brought forward or resources may become unavailable when they were planned to be used for no reason of direct technical relevance to the project. There is nothing the technical developer can do to prevent these influences, but it is possible to relate the real technical information and plans of the project to the possible points of problem if only the possible points of influence of related projects are incorporated into the overall requirement specification process. This requires co-operation across disciplines (management, user and technician) in a way which typically does not currently happen. The case for the existence of overlapping and conflicting types of requirement as described here could be argued at greater length and with more specific examples, but in this presentation the only intent is to promote realisation that this type of requirement conflict exists and is guaranteed to continue to exist. It means that the notion of a perfect (or even near perfect) requirement specification is an unattainable ideal except in very limited cases (e.g. where what is being introduced is identical or a very minor evolution from what is already in place - I call this producing Electronic Mars Bars). When writing a Contractual Requirement it is necessary to allow for the influence of evolution by devoting significant down-stream resources to the requirement maintenance activity and by allowing greater flexibility in the time and cost profile, within the constraints of an overall budget and timescale restriction. When writing a Domain Requirement it is necessary to allow for the possibility of incompleteness, inconsistency and ambiguity to exist over a period of time, which may well extend through into the design and implementation stages. When writing a Technical Requirement it is necessary to forecast where the Domain Requirement is most likely to change, to cater for the imperfections guaranteed to remain in the Domain Requirement and to insulate against the possibilities of foreseeable technology changes, to allow for evolution of the requirement even as the system is developed. Overall, it is necessary for each type of requirement to be expressed and for each to be related to the others. It is necessary to recognise that the pressure for change exists in each and changes in each may compromise the plans of the others. This pressure for change is continuous across the life of the system and can probably be forecast to have local peaks at each point where a significant milestone is scheduled to occur. What constitutes a significant milestone in this context may go beyond the narrow confines of the current project, since it exists in an environment where there are highly likely to be other projects, not necessarily wholly controllable by the customer for this project, which will cause pressure for change. We can go on trying to deal with requirement specification as a single, near-perfect entity concerned only with the proposed system which is the primary purpose of the requirement exercise - but if we do, we will continue to fail when we attempt to specify and implement complex or diverse or long-lived systems for an evolving environment. Alternatively, we can start to look at how, over the life of such a system to allow for the process of change - both during the initial specification process and later as development and in-service use proceeds. ********************************************************************** [15] From: jgray@vuse.vanderbilt.edu (Jeff Gray) Subject: SUGGESTIONS: Ambiguous Statements I have been working on a collection of ambiguous and incomplete/ inconsistent natural language statements. Most of the collection is very humorous - statements made in real advertisements, signs, and other situations have been included. My main goal is to demonstrate how the reliance on natural langauge (especially in a SRS) can have an undesired effect. I invite you to check it out. The list can be found at: http://www.vuse.vanderbilt.edu/~jgray/funny.html Any suggestions or contributions would be greatly appreciated! In particular, I would like to add to the collection ambiguous statements which may have been encountered in actual specfications that you may have seen. ********************************************************************** [16] From: EndUser@unb.ca (Andrew McAllister) Subject: QUESTIONNAIRE: Preparing End-Users for Participation in ISD PREPARING END-USERS FOR PARTICIPATION IN INFORMATION SYSTEMS DEVELOPMENT Confidential Professional Questionnaire ======================================= PROJECT DIRECTOR Andrew McAllister ================ Faculty of Computer Science University of New Brunswick Fredericton, NB, Canada, E3B 5A3 Tel: (506) 453-4566 Fax: (506) 453-3566 e-mail: EndUser@unb.ca ============================================================= === INTRODUCTION === ============================================================= Information system development projects typically involve a partnership between systems development professionals ("developers") and end-users. An end-user can be defined as someone who brings to the project a knowledge of the business that is to be supported by the system. End-users often contribute to the project in ways such as the following: - By describing the information required to support their business process; - By helping to define the desired appearance and behaviour of the system; and - By helping to test the resultant system. Effective participation of end-users is a critical success factor for most projects. While knowledge of business requirements is fundamental, experience has shown that other skills and knowledge are also important for end-users. The purpose of this research project is to inventory the skills and knowledge areas that should be included in end-user training and educational materials. As someone who has participated in systems development either as an end-user or by working with end-users, you can provide an important contribution. This questionnaire allows you to relate the factors that, in your experience, are most important for end-users. Your participation will help to ensure that the result reflects a broad range of experience. Your involvement is greatly appreciated by the University of New Brunswick and especially the project director. Please be assured that both your responses and your identity will remain completely confidential. THANK YOU VERY MUCH FOR YOUR PARTICIPATION! ============================================================= === INSTRUCTIONS === ============================================================= Please e-mail the completed questionnaire to: EndUser@unb.ca Responses are preferred by January 6, 1997. PLEASE FORWARD THE SURVEY TO ANY COLLEAGUES FOR WHOM YOU THINK IT IS APPROPRIATE. For most questions the response can be typed as a single character. The following symbol is used to indicate where your response should be typed: ==> Comments can also be inserted wherever you wish. ============================================================= === BACKGROUND === ============================================================= 1. Which of the following most closely describes the role in which you have most recently served on an information system development project? (E)nd-user (S)ystems analyst/designer (P)rogrammer project (M)anager (O)ther: please specify ==> 2. For approximately how many years have you been involved in information systems development projects? ==> 3. Which of the following most closely describes the types of system development phases or activities in which you have been involved? (Indicate all that apply) (R)equirements analysis (D)esign (C)onstruction/programming (T)esting (I)mplementation/deployment (M)aintenance (O)ther: please specify ==> 4. Describe in your own words the industry sector in which you are currently employed? (for example government, consulting, manufacturing, retail, etc.) ==> 5. In which country are you currently employed? ==> 6. (OPTIONAL) What is the name of your employer? (company or organization name) ==> ============================================================= === END-USER KNOWLEDGE === ============================================================= This section lists several knowledge areas. Please indicate for each item if you have found it important for end-users to be knowledgeable in this area. (Y)es or (N)o. To help determine importance, you might consider the following questions: - Have you encountered project situations where end-users (including possibly yourself) could benefit from increased knowledge in this area? - Have you found that misconceptions, uncertainties, poor results or other negative impacts can occur if end-users lack knowledge in this area? - - - - - - - - - - - - - - - PLEASE INDICATE IF YOU HAVE FOUND IT IMPORTANT FOR END-USERS TO UNDERSTAND: 1. The business process that the system is to support. (Y or N) ==> 2. The roles and responsibilities of end-users. (Y or N) ==> 3. The necessity of end-user involvement for project success. (Y or N) ==> 4. The amount of time and effort required of end-users. (Y or N) ==> 5. The continuing time commitment of end-users throughout the project. (Y or N) ==> 6. Roles and responsibilities of other participants (analysts, project managers, etc.). (Y or N) ==> 7. Sensitivity to challenges faced by other participants. (Y or N) ==> 8. What to expect in terms of system development phases, activities and deliverables as the project proceeds. (Y or N) ==> 9. How selection and purchase of package solutions fits into the system development process. (Y or N) ==> 10.The importance of system documentation - why is it worth investing time and effort. (Y or N) ==> 11.The importance of deliverable validation and sign-off. (Y or N) ==> 12.System development terminology. (Y or N) ==> 13.The level of detail at which end-users must make decisions. (Y or N) ==> 14.The degree of control that end-users have in deciding upon features of the system. (Y or N) ==> 15.General knowledge of information technology. (i.e. The sorts of automated functionality that can reasonably be attained.) (Y or N) ==> 16.The reasons why automation frequently involves a redesign of business processes. (Y or N) ==> 17.External stresses on the project. (e.g. tight budgets or deadlines) (Y or N) ==> 19.Please describe any OTHER knowledge areas that you have found to be particularly important. ==> ============================================================= === END-USER SKILLS === ============================================================= PLEASE INDICATE IF YOU HAVE FOUND IT IMPORTANT FOR END-USERS TO BE ABLE TO: 1. Communicate verbally. (Y or N) ==> 2. Communicate in written form. (Y or N) ==> 3. Work well with others. (Y or N) ==> 4. Negotiate compromises. (Y or N) ==> 5. Analyze and document the business process that the system is to support. (Y or N) ==> 6. Use the productivity tools selected for the project. (word processor, e-mail, CASE tool, etc.) (Y or N) ==> 7. Use an "end-user computing" environment so that end-users can define AND BUILD their own systems and/or reports. (Y or N) ==> 8. Organize and run Joint Application Design (JAD) workshops. (Y or N) ==> 9. Review and provide feedback concerning documentation items, including system models. (Y or N) ==> 10.Evaluate and provide feedback concerning system prototypes. (Y or N) ==> 11.Propose alternative system solutions. (Y or N) ==> 12.Please describe any OTHER skills that you have found to be particularly important. ==> ============================================================= === ANECDOTAL INFORMATION === ============================================================= 1. Please describe the most common end-user misconceptions you have encountered. ==> 2. Please describe the most common end-user fears you have encountered. ==> 3. Please describe the most common ways you have found that end-user attitudes can help or hinder a project. ==> 4. Please relate any project stories that illustrate the importance of end-user knowledge or skills. ==> ============================================================= === SUMMARY ISSUES === ============================================================= 1. Which of the above skills and knowledge areas have you found to be MOST IMPORTANT? ==> 2. To what extent have you found that the "average" end-user possesses the important skills and knowledge WHEN PROJECTS BEGIN? (M)ost important skills and knowledge areas are known (S)ome are known (F)ew are known ==> 2. Have your projects involved formal planned training for end-users? (Y or N) ==> 3. Have your projects involved impromptu coaching or training for end-users? (Y or N) ==> 4. If "Y" for questions 2 or 3, which areas or skills did the training involve? ==> 5. To what extent have you found end-users to vary in terms of effectiveness? (S)ignificantly - some are MUCH more effective than others (M)oderately (N)ot much - most end-users tend be equally effective ==> 6. In your opinion, to what extent would it help to provide training or educational materials to end-users? (S)ignificantly - many end-users would become more effective (M)oderately (N)ot much - very few end-users would become more effective ==> 7. Any additional comments: ==> ============================================================= === RETURNING THE COMPLETED QUESTIONNAIRE === ============================================================= Please e-mail the completed questionnaire to: EndUser@unb.ca Responses are preferred by January 6, 1997. THANK YOU VERY MUCH FOR YOUR PARTICIPATION! ************************* OVER & OUT ********************************