Handbook of Software Engineering and Knowledge Engineering Vol 0, No. 0 (2000) 000-000 © World Scientific Publishing Company

RATIONALE MANAGEMENT IN SOFTWARE ENGINEERING ALLEN H. DUTOIT1 and BARBARA PAECH2 1

Technische Universität München Institut für Informatik Munich, Germany E-mail:[email protected]

2 Fraunhofer Institute Experimental Software Engineering Kaiserslautern, Germany E-mail: [email protected]

In this chapter, we motivate and describe the use of rationale knowledge during software development. Rationale methods aim at capturing, representing, and maintaining records about why developers have made the decisions they have. They improve the quality of decisions through clarification of issues and their related tradeoffs. Moreover, they facilitate the understanding and reevaluation of decisions, which is an important prerequisite for managing change during software development. While there are several approaches for dealing with rationale knowledge, the systematic integration of rationale into software engineering processes and tools has yet to happen. In this chapter, we first introduce the fundamental rationale concepts. Next, we identify the knowledge management tasks that are related to identifying, eliciting, organizing, disseminating, and using rationale knowledge. Based on this, we survey representative rationale methods and illustrate the issues involved with a more detailed example on rationale management for requirements. We conclude with a discussion of open issues and future directions in rationale research. Keywords: Design rationale; Software evolution; Negotiation; Issue model; QOC; IBIS.

1. Introduction Rationale1 methods aim at capturing, representing, and maintaining records about why developers have made the decisions they have [8]. Rationale includes the problems developers encountered, the options they investigated, the criteria they selected to evaluate options, and, most important, the debate that lead to making decisions. Rationale can serve two different purposes: discourse and 1

Historically, much research about rationale focuses on design and, hence, the term design rationale is most often used in the literature. Instead, we use the term rationale to avoid confusion and to emphasize that rationale models can be used during all phases of development, including requirements engineering, system design, implementation, and testing. 1

2

Handbook of Software Engineering and Knowledge Engineering

knowledge capture. By making explicit the main decision making elements, rationale facilitates negotiation among developers by systematically clarifying the possible options and their evaluation against well-defined criteria. By capturing rationale, developers make explicit knowledge that is usually only implicit and can later examine the justification of certain decisions, for example, when changing the system as a consequence of evolving requirements or the availability of new technology. There are several reasons for integrating rationale methods in software engineering. First, software engineering, as in other design activities, involves the collaboration of many participants from different backgrounds and requires the negotiated settlement of many issues. Rationale methods, as negotiation support, clarifies issues and their related trade-offs for the involved participants. Second, software systems are complex and changing artifacts: They result from the making and reopening of many interdependent decisions. Capturing not only these decisions but also their dependencies and the justification behind them facilitates their reevaluation later in the development process. The capture and organization of rationale, while introducing an overhead during early phases of development is beneficial during later and more costly phases such as maintenance [12]. The application of rationale methods to software development is not new. General methods have been proposed to capture rationale as a graph of issues [12][23][30]. Specific methods have successfully tackled specialized issues, for example, in the area of requirements engineering [2][34][40]. While research efforts have focused on specialized applications of rationale, the systematic integration of rationale into software engineering processes and tools has yet to happen. Such a systematic integration would lead to a rationale centered development process, where rationale provides critical decision making information for system modeling and project management. In this chapter, we present and discuss the various uses of rationale management in software engineering. We describe the concepts behind rationale management (Section 2) and their relationship with knowledge management (Section 3). We provide examples of their application to software engineering and the experiences made (Section 4). We also illustrate them with an example process and tool in use case software development (Section 5). We then examine the challenges of rationale management which still need to be addressed (Section 6).

2. Rationale, Knowledge, and Software Engineering Concepts In this section, we define the fundamental rationale management and software engineering concepts we use in this chapter. First, we distinguish between the different types of knowledge in software engineering and their use within a project and within an organization. Next, we examine the representations for

Rationale Management in Software Engineering

3

rationale knowledge, and, finally, we discuss the different levels of use of rationale in development projects.

2.1 Knowledge Needed in Software Engineering Software engineering requires different types of knowledge depending on the activities being carried out. We distinguish between two types of knowledge: • System knowledge pertains to the system under construction. This knowledge is represented by several models looking at the system from different points of view. For example, the requirements analysis model describes the system from the end users’ point of view. The system design model describes the system in terms of components, boundary conditions, and global control flow. System knowledge is used by developers to design and validate the system at various stages of development. Parts of the system knowledge gained during a project can be generalized for the benefit of the organization. For example, a system architecture is a generalized system model that represents the structure of a class of systems with a common property. A design pattern represents a template solution to a common, local design problem. • Process knowledge pertains to the work required to develop the system, including knowledge about roles, resources, tasks, and work products. Process knowledge makes clear the responsibilities of each participants and the tasks they are currently accomplishing. Process knowledge is used by management and developers to plan and monitor work during development. As for system knowledge, process knowledge can be generalized across projects. For example, general process models describe a class of projects with common properties (e.g., same application domain, same staff expertise). For example, [22] in this book deals with knowledge management in software engineering related to process knowledge. We further characterize knowledge based on the scope of its use: • Product knowledge includes the system and process knowledge gained and used by a specific project in the course of developing a single system or a single product line. Product knowledge includes both system and process knowledge. A product’s system knowledge comprises all the system models and the information specific to the system. A product process knowledge comprises all of task plans, schedule, budget, and constraints specific to the development of the system. • Organizational knowledge includes the knowledge shared among the organization by multiple projects. System generalizations, such as domain models, design patterns, and software architectures, and process generalizations, such as generic process models and company procedures, are organizational knowledge. Organizational knowledge is much more structured and long lived than product knowledge.

4

Handbook of Software Engineering and Knowledge Engineering

All four types of knowledge (project system, project process, organizational system, and organizational process) can be augmented with rationale knowledge (see Table 1). Rationale is the justification of decisions. Rationale includes the problems that were solved, options that were considered, criteria that were used when evaluating options, arguments supporting or opposing options, and the decisions that were made to address problems. Rationale can be used by both management and developers to represent the justification of system or process decisions. While system and process knowledge focuses on the system and the work, rationale knowledge focuses on the decision making elements that lead to the system and process knowledge. Note that rationale can apply to both project and organizational knowledge. In this chapter, however, we focus exclusively on knowledge in the scope of a project and do not examine the implication of rationale in the organizational scope. Table 1 summarizes the types and scope of knowledge we introduced in this section and their relationship to different roles and activities. Table 1. Knowledge needed in software engineering, rationale knowledge emphasized with gray.

Represents

Product Knowledge

What

Why (rationale)

Organizational Knowledge

What

Why (rationale)

System Knowledge

Process Knowledge

System

Work Roles Resources Project plan Budget Expenditures Policies & Procedures

Specification System Design Object Design Source code Test plans and results Justification behind the system, including development goals and criteria, alternatives evaluated, and their evaluation Domain models System architectures Design patterns Justification behind the generalized model, such as forces and trade-offs

