Rationale Management in Software Engineering

1. Front Matter

   Pages i-xx

   PDF

2. Fundamentals – Rationale Representation, Capture, and Use

   1. Front Matter

      Pages 49-52

      PDF

   2. Rationale Management in Software Engineering: Concepts and Techniques

      • Allen H. Dutoit, Raymond McCall, Ivan Mistrík, Barbara Paech

      Pages 1-48

   3. Three Studies of Design Rationale as Explanation

      • Steven R. Haynes

      Pages 53-71

   4. Effective Design Rationale: Understanding the Barriers

      • John Horner, M. E. Atwood

      Pages 73-90

   5. Rationale as a By-Product

      • Kurt Schneider

      Pages 91-109

   6. Hypermedia Support for Argumentation-Based Rationale

      • Simon J. Buckingham Shum, Albert M. Selvin, Maarten Sierhuis, Jeff Conklin, Charles B. Haley, Bashar Nuseibeh

      Pages 111-132

3. Rationale Management for Requirements Engineering

   1. Front Matter

      Pages 133-136

      PDF

   2. A Hybrid Approach to Upstream Requirements: IBIS and Cognitive Mapping

      • John Rooksby, Ian Sommerville, Mike Pidd

      Pages 137-154

   3. From DREAM to Reality: Specificities of Interactive Systems Development With Respect To Rationale Management

      • Xavier Lacaze, Philippe Palanque, Eric Barboni, Rémi Bastide, David Navarre

      Pages 155-172

   4. The WinWin Approach: Using a Requirements Negotiation Tool for Rationale Capture and Use

      • Barry Boehm, Hasan Kitapci

      Pages 173-190

   5. Design Rationale in Exemplary Business Process Modeling

      • Holger Breitling, Andreas Kornstädt, Joachim Sauer

      Pages 191-208

   6. Promoting and Supporting Requirements Engineering Creativity

      • Lemai Nguyen, Paul A. Swatman

      Pages 209-230

4. Design Rationale and Software Architecting

   1. Front Matter

      Pages 231-236

      PDF

   2. A Framework for Supporting Architecture Knowledge and Rationale Management

      • Muhammad Ali Babar, Ian Gorton, Barbara Kitchenham

      Pages 237-254

   3. Capturing and Using Rationale for a Software Architecture

      • Len Bass, Paul Clements, Robert L. Nord, Judith A. Stafford

      Pages 255-272

   4. Rationale-Based Support for Software Maintenance

      • Janet E. Burge, David C. Brown

      Pages 273-296

   5. The Role of Rationale in the Design of Product Line Architectures – A Case Study from Industry

      • Jens Knodel, Dirk Muthig

      Pages 297-312

   6. The Role and Impact of Assumptions in Software Engineering and its Products

      • Meir Manny Lehman, Juan Fernándezl-Ramil

      Pages 313-328

   7. Design Decisions: The Bridge between Rationale and Architecture

      • Jan Salvador van der Ven, Anton G. J. Jansen, Jos A. G. Nijhuis, Jan Bosch

      Pages 329-348

Thirty years ago, I first entered the dark realm of software engineering, through a prior interest in documentation. In those days, documentation pretty much meant functional specifications. The idea that stakeholders in a system (its implementers, its end-users, its maintainers, and so forth) might want something other than an alphabetic list of function definitions was just taking hold. There was an exciting (to me) vision of stakeholders accessing and contributing to explanations of how and why aspects of a system work as they do, tradeoff analysis of concomitant downsides, and perhaps even accounts of why other possible approaches were not followed. There were many challenges to overcome in achieving this vision. The most formidable is the belief that people do not like to create or use do- mentation. This negative image of documentation is (unfortunately) more than just the bias of a few incorrigible system developers. It is more like a deep truth about human information behavior, about how human beings construe and act towards information. Humans are, by default, active users of information; they want to try things out, and get things done. When documentation is interposed as a prerequisite between people and a desired activity, they try to skip through it, circumvent it, or undermine it. Desi- ing information to suit the needs and interests of its users is an abiding challenge, but we have come a long way from functional specifications as the only answer.

• Knowledge Management
• Rationale Management
• Requirements Engineering
• Software Maintenance
• architecture
• design
• development
• management
• modeling
• software
• software architecture
• software development
• software engineering
• structured analysis
• technolo

Ten years ago, with Tom Moran, I edited a book entitled "Design Rationale." I think that book has held up quite well, though a decade onward it does seem a bit prefatory. It is past time for another detailed summary of research on design rationale. Allen Dutoit, Ray McCall, Ivan Mistrik and Barbara Paech have done an excellent job of this in "Rationale management in software engineering." The chapters in this volume show how design rationale can be incorporated into the heart of the software development process - into requirements engineering, software architecture, and code design. (John Carroll, School of Information Sciences and Technology, Penn State University, USA)

• Institut für Informatik, Technische Universität München, Garching bei München, Germany

  Allen H. Dutoit

• College of Architecture & Planning, University of Colorado, Boulder, USA

  Raymond McCall

• Publication and Information Systems, Fraunhofer Institute für Integrated, Darmstadt, Germany

  Ivan Mistrík

• Institut für Informatik, University of Heidelberg, Heidelberg, Germany

  Barbara Paech