非功能需求分析
1 目的
非功能需求分析检查解决方案的需求，这些需求定义了功能需求必须执行得有多好。它指定了可用于评估系统操作的标准（而不是具体行为——这被称为 功能性需求）。
2 描述
非功能需求（也称为质量属性 1或服务级别要求）通常与系统解决方案相关，但它们在更广泛的意义上也适用于解决方案的流程和人员方面。 它们补充了方案的功能需求、确定对这些需求的约束，或者描述基于这些功能性需求时必须具备的质量属性。
非功能需求通常以声明性语句或矩阵的形式用文本表示。 声明性非功能需求声明通常包含一个约束因素。 例如，错误不能超过X次/过程使用次数，事务必须在S秒后至少完成X%，或者系统必须在X%的时间内可用。
3 元素
.1 非功能需求的类别
非功能需求的一些常见类别包括：
- 可用性：当需要使用时，解决方案能够运行和访问的程度，通常用解决方案可用的时间百分比来表示。
- 兼容性：解决方案在环境中与其他组件有效协同的程度，例如一个过程与另一个过程。
- 功能性：解决方案满足用户需求的程度，包括适用性、准确性以及互操作性等方面。
- 可维护性：解决方案或组件修改以纠正错误、提高性能或其他属性，或适应更改环境的难易程度。
- 性能效率：解决方案或组件在使用最少资源的情况下执行其指定功能的程度。可以根据上下文或时期进行定义，例如高峰期、中峰期间或非峰值使用。
- 可移植性：解决方案或组件从一个环境迁移到另一个环境的容易程度。
- 可靠性：在规定条件下，解决方案或组件执行其所需功能的能力，在设备故障平均时间等给定时间内。
- 可扩展性：解决方案能够增长或发展的程度，以处理更多的工作量。
- 安全：保护解决方案的内容或组件免受意外或恶意访问、使用、修改、破坏或披露的解决方案方面。
- 可用性：用户学习使用解决方案的难易程度。
- 认证：为了满足某些标准或行业惯例而需要遵守的解决方案约束。
- 遵守规则：监管、金融或法律方面的约束，这些约束可能因上下文或司法管辖区的不同而有所不同。
- 本地化：与当地语言、法律、货币、文化、拼写和其他用户特征相关的要求，需要关注上下文。
- 服务级别协议：由解决方案提供商和服务方案用户正式同意的服务组织的约束。
- 可扩展性：解决方案包含新功能的能力。
.2 非功能需求的度量
非功能需求通常以模糊的方式描述质量属性，例如“过程必须易于学习”或“系统必须快速响应”。为了对解决方案的开发人员有用并可验证，非功能要求应在可能的情况下加以量化。包含适当的成功测量可以提供验证的机会。 例如：
“这个过程必须容易学习”可以表达为“在不超过六个小时的培训后，90%的操作员能够使用新的流程”，以及
“系统必须迅速响应”可以表达为“系统必须在两秒内提供至少90%的响应”。
非功能需求的其他类别的测量是由需求来源指导的。
例如：
- 认证要求通常由制定标准或惯例的组织以可衡量的细节指定，例如ISO认证标准，
- 供应商 2在可衡量的细节中规定了合规性和本地化要求，
- 有效的服务级别协议清楚地说明了需要的成功措施，以及
- 一个组织的企业架构通常定义解决方案环境的要求，并明确指定所需平台或环境的其他属性。
.3 非功能需求的上下文
根据非功能类要求的不同，上下文环境可能需要考虑。例如，监管机构可能会施加影响上下文合规性和安全性 3的要求，或者正在海外扩张业务的企业组织可能需要考虑本地化和可扩展性需求。在给定的组织环境中确定最佳的非功能类要求组合对于向涉众提供价值至关重要。
对非功能要求（如本地化或可维护性）的评估可能会给其他非功能要求带来上下文压力。例如，一个司法管辖区中的监管规定或资源可能会影响该地区的解决方案的可维护性，因此这可能导致成功度量的标准与另一个司法管辖区相比性能效率较低或可靠性较低。
上下文本质上是动态的，非功能需求可能需要调整或直接删除。商业分析师在评估非功能需求时会考虑上下文的相关稳定性。
技术
4 使用考虑情况
.1 优势
- 明确说明一组功能需求所适用的约束。
- 为功能需求提供了可衡量的表达方式，从而让功能需求来说明解决方案必须做什么或如何表现。这也会对用户是否接受该方案产生重大影响。
.2 限制
- 非功能要求的清晰性和实用性取决于涉众 4对解决方案的需求了解多少，以及他们能够清楚地表达这些需求的能力。
- 多个用户对软件的期望可能大不相同，由于用户的主观感知质量，很难就质量属性达成一致。例如，对于一个用户来说，“太快”可能是另一个用户“太慢”。
- 非功能要求可能包含固有的冲突，需要协商。例如，某些安全要求可能会对性能要求妥协。
- 过于严格的要求或约束可能会增加解决方案的时间和成本，从而产生负面影响并削弱用户的采用。
- 许多非功能需求具有定性的特点，因此可能很难在尺度上进行测量，并且用户可能会因其认为特定的需求如何满足他们的需求而产生一定程度的主观性。