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.

Evidence Based HiPPOs

A post over on AndrewMcAfee.org has me feeling uneasy, which is strange given my job and mandate (Head of Research and Innovation for IIBA, tasked to "transform business analysis into an evidence based profession and practice"). After some consideration, I think the source of my discomfort lies in the implication that opinion is never a good option. The comment below is posted to his blog, but I thought it worth noting here, as well.

(The image is from http://commons.wikimedia.org/wiki/File:Hippo_mouth.jpg)

---

As Andrew noted, the evidence we have does show us that more evidence usually improves decision making and performance. But the evidence has to be good evidence. It must be:

- Significant: the signal is clearly distinguished from the noise.
- Accurate: the measures reflect reality with useful fidelity.
- Unbiased: the data cover all relevant aspects of reality (not just the parts we like).

Collecting more evidence addresses the first factor directly: a certain volume is necessary for good evidence, but volume is not sufficient for good evidence. But learning to create and collect accurate evidence takes training and practice - a.k.a. experience. Your writing demonstrates that know that bias is insidious and pervasive, and can be controlled (to a degree) through rigor, discipline, and focus - but these are also characteristics developed through experience.

This leaves us in an uncomfortable situation. Good decisions* depend on good evidence - but good evidence depends on good decisions, and good decisions require experience (or expertise, or both).

So who has the experience needed to make good decisions with the available evidence? Perhaps it is a HiPPO who has lives by a heuristic:

"Evidence trumps reason trumps experience."**

This evidence-based HiPPO goes with experience only in emergencies, when there is no time for reasoning and no evidence available. Even in a crisis, the evidence-based HiPPO uses some rational approach to guide a decision, based on the situation: from argument and debate in some cases, decision tables in others. In all other conditions, the evidence-based HiPPO makes decisions based on good evidence.

The intersection of 'leadership skills' 'evidence-based decision making' and 'HiPPO' may be limited, but it exists, and is worth expanding. The HiPPO might be an endangered species on Vulcan, but they will never be rare on human worlds. This position is part of the way humans - irrational social animals that demand leadership - construct intentional collective endeavors. The power of evidence based practice is enormous, but it's not enough.***

___
* We're talking about systems that change based on decisions here and not systems that change over time without decisions (evolutionary systems, being an obvious example). Our species demands agency in most events, and finds it very hard to accept the idea that 'things just happen'. This makes changes that avoid agency appear to be wasteful in ways that make them hard to adopt in human endeavors. A/B/N testing is a rare exception in the business world.

**The pithier "evidence trumps experience" is usually how I express this idea, as one of four principles that guide how I live my life.

*** Summed up in another personal principle: "emotion motivates; data doesn't."

Make the Problem (Space) Bigger

Ron Ross has a post titled "Four Big Questions: Why Aren’t We Acting Like We’re in a Knowledge Economy?!" (I was particularly taken by the use of an interrobang.) I posted a long response, which I invite you to thrash over on Ron's blog. His questions do highlight a general systems-thinking technique that I use, and you may find useful. I call it 'Make The Problem Bigger' (after an infamous quote that I can't attribute at the moment). The more accurate name is 'Expand The Problem Space'. Here's how it works.

Questions, by their nature, imply or define a problem space. "Have you stopped stealing from the office?" is an example of a question that demands a binary, 'yes/no' response, but which likely can not be truthfully answered by either option. The form of the question limits the problem space in ways that make a satisfactory answer impossible.

This is common to all kinds of human endeavor: we try to simplify humans , or at least human irrationality, out of the system. I'm reminded of a phrase I have heard echoed through many roles in many industries: "This job would be so easy if it weren't for the damn [humans]!" (Substitute the stakeholder of your choice - customers, users, managers, vendors, programmers, and so on.) That means it is the first place I look for more problem space. I try out "because, humans?" as an answer to almost any intractable problem, and see where it leads.

Do you have a heuristic for expanding the problem space? What is it? Why does it work for you?

Bezos Buys Washington Post - A BA View

+Jeff Jarvis is one of my favorite positive curmudgeons. He's not afraid of being passionate, outspoken, opinionated, angry, gleeful, and excited. He's also not afraid to be wrong and to learn and to be public about it.

With those credentials, here's a quote from the BBC News Magazine:

Jeff Jarvis, author of What Would Google Do?, says he hopes Bezos will shake things up at the Post and help it adapt to a post-print world. 

"In some ways it has to be a philanthropic act," says Jarvis of the purchase. 

"Bezos is trying to protect an American institution. But I hope he doesn't just pay its bills. 

"My only fear is that he's famously secretive. It's part of his business. Whatever innovation he does at the Washington Post, it will help us all if it is done openly."

I haven't heard Jeff weigh in on This Week in Google (TWiG) yet - very curious! Before then, I have a thought about how Bezos thinks, and what that might mean for the Post.

From what I have read and seen, a big part of the genius of Amazon was the ability to break the business down into reusable, scalable parts. It's in their supply chain, their websites, and their web services. Some of these have become large businesses on their own as a result.

Purpose is another hallmark of his leadership. Amazon has created a lot of businesses, each with clear direction and focus. Right from the start it was a business based on a vision, and that hasn't changed.

If these behaviours are part of his nature, Bezos is looking at the Post in terms of it's parts and in terms of purpose. First things first - the post isn't a newspaper. Newspaper is a way to mass-distribute information when distribution is hard. The Washington Post, at it's core, does three things.

1. Find news.
2. Curate the news (for importance and relevance).
3. Distribute the news (to the people who find it important and relevant).

Somewhere among these three revenues must be collected and profit made. Right now the Post (and other news organizations) mostly monitise the third part. Ads and subscriptions are the traditional methods. Getting paid to find news invalidates the newsworthiness of the news, in the same way paying for love invalidates that love; non-monetary markets will remain a prime mover here. That leaves the money in curation.

What do you think?