Justification behind the task plan, including risk assessments, contingency plans, management goals & criteria, Process models Best practices Experiences Justification behind the generalized model, such as success factors associated with practices.

2.2 Representation of Rationale Rationale can be represented in several different ways [38], including as justifications in natural language, as rules in a knowledge-based system, or as arguments structured in rhetorical steps. The latter case, called argumentationbased rationale, represents rationale as a graph of nodes and edges, each node representing a decision making element or rhetorical step and each edge

Rationale Management in Software Engineering

5

representing a relationship between two elements. For example, the QOC notation ([30], Fig. 1) uses four rhetorical steps: • Questions represent problems to be solved, such as a design issue, a need for clarification, or a disagreement. • Options represent considered alternatives for answering a question. Options include designs, changes to a document, or clarifications. • Criteria represent qualities that are used to evaluate options in a certain context. Criteria include design goals (e.g., reliability, cheapness, performance) and management goals (e.g., on time delivery, under budget delivery). The assessment of an Option against a set of criteria is represented with assessment links between the option and the criteria nodes. • Arguments represent justifications of options or criteria as expressed by the participants. Arguments can support or oppose another rhetorical node. Question responds-to

objects-to supports

is a consequence of Option

objects-to supports

Argument objects-to supports

positive assessment negative assessment Criterion

Fig.1. Questions, Options, and Criteria (QOC), an argumentation-based representation of rationale [30] (UML class diagram, arrows depict associations navigation paths).

Consider, for example, the following argument examining the authentication mechanism in the context of the development of an Automated Teller Machine (ATM): “We considered three possible authentication mechanisms for the ATM: 1. the user enters an account number and a personal identification number, 2. the user inserts a card and enters a personal identification number, and 3. the user inserts his finger in a finger print scanner. We found that the first option is the cheapest but the least secure. The third option offers the most flexibility to the user (no card to carry around and to lose, no personal number to forget) and is the most secure. However, the cost of the third option and the lack of security of the first option lead us to select option 2.” Fig. 2 depicts an equivalent representation of the rationale described above using QOC. Argumentation-based representations, also called issue models, are widely used representations in rationale management [12][23][24]. Current research issues focus on the capture of rationale, its structuring as an issue-model, its

6

Handbook of Software Engineering and Knowledge Engineering

integration with other models, and the maintenance of the model. Next, we examine the different levels of use of rationale in development projects. Which Authentication Mechanism?:Question responds-to ––

Account&PIN:Option

Flexibility:Criterion

+

++

responds-to Card&PIN:Option

+

++ Low cost:Criterion ––

responds-to FingerPrint:Option

– + ++

Security:Criterion

Fig.2. An example of an issue model (UML object diagram).

2.3 Levels of Rationale Use Capturing rationale represents an early investment of resources which needs to be traded off against the potential later benefits. In other words, not all types of projects may benefit from such an investment. In general, we distinguish between four levels of rationale use [6] which depend on whether the rationale is captured and organized during or after development and how much rationale should be captured: • No explicit rationale capture. Resources are focused on development. No effort is invested in capturing or organizing rationale. Rationale information is present only as side effects of the development effort, such as in communication records (e.g., E-mail, faxes, meeting minutes) and developers’ memories. • Rationale reconstruction. Resources are spent in recovering and organizing rationale after the development is completed. Major goals, problems, and decisions are captured and justified based on records and developer knowledge. Discarded options and arguments are not captured. • Rationale capture. Resources are spent in capturing rationale during development. The goal is to prevent the loss of information which occurs in the previous level. The rationale is then organized and completed after development. • Rationale integration. Resources are spent to capture and organize rationale during development. This enables developers to also effectively access rationale. Rationale becomes an integral part of the development processes and tools. Rationale knowledge lives in an information base that is updated and augmented as development proceeds.

Rationale Management in Software Engineering

7

For projects in which capturing and using rationale makes sense, the benefits associated with rationale are the highest in the last level. The overhead associated with capturing and organizing rationale is lowest in the last level, assuming an integrated and pervasive process and tool support. For example, Grudin in [18] distinguishes four different types of development: off-the-shelf product development, internal or inhouse system development, large competitively bid development contracts, and smaller customized software development project. In each development context, the opportunities and barriers for using rationale techniques are different. Two examples at opposite ends of the spectrum are the off-the-shelf product development and the customized software development: • In off-the-shelf product development, project termination rates and staff turnover are high. Even though the availability of rationale records would make it easier for new developers to come on board, the constant pressure to show results frequently gives developers push ahead with coding and avoid any tasks requiring a short term overhead (including rationale techniques). Consequently, off-the-shelf product development projects are likely to fall into one of the first two levels of rationale use. • In customized software development projects by consulting companies, relationships with customers are often close and long term relationships. Moreover, consulting companies often target specific application domains and will reuse software from one customer to the next. In these context, the capture of rationale of reusable components and the system that include them can significantly lower the setup cost of a new project, thus representing a strong incentive for the consult company. In addition, rationale can serve to capture the company’s know how in the application domain and protect against staff turnover. We expect such development projects to fall into the last level of rationale use. In general, the decision about when and how much rationale to capture is constrained by the short term risk associated with redirecting personpower from development to rationale capture. A project with a high risk of cancellation (e.g., an off-the-shelf product development) will capture some rationale during development and delay the organization of the rationale until the end of the project, or, most likely, delay both the capture and the organization of rationale until a later phase. A long running noncompetitive project, on the other hand, will most likely capture and organize rationale concurrently to development activities.

3. Rationale Management Tasks In Section 2, we characterize rationale as a particular knowledge generated and used during software development. In this section, we characterize rationale management tasks as specific knowledge management tasks.

8

Handbook of Software Engineering and Knowledge Engineering

There are currently no generally accepted definitions of knowledge management. The definitions vary according to the origin within such different disciplines as economy, organizational science, information science, sociology, or psychology. Today, the most prominent driving factor to develop knowledge management techniques and tools is the area of organizational learning [27]. It aims at improving the know-how transfer within and to an enterprise, at making explicit and easy-to-use documentation of the know-how, and at evaluating the return of investment of knowledge management techniques. [13] presents a study of 31 ongoing knowledge management projects in 24 enterprises which evaluates the aims and results of these projects. In the following, we discuss the tasks to be supported by knowledge management and the specifics of rationale management.

3.1 Knowledge Tasks The task model depicted in Fig. 3 is taken from [36]. Similar distinctions can be found in [4] who discuss the technology needed for knowledge management and in [1] who discuss the use of knowledge management of software engineering lessons learned. Fig. 3 shows two kinds of tasks: Knowledge Goals Definition

Knowledge Measurement

Knowledge Identification

Knowledge Preservation

Knowledge Acquisition

Knowledge Use Knowledge Development

Knowledge Distribution

