Creating Software System Context Glossaries

Creating Software System Context Glossaries

Graciela D.S. Hadad (Universidad Nacional de La Matanza, Argentina & Universidad Nacional de La Plata, Argentina) and Jorge H. Doorn (INTIA, Universidad Nacional del Centro de la Provincia de Buenos Aires, Argentina and Universidad Nacional)
DOI: 10.4018/978-1-60566-026-4.ch128
OnDemand PDF Download:


Requirements engineering (RE) is the area of software engineering responsible for the elicitation and definition of the software system requirements. This task implies joining the knowledge of the services that a software system can and cannot provide with the knowledge of clients’ and users’ needs (Jackson, 1995; Katasonov & Sakkinen, 2005; Kotonya & Sommerville, 1998; Sommerville & Sawyer, 1997; Sutcliffe, Fickas, & Sohlberg, 2006; Uchitel, Chatley, Kramer, & Magee, 2006). Frequently, this activity is done by people with a software engineering bias. The underlying hypothesis of this choice is that users’ needs are easier to understand than the software’s possible behaviors. This is not always true; however, this is the metacontext in which most RE heuristics and methodologies have been developed. Understanding clients’ and users’ needs is far more complex than merely interviewing selected clients and user representatives, compiling all gathered information in one document. Defining how to put into service a complex software system within an organization requires envisioning how the business process of the organization will be in the future from both points of view: software organization and business organization. This is the key of the RE commitment: to imagine how the future business process will be. This RE commitment requires a good knowledge about how the business process actually is. Understanding the software system’s preexistent context basically means understanding the clients’ and users’ culture. In other words, this part of the RE is a learning process.
Chapter Preview


The importance language has in any culture should be noticed. Language is an organized system of speech by which people communicate with each other with mutual comprehension. Also, it is very important to note that by the words it contains and the concepts it can formulate, language is said to determine the attitudes, understandings, and responses in any society. Language, therefore, may be both a cause and a symbol of cultural differentiation (Fishman, 1999; Hall, Hawkey, Kenny, & Storer, 1986). Language reflects environment and technology: Arabic has 80 words for camels, while Japanese has more than 20 words for rice and Inuit has more than 20 words for snow and ice (Nettle & Romaine, 2000). Clients and users have several special words that they use when discussing their activities. The requirements engineer must pick and understand as many of these words as possible as a first step in understanding clients’ and users’ culture.

Glossaries have been used in software engineering with different purposes, such as data dictionaries in early database books (Codd, 1982) to document entities, attributes, relations, types, and services of databases. Thus, it provides a common understanding of all the system names to the developer team and later to the maintenance team. However, data dictionaries are also an important component of structured analysis, data recording, data storage, and the details of processes (Gane & Sarson, 1982; Senn, 1989), though authors like Gane and Sarson suggest that the real name for them should be project guide instead of data dictionary. These data dictionaries are created during analysis and also used during system design. They satisfy five objectives: to manage details, communicate common meanings, document system characteristics, help the analysis of details and changes, and locate errors and omissions of the system.

In this article an RE process beginning with the construction of a language-extended lexicon (LEL) as its first activity (Leite, Hadad, Doorn, & Kaplan, 2000) is addressed, and the structure and creation of this LEL is described.

Key Terms in this Chapter

Verification: It is the activity of checking for the consistency of different parts of a model or different models among them. It should answer the question “Are we creating the model right?”

Sources of Information: These include documents, key people, books, and so forth that can provide useful information about the matter being studied.

Heuristic: It is a set of guidelines to help people to use others’ experience to improve performance in a given task.

Elicitation: Elicitation is the activity of acquiring knowledge of a given kind during the requirements engineering process.

Software Engineering: It is the computer science discipline concerned with creating and maintaining software applications by applying technologies and practices from computer science, project management, engineering, application domains, and other fields.

Language-Extended Lexicon: An LEL is a semiformal model holding the most relevant words or phrases of the language of the application domain carrying special meaning.

Requirements Engineering: It is an area of the software engineering that is responsible for acquiring and defining needs of the software system.

Validation: Validation is the activity of contrasting a model with the actual world. It should answer the question “Are we creating the right model?”

Complete Chapter List

Search this Book: