Question

功能性概览部分总结了功能，也值得包含一个单独的总结质量属性/非功能需求的部分。

意图

这部分总结了主要的质量属性，应该回答下面几类问题。

对于架构必须满足的质量属性是否有清晰的认识？

质量属性是否满足SMART原则1（具体、可衡量、可达成、相关、及时）？

如果通常理所当然的质量属性并无必要，是否会明确标示为超出范围（比如，“用户界面元素只用英语呈现”就表明并没有明确考虑多语言支持）？

有没有不切实际的质量属性（比如，在很多组织中，实现真正的全天候往往很昂贵）？

1一种目标管理方法，http://en.wikipedia.org/wiki/SMART_criteria。——译者注

此外，如果有任何质量属性被视为“架构上重要的”，并对架构产生影响，为什么不把它们记下来，这样你事后就能在文档中查阅。

结构

直接列出每个质量属性是一个很好的起点。例子包括：

性能（比如延迟和吞吐）；

可伸缩性（比如数据和流量）；

可用性（比如运行时间、停机时间、定期维护、全天候、99.9%等）；

安全性（比如认证、授权、数据保密性等）；

可扩展性；

灵活性；

审计；

监测和管理；

可依赖性；

故障转移/灾难恢复的目标（比如手工还是自动化，要花多长时间）；

业务连续性；

互操作性；

遵守法律法规（比如数据保护法）；

国际化（i18n）和本地化（l10n）；

可访问性；

易用性；

等等。

每一个质量属性都应该是精确的，不要让读者来解释。不属于这种情况的例子包括：

“对于要求必须快速提供服务”；

“上不封顶”；

“尽快”；

“尽可能小”；

“尽可能多的客户”；

等等。

动机

如果你一直是个软件架构的好公民，积极考虑质量属性，那为什么不把它们写下来呢？质量属性往往不是放在盘子里端给你的，需要一定量的探索和提炼才能得到一个清单。简单地说，把质量属性写下来可以消除歧义，无论是现在，还是将来的维护/增强工作。

受众

由于质量属性本质上多半是技术性的，这部分实际上是针对软件开发团队中的技术人员。

是否必须

是，所有软件指南都应该包含对质量属性/非功能性需求的总结，因为它们通常以某种方式塑造了最终的软件架构。