Developing a Glossary for Software Projects

Developing a Glossary for Software Projects

Copyright: © 2018 |Pages: 12
DOI: 10.4018/978-1-5225-2255-3.ch644
(Individual Chapters)
No Current Special Offers


The success of a software project depends intrinsically on effective communication among stakeholders. The purpose of a glossary is to ensure that the knowledge of the domain underlying a software project be communicated properly to all the stakeholders of that project. This chapter provides the context, the rationale, and the means for developing a glossary for software projects. In doing so, it proposes a process for developing a glossary. This process is independent of any particular application domain, software development methodology, and information technology. The approaches for representing and presenting a glossary, for the consumption of humans as well as that of machines, are discussed.
Chapter Preview


In this chapter, the terms ‘software project’ and ‘project’ are considered synonymous, unless otherwise stated. The term ‘project’ is used to emphasize the fact that the notion of glossary is applicable to a variety of projects, including, but not limited to, software projects. A software project may be about development or about maintenance of a software product.

The following definitions are essential for the rest of the chapter. A domain is an area of interest (or the universe of discourse). A glossary is a list of terms in a particular domain of knowledge with the definitions for those terms. A stakeholder is an individual, group, and/or organization, having an interest in a project.

Glossary in Context

The history of use of glossary in software projects goes back to mid-to-late-1960s, and is therefore is almost as old as the discipline of software engineering itself.

A glossary is similar to, but different from, a dictionary, lexicon, and thesaurus. A comparison can be made using the criteria of goal and scope.


A glossary, like a dictionary, presents its terms (and corresponding definitions) in a lexicographical (alphabetical) order. Also, a glossary, like a thesaurus, may include synonyms of its terms, but does not include antonyms of any terms. For example, in a Glossary of Requirements Engineering Terminology (Glinz, 2014), bug, defect, and fault are considered synonymous. However, unlike a lexicon, a glossary usually does not point to etymology of a term.


A glossary is specific to the scope of a project, while dictionary, lexicon, and thesaurus are more general in scope as implied by the type of information they include.

Key Terms in this Chapter

Requirement: A statement which translates or expresses a need and its associated constraints and conditions.

Artifact: A document or a model produced during software development.

User Story: A high-level requirement statement that contains minimally sufficient information to produce a reasonable estimate of the effort to implement it.

Process: A set of interrelated or interacting activities that transforms inputs into outputs for some purpose.

Wiki: A Web application developed cooperatively by a community of users, allowing any user to add, delete, or modify information.

Software Engineering: The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.

Agile Software Development Methodology: A software development methodology based on the Agile Manifesto.

Social Web: The perceived evolution of the Web in a direction that is driven by ‘collective intelligence,’ realized by information technology, and characterized by user participation, openness, and network effects.

Complete Chapter List

Search this Book: