Slow responding applications can be a nightmare
Imagine that your customer sits next to you while you try to open his new account. You press the “Create Customer” button and expect that seconds later their account has been created. Surprisingly, after 60 seconds there is still no confirmation available, and your Create Customer process seems not to respond. That is a very embarrassing situation because you will lose the confidence of your new client and in the worst case, you will start the whole process once again including the insertion of the customer’s details.
It’s a common practice that the functionality is precisely specified. Requirement specialists outline use cases from a functional perspective. Developer’s implement expected features, and during system or user acceptance test, quality assurance specialists verify and validate the requirements. However, after rollout, serious performance issues occur.
Nobody would build a house without a detailed plan that outlines both, the visual representation and the architectural characteristics. The same practice should be applied when it comes to software. You should start with the specification of functional and also non-functional requirements. Architects should incorporate both in their decisions, and testers should validate the former and the latter.
But, vaguely formulated performance requirements are not useful at all. Based on my experience, meaningful performance requirements consists of:
• Expected number of concurrent users
• Expected number of use cases per interval
• 90th percentile response times for user interactions
• 90th percentile response times for backend service calls
• Maximum error rate per interval
• Acceptable response times on WAN locations
However, forward thinking companies have performance considerations already integrated into their development chain. Keep doing the good work and consider non-functional requirements in your development process.