The term requirement first appeared in software engineering in the 1960s.1)
The Business Analysis Body of Knowledge® version 2 from IIBA (BABOK),2) defines a requirement as having one or more of the following characteristics:
A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
A documented representation of a condition or capability as in (1) or (2).3)
This definition is based on IEEE Standardized vocabulary.4)
Although Requirements at first glance appear to be simple, they quickly become very complex as the number of requirements increase, and consequently they need to be managed and governed. Add this complexity to the complexity associated with any distribute system, and it can quickly seem daunting and overwhelming. Like any other large problem that confronts us, it is too hard to handle it as one big problem. In engineering, a common approach is to not address the one big problem but to refine the problem into a series of little problems which can be solved. Consequently, that is why the bigger solution requires governance.
The following chapters help refine this big problem into smaller ones.