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 |
In very rare cases, a key term is equally aligned to all six core concepts. So far, 'business analysis' is the only clear example:
Business analysis is the practice of enabling change in the context of an organization by defining needs and recommending solutions that deliver value to stakeholders."
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. |
These definitions are not completely consistent. The introduction describes a solution as a set of changes, but the glossary describes a solution as a way of addressing a need.
The introduction tries to address this by stating,
The introduction tries to address this by stating,
The scope of the solution ... will serve as the basis for the scope of a project to implement that solution or its components
The BACCM reconciles and clarifies these definitions by separating them:
A solution is a specific way of satisfying a need in a context.
A change is a controlled transformation of an organization.
A change is a controlled transformation of an organization.
Changes are made to increase the value delivered to stakeholders through capabilities, characteristics, and experiences. This may be the 'future state' that a change (such as a project) will create. It could also be a thing that already exists and is delivering value, but could deliver more.
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.
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.
.5 Requirements are Designs
Obi-Wan: So what I told you was true, from a certain point of view.
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
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
Some stakeholders consider a given power option to be a solution; others consider the same option to be a problem (a type of need). Many stakeholders will recognize the option solving some problems and causing others—as need and a solution at the same time, or an answer with consequences.
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:
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:
1. The business analyst elicits a need.
2. The business analyst represents the need as a rule on a whiteboard.
2. The business analyst represents the need as a rule on a whiteboard.
At this point, most BAs would agree that the rule is a requirement—a usable representation of a need. But, what if:
3. The business analyst represents the need as a rule in a business rules engine.
4. The business rules engine executes the rule, resolving the need from (1).
4. The business rules engine executes the rule, resolving the need from (1).
When it was written on a whiteboard in (2), the rule was clearly a requirement. But in (3), when written in the business rules engine the rule becomes a usable representation of a solution. The same statement becomes a design because of a change of context. (This example works equally well without a computer or other technology: imagine a poster on hospital room doors stating 'Wash your hands.')
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.
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
The BACCM clearly represents the reality of needs and solutions: people don't place the same value on any given thing. This is a foundation of economics, and how trade creates value. For example, farmers trade 'low value' vegetables (from their point of view) for 'high value' money; townies trade 'low value' money for 'high value' vegetables (from their point of view). The implications of the subjective nature of value—and therefore needs, solutions, requirements, and designs—are simultaneously earthshaking and simple for BAs.
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.
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.