Requirements Engineering and Analysis Workshop Proceedings

Technical Report CMU/SEI-91-TR-30 ESD-TR-91-30 Requirements Engineering and Analysis Workshop Proceedings Requirements Engineering Project December 1991 Technical Report CMU/SEI-91-TR-30 ESD-TR-91-30 December 1991 Requirements Engineering and Analysis Workshop Proceedings Requirements Engineering Project Unlimited distribution subject to the copyright. Software Engineering Institute Carnegie Mellon University Pittsburgh, Pennsylvania 15213 This report was prepared for the SEI Joint Program Office HQ ESC/AXS 5 Eglin Street Hanscom AFB, MA 01731-2116 The ideas and findings in this report should not be construed as an official DoD position. It is published in the interest of scientific and technical information exchange. FOR THE COMMANDER (signature on file) Thomas R. Miller, Lt Col, USAF SEI Joint Program Office This work is sponsored by the U.S. Department of Defense. Copyright © 1991 by Carnegie Mellon University. Permission to reproduce this document and to prepare derivative works from this document for internal use is granted, provided the copyright and “No Warranty” statements are included with all reproductions and derivative works. Requests for permission to reproduce this document or to prepare derivative works of this document for external and commercial use should be addressed to the SEI Licensing Agent. NO WARRANTY THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRAN- TIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTIBILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. This work was created in the performance of Federal Government Contract Number F19628-95-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The Government of the United States has a royalty-free government-purpose license to use, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so, for government purposes pursuant to the copyright license under the clause at 52.227-7013. This document is available through Research Access, Inc., 800 Vinial Street, Pittsburgh, PA 15212. Phone: 1-800-685-6510. FAX: (412) 321-2994. RAI also maintains a World Wide Web home page. The URL is http://www.rai.com Copies of this document are available through the National Technical Information Service (NTIS). For information on ordering, please contact NTIS directly: National Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161. Phone: (703) 487-4600. This document is also available through the Defense Technical Information Center (DTIC). DTIC provides access to and transfer of scientific and technical information for DoD personnel, DoD contractors and potential contractors, and other U.S. Government agency personnel and their contractors. To obtain a copy, please contact DTIC directly: Defense Technical Information Center, Attn: FDRA, Cameron Station, Alexandria, VA 22304- 6145. Phone: (703) 274-7633. Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder. Table of Contents 1 Executive Summary 1 1.1 Requirements Engineering Processes and Products 1 1.2 Requirements Volatility 2 1.3 Requirements Elicitation 2 1.4 Requirements Engineering Techniques and Tools 3 1.5 Overall Recommendations and Conclusions 4 2 Purpose and Structure of the Workshop 5 3 Requirements Engineering Processes and Products 7 3.1 Participants 7 3.2 Introduction 7 3.3 Discussions 8 3.3.1 Coping with Uncertainty and Change 8 3.3.2 Improving Requirements 10 3.3.3 Resolving Multiple Stakeholder Conflicts 12 3.3.4 Tracking Requirements Progress 13 3.4 Summary of Recommendations 15 3.5 A Summary of the Results from the CECOM Workshop 16 3.5.1 Problems 16 3.5.2 Recommendations 16 4 Requirements Volatility 19 4.1 Participants 19 4.2 Purpose of the Group 19 4.3 Discussion 19 4.3.1 Planning for Changes 19 4.3.2 Specifying Requirements for the User Interface 20 4.3.3 Prototyping 21 4.3.4 Testing 21 4.3.5 Improving the Quality of the Requirements 21 4.3.6 Reporting Development Changes 22 4.3.7 Using Incremental Development 22 4.3.8 Tracing Changes 22 4.3.9 Using Hierarchical Requirements 23 4.3.10 Applying Technologies 23 4.3.11 Changing the Development Process 24 4.4 Group Recommendations 24 5 Requirements Elicitation 25 5.1 Participants 25 CMU/SEI-91-TR-30 i 5.2 Introduction 25 5.3 Current Elicitation Practices 26 5.3.1 Common Practice 29 5.4 Problems with Elicitation 30 5.4.1 Communication Issues 30 5.4.2 Traceability Issues 32 5.5 General Process Issues 34 5.6 Suggestions for Improving the Elicitation Process 35 5.6.1 Communication Issues 35 5.6.2 Traceability Issues 36 5.6.3 General Process Issues 37 6 Requirements Engineering Techniques and Tools 39 6.1 Participants 39 6.2 Introduction 39 6.3 Discussion 39 6.4 Meaning of Context Analysis 40 6.5 Summary of Current or Potential Approaches 41 6.6 Gaps in Existing Technology 41 6.7 Identified Research Topics 42 6.8 Summary 49 References 51 Appendix A Position Papers 53 ii CMU/SEI-91-TR-30 List of Figures Figure 4-1 General Model of Communication for Requirements Engineering 25 Figure 5-1 AYK-14 SAC Example of Requirements Elicitation 28 CMU/SEI-91-TR-30 iii iv CMU/SEI-91-TR-30 List of Tables Table 1 Current and Potential Approaches 44 Table 2 Research Topics 47 CMU/SEI-91-TR-30 v vi CMU/SEI-91-TR-30 Requirements Engineering and Analysis Workshop Proceedings 1 Executive Summary Inadequate, incomplete, erroneous, and ambiguous system and software requirements are a major and ongoing source of problems in systems development. These problems manifest themselves in missed schedules, budget excesses, and systems that are to varying degrees unresponsive to the true needs of the sponsor. These difficulties are often attributed to the poorly defined and ill-understood processes used to elicit, specify, analyze, and validate requirements. The Software Engineering Institute (SEI) hosted the Requirements Engineering and Analysis Workshop in Pittsburgh, Pennsylvania, on March 12-14, 1991. The intention of the workshop was to focus discussion on issues and activities that could help the Department of Defense (DoD) to deal more effectively with the requirements of mission-critical systems. The SEI workshop built upon work performed previously at the Requirements Engineering and Rapid Pro- totyping Workshop held by the U.S. Army Communications-Electronics Command (CECOM) Center for Software Engineering in Eatontown, New Jersey, on November 14-16, 1989. The workshop participants were divided into four working groups: Requirements Engineering Process and Products, Requirements Volatility, Requirements Elicitation, and Requirements Engineering Techniques and Tools. A summary of the findings of each working group follows. 1.1 Requirements Engineering Processes and Products The Requirements Engineering Processes and Products group investigated process-related problems in requirements engineering. The group looked at the recommendations made by the CECOM workshop participants and considered the reasons why those recommendations have not yet been implemented. The group adopted the major issues of concern identified by the CECOM workshop: coping with uncertainty and change, reducing the difficulty in validation, resolving multiple stakeholder conflicts, and tracking requirements progress. The following strategies were proposed to facil- itate adoption of the CECOM recommendations: • Encourage innovation in the acquisition process including adaptation of DOD-STD-2167A (Military Standard, Defense System Software Development) and associated data item descriptions (DIDs) to support an evolutionary process model. • Emphasize up-front requirements engineering, including the early introduction of specification and analysis methods and the encouragement of prototyping techniques for early validation of operational concepts and user interfaces. CMU/SEI-91-TR-30 1 • Develop a multi-disciplinary team approach, to include users, domain experts, analysts, developers, testers, and maintainers in the analysis and decision-making process. • Capture lessons learned in the acquisition process, including both successful and unsuccessful acquisitions, then make those lessons learned available to other projects. 1.2 Requirements Volatility The Requirements Volatility group investigated the causes of volatility in requirements and possible steps toward reduction or management of such volatility. The most important point to be made is that requirements will change throughout the life of a system, no matter how good the requirements are initially. Recognizing that requirements will change permits requirements engineers to plan for changes and reduces the unwanted side effects of the changes. Although there were no specific recommendations from the group, the following issues were noted as needing further investigation. Requirements should be structured in a number of ways. Modular structuring is desirable because it reduces the effects of change. Hierarchical structuring is desirable because it provides appropriate levels of abstraction of requirements. View-oriented structuring is desirable because the different parties (e.g., tactical, strategic, etc.) have different understandings of the system. We need to understand how the different structuring approaches can be combined to produce requirements that are appropriate for the readers. Volatility can be reduced by the use of prototyping in parts of the system that are not well understood at the outset of requirements engineering. More investigation of prototyping techniques is needed, however, particularly for the user interface. The current process for system development does not easily accept the notion that requirements will change during system development. Therefore, other development processes that will allow for changes in requirements should be considered.

Load more