Fig. 3. Knowledge management tasks (UML Activity diagram).

• •

Strategic tasks: knowledge goals definition and knowledge measurement. Operational tasks: knowledge identification, knowledge acquisition, knowledge development, knowledge distribution, use of knowledge and knowledge preservation. The two strategic tasks are important to drive and control the knowledge management process. • Knowledge goals definition focuses the process on particular kinds of knowledge and their expected benefits of the process. • Knowledge measurement ensures the quality of the process and its results by comparing them with the expected benefits.

Rationale Management in Software Engineering

9

The operational tasks describe the generation and handling of the knowledge. • Knowledge identification aims at identifying the knowledge which is available in a specific context and important to achieve the knowledge goal together with the sources of this knowledge (internal or external, human or material). • Knowledge acquisition is needed to elicit the knowledge from the identified knowledge sources. This is particularly important for implicit knowledge. The execution of this task must be sensitive to psychological issues, since human knowledge sources are not necessarily motivated to give away their knowledge. • Knowledge development aims at packaging, consolidating, and enhancing the available knowledge. Typically, this is realized by communicating about the knowledge, integrating knowledge from different sources, and representing it in a specific format. • Knowledge distribution is the first step for a comprehensive use of the knowledge in the relevant context. Typical technology used nowadays is the internet or intranet. • Knowledge use is the key task where the return of investment of the knowledge management process is generated. Here, again, main psychological issues, such as the NIH-syndrome (Not-Invented-here Syndrome), have to be taken into account. Often, specific incentives to use the knowledge have to be given. • Knowledge preservation aims at preventing uncontrolled loss of knowledge. It consists of selection and storage of new knowledge as well as adaptation of existing knowledge (including controlled deletion). This supports one of the key factors to motivate the use, namely that the knowledge is up-to-date.

3.2 Rationale Management Tasks In the following, we discuss the specifics of rationale management tasks, again separating strategic from operational tasks: Strategic rationale management tasks include: • Identifying rationale goals. As described in the introduction, typical rationale goals include: • Improve quality. Software development involves the participation of stakeholders with different backgrounds and different objectives. Rationale improves the quality of decisions by making decision criteria and the evaluation of alternatives explicit. • Reveal complexity. Software systems are characterized by their high complexity. Complexity results from the making of many interdependent decisions spanning different aspects of the system. This complexity can only be handled adequately, if these decisions

10

Handbook of Software Engineering and Knowledge Engineering

and their dependencies are made explicit. Rational enables the traceability of decision making for improved understanding. • Support change. Software systems have a long life cycle or are embedded into systems with a long life cycle. Consequently, developers and maintainers often need to deal with decisions that have been taken in the past by participants who are not part of the project anymore. Rationale enables the record of decision making information for future use. In Section 4, we examine more specific goals, such as the enhancement of requirements elicitation or the improvement of training support. • Rationale measurement needs to define specific metrics for evaluating the rationale management process and its results according to the rationale goals. Up to now, there have been only few quantitative studies about rationale methods. Most empirical studies have focused on the feasibility or the usability of rationale [9][17][21]. Operational rationale management tasks include: • Rationale identification. Sources of rationale knowledge include all the persons involved in decision making throughout software development. This includes the developers, managers, reviewers, users, and clients. As discussed in Section 2.3 the main question of rationale identification is the amount of the rationale to be captured: only the issues involved in major decisions or all issues. In both cases, identification of major issues specific to particular domains and particular knowledge goals would be helpful.Thus, for example, if the goal is to enhance the quality of the decisions, then a classification of the issues which raise the most conflicts in the given domain would help to focus the rationale process on the essential issues. Similarly, to facilitate change, it would be helpful to know beforehand which decisions are most likely to be changed. • Rationale acquisition. In Section 2.3, we argue that there is a significant difference between rationale acquisition during or after development. In contrast to most applications of knowledge management, rationale is best captured during project execution, not after the fact. It is impossible to reveal the rationale of a development without the developers. But even with the developers the actual arguments and challenges are hard to discover after the fact, since too many issues have been discussed. However, eliciting rationale during development imposes an additional burden on software process participants during their most stressful working period. Thus, a smooth integration of rationale capture into software development is mandatory. In the example in Section 5 we describe some measures to alleviate this problem. • Rationale development. During rationale development, the rationale is consolidated and packaged. In particular, this is based on a particular model of how to represent and structure rationale. In Section 4, we give several examples of rationale models for particular applications. As for rationale acquisition, one important issue for rationale development is the

Rationale Management in Software Engineering

11

facilitation during software development. Often rationale acquisition and rationale development are intertwined. However, this imposes even more burden on the software developers. This can be alleviated by a dedicated rationale maintainer as described in the example of Section 5. • Rationale distribution. Since rationale is secondary knowledge attached to the development decisions, rationale distribution is best achieved by easy access to rationale starting from the decisions and vice versa. Thus, rationale models needs to be intertwined with the documented decisions. One obvious, but seldom implemented, consequence is that the decisions themselves need to be identifiable within the system documentation. Another important issue is, to alleviate the access to the rationale as much as possible. This can be achieved by a user-adaptable tool to browse, view and filter the rationale and the decisions. • Rationale use. As the next section shows, there is a wide variety of rationale use. It can be used throughout any software process task. For example, the rationale behind a requirements specification or a prototype can be revealed to users and serve as a basis for requirements questions. Another example is that the rationale behind the system design can be used by maintainers to make better maintenance decisions. • Rationale preservation: As with any knowledge, rationale is only useful if it is up-to-date. Thus, there needs to be some support for maintaining the rationale as long as it might be useful. At the same time, it is important to prevent uncontrolled collection of rationale which hinders access to important rationale. As with rationale development, to some extent this can be achieved, by a rationale maintainer. This view on rationale management as knowledge management is new. It helps to understand the differences between different applications, because it makes the different goals and solutions to the different management tasks explicit. It also makes obvious that introducing rationale management into software development is a complex process. One reason for the only partial success of rationale methods might be that so far they have only concentrated on some of the tasks, but not on a coherent process. In the following section, the rationale management tasks identified from the knowledge management tasks are used to survey typical rationale management methods. They are also used to structure the detailed example given in Section 5.

4. Use of Rationale Management in Software Engineering In this section, we discuss four different applications of rationale in software engineering: • supporting negotiation during requirements (Section 4.1), • facilitating the elicitation of domain knowledge (Section 4.2), • structuring and capturing design meeting (Section 4.3), and

12

Handbook of Software Engineering and Knowledge Engineering

• predicting change impact (Section 4.4). We selected these applications to provide a broad spectrum for the purpose of illustration. This list, however, is by no means complete. Other applications of rationale to software engineering include [23], [24], [34], [35], [37] and [38]. Each of these applications addresses a specific knowledge goal that refines the high-level goals we identified previously (Fig. 4). For example, supporting negotiation during requirements improves the quality of decisions made and reduces the effort spent in resolving conflicts. Predicting change impact improves the ability of maintainers to change the system without introducing new problems. Improve Quality

