scispace - formally typeset
Search or ask a question

Showing papers on "User story published in 1997"


Book ChapterDOI
01 Jan 1997
TL;DR: The experimental results demonstrate that a minimalist user modelling component does improve the subjective measure of user satisfaction and important issues and considerations for the development of user modelling components for commercial software systems are discussed.
Abstract: While user modelling has become a mature field with demonstrable research systems of great power, comparatively little progress has been made in the development of user modelling components for commercial software systems. The development of minimalist user modelling components, simplified to provide just enough assistance to a user through a pragmatic adaptive user interface, is seen by many as an important step toward this goal. This paper describes the development, implementation, and empirical evaluation of a minimalist user modelling component for TIMS, a complex commercial software system for financial management. The experimental results demonstrate that a minimalist user modelling component does improve the subjective measure of user satisfaction. Important issues and considerations for the development of user modelling components for commercial software systems are also discussed.

34 citations


Patent
26 Feb 1997
TL;DR: In this article, an apparatus and method for separating the design and implementation of a user interface (the user interface logic) from the design of the functional portion of a software program (the core logic) is presented.
Abstract: An apparatus and method for separating the design and implementation of a user interface ("the user interface logic") from the design and implementation of the functional portion of a software program (the "core logic"). The present invention uses an object-oriented programming model in which one or more look and feel agents (304) act as servers for one or more logic objects (302). The look and feel agent (304) controls the appearance and behavior of the user interface, while logic objects (302) perform the functions of the software program. A look and feel agent (304) does not "know" what functions constitute the core logic and the logic objects (302) do not "know" what the user interface looks like or how it behaves.

24 citations


01 Mar 1997
TL;DR: By focusing on essential use cases, stripped of implementation constraints or alternatives, the analyst can derive software requirements that will enable the user to achieve her objectives in each specific usage scenario.
Abstract: Perhaps the greatest challenge facing the software developer is sharing the vision of the final product with the customer. All stakeholders in a project—developers, end users, software managers, customer managers—must achieve a common understanding of what the product will be and do, or someone will be surprised when it is delivered. Surprises in software are almost never good news. Therefore, we need ways to accurately capture, interpret, and represent the voice of the customer when specifying the requirements for a software product. Often the customer will present as "needs" some combination of: the problems she has in her work that she expects the system to solve; the solutions she has in mind for an expressed or implied problem; the desired attributes of whatever solution ultimately is provided; and the true fundamental needs, that is, the functions the system must let her perform. The problem becomes more complex if the systems analyst is dealing with a surrogate customer, such as a marketing representative, who purports to speak for the actual end users of the application. The challenge to the analyst is to distinguish among these four types of input and identify the real functional requirements that will satisfy the real user's real business needs. Many techniques are used for eliciting user requirements, all of which attempt to include the voice of the customer in the product design process. A typical project might employ a combination of meetings with user representatives and developers, facilitated workshops (for example, joint application design sessions) with analysts and users, individual customer interviews, and user surveys. The use case approach is an especially effective technique for deriving software requirements, analysis models, and test cases. The Use Case Method Use (pronounced "youce," not "youze") cases were introduced as part of an objectoriented development methodology by Ivar Jacobson in Object-Oriented Software Engineering: A Use Case Driven Approach (Addison-Wesley, 1992). More recently, Larry Constantine and others have extended the concept into a general technique for requirements analysis and user interface design. Each use case describes a scenario in which a user interacts with the system being defined to achieve a specific goal or accomplish a particular task. Use cases are described in terms of the user's work terminology, not computerese. By focusing on essential use cases, stripped of implementation constraints or alternatives, the analyst can derive software requirements that will enable the user to achieve her objectives in each specific usage scenario. A software team at Eastman Kodak Company recently applied the use case method to specify the requirements for a chemical tracking system. Figure 1 illustrates the overall process we found to be effective with the use case technique and the key deliverables. We used a series of highly interactive sessions with customer representatives to identify and describe use cases. Functional requirements, behavioral characteristics, and business rules fell right out of the use case discussions.

17 citations


Book ChapterDOI
01 Jan 1997
TL;DR: It is argued that user knowledge can be modelled, up to a point, but that to ask whether or not the authors can know what the user knows is to misunderstand the question.
Abstract: Whilst many user models can function perfectly adequately with a behavioural impression of the user, the provision of assistance in some task domains, notably design, requires a richer understanding, incorporating information about the user’s knowledge and beliefs. This raises a number of important and difficult questions: How can we know what the user knows, and how can we know that we know? We present evidence that the psychological view of human conceptual knowledge that underpins typical approaches to these questions is flawed. We argue that user knowledge can be modelled, up to a point, but that to ask whether or not we can know what the user knows is to misunderstand the question.

