It's important for the RA or requirements engineer to settle on definitions of the types of requirements that he will use consistently. He should advocate consistent meanings for these types on his project and in his organization. Much confusion can be avoided by agreeing on a set of definitions and by not using certain terms. In this chapter, we'll review several types of requirements and suggest definitions for them. We'll suggest why some terms shouldn't be used and provide other guidelines. One important reason for agreeing on the definitions of the types of requirements is to avoid lengthy and heated debates about terminology while we are working together. Establish a project glossary that everyone can live with (even if some definitions are not everyone's favorites) and utilize it in your work. Consider the glossary provided with this book as a starting point, and tailor it as needed.

First, let's recall our simple and useful definition of a requirement from Chapter 1. A requirement is a statement that identifies a capability, characteristic, or quality factor of a system in order for it to have value and utility for a user. A requirement is well defined and more specific than a need, which is a capability desired by a user or customer to solve a problem or achieve an objective. The authors of the Systems Engineering Capability Maturity Model (SE-CMM ) [1] were insightful when they created Process Area 06, "Understand Customer Needs and Expectations". The purpose of this process area...