What is the focus of analysis: problem or solution?

This post is my shifted comment on Rafael’s post & discussion.
Rafael talks about analysis vs design in the software life-cycle, where problem is the requirement and solution the software to build.

First of all, IT or not, any answer makes sense as an answer only if it answers a question.

So, a solution is a solution to a problem. Still generally speaking, there are almost always several solutions to a problem. And the problem itself, as a question, is almost always a viewpoint on a problem area, or even I’d dare to say: the problem, taken as a problem for which we need to find a solution, is an abstraction of a problem domain.

But even if we details the problem at very fine-grained level the solution is not the problem, it’s a different thing. The solution is something concrete. A software as a solution is something executable (even if it’s bugged).

So: the problem is substantially an abstraction, while the solution is substantially concrete. However, the solution highly depends on the problem, by construction. So we need to weave(2) something concrete to something abstract.

Analysis often means focusing on the problem, while design means focusing on the solution. But how do we focus on the weaving(2) from an abstract problem to a concrete solution?

To my opinion, what is interesting to model in IT life-cycle is this weaving problem<>solution. The corresponding task is by nature an “analysis & design” work. In the “MDA like”(1) successful cases I know, this work is held by a ~PIM(3) model which takes into account business analysis and technical architectural design (which both need to adapt themselves to each other).

I don’t believe that “analysis & design” may generally be treated as a pure transformation from the problem to a solution, even with successive refinements. And my feeling is that when we find some occurrence of such an automated transformation the problem is, in those cases, sort of a “reverted solution” problem: a problem not issued from real life but issued from existing or projected IT life.

By the way, executable models are, by definition, models of a solution.

So, my answer is:
– We need a problem/solution weaving(2) which may not be derived from an analysis model, nor from a design model. Executable models or not. OO approach or not.
– Keeping analysis and design separate is a very well mean not to succeed in IT projects!

(1) Thanks to Ed Seidewitz for pointing out the original “MDA Guide Version 1.0.1” whose 80 printed pages are ready to be read during my next TGV travel to Nantes ;D
(2) I replaced “mapping” by “weaving” after TY comment. See my response to TY.
(3) I read the MDA Guide. More to come!

Featured image taken from http://f3fundit.com/blog/its-all-about-the-v-word-so-forget-the-problem-ideology-and-create-value-instead/