软件工程中的非功能性需求是指那些与特定功能或行为无关的特性。它们描述了系统应该如何执行，而不是应该做什么。本文将重点讨论非功能性需求。
1 什么是非功能性需求？
非功能性需求是定义软件质量属性的约束条件。这些需求涵盖了可扩展性、可维护性、性能、可移植性、安全性 1、可靠性等方面。它们对于确保软件系统的整体质量和成功至关重要，因为它们不仅影响着系统的可维护性和可移植性，还确保系统符合相关法律法规，并在可接受的时间范围内快速响应用户操作。此外，非功能性需求保证了系统的易用性和可访问性，定义了正常运行时间和停机时间，从而确保系统在需要时可靠且可用。
2 非功能性需求的类型
2.1 性能要求
- 响应时间：表示系统对用户请求做出反应的最长时间。
- 吞吐量：指系统在特定时间内能够处理的交易或流程的数量。
- 可扩展性：描述了系统如何通过添加资源来适应增长的工作量或用户群。
示例：系统应能够在不降低性能的情况下支持一定数量的并发用户或在指定时间内处理一定量的数据。
2.2 可靠性要求
- 描述了软件系统随时间推移一致且准确地执行其功能的能力。
示例：系统必须达到99.99%的正常运行时间。
2.3 可扩展性要求
- 表明系统在数据量和用户负载增加时保持稳定并维持性能的能力。
示例：系统应支持最多20,000个并发用户，而不会降低性能。
2.4 可用性要求
- 定义了系统的运行连续性，即系统应在需要时可用且响应，不应频繁出现故障或崩溃。
示例：系统应全天候可用（除维护时段外）。
2.5 易用性要求
- 涉及到软件系统的易用性和用户友好性，系统应当易于导航和理解，并向用户提供清晰简洁的反馈。
示例：新用户应能在10分钟内完成注册过程。
2.6 安全要求
- 包括身份验证、授权、数据加密等措施，以保护系统免受未经授权的访问、攻击和数据泄露。
示例：系统应对所有用户登录使用多因素身份验证。
2.7 可维护性要求
- 描述了软件系统随时间进行修改、更新和维护的难易程度。
示例：系统的代码库应遵循编码标准以确保可维护性。
2.8 效率要求
- 关注的是CPU、内存和网络流量等资源的有效利用。
示例：系统在峰值负载下CPU利用率不得超过75%。
2.9 可移植性要求
- 确定了系统是否能在不同的环境中工作。
示例：应用程序应在Windows和Linux操作系统上无需修改即可运行。
2.10 可重用性要求
- 指出系统组件可以在另一个系统中被重用的程度。
示例：登录和身份验证模块可以在多个应用程序中重复使用。
3 功能性需求与非功能性需求
| 方面 | 功能性需求 | 非功能性需求 |
|---|---|---|
| 定义 | 定义了系统必须提供的特性和功能。 | 定义了系统的质量属性 2。 |
| 重点 | 关注于系统的行为和功能实现。 | 关注于性能、可用性、可靠性等质量属性。 |
| 目标 | 目标是验证软件的功能正确性。 | 目标是验证软件的质量属性。 |
| 测试类型 | 如API测试、系统测试、集成测试等。 | 如可靠性测试、负载测试、可扩展性测试等。 |
| 重要性 | 对系统运行至关重要。 | 提高用户体验和系统质量，但可能不是强制性的。 |
| 指定者 | 通常由用户或业务方指定。 | 常由开发人员和技术团队指定。 |
| 例子 | 数据输入、存储、用户认证等。 | 系统响应时间、正常运行时间等。 |
4 识别非功能性需求的好处
- 提高系统质量：确保系统具备所需的性能、安全、可用性等特性。
- 增强用户满意度：满足用户对性能和安全的期望，提高用户满意度。
- 与业务目标对齐：确保系统支持组织的整体目标。
- 减少返工：早期识别并解决非功能性需求可以避免后期昂贵的返工。
- 提升系统可扩展性和适应性：确保系统能够应对不断增长的用户数和变化的需求。
- 加强合规性：确保系统遵守相关法律、法规和行业标准。
- 便于维护：确保系统易于维护、测试和调试，长期来看节省成本。
5 识别非功能性需求的挑战
- 难以识别全部需求：特别是在复杂系统或新技术中。
- 预测未来需求困难：可能导致软件过时或需要重新设计。
- 测量和测试难度大：难以量化和验证非功能性需求。
- 耗时：收集和指定非功能性需求可能非常耗时。
- 成本高昂：涉及多方利益相关者 3时成本可能会很高。
- 需求变更风险：随着时间的推移，需求可能会发生变化，导致额外工作。
- 冲突的需求：非功能性需求之间可能存在矛盾，难以平衡。
- 不可预见的需求：某些需求可能仅在系统部署后才会显现。
6 记录非功能性需求的最佳实践
- 明确：使用清晰、准确且可量化的术语定义需求。
- 避免歧义：记录需求时使用一致的语言。
- 与业务目标一致：确保需求与企业目标和用户期望相符。
- 优先级 4排序：根据需求的重要性和影响确定优先级。
- 合作：与包括开发者、最终用户和业务分析师在内的各方利益相关者合作。
7 结论
在软件工程中，非功能性需求是不可或缺的一部分，它们确保了系统除了功能实现之外的质量和特性，对于满足用户期望和保证系统在各种条件下高效可靠地运行至关重要。这些需求不仅提升了客户满意度及整体用户体验，还定义了系统的性能、安全性、可用性等方面的标准。通过一系列具体的指标来量化和评估非功能性需求，如响应时间（衡量系统对请求的处理速度）、错误率（反映系统的稳定性和可靠性）、正常运行时间（表明系统可用性的持续时长）以及吞吐量（表示单位时间内系统能处理的数据或事务数量），可以确保系统不仅能够完成既定的功能，还在稳定性、响应速度和数据保护等方面达到预期水平。
非功能性需求的定义是一个跨职能团队合作的过程，涉及多个关键角色 5：业务分析师理解并传达业务目标和用户需求；开发者提供技术视角，确保所提需求的技术可行性；最终用户直接反馈使用体验，帮助确定哪些质量属性最为重要；架构师从高层次设计的角度考虑如何支持这些非功能性要求。通过上述各方的紧密协作，可以更全面准确地捕捉到项目的非功能性需求，并将其转化为实际的设计与开发指南，从而构建出更加健壮且用户友好的软件产品。
总之，正确理解和实施非功能性需求不仅有助于提高系统质量、增强用户体验，还能更好地符合组织的战略 6目标，是确保最终产品成功的关键因素之一。