Support Negotiation Facilitate Elicitation

Reveal Complexity Support Meetings Support Change

Predicting Change Impact

Fig. 4. Relationships between high level and low level rationale goals.

We examine each knowledge goal from the point of view of the operational rationale management tasks described in Section 3. These include the tasks of identifying which rationale should be captured, to elicit the rationale from users or developers, to develop rationale by representing it into models, disseminating rationale usually with the help of a tool, and its use for supporting the intended goal. None of these four applications, however, addresses the preservation of rationale knowledge. We revisit this issue in Section 6, when we discuss the role of rationale maintainer. To give further evidence on the usefulness of the individual approaches, we also sketch the experiences made in their industrial or experimental application.

4.1 Supporting Negotiation By making explicit all decision making elements, including the available options and the evaluation criteria that are used to evaluate them, stakeholders solve problems by identifying conflicts and finding a commonly acceptable resolution instead of defending entrenched positions. For example, Theory W and WinWin [2], an issue model and its corresponding tool support, leveraged off this idea in the context of negotiation among the different stakeholders of the software system. Negotiation knowledge is acquired from the start of the WinWin development cycle. Each development cycle starts with three activities (Fig. 5): • Identification of the critical stakeholder • Identification of their Win conditions

Rationale Management in Software Engineering

•

13

Reconciliation of the Win conditions

2. Identify stakeholders’ win conditions 3. Reconcile win conditions. Establish next level objectives, constraints, alternatives.

1. Identify next level stakeholders

7. Review Commitments

4. Evaluate product & alternatives. Resolve risks

6. Validate product and process definitions 5. Define next level process–including partitions.

Fig. 5. Win win spiral model (adapted from [16]).

Stakeholders are participants who hold an interest in the successful development of the system, including end users, sponsors, managers, and developers. Win conditions are success criteria that a specific stakeholder uses to evaluate different options. Identification. The identification of stakeholders and the definition of their Win conditions leads to the discovery of areas of agreement and of conflict. For the areas of agreement, no more action is necessary. For the areas of conflict, however, each stakeholder needs to elicit more rationale knowledge. Acquisition. Rationale knowledge for each conflict includes acceptable options, trade-offs and refined criteria. Rationale is elicited incrementally with each stakeholder entering more information using the WinWin tool as a reaction to proposals by other stakeholders. Stakeholders can explore acceptable alternatives, compromise, and arrive at a consensus. Development. The knowledge acquired during negotiation is formalized in the WinWin Negotiation Model, which includes four types elements (Fig. 6). In addition to Win Conditions and Issues (discussed in the previous paragraph), the negotiation model also includes Options, which represent alternatives for resolving an issue, and Agreements, which represent decisions that close a specific issue. Issues are linked to the conflicting WinCondtions with “involve” links. Options are linked to the Issue they address with an “address” link. Agreements are linked to the option resolving the Issue with a “adopt” link and

14

Handbook of Software Engineering and Knowledge Engineering

to the related WinConditions swith a “cover” link. Finally, the negotiation model includes a domain taxonomy which is used to classify each element of the negotiation according to application specific categories. Stakeholders are responsible for linking the negotiation elements they create with a specific category in the taxonomy. The formalization of rationale knowledge is performed at the same time as it is acquired. Taxonomy Category Win Condition

involve Issue

address Option

cover

adopt Agreement

Fig. 6. WinWin Negotiation Model [16] (UML class diagram).

Distribution. The elements of the negotiation model are accessible to all stakeholders via the WinWin tool. Stakeholders can browse the negotiation model either by taxonomy category or by Win condition. Use. Rationale knowledge is used during the negotiation as it is being elicited. Each new piece of rationale allows stakeholders to refine their Win conditions and resolve conflicts by finding compromises. The acquisition and use tasks are tightly intertwined in this application. Experiences. [2] reports from an extensive case study aiming at evaluating the feasibility of using the WinWin spiral model by graduate student development teams. The case study consisted of the development of a library multimedia archive system. where WinWin was applied in four cycles. Cycle 0 focused on the feasibility of an appropriate family of multimedia applications, cycle 1 on the life-cycle objectives, prototypes, plans, specifications and architecture of each application. In cycle 3 the architecture was detailed and risks of project success handled. Cycle 4 produced an initial operational system. The study showed three main strengths of the approach: explicit negotiation enhanced flexibility in adapting to risks and uncertainties, discipline in order to maintain focus on the milestones, and trust enhancement between the project stakeholders. Overhead was mainly due to documentation overkill and to attempts to coordinate multiple views. These were reduced by more extensive training on the process and the tool.

Rationale Management in Software Engineering

15

4.2. Supporting Requirements Elicitation By making the rationale of requirements decisions explicit, users are encouraged to review the reasoning behind the proposed option and participate in the decision process. Sutcliffe found that with this method, combined with a scenario-based requirements elicitation approach, requirements analysts can elicit more information and more kinds of information from end users during requirements elicitation sessions [39][40]. In this method SCRAM, analysts elicit a first version of application domain knowledge through traditional techniques, such as interviews and questionnaires. From this knowledge, analysts build a prototype. Identification. During the development of the prototype, analysts identify issues that are ambiguous and that need to be further investigated and for these issues only the analysts elicit further rationale knowledge. Acquisition. Analysts elicit the rationale knowledge by describing trade-offs they made when specifying the system. In particular, they concentrate on the options they considered, the criteria they used to evaluate the options, and the selected option which is presented to the users. Development. Analysts describe the proposed system in terms of scenarios and of a demonstration prototype. The scenarios capture the context in which the system is to be used, that is, the users environment and their work. Analysts formalize the requirements rationale as a QOC model, as described in Section 2. The QOC model explicitly lists all options that were considered and the criteria used to evaluate them. Fig. 7 depicts an example QOC model used to justify the navigation features for a large information space [40]. Note that in this application the rationale is elicited and reconstructed after the fact.

How to navigate the information space?:Question

2D Navigator with entities & relations:Option

Shows how key items are related:Criterion

2D Category/Topic expansion :Option

Handles large amounts of information :Criterion

List of tables as in Access:Option

Expands categories with associated topics:Criterion

Fig. 7. Example of requirements rationale in QOC. (Adapted from [40], UML object diagram).

Distribution and use. During a requirements elicitation session, an analyst describes the system by executing a scenario using the demonstration prototype. At key points, the analyst stops and describes the rationale developed in the previous point as a paper QOC model. The QOC model is then used to ask probe questions to the users. The users are encouraged to review the rationale, confirm

16

Handbook of Software Engineering and Knowledge Engineering

