I have come to the start of the second week of the major HR system upgrade engagement. While working with the customer we identified conflicting performance requirements. We are now working on decoding the response time requirement.

The documented non-functional requirement for response time is:

“The application response times will be equal or better than the existing application”

After doing some investigative work, we identified the last performance test was conducted around 5 years ago when the system supported 3,000 named users. Since then the hardware has been upgraded 3 times and the user base has increased to 30,000 named users or by a factor of 10.

The customer rightfully then asked: “How fast is fast enough?”

When I am thrown curveball of non-functional like the system response times must:

• Be a reasonable amount of time
• Meet or exceed an existing application
• Unreasonably quick (for example 0.5 seconds for loading of a web page)

In this situation – I typically take the customer on a guided journey towards (this is very loosely based on Jakob Nielsen’s work on Usability Engineering) setting the response time to the following:

• 0.1 seconds for Instantaneous response – a response where the user is partway through a process and requires a system response to complete the process. An example is tabbing (moving) between fields on a form.
• 1 second for AJAX calls – a call to fill a list or self-populating suggestions.  An example is loading a list of stats after selecting a country or city suggesting while entering a billing address
• 3 seconds for general response – a response where a user has completed a task and requires a response to start a new task. An example is a loading a new page or viewing a product on a web store.
• 8 seconds for complex activities – response were a user is submitting something and expects to wait for a response. An example is processing a payment for an online order, searching for the best price on multiple sites or generating a report.

Note: these response times are a very general guide and should be set on a case by case basis. There are many factors that impact setting response times on a project and include:

• Do you have a captive audience – the response times can generally longer for a system where the users cannot go to another site (like the HR system upgrade)
• Response times of your competitors – For your customers to notice the difference your response times should be 20% quicker than your competition
• What information are you presenting – An application with time volatile information, for example, a gambling or stock market application users demand very fast response times. Whereas application presenting nontime volatile information, for example, viewers of this blog will accept slower response time
• The response times of existing downstream systems, for example, an internet banking system cannot provide an account balance faster than the request to the back-end system
• The cost of improving the response time