Nominalizations in Requirements Engineering Natural Language Models

Introduction

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.