Friday, August 30, 2013

What are Needs and Requirements?

There is a very active discussion about Agile and Waterfall over on the IIBA LinkedIn group. Many characters have been typed in that thread by many people (I have perpetrated quite a few). An important-but-separate topic has emerged there, on the nature of requirements.

Shamim Islam noted that the IEEE definition of a requirement is was:*

  1. a condition or capability needed by a user to solve a problem or achieve an objective 
  2. 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
  3. a documented representation of a condition or capability as in (1) or (2) 

Update: This post has been updated based on new information. The definition above is still widely quoted and used across the internet, but in the IIBA LinkedIn group an updated version has been noted. The quote below is excerpted from a Yahoo Requirements Engineering group. I don't have access to the source standards document today, so I can't verify it - yet. The content is from Paul R. Croll (Chair, IEEE Software and Systems Engineering Standards Committee); I'll be contacting him about this.
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 Core Team working on BABOK Guide v3 did a lot of analysis of these definitions - not knowing about the revision above) as part of the development of the Business Analysis Core Concept Model (BACCM). (I have written a lot about this model in the BA Connection Newsletter, starting in October 2012. The big BACCM Overview is in the November 2012 issue.) Over the course of about two years, the team came to some conclusions.

The old IEEE and BABOK Guide v2 definitions:
  1. Conflate "Needs" with the ways that needs are represented.
  2. Imply that requirements can exist whether or not they have been represented at all.
  3. Overly constrain the things that can be called a requirement. 
  4. Inappropriately limit "Value" to "things someone can do" and "things that are". 
This lead to two simpler definitions that broader than the previous definitions in many respects. They subsume the IIBA BABOK Guide v2 and old IEEE definitions - and are consistent with the new IEEE 29148:2011 definition:
    • Need: a problem, opportunity, or constraint with potential value to a stakeholder. 
    • Requirement: a usable representation of a need.
    From the BACCM view,
    • 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.
    We'll take these in turn.

    "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.

    These definitions mean that requirements can not (by definition) be 'unrepresented'. Needs can be unrepresented. Requirements are representations of needs. This is a practical approach: businesses don't exist to make perfect models of needs. They exist to create / store / consume / move value among stakeholders. If the need is not represented then no action can be taken - so there's nothing a business can do about it.

    Specific Representations

    A 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, Experiences

    The 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.

    No comments: