Julian V S.'s Blog

In my Twitter feed this morning was a post from Kevin (@bainsight): "Reading: Problem to Solution - The Continuum Between Requirements and Design http://bit.ly/c69aSz #baot". I clicked through to the Clear Conceptual Thinking blog, where Rolf Goetz (@rolfgoetz) said,

"Christopher Brandt, relatively new blogger from Vancouver, Canada, has an awesome piece about the difference between problem and solution. If he blogs more about problem solving, and in this outstanding quality, he definitely is someone to follow."

Rolf provided a nice summary of Christopher's post:

"Requirements written that imply a problem end up biasing the form of the solution, which in turn kills creativity and innovation by forcing the solution in a particular direction. Once this happens, other possibilities (which may have been better) cannot be investigated. [...] This mistake can be avoided by identifying the root problem (or problems) before considering the nature or requirements of the solution. Each root problem or core need can often be expressed in a single statement. [...] The reason for having a simple unbiased statement of the problem is to allow the design team to find path to the best solution. [...] Creative and innovative solutions can be created through any software development process as long as the underlying mechanics of how to go from problem to solution are understood."

In your RUP example "[Customer] Browses Auctions" (I'm assuming the customer is the actor) you're at the Stakeholder Requirements level. You have already determined that a Business Requirement is something like "Run Auctions: Sell products by auction, to anyone, anywhere, taking a percentage fee per sale." In keeping with your Continuum philosophy, a design option was chosen to meet this need -- like "eBay: Internet-based real-time public auction site." (Names chosen for convenience and humour only.) Although telephony based auctions and in person auctions were decided against, they would meet the objective of the business requirement. At this level of detail, the need and solution pair are half of a business case (with investment and risk being the other pillars). The Stakeholder Requirements you define are based on both the higher level need and the higher level solution.

This implies that there is another, even tighter relationship between needs and solutions: not only do they come in pairs, like inputs and outputs, they are _exactly the same thing from different perspectives_. A solution from one perspective is described as a need from another perspective. In the RUP example above, the top-level need 'Run Auctions' is solved by 'eBay'. From one level down in the organization, 'eBay' isn't a solution; it's a problem to be solved -- a requirement. From this perspective, the higher level need 'Run Auctions' is the motivation for 'eBay' -- the answer to 'Why?' The solution to 'eBay' could be many things, as you noted. Each of these 'solutions' will be perceived as 'requirements' by the people who have to address them.

At my last job as BA SME and Manager of the BA Centre of Competency, we got tired of the "It's a requirement!" "It's a design!"infighting, and dictated a perspective: the Project View trumps them all. This means everything that leads into a project is considered a requirement, and everything that answers the requirements and is directly traced to the solution is a design. This meant that implementation teams worked from design documents, even though they were using them as requirements for their work. The simplified terminology is wrong, of course, but wrong in a useful way.

Thanks again for the great post, Christopher. If you have comments, please go to his blog (http://j.mp/4RUxr0) to continue the conversation.