the selected option or propose changes or clarifying domain knowledge. The presence of rationale allows the users to select a different option and to clarify which decision criteria are more important from their point of view. This allows analysts to revise other decisions that depend on the same set of criteria. Experiences. [40] reports on the use of SCRAM on an European Union project, the multimedia broker. Four elicitation sessions of 1.5 hours on average with 20 users in total were held. These users gave positive feedback on SCRAM, because they thought it was helpful to see alternative designs and the demonstration was useful for discussing requirements. They all felt they had been given the opportunity to say what they wanted about the designs. Some problems encountered were the designer dominance during the session, the production of too many requirements because users were not forced to trade off judgements and session overload by discussing too many issues. The later could be reduced by filtering the more obvious and predictable requirements before hand. The effort of the designers was not further analyzed.

4.3 Structuring and Capturing Design Meetings By systematically enumerating options and their assessments, developers improve the quality of their decisions by discovering new options or detecting faulty assessments. In particular, issue models can be used to plan, execute, and capture design meetings [12][14]. Identification. The meeting facilitator selects a number of design issues to be discussed during the meeting. The list is then circulated before the meeting among participants in the form of a meeting agenda. The participants have the opportunity to augment the agenda with additional design issues and to prioritize the agenda items. Acquisition. The issues are then used to scope the discussion during the meeting. When an issues has been resolved or tabled, the facilitator moves to the subsequent issue in the agenda. A minute taker records the resulting discussion and decisions into meeting minutes. Development. Both agendas and meeting minutes are structured following an issue model (Fig. 8): the list of design problems are issues, the discussion is structured in terms of proposals and arguments, the decisions are recorded as decision nodes associated with the issues. When a design problem is discussed for several design meetings, the issue model associated with the design problem is carried over and updated after each meeting. The minute taker usually concentrates on capturing content during the meeting and formalizes the rationale knowledge into an issue model after the meeting.

Rationale Management in Software Engineering

17

Agenda Minutes Issue

addresses Proposal

supports opposes

based on

Argument resolves

Resolution Action Item

Fig. 8. IWEB meeting model [14] (UML class diagram).

Distribution. In [12], the issues were created, stored, and retrieved using a groupware tool called gIBIS. gIBIS enabled users to access the same issue model. In [14], issue models were represented in terms of meeting agendas and minutes that were posted on a newsgroup. Use. In addition to structuring the content of the meeting, the rationale knowledge can be used in several other ways. Participants can refer back to meeting minutes to update the project plan or the project status. Participants who did not attend the meeting can examine the discussions associated with a specific issues. Finally, the rationale knowledge, including the list of unresolved or tabled issues, can be used for organizing subsequent meetings. Experiences. Conklin and Burgess-Yakemovic used the IBIS model for structuring design meetings in an industrial setting for 18 months [12]. This case study identified several benefits of this approach for dealing with staff turnover, reviewing and tracking problems with requirements and design documents, and otherwise improving communication among the team. This case study also identified key points during the technology transfer issues when introducing rationale methods, such as the presence of a champion in the team, and a clear argument and supporting data of the costs and benefits of the approach. We confirmed most of these points in an experiment with senior students in the context of a software engineering project course using a similar approach for status meeting [14].

4.4 Predicting Change Impact By capturing the justification of the current design, maintainers have better and more information on which to base when designing changes hence avoiding the problem of architectural erosion [5]. However, designers usually dislike making

18

Handbook of Software Engineering and Knowledge Engineering

additional documentation. Also, all expansions of the software development process may affect lead-time negatively. [5] proposes a simple approach for documenting design rationale which was used to set up a controlled experiment to study effectiveness of rationale. Identification and acquisition. Designers write down a note for each system aggregation level documenting why it is broken down into the lower aggregation levels and what the purpose of each component is. This ensures that the rationale has a strong association with the code and that the size of the rationale is limited. Development. The rationale is structured according to four standardized headings: organization of system into files, use of language constructs, main dynamic architectural principles, and clues to understanding the system. Distribution and use. Maintainers can access the rationale when handling change requests. Experiences. The experiment was conducted with 17 participants, 7 of them from industry, the other 10 from university. All of the participants had to handle four change requests on a local telephony system modeled in SDL, but only half of them had access to the rationale. For each change request the participants were requested to indicate changes to existing components as well as the addition of new components. The maximum time allowed for each change request was 9 minutes. A similar experiment was conducted with only part of the former participants working on a cruise control system. Since this system was more complicated, only two change requests had to be handled with 30 minutes time for each of them. The analysis of the experiment data showed that for the first system there is a statistically significant difference between the two groups: the group using the design rationale on average only took 5 minutes (compared to 6 minutes for the other group) and identified more than 75% of the required change points (compared to 50% for the other group). Both groups had roughly 2 superfluous change points. The trends for the second system are similar, but not statistically significant. The reasons for this might be, that there were less data points available (due to the lower number of participants). Another reasons might have to do with the system itself. Thus the authors conclude that rationale documentation might be a cheap, yet effective way to facilitate future system evolution, without prolonging the time to the initial system release. However, further experimentation is needed to find out what is “the best” model for various purposes.

5. An Example: Using Rationale in Use Case Driven Software Development In this section, we present a particular instance of a rationale management process for requirements rationale. This section aims at complementing by a

Rationale Management in Software Engineering

19

detailed process example the survey of rationale management issues and methods given in the previous sections. Rationale management during requirements engineering is especially attractive given that requirements errors and changes are the most costly during development. Moreover, attaching rationale with requirements information, in particular with use cases, can have a high impact on all phases of development given that use cases are used throughout development. The process is described in more details in [15]. It takes the following approach to the rationale management tasks: Goal. The goal is to enhance the quality and facilitate the downstream use and change of use cases and the related requirements elements, such as scenarios, system services and non-functional requirements. Measurement. The quality of the requirements elements and their rationale is measured by the number of defects found in reviews. The usefulness of the rationale is measured by the number of accesses to the rationale during design, testing and requirements change. Identification. The approach aims at a very fine-grained capture of rationale. However, experiments will be carried out to evaluate the usefulness of the different rationale elements. Acquisition. The rationale is provided by the requirements engineers during requirements capture. Additional rationale is elicited during discussions initiated through reviews of requirements. Acquisition is made as easy as possible through provision of a tool and a defined process. Development. The rationale is formalized using the QOC—model as depicted in Fig. 1. The consolidation is supported by a dedicated rationale maintainer. The rationale maintainer is a developer or a former developer with librarian skills (e.g., a person with the ability to track large amounts of loosely organized and incomplete information). Distribution. Tool support for acquisition and access is provided. Currently, two implementations are under development: a dedicated web-based tool and an adaptation of the requirements management tool DOORS. Use. Currently, the main emphasis is on use in dependent software development tasks like design or testing and for requirements change. Preservation. The rationale maintainer is also responsible for keeping the rationale up-to-date. In the following, we concentrate on the process for rationale acquisition, development and preservation. We briefly sketch a requirements capture process. Then, we define a rationale process intertwined with the requirements capture process. The process steps can themselves be viewed as requirements for tool support for the integrated requirements and rationale capture process. A first generation of this process and its accompanying tool support is in use in the software engineering project course at the Technische Universität München (this project course is described in more detail in [7]). On the one hand, this approach provides us with a concrete example for teaching rationale

