The Documented Rationale Behind Performance Requirements

All to often, performance requirements are stated without including the rationale behind them. Although this isn't a front line risk when it occurs, it definitely can have an impact on shared understanding of what the performance requirement really means to the overall solution evaluation.

A mobile system takes 13 seconds to load after the splash screen appears and the target requirement is less that 5 seconds. The actual measurement is almost three times longer than the specified performance requirement. That sounds pretty bad, doesn't it? How about looking at the same reality from a different viewpoint? The system takes 8 seconds longer to perform than expected. Now the very same condition sounds almost trivial and we should move on to more important things.

Why does this requirement and the associated fulfillment of this requirement matter? If the target user opens this mobile application 10 times a month, they have lost a full 80 seconds of potential productivity that month. How many of us wait more than 80 seconds each day to get a cup of coffee? So can we say this performance requirement is unnecessary and has no real impact?

After all, how many development man hours would be spent to fulfill the less than 5 seconds launch to ready to validate this performance requirement? A developer would need to analyze the potential bottlenecks, research potential fixes, implement the fixes, test and then repeat this loop until they achieve success. Then that fix can be incorporated into part of the overall release cycle. This could easily run into 20 hours of overall development time and that is time that could not be used to fulfill other requirements. If we assume that developer time is $50 in house or $100 external, the fix will cost anywhere from $1,000 to $2,000. So we are investing $250 per second to improve screen loading time, is that right?

No, because where are not taking into account our full user base and so the cost per second value proposition is much more reasonable. However, this narrative is on its fifth paragraph and I still haven't submitted any real reason why this matters. In fact, we might have even forgotten about our "why objective" because we have been so caught up with the math.

Here is a potential definitive reason why the unusually slow load time for this mobile application matters. This is because the user might think to themselves every time they have to stare at the screen for the full 13 seconds, "this mobile application is a bit of a turd." "Why does it always load so slow, when all my other mobile applications load so much quicker?” "Doesn't this company know that I have better things to do with my life that stare at their company logo while this turtle of an application loads?"

The rationale behind a quick loading mobile application is that we want the users to have the impression we are speedy. If I finish 8 seconds behind you in a marathon race, the difference hardly matters. However, you don't want your customers to be reminded 10 times a month that you are slow. If we don't document the rationale behind performance requirements, they can easily loose their power and support in the development pipeline.

So this performance requirement is not about performance, it is actually about our brand image. Every interaction with our mobile application can easily modify our users future expectations of us. We want to build a consistent track record of exceeding expectations, do we not? 

© 2017 Dwayne Wright