This paper [1] provides revealing insights as to how non-functional requirements (NFRs) are (or not) elicited, documented and validated in the software industry and how they impact architectural decisions. It also points out glaring differences in the impetus associated to NFRs based on system criticality and the cost to benefit ratio. The paper also reveals challenges the industry generally faces in dealing with NFRs and classifies them based on standards already ascertained by the engineering community (ISO/ IEC 25000). Although the study was limited to companies in Spain, it provides a broad spectrum of organizations that are analogous to the global software companies. The article has established the scope for more empirical studies to be carried out with NFRs and their impact on architectural decisions.

The current study was based on a two part survey that dealt with NFRs in the requirements engineering phase and then its influences on architecture. It essentially consisted of curated interview notes and broad discussions with industry practitioners. Although these interviews do provide revealing insights into industry practices, they may still be devoid of essential statistical evidence. The notions about NFR management in the article could be backed by evidences like bug reports and user story backlog analysis, provided that the companies agree to share their data in an anonymized setting. It would also be beneficial to classify the software projects based on their criticality in terms of safety and scale to ascertain the impetus provided to NFRs and how it was reflected in the architecture. These could also be extended to other quality parameters.

CHALLENGES:
Cost to Benefit Perception of documentation: Practitioners generally do not document NFRs efficiently as they do not see a clear benefit in doing so. This is especially true in projects that cater to non-critical systems.
Mitigation Strategy:
A less rigorous approach to documenting NFRs in the form of concise Volere templates or natural language documentation can be created as an aid to future artifacts. These are less resource intensive but extremely useful when serving activities like refactoring or compartmentalizing the code base. Also many of the quality attribute requirements can be monetized in terms of additional features if they are unique to a software product. For example, exclusive highly available infrastructure is monetized by Amazon Web Services and has a different pricing from standard deployment facilities.

Lack of Validation for NFRs
Many non- critical software projects do not validate their quality requirements and many do not have an appropriate quality metrics to ascertain the efficacy of their systems. They also forego important quality attributes like security.
Mitigation Strategy:
The authors observed that shoddy documentation practices often led to sub-par validation schemes as well. While documenting quality attributes, appropriate and clear metrics must be decided upon to ensure the system is working efficiently on all fronts. Automated tests can be part of the deployment phase to ensure regressive validation.
Terminology Issues
The researchers observed that many of the respondents used incorrect terminology or overused certain quality attributes pertaining to NFRs which might be a potential risk if the decision makers are not completely aware of the wide spectrum of issues that a product might be vulnerable to that are based on quality issues.
Mitigation Strategy:
Architects can use ISO/ IEC 25000 standard to clarify terminology and understand more about other quality attributes. Organizations must provide training for their technical leaders with standard policies regarding architectural designs or seek outside help for expertise.
New Research Article:
I believe this paper [2] provides a more precise and verifiable heuristic for software architectural decision making based on non-functional quality requirements. It provides variables for resource availability and cost and then calculates operational stages needed to achieve each soft goals based on the NFR framework. The graph allows for easy approximation of tasks and also a scheme to prioritize quality requirements. It also provides for impact assessments based on architectural tradeoffs. This can potentially help architects to rely on a more concrete simulation than just their intuition or experience.

References:
[1] Ameller, D., Ayala, C., Cabot, J., & Franch, X. (2013). Non-functional Requirements in Architectural Decision Making. IEEE Software, 30(2), 61-67. doi:10.1109/ms.2012.176 [2] Affleck, A., A. Krishna, and N.R. Achuthan, Optimal Selection of Operationalizations for NonFunctional Requirements, in 9th Asia-Pacific Conf. on Conceptual Modelling. 2013: Adelaide, Australia. p. 69-78. http://crpit.com/confpapers/CRPITV143Affleck.pdf