All to often terms such as "fast," "responsive," and "extensible" are listed as software product requirements. Software architects often spend a lot of time helping product owners turn these desires into objective requirements. We do this by asking a lot of questions: How often? How many in what period? Increasing or decreasing at what rate?
It is a process that most product owners find maddening. Which is why it is important to explain that an exact answer is not expected. In fact, an exact answer would be a little worrying and I'd want to know how they got it. It is that process of how to get quantitative criteria that often needs to be explained and planned for. Finding ranges for quantitative requirements and checking against them is a time-consuming and expensive process. If no one wants to spend the time, effort, and money to do so then it reveals that the requirement isn't actually needed.
Focus your efforts on the parts of the system that stakeholders actually consider worth paying for.
