Powerful non-functional requirements definitely have a fundamental part to play in providing high-performing IT services.
Sad, but true to say though, too many decision makers neglect this crucial aspect of performance requirements, and focus entirely on functional needs alone. These decision makers only realize this oversight when the new business applications fail to fulfill their customers’ expectations after deployment to production.
In this post, I’ll shine a light on how we at Performetriks craft strong performance requirements. Read on and learn why we prioritize these requirements, and how you can adopt this essential element in your project.
Result of weak performance requirements
Disappointed customers: We’re often so tied up in our features that we forget to consider the functionality of the end products we present to our customers. The best features are worth nothing if they don’t match the consumer’s performance expectations. An outstanding feature that is slow will never make your customer happy—it will only make them feel frustrated.
Wasting your test budget: From the standpoint of economics, it’s better to skip the entire performance test than spend man-days implementing tests that are based on vague requirements. Let’s imagine that according to your Non-Functional Requirements (NFRs), a system will be used by 300 concurrent users, and there are 300,000 transactions every hour. This massive volume of transactions requires services designed for high-performance. If, on the other hand, your application processes a much smaller volume of transactions, the big expense of tuning for high speed will be a waste of money.
Frustrated customers: Research shows that customers are more likely to return after experiencing an outage than after performance slowdowns. Slow-loading applications simply destroy your reputation as a trustworthy provider. Whether you’re developing systems for your employees or for external customers, they’ll simply abandon your services regardless if performance falls below their expectations.
Massive firefighting: The total neglect of performance during the entire software-development phase is a common scenario. Then, suddenly—just a few hours after the deployment of your brand-new system on production—you’re faced with severe issues. The operations team falls back to default: “Let’s restart the procedure and all the services!” They spend a couple of hours trying to pinpoint the problems using trial and error. The business escalates the matter to IT management, and the hunt is on for the engineer responsible. Such situations are almost a daily occurrence in many organizations. Due to the neglected NFRs, their problem had actually been there from Day One. It was just that no one had noticed. The trouble is; it takes several times longer to fix the issue in the firefighting mode than if it had been addressed at the beginning.
The best way to avoid these nightmares is to create meaningful and correct performance requirements at the outset. If you’ve ever worked as a business analyst, you’ll probably know that there’s little information available on how the new software can provide the high level of performance you require—you need to deliver your intended services in a manner that fully satisfies the users. It is here that the holy grail of performance requirements begins.
In the next blog post, we’ll show you a structured approach for the creation and validation of performance requirements that will really please your users!
Keep up the excellent work! Happy performance engineering!