7 citations


Book ChapterDOI
01 Jan 1997
TL;DR: The paper focuses on the representation of plans and suggests a partition of the user model to separate the user’s capabilities from his or her beliefs.
Abstract: The goal of this work is a systematic basis for modeling the planned or possible actions taken by the user of a computer system. This type of model should be able to support the recognition of the user’s plans as well as the generation of a plan adapted for the user’s needs. The paper focuses on the representation of plans and suggests a partition of the user model to separate the user’s capabilities from his or her beliefs.

1 citations


Journal ArticleDOI
TL;DR: The Fifth International Conference on User Modeling (UM-96) is part of a recently established, biennial conference series that provides a forum for researchers in the field of user modeling and user-adapted interaction.
Abstract: The Fifth International Conference on User Modeling (UM-96) is part of a recently established, biennial conference series that provides a forum for researchers in the field of user modeling and user-adapted interaction. The next major software revolution after graphic user interfaces will be software that adapts itself to the user. By adapting to the user's needs, preferences, knowledge, language, and even moods, software will attain new levels of usability and broad acceptance that would not be possible without built-in models of the user. This conference series provides a forum for recent research in the field, ranging from theoretical foundations to implemented systems to controlled studies of the human-computer interfaces of user-adapted systems.

1 citations


01 Jan 1997
TL;DR: The aim of this project is the development of a MAS for distributed resource management on civil construction companies, the large number of software agents involved in this particular application, the presence of different companies and the variety and number of users interacting with the system lead us to theDevelopment of MAGUI.
Abstract: Man-machine interfaces are a very important part of any computer application. A good human interface must be friendly and effective providing a good interaction between the human operator and the application. Human interfaces for multi-agent systems (MAS) are specially complex because the multiple requirements of this kind of architectures where the human operator is interacting with a multitude of different autonomous agents often characterized by a great dynamics. The presence of more than one user in the system, with similar or with different competencies is another interesting problem that is quite realistic in many applications of MAS. In this paper, the particular requirements of user interfaces for multi-agent systems are discussed and a multi-agent graphical user interface in the framework of a multi-user multi-agent system is presented. Keywords: Multi-agent systems, man-machine interface, user modelling. I. Introduction User interface design is often a large, complex and difficult task. A 1992 study found that 48% of the code of applications and 50% of the development time is dedicated to the user interface portion [1]. Nowadays, graphical user interfaces (GUI) are almost universal. Studies from 1993 indicate that 97% of all software development on UNIX involved a GUI [2]. In fact, the user interface is usually a crucial part of any commercial product. Because it is the front end of the application it usually must be easy to learn, use and perform the functions their users want [3]. Poor human interfaces degrade human-computer interaction increasing mistakes and user frustration and, as a consequence, degrading system performance and reliability. Also, because this is the portion of code directly in contact with the user, the only way to get good results is to design and re-design it iteratively in direct cooperation with the final users. Only if this process is followed the product can be correctly adapted to the real requirements, despite the fact that the implementation becomes harder. Unfortunately, all these difficulties are present, and some of them aggravated when developing user interfaces for multi-agent systems (MAS). In addition to the usual requirements of any other user-interface, in multi-agent systems, several factors introduce a higher degree of difficulty to the GUI designer specially when considering fine-grained MAS: • a large number of agents can be present on the system trying to communicate with the user. In order to overcome this problem the human interface must provide a way for the user to choose among the various agents those that justify attention with the higher priority. • the possible heterogeneity can introduce difficulties on the communication process between the agents and the user. Whenever we consider that a multi-agent system can contain agents representing different companies, reflecting different commercial “cultures”, the problem of language translation (both at syntactical and semantic levels) becomes important. • the unpredictability associated with this kind of systems introduces particular problems, specially when the Multi-Agent Systems are supposed to have high dynamics, with agents appearing and going on runtime. The motivation for the development of a graphical user interface especially dedicated to multi-agent systems environment was mainly the MACIV project [4]. The aim of this project is the development of a MAS for distributed resource management on civil construction companies. The large number of software agents involved in this particular application, the presence of different companies and the variety and number of users interacting with the system lead us to the development of MAGUI. MAGUI is a completely dynamic GUI, which means that all its configuration is done at run-time by the agents themselves. This way, whenever the agents become active they can make their own registration on the GUI to obtain a “communication channel” to the user and “unregister” when they have their job done. In order to support all the unpredictability inherent to such a system, nothing is pre-determined in what concerns to interface menus. All

1 citations