Why the quality of requirements cannot fully be controlled at design time?

Voiced by Amazon Polly

Quality of a service (such as, e.g., a flight) correlates negatively with the gap between what you expect from the service and what you experience through that service [1]. The greater the gap, the lower the quality. You expected more than you got. The smaller the gap, the closer the experience to expectations, and the greater the quality. Saying that you got more and better than expected is to say that the gap was negative – you expected less than you experienced.

This translates to the quality of software. If you think of software as being something that delivers services, or to make it simple here, one service, then software quality correlates with the gap between what you expected that service to be, and what you experienced when software delivered the service. Your perception of quality of a flight booking software, correlates negatively with the gap between what you expected it to do for you, and what it ended up doing. As above, it could be low quality (some positive gap) or high quality (some negative gap), or somewhere in-between (gap close to zero, from either side).

How does this translate to the quality of requirements? The service requirements should do for you, is that they should guide the engineering of the system-to-be in some specific way you are interested in. You give a requirement in order to have, eventually, the system do something you expect. So if it does not, then requirements, however good they may have seemed at the time, ended up giving you the experience which is different from the expectations you had. It follows that the quality of requirements is only partly determined by such properties as their precision, clarity, absence of vagueness, ambiguity, how they have been specified, validated, and so on – namely, by the many things which could be controlled when requirements are being elicited, analyzed, specified, verified, and validated. In other words, you cannot fully control the quality of requirements at design-time.

Simply put, it is because the evaluation of quality of the system-to-be will happen at run-time, that there is always going to be uncertainty about the quality of its design-time requirements.

References

  1. Parasuraman, Anantharanthan, Valarie A. Zeithaml, and Leonard L. Berry. “A conceptual model of service quality and its implications for future research.” Journal of marketing 49.4 (1985): 41-50.APA