Consistent Terminology

When a poet writes a poem, he intends that it should inspire rich and diverse visions in anyone who reads it. The requirements analyst has the opposite intention: He would like each requirement to be understood in precisely the same way by every person who reads it. Requirements specifications are not poetrythey are not even novels where a subjective interpretation is sought. The requirements specification must have only one interpretation if the developer is to build the right product. Otherwise, there is an obvious danger of building a product that satisfies the wrong interpretation of the requirement.

Does the specification contain a definition of the meaning of every essential subject matter term within the specification?

To specify a requirement so it is understood in only one way, you should define the terms you are using and the meanings of those terms within the specification. Section 5 of the Volere Requirements Specification Template is called Naming Conventions and Definitions. This section is a repository for the terms that are used for this particular project. The terms are given a definition that is agreed by the stakeholders. This section acts as a reference point for the words used to write the requirements.

Is every reference to a defined term consistent with its definition?

The next act of consistency is to test that every requirement uses terms in a manner consistent with their specified meanings. It's not enough to define the terminology: We have to make sure that each term is used correctly. For example, in a requirements specification we once audited, we found the term "viewer" in many parts of the specification. Our audit identified six different meanings for the term, depending on the context of its use. This kind of terminology defect causes problems during design and/or implementation. If you are lucky, a developer realizes there is an inconsistency, but then has to reinvestigate the requirement. If you are not lucky, the designer inadvertently chooses the meaning that makes most sense to him at the time and implements that one. Any stakeholder who does not agree with that meaning will naturally consider the product to fail the requirement.

One last word about inconsistency: You should expect it, and you should look for it as part of the process of specifying requirements. When you discover inconsistencies, they point to a need for further investigation and perhaps negotiation.