You have probably heard of non-functional requirements. One of the most used phrases by architects. Rather ridiculous if you consider it means ‘broken’ in English. The term is already being transformed into “quality requirements” by many.

Example of a quality requirement: response time of a specific request in our system. Or more ambiguous: suitability or maturity. The last two are part of ISO/IEC 9126 standard full of other nice sounding academic words. ISO/IEC 9126 with all the ilities was for me never really useful in practice because it replaces common sense, which proved to be much better without the standard. The common sense of defining our ilities should always be driven by explicitly stated requirements from users and stakeholders.

Question: “In how much time does user wants to complete his registration?”
Answer: “About one minute… In that case, number of clicks should be very low and response times very fast.”

My point is: I don’t need some standard to figure this out. What I do always need is a way to identify them based on real needs from users and business, sometimes quantify them, but mainly a way to measure them. The answer came partially from Planguage created by Tom Gilb. Although I must admit I use it in a rather simplified manner. A quality requirement which I wish to precisely identify and follow is placed in the following table:

Nice thing about Scrum is that when you deliver software after each sprint, users and business can tell you how satisfied they are and if quality in identified areas has improved. Even better is the fact that for most of the quality requirements you don’t need to define them before sprint starts, but simply make a best guess, measure qualities afterwards and improve them in the next sprints.

For me the most important part of quality requirements management is the “current” value part. Is it high or low enough? No? Let’s improve it!

Question: “How easy to use should this page be?”
Answer: “We have no idea, because we don’t know how often user will use it and it is too much hassle to find that out. User sometimes think she will use it often, but eventually she doesn’t. It is costly to make it very user friendly. Let’s choose the basic / cheaper version and hear from first users what they think about it. If they are not happy, we’ll adjust it accordingly in the following sprint”.

Another nice thing about Scrum is disappeared need for heavy requirements management because of so many feedback loops. For most of them, we simply don’t need to think about quality requirements much. As soon as you deliver software after each sprint, requirement (e.g. system stability) is going to hit you back (e.g. system down time) and team must improve it. On other hand, this should not prevent a team from making sure that obvious requirements are in place before end of a sprint as part of Definition of Done. E.g. “after this sprint we’ll have aprox. 1000 users and 100.000 requests per day. Can our system handle this load?