Where do Software Defects Originate?
Defects in software are inevitable. A common misperception is that the defects are caused only by faulty code, this is NOT so. In fact, more defects are caused by poor requirements, poor architecture or poor design (collectively) than poor code.
Usually the concept of a defect or bug is thought as “non-conformance to requirements” and yet if the requirements are wrong, could we still have a bug? Yes! A bug or defect is a failure to meet the desired outcome. If the desired outcome is poorly described (ie poor requirements) then we still have a bug, even if the code does exactly what the specific requirement describes.
We need to think more holistically about quality and how to satisfy the objectives or outcomes.
So, what are the root causes of software bugs, and why should we care?
By looking into the root causes of software bugs, where and when the bugs appear first, we can establish better ways to avoid them in the future. Our goal is to find and fix the problems as early as possible, so that they are not experienced by users.
It is interesting to note from the graph above that more defects come from pre-coding work, than coding itself. That is, the sum of the defects from requirements, architecture and design is greater than the coding defects. Given that the code is built on the foundation of the previous three, we will end up coding the wrong thing or in the wrong way unless we fix those pre-coding defects first.
Defect Potential
Defect potential is the likely number of defects generated and latent within each artefact. For example, if we spend a day writing requirements, it is inevitable that we will make a few mistakes. We can then say that there is a defect potential based on the size of the requirements. Using a universal metric for size (the function point) allows us to compare defect potentials across different artefacts.
If you have an understanding of the defect potential, you can then take the next step and consider the steps required to detect those defects, remove them and then verify that they have been removed.
Defect Origins
| Defect Origin (Defects per Function Point) | Best | Average | Worst |
|---|---|---|---|
| Requirements | 0.34 | 0.70 (16.5%) | 1.35 |
| Architecture and Design | 0.67 | 1.05 (25%) | 1.78 |
| Code | 0.44 | 1.15 (27%) | 2.63 |
| Security flaws | 0.18 | 0.25 (6%) | 0.4 |
| Documents | 0.20 | 0.45 (10.5%) | 0.54 |
| Bad fixes | 0.39 | 0.65 (15%) | 1.26 |
| Total | 2.22 | 4.25 | 7.96 |
Measured in defects per function point for a 1000 FP system. Source: p. 256. Capers Jones, Quantifying Software, 2018 CRC Press.
We should start with the premise that a team developing software will not do perfect work, but can do excellent work. On average, however, they will do average work. And with any knowledge work, mistakes will creep in. It is very useful to consider the idea of defect potential. Defect potential is the idea that a given piece of software is likely to have a probably number of defects unless and until those defects are removed. Defect potentials vary by size. That means that a large application has a greater tendency to be buggy than a small one.
Achieve Better Quality
The single most time consuming aspect of software development is finding and fixing bugs.
On agile projects we can see as much as 40% of overall effort is rework that is mostly caused by poor quality on the pre-coding work. Most of this wasted effort is avoidable by paying more attention to quality right from the beginning – before coding starts. Anything that can be done to avoid bugs should be taken seriously. Defect avoidance and defect prevention requires proactivity.
To fully understand how we can speed up the journey to great quality, we need consider on all of the following:
- Defect Potentials
- Defect Discovery
- Defect Avoidance
- Defect Removal
These need to be considered in the context of, at least, requirements, design, code and tests. In other words, starting with requirements:
- what is the requirements defect potential?
- how will we discover the requirements defects?
- how can we avoid the requirements defects?
- and how can we remove the requirements defects?
Repeat the same questions for design, code and tests. Learn how ScopeMaster can find the potential requirements defects so that you can fix them easily.
ScopeMaster will help you prevent bugs, by making sure your requirements are high quality.
Up to 35% Production Bugs are from Poor Requirements
In January 2021 Accenture acknowledged at the Software Intelligence Forum that as many as 35% of production defects are caused by requirements problems, according to their data based on 1000 projects. What this means is that on most projects, requirements quality assurance work is failing. Further more requirements problems are amongst the most expensive to fix once coding has begun. Finding ways to fix requirements problems is achievable through a combination of education, time, attention to quality and automation. This is where ScopeMaster can help, ScopeMaster can reliably find 50% of requirements problems, and help you fix them quickly too. Overall, using ScopeMaster helps you find and fix problems ten times faster than attempting to do the same manually.
To detect potential requirements defects, we must examine requirements in great detail. Fortunately the heavy-lifting is now done for us by ScopeMaster, the world first and most advanced software requirements analysis tool.
High Requirements Quality is a key to Minimising Software Defects
ScopeMaster assesses your requirements quality.
