I recently heard of a business analyst who trying to argue that “requirements gathering” and “solutioning” are two completely separate steps in the process of delivering software to clients.
I have encountered this idea before. I think this kind of thinking is a huge problem. This post explains why and offers an alternative, which is to think of “requirements gathering” and “solutioning” as steps in a larger process of principled negotiation.
What We Mean by “Requirements” and “Solutioning”
1.Requirements
As software development as an industry and practice was evolving in the late 20th century, the term the term “requirements” emerged as a way to refer to the set of things detailed in some kind of documentation about how a given system should function and what it should do when it is built. For example, if your daughter asks for a way to get to her best friend’s house 10 blocks away, the requirement might be to “have a means of transportation to get to Shirley’s house.” Great.
2.Solutioning
I have encountered this idea before. I think this kind of thinking is a huge problem. This post explains why and offers an alternative, which is to think of “requirements gathering” and “solutioning” as steps in a larger process of principled negotiation.
What We Mean by “Requirements” and “Solutioning”
1.Requirements
As software development as an industry and practice was evolving in the late 20th century, the term the term “requirements” emerged as a way to refer to the set of things detailed in some kind of documentation about how a given system should function and what it should do when it is built. For example, if your daughter asks for a way to get to her best friend’s house 10 blocks away, the requirement might be to “have a means of transportation to get to Shirley’s house.” Great.
2.Solutioning
In my experience, “solutioning” generally refers to the process of determining what and how the requirements will be met. Returning to your daughter, this could take a huge number of forms, including a piggyback ride, a pogo stick, a pair of shoes, a skateboard, a hover craft, or a hot rod.
The origin of a “Requirements” vs. “Solutioning” Mindset
In my experience, the “Requirement” vs. “Solution” distinction happens most often when there is tension between client team / business interest (the commissioners/buyers) and the tech team (the builders/sellers). Basically, this distinction happens when the relationship is already strained. People start pointing fingers when they feel unheard or unseen and they turn litigious – focusing minutely on “what was requested” and “what was delivered” as a way to establish blame.
There is a reason that you hear the advice from married couples to “Not keep score.” It’s because keeping score is a loser’s game. Successful relationships are successful because needs of each party are met such that each feels better off than they were before.
Returning to the example with your daughter and her requirement for a transportation medium - suppose you have a crazy great uncle who just died and left you – surprise – a single Sheltland Pony. So you offer it to her because you don’t know what else to do with it. Do you just turn to your daughter and say “Well honey, strictly speaking your requirement was just that you needed a transportation medium, so really, I have met my obligation… so you’re welcome.” Of course you don’t.
When people do draw this absurd line-in-the-sand, the obvious retort from the business interest is, similarly, to change the goal posts – e.g. “Well, the new requirement is that my transportation medium is a non-pony.”
This whole framing of the conversation gets no one anywhere. And intuitively, we all know this. In the real world, say, with your daughter, you ask your daughter to clarify what she needs and why she needs it and then you see what you can do and make work because you want to help.
An Alternative – Principled Solution Negotiation
Instead of quibbling this way about requirements and solutions, I think a better alternative happens in two general steps:
The origin of a “Requirements” vs. “Solutioning” Mindset
In my experience, the “Requirement” vs. “Solution” distinction happens most often when there is tension between client team / business interest (the commissioners/buyers) and the tech team (the builders/sellers). Basically, this distinction happens when the relationship is already strained. People start pointing fingers when they feel unheard or unseen and they turn litigious – focusing minutely on “what was requested” and “what was delivered” as a way to establish blame.
There is a reason that you hear the advice from married couples to “Not keep score.” It’s because keeping score is a loser’s game. Successful relationships are successful because needs of each party are met such that each feels better off than they were before.
Returning to the example with your daughter and her requirement for a transportation medium - suppose you have a crazy great uncle who just died and left you – surprise – a single Sheltland Pony. So you offer it to her because you don’t know what else to do with it. Do you just turn to your daughter and say “Well honey, strictly speaking your requirement was just that you needed a transportation medium, so really, I have met my obligation… so you’re welcome.” Of course you don’t.
When people do draw this absurd line-in-the-sand, the obvious retort from the business interest is, similarly, to change the goal posts – e.g. “Well, the new requirement is that my transportation medium is a non-pony.”
This whole framing of the conversation gets no one anywhere. And intuitively, we all know this. In the real world, say, with your daughter, you ask your daughter to clarify what she needs and why she needs it and then you see what you can do and make work because you want to help.
An Alternative – Principled Solution Negotiation
Instead of quibbling this way about requirements and solutions, I think a better alternative happens in two general steps:
- Frame the “requirements gathering” and “solutioning” as part of the same process, not distinct steps. Do this by…
- Treating the path to a solution as a principled negotiation, as spelled out in the classic book on negotiation: “Getting to Yes.” Principled negotiation has four parts:
- Separate the people from the problem.
- Focus on interests, not positions.
- Invent options for mutual gain.
- When necessary, focus on objective acceptance criteria
RSS Feed
