Problem Analysis is the most important step in development of any software. It is what allows us to make the most impactful initial design decisions based on more than feelings and assumptions.
In my experience, whenever I get stuck on implementation or design of a program, it’s always because I started without understand the problem well enough to actually solve it properly.
In this post I hope to show that solid analysis is fundamental to creating quality software.
What is Analysis
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. Different sources may also call this concept “Requirements Analysis”, “System Analysis” or something similar.
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.
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.
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?
I think 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.
In contrast, analysis is the study of the problem itself. Analysis seeks to make the problem as specific as possible. This will help in finding 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.
This was just an overview of the concept of analysis. I will cover specific tools and techniques in further posts.
You can also check out the analysis section of recommended reading.
Feel free to leave your questions, comments or suggestions below. I will get back. Subscribe for more.