Problem to Solution Responses

I've finally had an opportunity to read Julian's response to my article, Problem to Solution.... Because I can't respond on his site, I'll respond here with a promise to expand these thoughts into another article.

First, I generally agree with Julian's thoughts as I understand them.

Julian makes the point that "needs" and "solutions" are tightly coupled pairs that cannot live alone. I think what he is saying is that a real life problem statement always implies some level of solution. If it didn't we'd start every project from a point charge in a vacuum (a phrase I've stolen from my colleague). While this is generally true, I think it's a different vein of argument. What I'm trying to show is that we want to get to the most abstract statement of the problem that meets the business vision. This focuses us on the problem independent of all solutions.

I really bristle when I read terms like "business requirement" and "stakeholder requirement". I used to live by RUP so I understand what they are attempting to capture. My problem is the mindset they put the reader in. I'll post more on this later, but generally a "requirement" is something that "must" happen which implies that someone has already thought about how to do it (the solution), it just has to happen now. My preference is to keep people thinking about the possibilities as long as possible which is a different mindset. To get into this mindset we think about the problem we have, rather than a set of requirements.

Julian does tie the terminology to the perspective, which is something I also eluded to but have yet to fully articulate. One person's "requirement" is another person's "design". I agree with this notion, but I would state it differently. I would say that a solution at one level is a problem at the next level. So we know we want a website for auctions (a solution) what's the nature of that website (new problem). I'm still clarifying this stuff in my head, so the discussion is useful.