Together with X. Franch, D. Ameller and C. Ayala (all members of the GESSI group), I’ve been recently interested in exploring to what extend the huge amount of elicitation, documentation, validation, … techniques for non-functional requirements (NFRs) were useful and used in practice.

The full results of our empirical study can be read here but you can read here some of the findings plus the discussion they triggered with Frank Buschmann regarding how generalizable they were across all areas of Software Engineering in the latest issue of the IEEE software journal :

Architecture Quality Revisited. Buschmann, Frank; Ameller, David; Ayala, Claudia P.; Cabot, Jordi; Franch, Xavier. IEEE Software, vol. 29 (4)

Some highlights:

• Nontechnical constraints (like cost, type of license, specific providers) are as prominent as technical quality requirements like performance or security (see figure below)
• The software architect and not the client is usually the one defining the NFRs of the project
• NFRs are hardly ever documented and poorly validated

and some reflections about the why’s:

• A prime indicator for how NFRs are handled is their business value. CThe more important a non-functional quality is, the more care customers take in defining those requirements.
• Architects must find a balance between non-functional qualities and the cost to guarantee them
• Modern technology platforms already cover many applications’ quality requirements.

And a final punchline:  NFRs are important – except when they aren’t

(figure shows the number of interviewees that mention each type of NFR as relevant)