20

Handbook of Software Engineering and Knowledge Engineering

methods to students in computer science. On the other hand, it enables us to evaluate and refine this rationale methods in a realistic (and controllable) development project.

5.1. Use Case-based Requirements Capture Use cases are a popular addition to object-oriented software development. They have first been proposed by Jacobson [19] and are now part of the (Rational) Unified Software Development Process [20]. In [15] we stipulate a detailed process of requirements capture with use cases. For the purpose of this paper it suffices to say that the main step of the requirements capture is Propose Option in which user tasks, use cases, example scenarios, system services and glossary entries are created as part of the requirements specification. We refer to these artifacts as requirements elements. The other steps of the requirements capture process are Define Constraints (on the options) and Consolidate Requirements Elements. The process is carried out by the requirements engineer. It is intertwined with the following rationale capture process.

5.2. Issue-based Rationale Capture The rationale of requirements is captured by two processes. The first process, the capture process executed by a requirements engineer or a reviewer, focuses on rationale acquisition, whereas the second process, the maintenance process executed by the rationale maintainer, focuses on rationale development and preservation. The capture process is composed of the following steps (see Fig. 9):

Browse Requirements Elements UC Reviewer

Review Requirements Elements UT Challenge UC

Explore Options UC

Define Constraints UC

Propose Option UC

Propose High-Level Option UC

Assess Option Against Constraints UC Requirements Engineer

Address Challenge UT

Evaluate Options UC Argue Option UC Select Option UC

Fig. 9. The rationale capture process (UML use case diagram)

Rationale Management in Software Engineering

21

1. Review. A reviewer reads some part of the requirements specification and challenges problem areas with questions. 2. Explore Options. Questions can result in the discussion of possible changes in the requirements specification. A possible option that is always available is the status quo, that is, not to change the requirements. Clarification questions are addressed with options to improve the requirements specification without necessarily resulting in changes to the system. An option can be completely specified by writing out the corresponding use cases (Propose Option) or can be simply described as a high-level option (Propose High-Level Option). In both cases, the options should contain enough detail to enable the requirements engineer to evaluate and compare the proposed options (Define Constraints). 3. Evaluate Options. Once a sufficient number of options have been proposed, requirements engineers need to evaluate them and refine them to satisfy nonfunctional constraints (Assess Options Against Constraints). During this step, requirements engineers also create arguments supporting and opposing options (Argue Option). 4. Select Option. Once requirements engineers have evaluated and refined (most or) all options, requirements engineers create a decision by selecting an option which can result in minor or substantial change in the requirements specification. Note that a clarification question can be resolved without any changes. Note also that addressing a question may invalidate previous options and revisit earlier decisions. During the capture process, requirements engineers may skip any of the above steps. Options can be generated and evaluated without an explicit question. Decisions can be taken and changes implemented without explicit discussion. It is desirable, however, that at least some of the components of the decision are recorded so that the rationale maintenance process can recover the missing parts.

Identify Missing Questions UC Identify Missing Decisions UC Maintain Rationale UT Rationale Maintainer

Consolidate Options UC

Consolidate Questions UC Consolidate Arguments UC

Fig. 10. The rationale maintenance process (UML use case diagram)

The capture process can be executed at any time. Typically, it will occur when requirements engineers review the requirements specification, either when validating the requirements or in the process of executing a requirements step.

22

Handbook of Software Engineering and Knowledge Engineering

The maintenance process, however, is executed by the rationale maintainer whose responsibility is to keep the content and structure of the rationale up to date. The maintenance process is composed of the following steps (see Fig. 10): 1. Identify Missing Questions. Given that requirements engineers may skip steps in the capture process, there can be questions and their corresponding options that were not captured. The rationale maintainer, if involved with the development process, can document such questions, which were debated in meetings but not recorded online. In general, however, this task is difficult to accomplish systematically. Some important questions will occasionally fail to be recorded. 2. Identify Missing Decisions. Most decisions occur during meetings or face-to-face conversations. Consequently, they may be implemented in the requirements specification but not captured in the issue model. The rationale maintainer can identify these decisions by ensuring each change is associated with a decision. 3. Consolidate Options. When discussing a question, the requirements engineers may propose similar options. The rationale maintainer consolidates identical options into single nodes and restructures similar options. 4. Consolidate Questions. When reviewing requirements elements, reviewers may raise similar questions. The rationale maintainer consolidates identical questions into single nodes and restructures similar options. 5. Consolidate Arguments. Arguments often constitute the bulk of rationale information [31]. Arguments are usually unstructured and may apply to several options and decisions. The rationale maintainer summarizes verbose or redundant arguments and adds missing links to relevant rationale nodes.

5.3. Integrating requirements and rationale In the previous two subsections, we described two groups of processes: one for capturing and consolidating requirements and one for capturing and maintaining rationale. The group of processes focusing on rationale represents additional overhead for developers. Capturing and maintaining rationale will yield benefits only if processes from both groups and their corresponding tool support are integrated. Indeed, the integration of rationale methods and tools with various aspects of development is a fundamental issue that has received too little attention in rationale research [26]. In this section, we describe the concepts and process steps which are related to the integration of requirements and rationale capture. 5.3.1. Concepts There are three areas where additional associations need to be created:

Rationale Management in Software Engineering

23

Questions/Requirements associations. The association between a question and the requirements elements that are challenged needs to be captured. This enables a reviewer to specify which parts of the requirements are challenged and for a requirements engineer to list all questions for a given requirements element. Option/Requirements associations. The association between an option (or a high-level option) and the requirements elements that the option proposes, removes, or modifies also needs to be captured. When evaluating an option, this enables the requirements engineer to assess the impact of an option. When understanding the requirements, this allows a reviewer to trace back the source option or question that lead to a specific requirement. Requirements elements status. Given that requirements engineer can propose new requirements elements as part of an option but that these requirements elements can be discarded in favor of another option, each requirements element in the option base needs to include a status attribute. The requirements status can take three values: • current, if the requirements element is part of the current option, • proposed, if the requirements element is part of an option that has not been selected, • discarded, if the requirements element was part of the current option but has been discarded in favor of another option. 5.3.2. Processes To integrate the requirements and rationale processes, the steps Propose Option, Challenge, and Select Option, need to be modified and three new steps, Realize High-Level Option, Discard Current Requirement, and Make Proposed Requirement Current have to be introduced.

Realize High-Level Option Select Option

Propose Option

Discard Current Requirement Make Proposed Requirement Current

Fig. 11. Select option use case (UML use case diagram).

The Propose Option step sets the initial value of the status attribute of each new requirement to proposed. This allows requirements engineers to distinguish between requirements they have just entered and those that are part of the current option. The Challenge step creates associations between the question and the requirements being challenged. These associations make explicit relationships

24

