Analysis is the most important step in development of any software.

There’s no point studying design without first understanding the basics of analysis. Analysis is what allows us to make the most important initial design decisions based on more than feelings and assumptions.

In my experience, whenever I get stuck with some issue during implementation or design, it’s most likely because I just don’t understand the problem well enough to solve it.

This article is a brief introduction to the topic. It explains what analysis means for a developer. I hope by the end you will see why solid analysis is fundamental to creating quality software.

What is Analysis

Definition

Analysis is a study of a problem - the one we are trying to solve.

Or it might be a study of an existing system we are trying to change.

I use the term “analysis” for the concept other sources may call

  • Requirements Analysis
  • Problem Analysis
  • System Analysis
  • Domain Analysis

I find those names too restrictive. I use a broader definition of analysis that covers all of them.

Objectives

Analysis has the following objectives:

  • make sure the problem is understood (well enough for the current iteration)
  • discover essential rules and processes of the problem domain
  • describe function/responsibility of the new system/solution
  • describe the integration of the new system/solution into the problem domain

Analysis is best performed before any further development/design takes place. It is the first step in our problem solving approach.

Analysis can be performed at any abstraction level from the whole system down to individual modules. This depends on the scope you are working on.

Analysis as a step of problem solving process

The diagram shows some initial requirements as an input to the analysis process. Analysis produces artifacts useful for further design. We call them problem specification.

None of the input/outputs of the analysis process have to be formal.

During implementation we might run into a new problem. It could be related to the chosen design or implementation approach. And may not have anything to do with the original problem the whole system is solving. When this happens, we can deal with the new problem at the appropriate level of abstraction, using nearly the same process, as illustrated on the diagram.

Quality Benefits

OK, but why do analysis? Can’t we just read the requirements and start making up modules and classes?

Upfront analysis brings the following benefits:

  • less risk of solving the wrong problem
  • less risk of serious design mistakes
  • more information to support and drive design decisions
  • fewer functional defects

Let’s consider each one in more detail.

Less risk of solving the wrong problem

Obviously, it’s bad when unnecessary effort is spent.

Analysis makes us question the problem statement or requirements to make sure we are solving the right problem. Otherwise the future solution is useless.

Less risk of serious architecture/design mistakes

Serious design mistakes are the ones that are hard to fix once implementation has started.

Examples of such mistakes are:

  • bad decomposition (partitioning) - can happen as a result of a failure to understand inherent dependencies between different parts of the problem

  • overly complicated design - because the problem appears harder than it really is

By providing insight into the problem domain, analysis helps to reduce the possibility of such issues.

More Information to support and drive design decisions

Not only analysis reduces design risks, but it also makes the design process easier by providing additional information.

One of the main properties of a good design is that it ‘models’ the actual problem. A good design uses the terms or concepts from the problem domain and a good solution takes the ‘shape’ of the problem.

Analysis helps us achieve this.

Fewer functional defects

This one is pretty obvious. With solid analysis it becomes harder to create a bug, especially a serious one.

It’s harder to miss a requirement, or make a logical mistake after the problem has been decomposed and specified.

Isn’t Analysis just Design?

No, there’s a difference.

Design focuses on finding the best solution to a specific problem. It looks for the right balance between engineering trade-offs, like performance vs maintainability.

By contrast, analysis is the study of the problem itself. Analysis seeks to make the problem specific to make it easier to find the optimal solution.

Design outputs are much more likely to change. This is because there can be multiple solutions to one problem. Analysis outputs are as stable as the problem. So they are more worthy of being formally documented.

You Can’t Avoid Analysis

That’s one more reason you’re better off investing time in analysis from the start.

Here is what happens when you try to “save time” by skipping analysis:

  • when you do design, you must still figure out many of the same things about the problem as you would learn from analysis
  • you end up with an incomplete understanding of the problem domain, leading to functional defects
  • when there’s a bug, you must still find out how everything should work. You could have learned this from analysis or you could even prevent the bug
  • when you explain how the system works to a new person, you must repeat the same things you would have documented during analysis
  • everyone working on the project will eventually do some analysis work that has already been done by someone else. No one will benefit from re-using a shared understanding of the problem

So you can’t really skip analysis. You can try to postpone it, but the overall effort will be greater. And the quality of results may suffer.

So get into the habit of carefully analyzing every problem right from the start.

Further Reading

This was just an overview of the concept of analysis. I will cover specific tools and techniques in further posts.

See system context analysis, use case specification, data flow analysis - some of the techniques you can use.

You can also check out the analysis section of recommended reading.