Shamim Islam noted that the IEEE definition of a requirement
- a condition or capability needed by a user to solve a problem or achieve an objective
- 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
- a documented representation of a condition or capability as in (1) or (2)
The latest IEEE definitions for system and software requirements are contained in the new ISO/IEC/IEEE 29148:2011, Requirements engineering, which replaces IEEE 830 and 1233.
Requirement: statement which translates or expresses a need and its associated constraints and conditions
NOTE Requirements exist at different tiers and express the need in high-level form (e.g. software component requirement).
Further, "Defining requirements begins with stakeholder intentions (referred to as needs, goals, or objectives), that evolve into a more formal statement before arriving as valid stakeholder requirements. Initial stakeholder intentions do not serve as stakeholder requirements, since they often lack definition, analysis and possibly consistency and feasibility."The old IEEE definition of a requirement is riddled with problems, as is the IIBA definition based on it. IIBA replaced 'system or system component' with 'solution or solution component', which clarified the role that requirements play in a change to an organizational system; "system" has become a synonym for "computerized or automated". That is a far cry from the intent in the IEEE definition, but one that the team writing BABOK Guide v2 had to take practical action to address.
The old IEEE and BABOK Guide v2 definitions:
- Conflate "Needs" with the ways that needs are represented.
- Imply that requirements can exist whether or not they have been represented at all.
- Overly constrain the things that can be called a requirement.
- Inappropriately limit "Value" to "things someone can do" and "things that are".
- Need: a problem, opportunity, or constraint with potential value to a stakeholder.
- Requirement: a usable representation of a need.
- Part 1 (needed by a user) describes problems and opportunities;
- Part 2 (met or possessed) covers constraints of various sorts;
- Part 3 (documented) is covered by the new definition of requirements.
"A Usable Representation Of A Need"The first two concerns that the core team identified are related, and addressed together by separating the meaning of 'need' from the ways that needs are represented. This approach recognizes that needs exist whether or not they are represented or even known. People needed vitamin C to live before vitamin C was known to exist. 'Requirement' is the term we use to mean the description of a need in any usable form. Requirements exist to be used by someone to fulfill a need - to do something to deliver that potential value.
Specific RepresentationsA few years ago, a need could not be represented using a wiki: the technology didn't exist. Often, requirements are not 'documented' in any traditional sense - nor should they be. In an Agile environment or an innovation shop a good conversation may be enough. Needs are still represented in some way, whether through speech, video, prototypes, working code, automated test cases, etc. Documents are in the set of representations - but representations include a lot more.
The list of 'formally imposed documents' in IEEE /BABOK Guide v2 is therefore far too narrow. The new definitions are easily applied at any span of the organization, and at any strata. A business case can be understood as a requirements document mixed in with a design document, financial planning, and some other things. A project charter has requirements in it, too.
Value - Features, Characteristics, ExperiencesThe nature of value is a passion of mine. I have written about a lot, both in those BACCM articles and in an older series called 'The Future of Business in the Internet Economy' from 2010 and 2011. It is relevant to this discussion because the current definitions of 'requirement' limit our understanding of value, and frame our thinking in ways that make us blind to many opportunities.
The mindset of the engineers who defined 'requirement' for IEEE was eminently practical. They were interested in what the system would be able to do once constructed and operational. These capabilities are often described in terms of features or functionality.
Features have value - but they are not the whole story. The features of a cloth grocery bag are quite similar to a designer purse, and a knock-off 'Guoci' bag could be identical to a 'Gucci' bag. These bags have very different valuations, however. This means that features have value - but value is determined by more than just features.
In the case of the bags, value is based on the characteristics that the product confers to the owner. The person with the Gucci bag is seen to be different from the person with the Guoci bag. In the case of an iPod "1000 songs in your pocket" was not valuable as a feature; it was an experience the owner of an iPod could have. Features are valuable because they affect what you can do. Characteristics and experiences are valuable because they affect who you are.
The new definitions of requirements and needs encompass these concepts. They make it coherent to define requirements for the experience a person should have, or the way a product should affect social interactions among product owners. This is not just the realm of marketing or social scientists. It is also the realm of the most successful businesses, and of business analysis.