Handbook of Software Engineering and Knowledge Engineering

between rationale and requirements and allow reviewers and requirements engineers to trace changes to specific problems. The Select Option step can have two variations. Either an option is selected or a high-level option is selected. If a high-level option is selected, it is first realized by creating all proposed use cases and modifying existing use cases. This is accomplished using the Realize High-Level Option process step. At the end of this step, a new option is created and linked with the corresponding requirement. The Select Option step then invokes the Discard Current Requirement step to change the status of any requirement that needs to be discarded. The Make Proposed Option Current step is then invoked to change the status of the proposed requirements to current. The differentiation between high-level options and options enables requirements engineer to debate several options without fully developing them a priori. This encourages the capture of more information about discarded options.

5.4. ATM Example revisited In the software engineering project course at TU München, the process described in this section is supported by a simple web application called REQ/QOC (Fig. 12). This tool enables the users (e.g., requirements engineer and reviewers) to examine simultaneously the requirements specification and its rationale. The requirements specification (left column in Fig. 12), is expressed in terms of requirement elements (i.e., actors, user tasks, use cases, services, nonfunctional constraints, and glossary terms). The rationale (right column in Fig. 12) is represented in terms of an issue model (i.e., questions, options, criteria, and decisions). Users collaborate by concurrently creating and modifying requirements elements, challenging them with questions, and resolving questions through argumentation. For example in Fig. 12, a reviewer noticed that the authentication mechanism used by the ATM had not been specified. The reviewer created a question Authentication Mechanism and linked it with the Deposit Money, Withdraw Money, and Check Balances user tasks. The requirements engineering subsequently debated three possible options to this question (Account Number & PIN, Card & PIN, Finger Print) and assessed them against the nonfunctional constraints (Security, Low per unit Cost, and Flexibility) of the ATM system.2 The requirements engineers discussed the question using the discussion thread at the bottom of the right column and subsequently agreed to select the Card & PIN option, now displayed in bold, and created an Authenticate use case to document this decision. The user tasks Deposit Money, Withdraw Money, and Check Balances and the use case Authenticate are associated with this question and are displayed as 2

Note that these nonfunctional constraints are listed as Criteria in the rationale window.

Rationale Management in Software Engineering

25

links in the References section of the question. Similarly, links to open questions are listed in the left column under their corresponding requirements elements (not depicted in Fig. 12). These cross references enable users to quickly navigate between the requirements elements and their rationale.

Fig. 12. ATM Authentication question of Fig. 2 depicted in the REQ/QOC tool.

6. Open Issues and Future Directions In this chapter, we focus on the fundamental concepts behind rationale knowledge and its application to software engineering. We presented several applications of rationale as illustration of the broad range of goals that can be satisfied with rationale knowledge. Several obstacles, however, have prevented the wide-spread use of rationale in the software industry. The obstacles include: • Cost. Capturing rationale introduces an initial cost. Developers need to capture more information and justify more decisions. For the organization, this is an investment, as rationale information will be most useful later in the process. However, from the developers’ perspective, this is perceived as an overhead as users of the rationale are usually different persons (e.g., maintainers). If the developers do not see a short

26

Handbook of Software Engineering and Knowledge Engineering

term benefit for themselves, it is likely that they will not invest sufficient effort into this task. • Completeness. Rationale is lost if not captured early. Decisions can be reopened a number of times over a long period of time. If the options that were evaluated and the criteria that were used in the evaluation are not captured, it is difficult for developers to reconstruct the rationale associated with early decisions. • Complexity. Rationale models are larger and more complex than system models. Given that rationale also include discarded options and argumentation, it represents a larger body of information and is harder to search. If the access to the rationale is too cumbersome, developers will not consult it prior to reopening decisions. • Consistency. Rationale is useful only if consistent with the system models. System models evolve over time. Similarly, their corresponding rationale also evolves. If the rationale models are not kept consistent with subsequent version of the system models, the rationale quickly becomes outdated and useless. However, recent progress in several technological areas (e.g., hypertext and hypermedia technology, search engines and natural language parsing) and organizational areas (e.g., knowledge management) promise that some these obstacles could be overcome in specific contexts. For example: • Process integration. By integrating the capture of rationale with existing activities (e.g., negotiation in Section 4.1, elicitation in Section 4.2), we can create a short term incentive for developers to capture rationale, thus reducing the perceived overhead of capture. Moreover, this increases the completeness of captured rationale since rationale is captured during development. • Tool integration. Modern computer supported software engineering (CASE) tools, integrated development environments (IDEs), and groupware provide open interfaces enabling third parties to customize and integrate these tools with others. This also enables us to integrate rationale management support tools with development tools, thus providing developers easier access to rationale information. Moreover, this enables developers to capture more information during development, for example, in the form of annotations. By linking system and rationale knowledge and by providing the developers with familiar tool interfaces, we can reduce the complexity of organizing and accessing rationale knowledge. This contrasts with earlier approaches to rationale tool support in which monolithic and dedicated tools were developed (e.g., gIBIS [12]). • Knowledge management roles. In knowledge management, specialized roles dedicated to knowledge acquisition and organization (e.g., knowledge brokers) are not uncommon. This stems from the realization that knowledge can become obsolete or irrelevant quickly and that only persons dedicated to maintaining this knowledge can address this issue

Rationale Management in Software Engineering

27

effectively. Early efforts in rationale management assumed that developers could deal with rationale as a side effect of their work. However, preserving rationale knowledge turned out to be the most difficult challenge in rationale management. In the example we presented in Section 5, the rationale maintainer, is an example of such specialized role and focuses mostly on the preservation of knowledge. Once adequate tool and organization support exists for capturing and disseminating rationale, it then becomes possible to conduct systematic quantitative studies to identify which subset of rationale knowledge are useful and used by developers and in which applications. This would then allow further improvements in reducing the cost of introducing rationale methods in development and provide success cases for illustrating their utility, a necessary requirement before a meaningful adoption of rationale methods into everyday practice.

References 1.

