Nominalizations in Requirements Engineering Natural Language Models

Nominalizations in Requirements Engineering Natural Language Models

DOI: 10.4018/978-1-5225-2255-3.ch445
(Individual Chapters)
No Current Special Offers


It is a usual practice to use natural language in any document intended for clients and users in the requirements engineering process of a software development. This facilitates the comprehension of the requirements engineer's proposals to clients and users. However, natural language introduces some drawbacks, such as ambiguity and incompleteness, which attempt against a good comprehension of those documents. Glossaries help by reducing ambiguity, though they introduce their own linguistic weaknesses. The nominalization of verbs is one of them. There are sometimes appreciable differences between using a verb form or its nominal form, while in other cases they may be synonyms. Therefore, the requirements engineer must be aware of the precise meaning of each term used in the application domain, in order to correctly define them and properly use them in every document. In this chapter, guidelines about treatment of verb nominalization are given when constructing a specific glossary, called Language Extended Lexicon.
Chapter Preview


The first activity of the development of a software system is to define its requirements. Requirements engineer must interact mainly with clients and users among other stakeholders (Macaulay, 1993). He or she has to understand the context in which the future system will act and he or she must carefully consider the reasons that conducted to the decision of developing such system. Requirements engineer’s responsibilities include establishing a fluid communication with all stakeholders to produce reliable documents that will be used later in the software development process (Leite et al., 2004). Usually the culture, knowledge and skills of clients and users are rather different from those of the software development experts. As part of the communication with clients and users, the requirements engineer must clearly show them the characteristics of the software system that he or she is conceiving to attend clients and users’ issues. Requirements Engineering process has two main activities: to understand the application domain, and to correctly define the services that the future software system will provide (Leite et al., 2004). As a general practice, both activities involve the development of models that describe such domain. It is also a common practice to develop such models in natural language to enhance the communication among stakeholders (Rolland & Ben Achour, 1998; Leite et al., 2004; Seiff et al., 2009); however, this introduces some obstacles, such as ambiguity, incompleteness and poor information structuring (Zowghi & Gervasi, 2002; Berry & Kamsties, 2004; Leite et al., 2005; Doorn & Ridao, 2009; Hadad et al., 2015). All of these inconveniences come from the natural language itself. As a consequence, Requirements Engineering has become more and more involved with linguistic considerations. Furthermore, it should be kept in mind that language conveys culture and knowledge (Nettle & Romaine, 2000; Fishman, 1999). Thereby, the terminology of clients and users holds application domain knowledge. Therefore, to document and to slightly formalize the relevant words or phrases heard from clients and users or read from documents is a valuable practice. In other words, creating a glossary of such terminology helps the Requirements Engineering process in two relevant ways: it eases the understanding of the application domain and it reduces the ambiguity of the oral communication with clients and users and the ambiguity of every produced document (Hadad, Doorn, & Kaplan, 2009).

However, the glossary construction itself introduces some drawbacks. The most important of these drawbacks, not yet treated, is the presence of nominalizations, either in the clients and users’ terminology or in the produced glossary. The former is a possible source of ambiguity while the latter is a hint of an adequate or inadequate creation of glossary symbols by the requirements engineer. Both may cause defects in the glossary. Nominalization refers to the construction of nouns from verbs or adjectives. Linguistic authors have largely studied nominalization in many languages such as English, French, German, Russian, Spanish, etc. (Alexiadou, 2001; Bisetto & Melloni, 2005; Grimshaw, 1990; Rothmayr, 2009; Rozwadowska, 1997). The simplest way to describe verb nominalization is by means of the phrase action of and effect of. In some cases, nominalization occurs only by action of; while in others only occurs by effect of.

In this chapter, the influence of nominalization on the quality of Requirements Engineering documents is analyzed. The requirements engineer should be aware of the substantial differences in meaning, that sometimes arise when using the nominal mode of a verb or its verbal mode, since the action and the effect of a verb nominalization may produce synonyms or even homonyms.

Key Terms in this Chapter

Completeness: The state or condition of having all the necessary or appropriate parts of a model or document.

Scenario: The description of a situation that currently happens or will happen in the application domain. The former are called Current Scenarios and the latter are referred as Future Scenarios.

Language Extended Lexicon: A glossary composed by a set of symbols, which are words or phrases peculiar and frequently used in a given application domain. The lexicon symbols have an additional description, not present in other glossaries. It contains hypertext links that interconnect symbols.

Omission: Information that has not been included in a model or document. It is the nominalization of the verb omit. In this chapter it is used as the effect of the verb (a state).

Natural Language Model: A model in narrative text produced during Requirements Engineering process, with a structure and content easily read by all stakeholders.

Ambiguity: Phrase or sentence that does not have a single clear meaning. It provokes two or more possible interpretations.

Complete Chapter List

Search this Book: