Date: Tue, 24 Aug 93 17:50:35 BST To: re-world@doc.ic.ac.uk From: acwf@doc.ic.ac.uk (Anthony Finkelstein) X-Sender: acwf@gummo.doc.ic.ac.uk Subject: REQUIREMENTS ENGINEERING NEWSLETTER (9) ****************REQUIREMENTS ENGINEERING NEWSLETTER******************** No. 9. 1. Good News! (Anthony Finkelstein) 2. Univ. of Oregon RE reports (Anne Dardenne) 3. Imperial College RE reports (Olly Gotel) 4. CFP 4th Systems Reengineering Workshop (Bruce Blum) 5. Glossary of Software Engineering Terms (Annie Anton) Contents Contributions to: re-list@doc.ic.ac.uk (will be moderated) Subscription or Removal 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 ********************************************************************** From: Anthony Finkelstein (acwf@doc.ic.ac.uk) Subject: Good News! The IEEE CS Press have been persuaded to reprint the bestselling RE93 Proceedings... > Proceedings of RE93 (International Symposium on Requirements Engineering > 1993) are available from the IEEE CS Press. The ISBN is 0-8186-3120-1. The > catalog number is 3120-02. The cost is $60 ($30 for members). You can > obtain a copy by sending a fax to IEEE CS Press Customer Services on > 714-821-4010. The new printing should be ready shortly. Demand a copy from your library. ********************************************************************** From: Anne Dardenne Subject: Univ. of Oregon RE reports The following report is now available. To receive a copy, send email to Jan Saunders (jan@cs.uoregon.edu). Report number: CIS-TR-93-17 On the Use of Scenarios in Requirements Acquisition Anne Dardenne University of Oregon Computer and Information Science Dept. Eugene, OR 97403 (USA) Abstract This report will focus on the use of scenarios in requirements acquisition. Requirements acquisition is the very first step of the software life-cycle. It is now well established that it has a major impact on subsequent steps. There are several ways in which users can describe requirements. We will focus on scenarios. We are interested in scenarios for requirements acquisition because it seems that it is a very natural way for people to describe what they want a system to do. We plan to build a tool that will help acquire scenarios from users. The tool functionality is outlined in the report. ********************************************************************** From: Olly Gotel (oczg@doc.ic.ac.uk) Subject: Imperial College RE reports The following new report is available via anonymous FTP from ftp-host: dse.doc.ic.ac.uk (IP number: 146.169.2.20) directory: dse-papers All the papers in this directory are compressed postscript. Remember to set binary mode before transfering them! analysisrt.ps.Z Gotel, O. & Finkelstein A. (1993); An Analysis of the Requirements Traceability Problem; Imperial College, Department of Computing Technical Report; TR-93-41. Abstract: In this report, we investigate and discuss the underlying nature of the requirements traceability problem. Our work is based on empirical studies carried out with over a hundred practitioners and an evaluation of current support for requirements traceability. We introduce the distinction between pre-requirements specification traceability and post-requirements specification traceability, to demonstrate why an all-encompassing solution to the problem is unlikely, and to provide a framework through which to understand its multifaceted nature. We report how the majority of the problems attributed to poor requirements traceability are mainly due to the lack of, or inadequate, pre-RS traceability and explain the fundamental need for improvements here. In the remainder of the report, we present an analysis of the main barriers confronting such improvements in practice, identify relevant areas in which advances have been, or can be made, and make recommendations for further research. ********************************************************************** Subject: CFP 4th Systems Reengineering Workshop From: bib@aplcomm.jhuapl.edu (Blum Bruce) CALL FOR PAPERS FOURTH SYSTEMS REENGINEERING TECHNOLOGY WORKSHOP February 8-10, Monterey, California This is the fourth of a series an annual workshops sponsored by the Naval Surface Warfare Center (NSWC). The motivation for these workshops stems from the fact that the Navy has invested billions of dollars in the development of systems that may be modified and extended to respond to changing requirements. Systems reengineering technology is necessary if the Navy (as well as the other users of large-scale, complex systems) are to benefit from their extensive investments. The workshop brings together representatives of government, industry, and academia to address the issues confronting this technology. Although the principal interest of the sponsors is the reegineering of embedded, real-time systems that include hardware, software, and human-computer interaction, the workshop encourages the participation of individuals and organizations concerned with the reengineering of large-scale, complex systems. Suggested topics include but are not limited to: Systems reengineering process models Evaluation methods and metrics for reengineering Reengineering tools and environments Reuse, domain analysis, and domain modeling Redocumentation support Program translation (e.g., CMS-2 to Ada) The use of models and simulations in reengineering Reverse engineering methods and tools Problems of integration and transition Guidelines and insights from maintenance experience Case studies are particularly welcome, even if the reengineering project took place in a domain other than embedded, real-time applications. Selection of papers for presentation will be based on 5-10 page submissions. All accepted papers may be extended for inclusion in the workshop proceedings. Selected authors will be invited to revise their papers for inclusion in a special issue of the Journal of Systems and Software. Submitted papers must identify the author to be contacted as well as his or her address, telephone, e-mail, and fax number. Send 3 copies of the paper to Bruce I. Blum Tel: (301) 953-6235 Room 2-246 Fax: (301) 953-6904 Applied Physics Laboratory bib@aplcomm.jhuapl.edu Laurel, MD 20723-6099 (E-mail transmission of an ASCII version of the paper will be accepted.) Key dates: November 1, 1993 Draft paper to B. Blum November 15, 1993 Notification of acceptance sent out January 7, 1994 Camera ready final paper due Workshop Chair Mark Wilson Code B40 Naval Surface Warfare Center Silver Spring, MD 20903-5000 mlwilson@relay.nswc.navy.mil Workshop Location Monterey Marriott Monterey, California Program Co-chairs Gilbert Myers Code 41 NRAD 271 Catalina Blvd. San Diego, CA 92152-5000 Tel: (619) 553-4136 gmyers@nosc.mil Bruce I. Blum (Address given above) ********************************************************************** From: Annie I. Anton Subject: Glossary of Software Engineering Terms Glossary of Software Engineering Terms Capability maturity model a method of determining to what extent the developer can reasonably be blamed for the inevitable failure Cleanroom a management technique that applies to horizontal interfaces what the mushroom technique applies to vertical interfaces Compiler a tool for adding an exciting amount of uncertainty to the size, speed and correctness of a program Computer human interface the means by which the program conditions the user into never trying all the things that don't work Cost modelling a means of convincing the customer to pay for whomever you need to keep employed this year Customer a primitive life form at the bottom of the food chain Debugger a tool that substitutes afterthought for forethought Design the activity of preparing for a design review Design review a process for ensuring you know exactly what it is you won't build Documentary hypothesis the discredited notion that software is the outcome of a systematic and rational process of development, rather than the result of divine inspiration Documentation a process for converting trees into entropy, usually applied to provide busywork for the people whose employment cannot be justified by cost modelling Domain a class of applications where failure on one project gives you an advantage in bidding on the next Enhancement breaking what you did right and getting paid for it [see also: maintenance] Formal verification the construction of an incorrect proof isomorphic to an incorrect program Function point analysis cost modelling a program by what it won't do, rather than by how big it won't be Incremental implementation delivering several partial products each for the price of a complete one Maintenance fixing what you did wrong and getting paid for it [see also: enhancement] Programs what software used to be, back when we knew how to write it Programmer one who is too lacking in people skills to be a software engineer Project management the art of always knowing how badly you're doing your work and how late you're doing it Quality assurance a way to ensure you never deliver shoddy goods accidentally Real time an attribute applied to software that's even more expensive than can be justified by cost modelling Requirements analysis determining what it is you can't do before failing to do it Requirements engineering convincing the customer to want what you think you can build Requirements review explaining what the customer won't get in language they don't understand Reuse using an existing product in a new context; especially as applied to proposals, resumes, disclaimers and excuses Software engineer one who engineers others into writing the code for him/her Spiral model a development model that allows you to fail in a small way several times over [see also: waterfall model] State-of-the-art what we could do with enough money State-of-the-practice what we can do with the money you have Structured walkthrough the process whereby the false assumptions of one member become shared by an entire team Technology transition helping people replace old useless processes, methods and tools with new useless processes, methods and tools Testing a process for ensuring that the product will work in all circumstances that anybody other than the user can imagine Total quality management a way of teaching your managers five words of Japanese, without any risk that they will acquire an equivalent amount of competence User a harmless drudge Waterfall model a development model that allows you to fail in a big way just once ********************************************************************** ______________________________________________________________________________ Anthony Finkelstein | Email: acwf@doc.ic.ac.uk Imperial College, | Phone: +44 71 589-5111 x7535 Department of Computing, | Fax: +44 71 581 8024 180 Queens Gate, | London SW7 2BZ, UK | _____________________________________________________________________________