...we in the Software world just don't use it -- or more precisely have gleefully ignored it and create our own definitions as suit our agendas. This is perfectly natural, but that doesn't mean we have to play along.
(Uncle Bob Martin takes a (possibly aporic) position that the problem with the common industry practice of defining Analysis as "what" and Design as "how" to build, is that 'what' and 'how' are really the same thing (thus implying that Analysis and Design are the same thing). Here explain why I disagree.)
In Philosophy, Science, and Just Common Parlance, Analysis is the opposite of Synthesis (bringing things together) i.e. Analysis means to take apart, to break into bits, to see what makes things tick (presumably to understand). Gaining insight (sight inside something!) is the spirit of Analysis. A quick dictionary check says analysis is from a Greek root meaning to dissolve. The infinite regress Bob describes above (where a 'what' can be recast as a lower-level 'how') is all analytical. I.e. the problem with the what/how distiction isn't that analysis and design are the same, its that they are opposites. Design (especially design-as-indistinct-from-coding) is synthesis -- which can also be described in either 'what' or 'how' terms (e.g. what the final implementation will look like, how we will implement the actual solution, and so forth).
In fact, software development can be described entirely in these terms: Envision an idea, analyze it in order to envision a solution, use the insight gained to synthesize the idea into code (lather, rinse repeat as necessary to achieve the desired results). You can also substitute just about any act of creation for 'software development' in that definition.
Programmers of course can perform both of these activities -- and do perform them all the time (regardless of what that full-time analyst 'gathering requirements' wants the rest of us to believe), but Analysis in our industry -- particularly when contrasted with 'Development' -- has become a strange echo of its wider meaning denoting that part of the software development process where someone (all too often a semi- or non- technical person distinct from those labelled 'Developers') performs some sort of analytical exercise in order to systemize, rationalize, or otherwise prepare the wishes of the user so that programming (synthesis of) their desired software can occur (again presumably, but not necessarily better than without the Analyst's involvement).
Of course, I do agree with Bob that trying to formally characterize Analsysis as 'what' and Design as 'how' is an act in futility (although informally I often find the distinction tactically useful). I also agree with the implication made that this is a foolish way to separate the responsibilties of the Analyst from the Programmer, or to otherwise design one's process around the fallacy of believing that programmers only synthesize (hint: think 'Activities' not 'Roles' when trying to figure out how to staff a team).
But deeper than this is the "language on holiday" effect that these discussions (and the related turf wars) have on our respective sense of frustration about what it means to build software. I hold that there exists no "True" definition of Analysis, or Design, or Development (or Testing to touch on yesterday's post) -- beyond the definition of how these terms are used -- and further -- such usage is neither univeral, or universalable. Continuing to pick on Analysis (maybe I'll pick on Design tomorrow) I've seen it used to describe control of the development process, attempts to create bottlenecks of opportunity for one's importance, schems to manage risk via predictable levels of inefficiency, and (in the best cases) to reach common understanding of what is really desired (and not desired) by the customer.
Are we doomed to choosing sides in this game of Programming Pendantry?
No, we have a choice. We don't have to play along. We can disavow the need for more definitions of terms, we can abstain from fighting for (or against) universal acceptance of The One True Vocabulary, and understand that language is not a substitute for communication.
IMO, what our industry needs are Wittgenstinian philosophical therapists that can "show the fly out of the fly bottle" -- wean the rest of us from our futile habit of trying to distill Truth from the myriad definitions and specfications variously upheld to Define What Things Are. The trap is to believe that true, useful, universal definitions of Software Terms exist, could exist or would help us if they did exist. The way out is to bring the desire of what is to be into close communication with the ability of being, and to recognize our jargon for what it is: meaning as use and not a burgeoning taxonomy.
In short, Synthesis follows Analysis, both are (necessary) overhead to the process of taking an idea and realizing it in code and should be treated accordingly. Everything else is just noise (or music).