Slow response 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 tests, quality assurance specialists verify and validate the requirements. However, after the rollout, serious performance issues occur. 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.
The Problem 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 tests, quality assurance specialists verify and validate the requirements. However, after the rollout, serious performance issues occur.
The Solution 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 consist 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.
Comments