Needs and Solutions, Requirements and Designs
1.0 Needs and Solutions, Requirements and Designs
Six core concepts form the foundation of Business Analysis: change, need, solution, context, stakeholder, and value. The Business Analyst Core Concept Model™ (BACCM)™ describes these relationships among these core concepts as a dynamic conceptual system. All the concepts are equally necessary; there is no 'prime' concept, and they are all defined by the other Core Concepts. Because of this, no one Core Concept can be fully understood until all six are understood.
This article focuses on the nature of needs and solutions and how business analysts represent them both with requirements and designs. (The interconnectedness of the BACCM means that some discussion of value, stakeholders, context, and change is inevitable.)
.1 A usable representation of...
The BACCM separates the core concepts from the way they are represented, because core concepts don't have to be represented to exist. Vitamin C solves a metabolic need in humans, but until just a few hundred years ago no one knew it existed. Humans had a need for something, a solution to that need, and no representation of either.
When A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) version 2, was written, this distinction was not clear. The community didn't have a way to differentiate some tightly related concepts, like need and requirement. The BABOK® Guide v2 definition of a requirement implies that a need that is never expressed—or even imagined—is a requirement (part 3 of the definition). But how can an unknown need be managed or analyzed? To a lesser degree, this same confusion exists between 'solution' and 'design'.
By separating the core concepts from their representations, the BACCM simplifies and clarifies both.
.2 Key Concepts, Key Terms, and Core Concepts
The introduction to the BABOK® Guide v2 lists several 'key concepts', including both 'solution' and 'requirement'. In the BACCM, these ideas have a different nature, and are categorized differently. Solutions are grouped with the other five core concepts: value, need, change, stakeholder, and context. Requirements are grouped with dozens of 'key terms', such as design, plan, risk, domain, scope, organization, and many more.
Key terms are not subsets of core concepts, or contained within a single core concept. They are aligned to each core concept to varying degrees. A few key concepts are noted here to illustrate this alignment.
Key Concepts | Alignment to Core Concepts (starting with strongest alignment) |
Requirement | Need, Value, Stakeholder |
Design | Solution, Need, Context |
Plan | Change, Solution, Context, Stakeholder |
Risk | Change, Value (reduced) |
Benefit | Value (increased), Stakeholder, Context |
3 What are Needs? What are Requirements?
In BABOK® Guide v2 'need' is used over 400 times, and requirement appears about 1800 times. Taken together, these words appear about ten times per page. And yet, despite widespread agreement that requirements describe needs, 'need' is never defined. The book assumes 'need' is already understood (much as almost every business book assumes 'value' is understood and agreed on). Requirements1 are defined, however:
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).
The BABOK® Guide goes on to say,
The term “requirement” is one that generates a lot of discussion within the business analysis community. Many of these debates focus on what should or should not be considered a requirement, and what are the necessary characteristics of a requirement. When reading the BABOK® Guide, however, it is vital that “requirement” be understood in the broadest possible sense. Requirements include but are not limited to, past, present, and future conditions or capabilities in an enterprise, and descriptions of organizational structures, roles, processes, policies, rules, and information systems. A requirement may describe the current or the future state of any aspect of the enterprise.
This definition can be simplified and generalized several ways.
- Assume that part 3 of the definition is not optional: a requirement is a representation, not the thing itself.
- Looking at the first part of the definition, 'a condition or capability' can be generalized to 'something that could deliver value' by conferring an ability, a characteristic, or an experience to the stakeholder.
- The general case of 'achieve an objective' can be rephrased as 'take advantage of an opportunity'.
Taken together, this means that one aspect of a requirement is
'A representation of something that could deliver value to a stakeholder by solving a problem or by taking advantage of an opportunity.'
The second part of the definition can be simplified and generalized as well.
4. The words 'that must be met by' are key: a requirement can represent constraints that a solution must conform to.
Since we have declared that requirements are a representation of a need, we can define a need as:
'something that could deliver value to a stakeholder by solving a problem, taking advantage of an opportunity, or conforming to a constraint.'
In the BACCM, we simplify further. A need is:
'a problem, opportunity, or constraint, with potential value to a stakeholder.'
Describing a requirement as 'a representation of a need' is a great start, but not sufficient. If you represent a business need for an application interface improvement through interpretive dance it's unlikely that anyone will be able to use that representation to do anything. Since organizations exist to do things, requirements must be useful at some level. The result is the BACCM definition of a requirement:
'a usable representation of a need.'
.4 What are Solutions? What are Designs?
In BABOK® Guide v2, designs are not defined, but solution is defined in two places:
Ref | Definition |
p.4 | A solutions is a set of changes to the current state of an organization that are made ... to enable the organization to meet a business need, solve a problem, or take advantage of an opportunity. |
p.232 | A Solution meets a business need by resolving a problem or allowing an organization to take advantage of an opportunity. |
The introduction tries to address this by stating,
A change is a controlled transformation of an organization.
The BACCM uses parallel definitions for requirement and design. A design is 'a usable representation of a solution,' where version 2 of the BABOK® Guide does not define or refer to designs in any consistent way. This decision was based on many factors, including the need to clearly differentiate the emerging business analysis profession from project management, software designers, and other professional change agents. Given years of conflict embodied in the question "is it a requirement or a design," this was a reasonable and practical approach to take. Business Analysts dealt with requirements, and other people dealt with designs.
With the structure of the BACCM, it is now clear that business analysts deal with requirements and designs all the time, because requirements and designs are labels we use to express a judgment of value.
Luke: [incredulously] A certain point of view?
Obi-Wan: Luke, you're going to find that many of the truths we cling to depend greatly on our own point of view.
—From Return of the Jedi
Needs and solutions are real—but they are subjectively real, not objectively real; they require a point of view.
- Objectively real: existing without influence from personal feelings or opinions.
- Subjectively real: existing based on or influenced by personal feelings, tastes, or opinions.
Needs and solutions are subjective because value is a judgment of the relative importance of something to someone. As judgements or relationships that stakeholders have to things, needs and solutions can't exist independent of things (and anything can be a thing). When value is being realized through a thing, the stakeholder calls the thing 'a solution'. When value could be increased or realized through a thing, the stakeholder calls the thing 'a need'.
This means that one stakeholder may consider a thing to be a need—while another stakeholder considers the same thing to be a solution. For example, classify each of these power sources as a need or a solution:
- wind power
- solar power
- oil power
- nuclear power
- natural gas power
- hydroelectric power
- coal power
Since needs and solutions can only be defined in terms of a stakeholder and a context, requirements and designs must behave the same way; they are just usable representations of needs and solutions.
Practically, the BACCM resolves problems BAs face when dealing with stakeholders who want to name representations as designs or requirements. Consider processes and rules: Should BAs work on them? Are they designs? Are they requirements? Based on the BACCM, the answer to the first question is 'definitely'. Depending on the stakeholder's point of view, these may be a usable representation of a need, or a usable representation of a solution, or both. Consider this scenario:
2. The business analyst represents the need as a rule on a whiteboard.
4. The business rules engine executes the rule, resolving the need from (1).
Using the BACCM, a BA can confidently work on processes, rules, decision tables, and many other usable representations. If the representation gets a stakeholder closer to understanding the value that could be delivered, it should be labelled as a requirement for that stakeholder. If the representation gets a stakeholder closer to realizing value, it should be labelled as a solution for that stakeholder. If it does both at the same time, call it both, or avoid the terms altogether.
2.0 Synthesis
On the simple side, almost all BAs can see practical benefit from recognizing that 'need' and 'solution' are value judgements about things. As communicators, facilitators, and negotiators, this subjective view makes it easier to consider the views of many stakeholders. It makes mental space for questions like, "Let's make a list of the problems this change will solve for you—and cause for you. Then we'll do the same thing from an organizational point of view." It gives Business Analysts a coherent way to sidestep the question, 'Is it a design or a requirement?'
On the earthshaking side, 'design' is often considered a dangerous word for the profession. Many business analysts have fought hard for recognition, and many business analysts are still in that fight. For decades, we have defined our profession by what we are not: BAs are not Project Managers, or Testers, and we are not Designers. With the BACCM, we can show that the Business Analysis profession is concerned with value, needs, and solutions—so business analysis must be concerned with requirements and with designs.