Issue
Article
Vol.29 No.1, January 1997
Article
Issue
Issue |
Article |
Vol.29 No.1, January 1997 |
Article |
Issue |
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 work language, 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
Category Notion Impact 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.
...
sign INSCRIPTION/ DO_INSCRIPTION/DOES_INSCRIPTION/...
notion (Category Action)
Action executed by STUDENT. (Who executes)
STUDENTS PAY_INSCRIPTION by CARD or CASH. (Subtask of action execution)
STUDENT has done INSCRIPTION_TEST for
EVALUATION_LEVEL of FOREIGN_LANGUAGE. (Pre-condition)
...
impacts
STUDENT IS_INSCRIBED in LEVEL_n of a COURSE. (Post-condition)
STUDENT chooses CLASS_DATE and CLASS_HOUR. (Optional Next Action)
STUDENT must BUY-TEXTBOOK during INSCRIPTION. (Next Action)
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.
The participation of Marcelo Pimenta is sponsored partially by CAPES, a Brazilian Research Council.
[Andersen 90] Andersen, P. B., A Theory of Computer Semiotics, Cambridge University Press, Cambridge, 1990.
[Bubenko 94] Bubenko Jr., J. Enterprise Modelling. Ingénierie des Systèmes d'Information, V. 2, N. 6, 1994, 657-77 (Special Issue on Requirements Engineering).
[Curtis 88] Curtis, B.; Krasner, H.; Iscoe, N. A Field Study of the Software Design Process for Large Systems. CACM, 31(11), 1988
[Falzon 84] Falzon, P. The Analysis and Understanding of an Operative Language. In: Shackel, B. (ed.) Proc. of INTERACT '84, 437-41, Amsterdam, North-Holland, 1984.
[Faust 92] Faust, R. Domain Object Model -- Definition and a Case Study. Technical Report 03/92. Computer Science Department, Universidade Federal de Santa Catarina, Brazil, 1992. (In Portuguese). Available directly with the author.
[Faust 95] Faust, R., Software as Sign Interpretation: A User Linguistic-Register-Centred Strategy for Software Development, Master Thesis, Federal University of Santa Catarina, Brazil, 1995 (In Portuguese).
[Fillmore 68] Fillmore, Ch. J.,The case for case. In: Bach, E. & Harms,R.T. (eds.), Universal in Linguistic Theory, Holt, Rinehart and Winston, London, 1-90, 1968.
[Jacobson 92] Jacobson, I. et al. Object Oriented Software Engineering, ACM Press, Addison-Wesley, 1992.
[Jarke 94] Jarke, M. et al. Requirements Information Management: the NATURE approach. Ingénierie des Systèmes d'Information, V. 2, N. 6, 1994, 609-37 (Special Issue on Requirements Engineering).
[Kammersgaard 88] Kammersgaard, J. Four Different Perspectives on Human-Computer Interaction. International Journal of Man-Machine Studies, V. 28, 343-62, 1988.
[Katzenberg 93] Katzenberg, B.; Piela, P. Work Language Analysis and the Naming Problem. Comm. of ACM, V.36, N. 4, June 1993.
[Leite 93] Leite, J.C; Franco, A.P.M. A Strategy for Conceptual Model Acquisition. Proc. of the First IEEE International Symposium on Requirements Engineering: (1993), IEEE Computer Society Press, 243-46.
[Macaulay 95] Macaulay, L. Human-Computer Interaction for Software Designers. International Thomson Publishing, London, UK, 1995.
[Marcus 92] Marcus, A. Graphic Design for Electronic Documents and User Interfaces. New York, ACM Press, 1992.
[Nadin 88] Nadin, M. Interface Design: a Semiotic Paradigm. Semiotica 69, 3/4, 269-302, 1988.
[Souza 93] Souza, C.S. The Semiotic Engineering of User Interface Languages. International Journal of Man-Machine Studies, V. 39, 753-73, 1993.
Richard Faust
Universidade Federal de Santa Catarina
Caixa Postal 476 Cep 88040-900
Florianópolis -- SC -- Brazil
Issue |
Article |
Vol.29 No.1, January 1997 |
Article |
Issue |