Enhanced Maintenance and Explanation of Expert Systems Through Explicit Models of Their Development

Neches, Robert; Swartout, William; Moore, Johanna D.

doi:10.1109/tse.1985.231882

Cited by 124 publications

(43 citation statements)

References 2 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…For example: the history of the requirements evolution process (REMAP [Ramesh & Dhar 1992]); the design rationale of teams working in real-time (rIBIS [Rein & Ellis 1991]); requirements trade-offs (KAPTUR [Bailin et al 1990]); explanations and justifications (XPLAIN [Neches et al 1985]); a record of collaborative activities (Conversation Builder [Kaplan 1990]); the conversations underlying group work (coordinator software [Marca 1989]); tangible products produced and used, settings in which developed and maintained, and processes carried out (ISHYS [Garg & Scacchi 1989]); distinctive sources in a heterogeneous domain (PROLEXS [Walker et al 1991]); and a rich diversity of multimedia information used in requirements engineering [Palmer & Fields 1992]. Additional advances could be gained from current work directed towards the use of ethnography or ethnomethodology to inform requirements gathering [Jirotka 1991].…”

Section: Obtaining and Recording Diverse Project Informationmentioning

confidence: 99%

An analysis of the requirements traceability problem

Gotel

Finkelstein

Proceedings of IEEE International Conference on Requirements Engineering

792

533

View full text Add to dashboard Cite

In this paper, 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 paper, 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.

show abstract

Section: Obtaining and Recording Diverse Project Informationmentioning

confidence: 99%

An analysis of the requirements traceability problem

Gotel

Finkelstein

Proceedings of IEEE International Conference on Requirements Engineering

792

533

View full text Add to dashboard Cite

show abstract

“…Therefore, users need to be able to obtain information about the rationale for the critique. Simple explanation components provide prestored text explanations [40,47]. But there is not always a simple explanation.…”

Section: Explanation and Argumentationmentioning

confidence: 99%

The role of critiquing in cooperative problem solving

Fischer

Lemke

Mastaglio

et al. 1991

ACM Trans. Inf. Syst.

121

View full text Add to dashboard Cite

Cooperative problem-solving systems help users design solutions themselves as opposed to having solutions designed for them. Critiquing-presenting a reasoned opinion about a user's product or action-is a major activity of a cooperative problem-solving system. Critics make the constructed artifact "talk back" to the user. Conditions under which critics are more appropriate than autonomous expert systems are discussed. Critics should be embedded in integrated design environments along with other components, such as an argumentative hypertext system, a specification component, and a catalog. Critics support learning as a by-product of problem solving. The major subprocesses of critiquing are goal acquisition, product analysis, critiquing strategies, adaptation capability, explanation and argumentation, and advisory capability. The generality of the critiquing approach is demonstrated by discussing critiquing systems developed in our group and elsewhere. Limitations of many current critics include their inability to learn about specific user goals and their intervention strategies.

show abstract

“…The issue of accessibility to domain experts has been central in the design of our architecture [Neches , 1985;Swartout and Smoliar, 1987]. The explicit representation of factual and problem-solving knowledge and the ability to produce exible explanations in an interactive dialogue provide the basis for building a KA tool that communicates with an expert much in the way a colleague in their eld of expertise would.…”

mentioning

confidence: 99%

“…Our scenarios illustrate the user's involvement during knowledge acquisition, as well as which parts of the process are automated by the tool. builds upon previous work on the Explainable Expert System ( ) framework [Neches , 1985;Swartout and Smoliar, 1987], which allows for the construction of expert systems that can provide good natural language explanations of their behavior [Moore and Paris, 1993;Swartout and Moore, 1993;Moore, 1989;Moore and Swartout, 1989;Moore and Swartout, 1991].…”

mentioning

confidence: 99%