A. Birk & C. Tautz. “Knowledge management of software engineering lessons learned.” In Int. Conf. on Software Engineering and Knowledge Engineering, pp. 116—119, 1998. 2. B. Boehm, A. Egyed, J. Kwan, D. Port, A. Shah, & R. Madachy, “Using the WinWin Spiral Model: A Case Study,” in IEEE Computer, July 1998. 3. G. Booch, J. Rumbaugh, & I. Jacobson, The Unified Modeling Language User Guide. Addison-Wesley, Reading, MA, 1998. 4. U. Borghoff & R. Pareschi. Information Technology for Knowledge Management. Springer, 1998. 5. L. Bratthall, E. Johansson & B. Regnel, “Is a Design Rationale Vital when Predicting Change Impact?—A Controlled Experiment on Software Architecture Evolution”, In Int. Conf. on Product Focused Software Process Improvement, LNCS 1840, 2000 6. B. Bruegge & A.H. Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems, Prentice Hall, Upper Saddle River, NJ, 1999. 7. B. Bruegge, A.H. Dutoit, R. Kobylinski, & G. Teubner. “Transatlantic Project Courses in a University Environment,” Asian Pacific Software Engineering Conference, Singapore, December 2000. 8. S. Buckingham Shum & N. Hammond, “Argumentation-based design rationale: what use at what cost?” International Journal of Human-Computer Studies, vol. 40, pp. 603—652, 1994. 9. S. Buckingham Shum, “Analyzing the Usability of a Design Rationale Notation,” in T.P. Moran & J.M. Carroll (eds.) Design Rationale: Concepts, Techniques, and Use. Lawrence Erlbaum, Hillsdale, NJ, 1995. 10. T. Carey, D. McKerlie, & J. Wilson, “HCI design rationales as a learning resource,” in T.P. Moran & J.M. Carroll (eds.) Design Rationale: Concepts, Techniques, and Use. Lawrence Erlbaum, Hillsdale, NJ, 1995.

28

Handbook of Software Engineering and Knowledge Engineering

11. A. Cockburn, “Goals and Use Cases”, Journal of Object-Oriented Programming, vol. 10, no.5, pp. 35— 40, 1997 12. J. Conklin & K. C. Burgess-Yakemovic, “A process-oriented approach to design rationale,” Human-Computer Interaction, vol. 6, pp. 357—391, 1991. 13. T. Davenport, “Successful Knowledge Management Projects,” Sloan Management Review, vol. 39, no. 2, pp. 43—58, 1998 14. A.H. Dutoit, B. Bruegge, & R. F. Coyne, “The use of an issue-based model in a team-based software engineering course,” Conference proceedings of Software Engineering: Education and Practice (SEEP’96). Dunedin, New Zealand. January 1996. 15. A.H. Dutoit & B. Paech, “Supporting Evolution: Rationale in Use Case Driven Software Development,” In International Workshop on Requirements Engineering: Foundations of Software Quality (REFSQ’2000), Stockholm, June, 2000. 16. A. Egyed & B. Boehm. “Comparing Software System Requirements Negotiation Patterns,” in Journal for Systems Engineering, John Wiley & Sons, 1999. 17. G. Fischer, A.C. Lemke, R. McCall, & A. I. Morch, “Making Argumentation serve design,” Human Computer Interaction 6,3, 393-419, 1991. 18. J. Grudin, “Evaluating Opportunities for Design Capture,” in T.P. Moran & J.M. Carroll (eds.) Design Rationale: Concepts, Techniques, and Use. Lawrence Erlbaum, Mahwah, New Jersey, 1996. 19. I. Jacobson, M. Christerson, P. Jonsson, & G. Overgaard, Object-Oriented Software Engineering—A Use Case Driven Approach. Addison-Wesley, Reading, MA, 1992. 20. I. Jacobson, G. Booch, & J. Rumbaugh, The Unified Software Development Process. Addison-Wesley, Reading, MA, 1999. 21. L. Karsenty, “An empirical evaluation of design rationale documents,” in Conference Proceedings on Human Factors in Computing Systems, 150-156, Vancouver Canada, 1996. 22. R. Kneuper, “Supporting Software Processes Using Knowledge Management,” to appear in Handbook of Software Engineering and Knowledge Engineering, World Scientific, 2001. 23. W. Kunz & H. Rittel, “Issues as elements of information systems,” Working Paper No. 131, Institut für Grundlagen der Planung, Universität Stuttgart, Germany, 1970. 24. J. Lee, “A qualitative decision management system,” Artificial Intelligence at MIT: Expanding Frontiers. P.H Winston & S. Shellard (eds.) (MIT Press, Cambridge, MA,) Vol. 1, pp. 104—133, 1990. 25. J. Lee, “Extending the Potts and Bruns model for recording design rationale.” Proceedings of the 13th International Conference on Software Engineering (ICSE’13), 114—125. Los Alamitos, CA, IEEE Computer Society. 26. J. Lee, “Design Rationale Systems: Understanding The Issues,” in IEEE Expert, May/June 1997. 27. F. Lehner, Organizational Memory. Hanser, 2000 28. J.C.S. do Prado Leite, G. Rossi, F. Balaguer, A. Maiorana, G. Kaplan, G. Hadad & A. Oliveros, “Enhancing a Requirements Baseline with Scenarios”, International Symposium in Requirements Engineering (RE’97), pp. 44-53, 1997 29. R. Lougher & T. Rodden, “Supporting Long-term Collaboration in Software Maintenance,” in Proceedings of the Conference on Organizational Computing Systems, 1993.

Rationale Management in Software Engineering

30. A. MacLean, R. M. Young, V. Bellotti, & T. Moran, “Questions, options, and criteria: Elements of design space analysis,” Human-Computer Interaction, vol. 6, pp. 201—250, 1991. 31. T. P. Moran & J. M. Carroll (eds.), Design Rationale: Concepts, Techniques, and Use. Lawrence Erlbaum Associates, Mahwah, NJ, 1996. 32. J. Mylopoulos, L. Chung & E. Yu, ”From Object-Oriented to Goal-Oriented Requirements Analysis”, Communication of the ACM, vol. 42, pp. 31-37, 1999 33. K. Pohl & P. Haumer, “Modelling Contextual Information about Scenarios”, International Workshop on Requirements Engineering: Foundations of Software Quality (REFSQ’97), pp. 197-204, 1997. 34. C. Potts, “ScenIC: A Strategy for Inquiry-Driven Requirements Determination”, International Symposium on Requirements Engineering (RE’99), pp.58-65,1999. 35. C. Potts & G. Bruns, “Recording the reasons for design decisions” Proceedings of the 10th International Conference on Software Engineering (ICSE’10), 418—427. Los Alamitos, CA, 1988. 36. G. Probst, K. Romhardt, & St. Raub: “Managing Knowledge: Building Blocks for Success”, John Wiley & Sons, 1999. 37. B. Ramesh & V. Dhar: “Representing and Maintaining process Knowledge for Large Scale System development”, In IEEE Expert, vol. 9, no. 2, pp. 54-59, 1994 38. F.M. Shipman III & R.J. McCall, “Integrating different perspectives on design rationale: Supporting the emergence of design rationale from design communication,” Artificial Intelligence in Engineering Design, Analysis, and Manufacturing, vol. 11, no. 2, 1997. 39. A. Sutcliffe “Requirements Rationales: Integrating Approaches to Requirement Analysis,” In Olson G.M., Schuon S, (eds.) Proceedings of Designing Interactive Systems, DIS’ 95. ACM Press, New York, 1995. 40. A. Sutcliffe & M. Ryan, “Experience with SCRAM, a SCenario Requirements Analysis Method,” In Proceedings of the 3rd International Conference on Requirements Engineering, April 1998. 41. K.M. Wiig. Knowledge Management Methods. Schema Press Ltd., 1995.

29