ArticleS. UncleBob.
AnalysisVsDesign [add child]

Analysis Vs. Design

What is analysis? Is there an accepted definition? If you read through the software literature and textbooks, you will find that there are as many definitions of analysis, as there are authors. Ironically, analysis is something we know we must do; and yet have no real definition for.

One of the most common ways to differentiate analysis from design is to say that analysis is "what" and design is "how". This sounds compelling at first. Clearly if we can first define "what" we want the system to do, then it will be easier to define "how" the system should do it. Indeed, vast quantities of man-hours have been spent attempting to separate the "what" from the "how". It is not uncommon for a conference room full of people to descend into the interminable argument over whether what we are currently doing is analysis or design.

Arguments like this are common because of the peculiar fact that every "what" is also a "how", and every "how" is also a "what". The arguments cannot be decided, because both sides are actually correct. If we use the "what" vs. "how" definition of analysis and design, then every concept that is an analysis concept is also a design concept and vice versa.

To demonstrate that every "what" is a "how" and vice versa, consider what I am currently doing.

What am I doing? I am writing a blog.
How am I doing it? I am typing on my laptop.

What am I doing? I am typing on my laptop.
How am I doing it? I am moving my fingers to hit keys that correspond to letters that are assembled into words.

What am I doing? I am moving my fingers to hit keys that correspond to letters that are assembled into words.
How am I doing it? The cognitive portions of my brain are putting words together and directing the motor portions of my brain to send signals to the muscles that control my fingers.

I could go on indefinitely. The fact that I could go on indefinitely means that "what" and "how" are associated by an equivalence relationship that leads to a recursive descent into detail. Every "how" become the "what" at the next level of recursion. Every "what" is just the "how" of the level above it. The number of levels is very large, and probably infinite. This means that "what" and "how" are separated by an infinitesimal and are virtually identical.

So, for all practical purposes, if we view analysis as "what" and design as "how" then they are equivalent operations that cannot be separated from each other. All analysis is design, and all design is analysis.
 Wed, 19 Oct 2005 13:18:02, Marco Dorantes, Recursive - inductive definition
Certainly. Also, analysis could not be really completed without design and vice versa
 Wed, 19 Oct 2005 13:46:34, George Petrov, Every what is a how, but on a different level
It seems to me (from your example,) that the What only becomes a How once you zoom one level deeper, i.e. increase/decrease the scale of your vision.

The key, therefore, seems to be in establishing the right scale first. Only then can ew effectively tell the means from the ends. The problems only arise when we try to deal with different zoom levels at once.

From my experience, half of this can be achieved just by calling the things by their real name.
 Wed, 19 Oct 2005 14:28:36, Michele Arpaia, What and How belong to Design
I used to adopt the same simple what/how method to define analysis/design and I ended up to the same conclusion.
In my opinion It would be easier to define analysis as domain exploration (i.e. domain analysis). Here there is no system and so it's meangless to define what to do.
Design, on the other hand, involves WHAT the system must do (Requirements)and HOW the system should do it (Specification)
It is a design phase because when system definition comes into play you are designing not analyzing.
Of course, that's just from my experience.
 Wed, 19 Oct 2005 17:50:59, Bill Caputo, Analysis has a definition...
...but my answer got too big for a comment, so I pulled it out to my own blog:
 Thu, 20 Oct 2005 16:08:53, Vishal Shah, At least they have an order before they become interchangeable
At least they have an order before they become interchangeable, which gives us some guidance. For example, I cannot:

First ask - How am I doing it? I am moving my fingers to hit keys that correspond to letters that are assembled into words.
Then - What am I doing? I am typing on my laptop.

 Sat, 22 Oct 2005 12:45:13, BM, What.. how... What ... how... (When does it stop)
Analysis is not necessarily the process of defining the what and not the how. Analysis is the process of identifying the what and the how as well as identifying when to stop. The idea of equivalence of analysis(what) and design (how) is based on the premise of indefinite what's and how's. Analysis is the abstract definition of process and therefore both the what and how. Design is the physical manifestation of the abstract definition obtained by analysis and thereby depends on the what and the how. Based on my previous 2 statements I would argue that design start where analysis stops.

From your example above every what can be rephrased with a equivalent how . A rephrasing of you how's follows

What am I doing? I am writing a response.
What am I doing to write a response. I am typing on my keyboard
What am I doing to type on my keyboard? I am moving my fingers to correspond to letters that are assembled as word

My point being, the definition of analysis (based on what) and design (based on how) are not necessarily incorrect, just ambiguous
 Sun, 23 Oct 2005 09:14:41, Sebastian K├╝beck, Who is doing what and how..
