Computer Science Dept.
University of Oregon
Eugene, OR 97403
The Kate project started in the area of Requirements Engineering (RE) called early requirements acquisition. The project goals were (1) to study the dialog carried out between a requirements analyst and a customer, and (2) to produce a computer-based tool, based on the study, to aid in the capture of early requirements.
As the project evolved, it began to take on the hue of a knowledge engineering (KE) effort, in no small part because of the author's earlier affiliation with the KE group at ISI. Eventually, the notion of a "critic" emerged - a knowledge-based tool that could critically comment on a software specification.
I will give the audience a brief travelogue of the project as it moved among disciplines, and close with some comments on the interplay between RE and KE as I've experienced through tiptoeing on the edge of each.
See my home page for further information, http://www.cs.uoregon.edu/~fickas/
Fickas, S., Nagarajan, P., Critiquing software specifications: a knowledge based approach, IEEE
Software, November 1988
Both this paper and the next give an intro to the Kate system. This one has more detail on the actual results of the dialog between analyst and customer.
Fickas, S., Nagarajan, P., Being suspicious: critiquing problem specifications, In Proceedings of
the 1988 AAAI Conference, Minneapolis
Pushes more on the CBR point of view.
Downing, K., Fickas, S., A Qualitative Modeling Tool for Specification Criticism, Conceptual
Modeling, Databases, and CASE: An Integrated View of Information Systems Development,
Peri Loucopoulos (ed), Ablex, 1991
This work extends the Kate system into the area of qualitative modeling. General idea is if the specification can be represented qualitatively, then it may be possible to criticize it in qualitative terms, using qualitative diagnosis techniques. This wins big for complex specs. Ok, not real sure of tie to KE.
Helm, R., Fickas, S. Scare Tactics: Evaluating Problem Decompositions Using Failure Scenarios,
Proceedings of the Workshop on Change of Representation and Problem Reformulation (Asilomar,
CA, April 1992). Technical Report FIA-92-06, NASA Ames Research Center,
Moffett Field, CA 94025, p. p. 85-93.
This is another extension of Kate. This time, we are trying to generate scenarios or scary test cases that might convince the customer that what they have specified might not be what they want. Is there a similar issue when acquiring knowledge from experts?
Fickas, S., Helm, R., Automating the design of composite systems, IEEE Transactions on
Software Engineering, 6/92
This work builds on the notion of a knowledge-based specification critic, started in the Kate project. This work is more ambitious in that it includes a general purpose planner (a weak method) for discovering flaws in a spec. It also attempts to reason about composite (i.e., multi-agent) systems and how agents may or may not "get along". In retrospect, the planning technology we used did not scale.
Dardenne, A., van Lamsweerde, A., Fickas, S., Goal-Directed Requirements Acquisition, Science of Computer Programming (to appear)
This paper discusses a means of acquiring requirements from a customer by using a structure of goals to guide the capture. It might relate to a knowledge acquisition process, but none that I am aware of.
M.S. Feather, Constructing Specifications by Combining Parallel Elaborations,
IEEE Transactions on Software Engineering, 1989, Number 2, Volume 15
I like this paper a lot. General idea is that you capture requirements by talking to the various stakeholders involved. However, you do not attempt to come to consensus initially. Each stakeholder states her ideal set of requirements. Once all ideals are in place, you attempt to merge the various ideals together. Would appear to be applicable to any acquisition task involving multiple points of view.
W.N. Robinson, S. Fickas, Supporting multi-perspective requirements
engineering, Proceedings of the First International Conference on Requirements
Engineering, IEEE Computer Society Press, Colorado Springs, April 18-22 1994.
This builds on Feather's work above. We look at the problem of merging ideal "lines of thinking" into one specification. We view the problem as conflict management and draw on solutions from negotiation techniques. A more general reference to the "multiple viewpoint" area in requirements engineering can be found at the Viewpoints Workshop page.