Interactive systems can be seen, according the media
perspective [Kammersgaard 88], as a communication medium through which
messages are passed between human actors. The communication process
naturally involves the intuitive notion of messages being passed from
sender(s) to receiver(s). This message-passing process may be examined
in two-levels: (i) a system as a one-way message sent from designers to
users via a computational medium; and (ii) the interchange between the
user and the system, where the system is considered as a message
playing the role of sender and receiver of other messages at interface
level. Consequently, systems are a peculiar type of meta-communication artifact [Souza 93], related to two distinct contexts of communication. The context of development
concerns the establishment of a common basis for user-designer
communication in order to allow the mutual learning necessary to
translate and adapt task delegation into the operation procedures and
functions provided by the system; while the context of usage concerns the user-system interaction supported by the human-computer interaction component of the system.

Human-Computer Interaction (HCI) approaches have been usually
trying to incorporate Ergonomics and Cognitive Psychology knowledge
into Computer Science methods and tools in order to design useful
systems with an usable human-computer interface. Both communication
contexts above are intrinsic in these approaches, which can benefit
from a Semiotic perspective that helps both designers and users to
focus on their communication role.

This paper presents our semiotic approach to interactive
systems requirements elicitation and it is structured as follows.
Section 2 presents an brief comparison with other semiotic approaches.
Section 3 introduces the user-designer communication problem during the
elicitation phase as a motivation for our work. Section 4 presents an
overview of the semiotic framework and the main characteristics of our
requirements elicitation strategy. In the section 5, a short but
comprehensive example illustrates some aspects of semiotic approach
usage. Finally, some final remarks are drawn.

In the last years, some semiotic approaches have been proposed for
HCI design, such as [Nadin 88] and [Marcus 92], inspired by Peirce's
work; and [Souza 93], inspired by Eco's Theory of Sign Production.
Essentially, these works focus on a set of theoretically-based
guidelines for design of user interface languages, either textual
(based on words and sentences) or iconic (based on graphics and
pictures). They all converge to identify the symbolic nature of HCI
design, although with an emphasis on its presentation component.

Our work is also concerned with identification of semiotic
principles for increasing the system design but we are not restricted
to user interface signs related issues. In fact, like [Andersen 90], a
work inspired by Hjelmslev's glossematic theory, a Scandinavian
systematisation and reinterpretation of European structuralism, we
consider HCI design as a critical part of user-centred design, but
always tackling functionality. Rather than the user-system
communication, we are addressing the user-designer communication to
allow a better elicitation of system requirements from the user needs,
a fundamental part of the Requirements Engineering process [Jarke 94].

By the early 80's it was widely recognised that the major problems
in improving software quality and productivity was concentrated in the
early part of the software development cycle. In fact, understanding
user needs and environment constraints is a very complex process,
called the Requirements Engineering process.

According to [Jarke 94], the classical Requirements
Engineering cycle consists of three steps: Elicitation (also called
Determination), Expression (also called Modelling) and Validation.
Here, we are concerned with elicitation issues, which usually include
investigation and preliminary representation of both present activities
and future needs. Thus elicitation goals are firstly to acquire
knowledge of the user's present job and then to develop a vision of how
things might change in the future using the new system.

Traditional `Analyst-Centred' approaches to Requirements
Elicitation are usually associated with some implicit assumptions. For
example, most designers using traditional approaches think that, while
the designer is a computer expert, users are domain problem
specialists. Thus they know very well what they want and if an analyst
wants to know it, users just need to be questioned in the right way. In
practice, the term `requirements capture' is often used. We think, like
[Bubenko 94], that the term is however somewhat misleading because it
indicates that the requirements "are already there" and all we need is
some method or tool-set to better apprehend and to get the requirements
from users.

This central role of analysts in the elicitation process is
abandoned in favour of a broader user participation in `User-Designer
Cooperation' approaches, where analysts elicit with users
[Macaulay 95]. Technological knowledge is necessary but not sufficient
for an analyst collaborating with users. Consequently, a
multidisciplinary perspective, borrowing ideas and concepts from other
scientific domains, is considered essential for the success of this
approach.

Major problems with requirements engineering arise from a lack
of knowledge about the application domain and user-designer
communication breakdowns (see [Curtis 88] for empirical evidence).
Several techniques, including user participation, AI-based requirements
capturing systems or knowledge acquisition systems and various forms of
prototyping, are used to provide methodological support for the process
of domain knowledge capture and to adapt software design to meet the
needs of specific user communities. However, there is surprisingly
little effort to provide support to user-designer communication. Since
the object of Semiotics is sign systems and within its scope are
communication and signification phenomena, we have chosen to borrow
concepts and techniques from Semiotics to propose an approach for
requirements elicitation.

Our research has three basic lines. First, the definition of a
semiotic framework that integrates into an interdisciplinary coherent
whole a semiotic theoretical basis and the software development
activities, in particular the requirements engineering activities.
Second, the specification of a strategy and the implementation of
development tools using this semiotic framework. Third, the validation
of both our concepts and tools by means some actual case studies. In
this section, we present our requirements elicitation oriented semiotic
framework and the basic lines of our requirements elicitation strategy.

Our semiotic approach aims to support mutual learning, that is, user and designer participating on a mutual process of learning and communicating. It has three basic assumptions. First,
we think that increasing and improving the user designer communication
is a sound way to know more about both the user and his/her problem
domain. Second, we think that this communication is improved by
an explicit commitment to "Talk the user language". Our work then
presumes the elicitation of user language itself before the
requirements elicitation phase. Third, elicitation of user
language is an interactive, cyclic and incremental process of
determination/validation of his/her code. Here, `code' is not
understood as only a `vocabulary', but as a `semiotic system', covering
any set of symbolic acts and their underlying signs manipulated during
the user-designer interaction.

