The IEEE 610.12-1990 standard defines a "requirement" in three parts. What are they?
A requirement is (1) a condition/capability a user needs to solve a problem, (2) a condition/capability a system must possess to satisfy a contract or standard, or (3) a documented representation of (1) or (2).
The three-part definition is deliberately layered, because the word "requirement" gets used loosely to mean three different things:
- User-side need — "A condition or capability needed by a user to solve a problem or achieve an objective." This is the problem as the stakeholder experiences it ("I need to recover my password without calling support").
- System-side obligation — "A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document." This is the obligation placed on the thing you build, often because a contract or a standard (like PCI-DSS) demands it.
- The documented artifact — "A documented representation of a condition or capability as in (1) or (2)." A requirement isn't real engineering until it's written down; the sentence in the spec is itself "a requirement."
Why it matters: the same need can be high-level or detailed, and a requirement can serve as the basis for a contract you bid on, or be the basis of the contract itself. Pinning down which of the three meanings is in play avoids the classic confusion where one person means "the customer's wish" and another means "the line item in the spec."