I think what is missing here is the actor, the one who is doing something.
In your case, the "how" is the way things are already done so your "hows" belong to analysis.
Design means doing things in a different way than they are actually done.
Anyway, it's a good practice to start designing throughout analysis to get feedback
from design to analysis. This way, the model constructed during analysis can prove its
value for design early so waste can be reduced to a minimum.
 Fri, 28 Oct 2005 09:44:06, Siva, Analysis vs. Design
'What am I doing? I am typing on my laptop' -- Does not really capture the requirement.

Requirement (what) could be that I need to write a blog.

 Wed, 7 Dec 2005 03:03:27, niesa, Object oriented design
1)what are the qualities and objectives of design?
2)how can we plan for the design process?
3)how can we measure objective within the design process?

can you give the answer for this question? tq
 Fri, 9 Dec 2005 17:36:12, Uncle Bob, Niesa's Questions:
1)what are the qualities and objectives of design?
The objectives of good design are to imbue a software system with a shape, structure, and subtance that is flexible, maintainable, and reusable. A design should be intuitive and simple. The reader of the software should clearly see the intent of the developers. The pieces should fit together obviously. A maintainer should intuitively know where to look for certain features and behaviors; and the design should lead him how to make the appropriate changes.

2)how can we plan for the design process?
Design is not a process that is separate from programming. We do not plan for it in the sense that we plan for a pregnancy, or for retirement, or for building a house. Instead, good design is more like the struggles of an artist trying to perfect a great painting, or a craftsman trying to build a wonderful divan. Design is about care, time, patience, and determination. A better question to ask is: "How to we learn to be good designers?" The answer is to learn, learn, learn. To read great quantities of code, both good and bad. To understand the systems that others have built. And to build your own systems over and over again. If you want to become a great designer, you need to work with other great designers.

3)how can we measure objective within the design process?
Again, design is not a process that is separate from development. However, there are definitely things that can be measured. You can measure defect discovery rate. You can measure test creation and test completion rates. You can measure velocity. You can measure various attributes of coupling, cohesion, and abstractions. (see
 Tue, 23 May 2006 07:17:19, ,
Straight to the point. Pragmatic argument
 Mon, 29 May 2006 18:07:19, Emil Koutanov, Quite trivial, really...

I agree in general that analysis pertains to the problem, while design pertains to the solution. But as we've already seen in the original blog, the two bounderies between the two are ill-defined. A solution to one is a problem for the other. Even in the case of good classical programming. A specification (problem) is mapped to source code that, once compiled, provides one potential solution. This is now a new problem. How does the source code execute? More specifically, how does the code map into discrete instructions and how should the processor fetch and execute instructions, and pipeline these for efficiency.

But there two fundamental problems to this path of thinking.
1) The second order problem is too detailed, and operates within a deeper scope than the original problem.
2) The second order problem has already been solved! Optimising compilers and highly pipelined CPU architectures do a wonderful job of mapping higher-level source into binaries and subsequently executing these.

To cut to the chase, the problem A vs D problem is actually trivial, but because of its iterative nature, is one that is readily exposed to unnecessary complication. To avoid falling into the pitfall, one must define an upper bound on the scope of the problem that they are trying to solve. It should stop precisely at the order where a solution yet again morphs into a problem, but for which a solution already exists. For example, you're asked to build a system to solve a particular problem. Right from the early stages you realise that you can effectively combine some middleware, a relational DBMS, and some other technology, held together with a little glue J2SE code to solve the problem. Apart from elaborating on the glue, you should refrain yourself from delving any deeper into the high-level building blocks, for these have already been solved.

|Going back to the original blog, the author mentions the original problem, being the formulation of a blog. The other two orders are irrelevant, for their occur intuitively and need neither analysis nor design. I've talked before about the "upper bound" as opposed to the entire scope, because the analysis/design process could be evolutionary, taking place in increments. It doesn't matter how much is performed in each increment, as long as the upper bound is respected.

So keep design to the problem that YOU are trying to solve. All too often system architects and even requirements engineers go one (or two) levels deeper than what they have been commissioned to do. An architect should never have to draw a class diagram - even though this problem is yet to be solved by implementers, this is beyond the scope of architecture. The analysis is then all the understanding of the problem leading up to the design of the solution. Oh and by the way, the design process is not separated from programming. The derivation of source code, aka implementation, is littered with elements of design. In large systems, often one might find themselves implementing from a class diagram, but the latter does not specify intrinsic details of the source code, merely relations, attributes and method signatures. The implementor still has to design the internals of each method, branching, loop structure, e.g. whether to iterate or recurse.

[Emil Koutanov]