Most approaches using (human or automatic) translators for
intermediate communication with users have been proven to be
ineffective, probably due to the impossibility of studying work
language apart from its non-symbolic context [Andersen 90]. In our user
language centred approach, we address the direct communication problem
faced by designers and users describing in a semiotic framework both
the concepts that reflect the characteristic features of user language
and the meaning of their occurrence related to other concepts.

From a semiotics' point of view, the context of development concerns
the construction of a set of signs that are going to be interpreted in
the context of usage. As part of creating an appropriate context of
interpretation and `sign halves', we devised an strategy centred on a
user language, namely the user-language-about-work. This language is used to talk about the work situation and it should not be confused with a user worklanguage, an operative language used in work situation [Falzon 84] [Katzenberg 93].

The signs of the user-language-about-work are the foundation of our semiotic framework and the language elicitation is the right starting point for our user-language centred requirements engineering strategy (see Figure 1).

The basic unit of user-language-about-work is a sign
description, used to signify actual concepts of user language. Each
sign description is composed by:

a) a name (and an enumeration of synonyms used by the user);

b) a notion of sign (that is, its definition); and

c) a set of impacts (that is, the effects of its usage or occurrence).

Notions and impacts are interpretants (in Peirce's terminology)
of each sign of user language. In other words, they are signs which
help us to find an approximate meaning of the sign being described, by
means of both (i) signs that belong to user-language-about-work --
which are important concepts of user language that must be described --
and (ii) common signs -- which most people use without interpretation
problem in daily situations, like prepositions, connectives, and so
forth, then not described.

Notions and impacts must abide by two principles: circularity and minimal vocabulary, defined primarily in [Leite 93]. The Circularity Principle establishes that each user language sign shall be described as much as possible by means of other user language signs. The Minimal Vocabulary Principle establishes that use of signs not pertaining to the language shall be kept to a minimum.

Figure 1: Semiotic approach as a support for user-designer communication

User-language-about-work knowledge supports the
communication process where system signs are invented. Actually, these
signs are only "sign halves", as long as the other half is constructed
in the meaning construction process of software usage. It is only then,
during software usage, that the design will prove to be successful or
not. Our approach aims to increase the odds of a successful
interpretation, by improving the mutual understanding, and thus the
mutual learning, as user and designer collaboratively design the system
signs. The strategy briefly described below is an attempt at putting
this theory into practice. It describes how user language is elicited,
represented, validated and used in requirements elicitation.

The User Language Centred strategy consists basically on the
gathering and organisation of user language knowledge following the
semiotic framework, then link it to the Objectory object-oriented
development method [Jacobson 92]. Figure 2 shows the architecture of
User Language Centred Strategy.

The first activity prescribed by the strategy is the
elicitation and further representation of the user-language-about-work.
Firstly, we use a sign determination process as a means to elicit the
user-language-about-work. The Sign determination process is an
iterative process of acquisition/representation/validation of signs,
which must be done incrementally and collaboratively by users and
designers. Sign acquisition is done usually by means of
informal interviews but also by means of retrospective protocols and
immersion of analysts in the workplace. In retrospective protocols, the
worker is required to generate a verbal report of their own activities
performance. Immersion is the active participation of analysts in
worker's activities. Sign validation is usually made by means of Informal Interviews. Sign representation
is firstly informal and then structured using Language Extended Lexicon
-- LEL [Leite 93], a hypertext-like notation (supported by the HyperLex Cover tool [Faust 95]). Using LEL, structure is very simple: a sign description is an entry; signs that belong to user language present in notions or impacts descriptions are links to their corresponding entries; for a more detailed understanding of user language, we may `navigate' signs descriptions.

Figure 2: Architecture of User Language Centred Strategy

The theoretical foundation for the sign determination
process is the Case Grammar Theory [Fillmore 1968], a discourse
analysis technique which we use in a particular way. In the Case
Grammars theory, the constituents of a sentence fall into a small
number of meaning categories, defined by their relationship to the
verb. The exact number and definition of the cases may differ, and our
choice includes the following categories: Agent, Beneficiary,
Instrument, Object, Time, Place, Source/Destination, Action. For us,
these categories are an easy way to identify relevant user language
signs. The corresponding meaning of both notion and impacts concepts
changes according to the corresponding category (see table 1). In the
case of a sign being classified in two or more categories, the notion
of the sign is the union of all possible notions and the set of impacts
of the sign is the union of all possible impacts.

