%% Last Updated: - [[2021-03-30]] %% A good requirement, just like any good goal, is SMART: ### Specific Vagueness in a requirement leads to vagueness in results interpretation. __Instead of__: “The performance of the web application…” __Try__: “The average response time of the Login transaction...” ### Measurable Make sure there is a quantifiable way to know whether requirements have been achieved. __Instead of:__ “Decrease user frustration.” __Try: __ “The error rate must be below 3% at peak load.” ### Agreed Upon Have the appropriate stakeholders been involved? __Instead of:__ “The system must be able to generate emails as soon as users register.” __Try:__ “The system must be able to generate a maximum of 100 emails an hour, after which emails are queued.” A good example for this is a project I was involved in that aimed to increase the speed with which emails were generated. Unfortunately, the particular email being sent included a big change that many customers were expected to contact the support team about. The problem was that nobody had thought to include Support in the conversation. Once they heard about the expected end result, the support team quickly raised their concern that they would not be able to handle the expected volume of emails unless the emails were staggered. This could have been avoided if they had been brought into discussions from the very beginning, in the requirements gathering phase. ### Realistic Can we meet this requirement given the resources available? __Instead of:__ “All requests must be returned within 5 ms.” __Try:__ “90% of the Catalog page requests should be returned within 3 seconds.” ### Timely Especially for nonfunctional testing, consider adding a timeframe to requirements. __Instead of:__ “The digital code is sent by SMS upon successful client log in at peak load.” __Try:__ “The digital code will be sent by SMS no later than 5 minutes after successful client log in at peak load.”