STRUCTURING KNOWLEDGE ACQUISITION THROUGH GENERIC TASKS: A CASE STUDY IN HINDSIGHT

Knowledge Acquisition is widely recognized as the single major bottleneck in the commercialization of Expert Systems technology. The typically ad-hoc choice of techniques for eliciting and representing expert knowledge, makes Expert Systems development expensive and prone to failure. Arguments have been made in the Knowledge Acquisition literature for performing an epistemological or "knowledge-level" analysis to "structure" the knowledge elicitation process. The need of the hour is for an empirical evaluation of these claims. In this paper, we present the results of a study that evaluates an approach to Structured Knowledge Acquisition, that is based on analyzing expert behavior using generic problem-solving tasks. Data from a large Expert Systems project currently nearing completion, has been used for the study.Information Systems Working Papers Serie

Effective communication in requirements elicitation: A comparison of methodologies

The elicitation or communication of user requirements comprises an early and critical but highly error-prone stage in system development. Socially oriented methodologies provide more support for user involvement in design than the rigidity of more traditional methods, facilitating the degree of user-designer communication and the 'capture' of requirements. A more emergent and collaborative view of requirements elicitation and communication is required to encompass the user, contextual and organisational factors. From this accompanying literature in communication issues in requirements elicitation, a four-dimensional framework is outlined and used to appraise comparatively four different methodologies seeking to promote a closer working relationship between users and designers. The facilitation of communication between users and designers is subject to discussion of the ways in which communicative activities can be 'optimised' for successful requirements gathering, by making recommendations based on the four dimensions to provide fruitful considerations for system designers

How do software architects consider non-functional requirements: an exploratory study

© 2012 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.Dealing with non-functional requirements (NFRs) has posed a challenge onto software engineers for many years. Over the years, many methods and techniques have been proposed to improve their elicitation, documentation, and validation. Knowing more about the state of the practice on these topics may benefit both practitioners' and researchers' daily work. A few empirical studies have been conducted in the past, but none under the perspective of software architects, in spite of the great influence that NFRs have on daily architects' practices. This paper presents some of the findings of an empirical study based on 13 interviews with software architects. It addresses questions such as: who decides the NFRs, what types of NFRs matter to architects, how are NFRs documented, and how are NFRs validated. The results are contextualized with existing previous work.Peer ReviewedPostprint (author’s final draft

Fostering collaborative knowledge construction with visualization tools

This study investigates to what extent collaborative knowledge construction can be fostered by providing students with visualization tools as structural support. Thirty-two students of Educational Psychology took part in the study. The students were subdivided into dyads and asked to solve a case problem of their learning domain under one of two conditions: 1) with content-specific visualization 2) with content-unspecific visualization. Results show that by being provided with a content-specific visualization tool, both the process and the outcome of the cooperative effort improved. More specifically, dyads under that condition referred to more adequate concepts, risked more conflicts, and were more successful in integrating prior knowledge into the collaborative solution. Moreover, those learning partners had a more similar individual learning outcome