When I first started at ArgonDigital, I heard a lot about how requirements are the “foundation” of software development and design. That sounds great and the analogy does hold well in some cases. However, coming from a structural engineering background in school, I’ve begun to ask why we don’t treat requirements estimation and design in software development more like foundation design is treated in structures.
Let me back up and explain what I mean here. In structural design (and really almost any engineering design), there is always a factor of safety to the design. In civil and structural engineering, these factors of safety are higher because of the human life component (if your iPhone breaks, you’re upset, but if a bridge collapses, people could die). So if you estimate that a bridge would see “X” amount of live or static load in a given day, you multiply that by a factor of safety (usually 1.2 for static loads and 1.6 for live loads). You also divide your design by a factor of safety because of construction and material uncertainty (usually 0.9 for the design of the building).
These factors of safety are very different for foundation design, and for one very simple reason: uncertainty. Designing a foundation requires that the engineer know how much weight and force the soil beneath a structure can withstand. However, knowing how much force the soil can take is very difficult to determine. You can take a soil sample and test it, of course, but merely taking the sample changes the properties of the soil and there’s the fact that just because your soil sample has a certain composition, that does not mean the rest of the soil under the building will. You might have a sand patch somewhere under your foundation or a boulder. Because of this uncertainty, when an engineer estimates how much force a foundation needs to hold, he uses a factor of safety of 3-5 (much larger than those used for the structural design). So nominally, a foundation could hold 3-5 times more than the weight of the building on top of it, not because the weight of the building is unknown but because the strength of the underlying soil is.
I feel that this principle can be applied to requirements estimation and design as well. When a project is started and the requirements work needs to be estimated, we should use higher factors of safety than we might for the development, testing or even planning phases because of the uncertainty in what the business objectives are, what features need to be included, etc. This way, when a whole branch of functionality is discovered, there is room in the estimation to determine if it really should be part of scope or excluded.
Now, this analogy to foundations is still not 100% accurate, because unlike in foundation design, the development, planning, testing and all other estimations are, at least in part, based on the requirements estimation and design. And in structural engineering, that is the other way around; the foundation design depends on the building, not the building on the foundation. But if we apply some of the engineering principles to the requirements design and estimation, we might be able to give ourselves, as business analysts, more room to understand the full scope and size of a given project if we have a greater factor of safety taken into account in our estimates.
Stay tuned for my next blog post about using “front-end engineering design” to inform our requirements estimates and design!
