First of all, what is meant by a requirement? Here is a typical definition drawn from IEEE-STD-
1220-1998 (IEEE 1998):
Requirement: a statement that identifies a product or process operational, functional, or design characteristic or constraint, which is unambiguous, testable or measurable, and necessary for product or process acceptability (by consumers or internal quality assurance guidelines).
This definition draws out a number of facets of a requirement that are briefly discussed here, and in greater detail later:
• Statement. That a requirement should be a statement is perhaps biased towards textual expression, whereas they can also be captured in tabular form, such as in Tom Gilb’s Planguage (Gilb 2005), in diagrammatic form in notations such as UML (OMG 2003), in formal notations, such as Z (Spivey 1989), VDM (Jones 1986), LOTOS (Bjorner 1987) and the BMethod (Abrial 1996), or in domain-specific notations, e.g. (Chaochen et al. 1991). The important concept, though, is to have a set of traceable, manageable elements identified
as requirements.
• Product or process. Complete solutions contain varying mixtures of product (things that are built in response to requirements) and process (procedures for using the things that are built). Requirements may therefore define process as well as product. In addition to this, there may be requirements that stipulate how the product should be developed, usually for quality control purposes.