Table 1: Categories used in the sign determination process and their
corresponding notions and impacts

CategoryNotionImpact

Agent Who is s/he? Agent actions Object What is it? Actions applicable on the Object

Instrument What is it? How Instrument is used in an action execution Beneficiary Who is s/he? Which action affects her/him? How?Place Where? Actions which occurs there Time When? Action which occurs at this Time (chronological or relative to other actions) Source What is it? Actions that moving some thing from Source Destination What is it? Actions that moving some thing to Destination Action Who executes it? Consequences: Pre-Conditions Post-conditions or more Procedure to actions (propagation) Execution (sub-actions, etc.)

A structured LEL signs description may be translated to the Domain
Object Model -- DOM [Faust 92], an object-oriented domain model, using
a set of heuristics fully described in [Faust 95]. While LEL concerns
elicitation of signs, DOM aims at detecting misconceptions and
omissions in the definitions, and setting down a basis for reusability.

The second activity of the strategy is the link between the DOM
model and the Requirements Model of the Objectory Use-Case Driven
Analysis Process for then specifying the requirements and defining the
preliminary object-oriented architecture of the system. As tasks
related rather to modelling than to elicitation of requirements, both
DOM modelling and the link with Objectory method are outside the scope
of this paper and are not described here.

The incremental process moves from gathering knowledge about
work language to inventing the system signs for the new system. We
expect to have higher quality requirements (including both functional
and HCI requirements) at the end of this process because we will be
communicating with users in a better way. In addition, the system signs
proposed will be inserted in the work language and designed in a
participatory process, therefore increasing the chance of a proper
interpretation by the user community(ies) when using the system.

This is an example of a LEL sign description for an user language
elicited in one of case studies we did: a foreign language school. As
the work was done in Brazil, we originally used Portuguese words but we
have tried to translate them to English. However, we think it remains
comprehensible to demonstrate some aspects of our framework.

sign: STUDENT/ STUDENTS (this is an entry with name and synonyms)notions Person IS_INSCRIBED in FOREIGN_LANGUAGE_SCHOOL. (Category Agent) STUDENT is EDUCATED by TEACHER. (Category Beneficiary) STUDENT is CLIENT of SCHOOL. (Category Object)impacts As Agent: (Actions of the agent) STUDENT does INSCRIPTION. STUDENTS BUY-TEXTBOOK. STUDENT GOES-TO-CLASSES. STUDENT STUDIES-A-FOREIGN-LANGUAGE. STUDENT makes EXERCISES. ...

In this example, we have a (deliberately incomplete) description of
2 signs: student and inscription. These sign names and their synonyms
are presented separated in each entry by an slash. An uppercase format
is an indication that a sign is also a link to another entry. Lowercase
format signs are common signs, not entries. Comments are shown in
italics.

The sign `student' is classified as an agent, a beneficiary and
an object. So, the notion (respectively the impact) of `student' is an
union of the notion (respectively the impact) of each student category.
For brevity, only the impacts of an student as an agent are partially
presented, like the actions `student does inscription', `students
buy-textbook' and so on. Note that each action is also an entry. Then,
if we are interested in more details about the `INSCRIPTION' action, we
may `navigate' the description to find it. The sign `INSCRIPTION' has
some verbal forms as synonyms, a common characteristic for an action
category.

Descriptions like this are very long, and a tool for LEL
structures manipulation may be used to aid construction and
organisation of sign descriptions.

Semiotic approaches have been used successfully for HCI design. HCI
phenomena are amenable to several kinds of analysis, each of them
bringing a new understanding and interacting with each other. Semiotics
is typically a science of this age of mass communication and
information-intensive industry. Computer systems, as messages conveyed
by a medium with unique features, will be better designed if we reach a
thorough understanding of their idiosyncrasies and interactions with
existent semiotic systems.

In this paper, we have exposed a preliminary investigation with
a semiotic approach to requirements engineering of interactive systems
as a whole (integrating user interface and functional components). The
application of semiotic concepts to the requirements elicitation may
help designers cope with the difficulties of communication with users
and consequently accomplish their development tasks more efficiently
and effectively. It was assumed software development as the invention
of computer based signs collaboratively by users and designers engaged
in a conversation where signs are proposed and its proper
interpretation tested. A better user-designer communication allows a
better problem domain knowledge acquisition and a good user
idiosyncrasies understanding. This communication is improved by an
explicit commitment to "talk the user language", presuming the
elicitation of user language itself before the requirements elicitation
phase.

We have performed several case studies in small organisations,
not only to validate the outcomes but to further develop the strategy
and evaluate its feasibility as well. Two of them have produced
Smalltalk prototypes for simple problem domains (a news-stand and a
foreign language school). Though not yet conclusive, the case studies
attest that the semiotic framework is useful for devising user centred
software construction and that the strategy is feasible and effective.
We are currently setting up new case studies, some of them in similar
organisations, allowing investigate reusability issues, and also in
more complex ones. We plan to report the results in future papers.