如何在项目中考虑非功能需求_非功能性需求

软件的非功能需求指的是除了软件的功能需求以外，软件需要满足的一些其他需求。常见的非功能需求包括：

1. 性能需求：软件需要在特定的时间内完成特定的任务，例如响应时间、吞吐量等。
2. 可靠性需求：软件需要在各种环境下都能够稳定运行，例如在不同的操作系统上、在不同的硬件上等。
3. 安全性需求：软件需要保护用户的隐私和数据安全，例如防止未经授权的访问、防止数据泄露等。
4. 易用性需求：软件需要易于使用，例如界面友好、操作简单等。
5. 可维护性需求：软件需要易于维护和升级，例如代码清晰、文档完整等。
6. 可移植性需求：软件需要能够在不同的平台上运行，例如在不同的操作系统上、在不同的硬件上等。
7. 兼容性需求：软件需要与其他软件或硬件兼容，例如在不同的数据库上运行、在不同的网络上运行等。
8. 可重用性需求：软件需要具有良好的可重用性，例如模块化设计、设计模式等。
9. 可扩展性需求：软件需要具有良好的可扩展性，例如易于添加新的功能、易于扩展系统等。
10. 可观察性需求：软件需要具有良好的可观察性，例如日志记录、性能监控等。 以上是常见的软件非功能需求，不同的软件可能需要满足不同的非功能需求。

也有一种说法叫做质量属性，主要分为开发期质量属性和运行期质量属性，二者分别关注软件开发阶段和软件运行阶段的质量特征。

开发期质量属性主要包括以下几点：

1. 易理解性（Understandability）：指软件系统或软件模块被开发人员理解的难易程度。
2. 可扩展性（Extensibility）：指软件系统适应新需求或者需求变化而增加新功能的能力。
3. 可重用性（Reusability）：指软件系统或某一部分可以被重复使用的难易程度。
4. 可测试性（Testability）：指对软件系统进行测试以证明其满足需求规范的难易程度。
5. 可维护性（Maintainability）：当需要修改缺陷、增加功能、提高质量时，定位修改点并实施修改的难易程度。
6. 可移植性（Portability）：将软件系统从一个运行环境转移到另外一个不同的运行环境的难易程度。

运行期质量属性主要包括以下几点：

1. 性能（Performance）：指软件系统及时提供相应服务的能力，包括速度、吞吐量和持续高速性等几个方面。
2. 安全性（Security）：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
3. 易用性（Usability）：指软件系统易于被使用的程度。
4. 可伸缩性（Scalability）：指当用户数和数据量增加时，软件系统维持高服务质量的能力。
5. 互操作性（Interoperability）：指软件系统与其他系统交换数据和相互调用服务的难易程度。
6. 可靠性（Reliability）：指软件系统在一定的时间内无故障运行的能力。
7. 持续可用性（Availability）：指软件系统长时间无故障运行的能力。
8. 鲁棒性（Robustness）：指软件系统在一些非正常情况下，如用户进行了非法操作、相关的软硬件系统发生了故障等，仍然能够正常运行的能力，也称健壮性或容错性。

那我们在实际的工作过程中如何考虑这些非功能需求呢，我现在了解到的主要有几种架构评估方法：saam、atam、cbam、ADMEMS矩阵方法。

下面我简介下查到的：

一、ATAM

第0阶段 建立评估小组， 建立评估组织和待评估组织间的合作关系 ；

第1阶段 以架构为中心，重点获取架构信息并对其进行分析。 评估阶段，下面的9个步骤在这时完成

（

• 确定参与人员：组建评估团队，包括架构师、开发人员、测试人员等。
• 描述商业动机：明确软件项目的商业目标和动机。
• 描述架构：提供架构的详细描述，包括主要组件、交互方式等。
• 确定质量属性：识别关键的质量属性，如性能、可用性、安全性等。
• 生成质量属性效用树：建立质量属性与架构决策之间的关系树。
• 分析架构方法：通过场景分析、风险点识别等方式，对架构方法进行深入分析。
• 讨论确定场景优先级：根据商业动机和质量属性要求，讨论并确定关键场景的优先级。
• 分析架构方法（续）：基于优先级排序的场景，进一步分析架构方法的有效性和适应性。
• 表述结果：整理评估结果，提出改进建议，并与项目团队共享。）

第2阶段 以风险承担者中心，重点为获取风险承担者的观点，并对第1阶段的结果进行验证。

第3阶段 后续阶段，形成最终报告，对后续活动做出规划，评估组织在此阶段实现文档和经验的更新。

（一）策略阶段

• 参与者: 评估组长和关键的项⽬决策者
• 输⼊:架构文档
• 目标：确定评估的目标、计划、评估组成员
• 输出: 评估计划: 谁、什么时间、提供什么样子的评估报告

（二）评估阶段

• 参与者:评估小组和项目设计决策者(肯定包括了项目经理和架构师)
• 输出: 架构简要展示、业务目标、质量属性和相关场景、效用树、风险和非风险点、敏感点、权衡点

1. 介绍ATAM方法(评估小组长)
2. 介绍商业动机(项目经理或系统客户)
3. 介绍架构(首席架构师)
4. 识别使用的架构方法(评估小组)
5. 生成质量属性效用树(评估小组和项目设计决策者) 决定性的一步
6. 分析架构方法(评估小组) 确保方法是正确的 获得风险点、非风险点、敏感点和权衡点列表

（三）评估

• 参与者: 评估小组、项目设计决策者和架构涉众
• 输出: 从涉众群体获得的一个优先级场景列表、风险主题和商业动机

1. 介绍ATAM方法和之前的结果(评估小组长) 重复以确保涉众也知道方法并回顾分享之前2~6步的结果
2. 头脑风暴、场景划分优先级(评估小组问涉众) 与质量属性效用树进行比对
3. 分析架构方法(评估小组、架构师) 使用新产生的优先级靠前的场景、架构师解释与之相关的架构决定
4. 展示结果(评估小组)

（四）后续工作 Follow up

• 参与者:评估小组和主要涉众
• 输出:最终的评估报告

（五）ATAM 输出

• 架构简要介绍

• 业务目标

• 以质量属性场景表示的带优先级的质量属性需求

• 效用树

• 系列风险点和非风险点

• 风险主题

• 架构决定与质量需求之间的映射

• 敏感点、权衡点

• 最终评估报告

• 在公司里面的流程如下：

• 

二、ADMEMS矩阵方法

ADMEMS（Architecture Design Method has been Extended to Method System）矩阵方法是一个由CSAI顾问团架构设计专家组发布的软件架构设计方法。它旨在通过一套系统的方法论来指导软件架构师进行架构设计，并确保架构能够满足项目的需求。

（一）预备架构阶段（PA）

1. 目标：与项目干系人沟通，收集业务需求、技术需求和非功能需求，对需求进行分类和优先级排序，确保架构设计关注最重要的方面。把握需求特点，确定架构设计驱动力。

   • 活动：分析项目需求，识别关键业务场景和技术约束，建立ADMEMS矩阵，将需求分类并映射到矩阵中。

     

   （二）概念架构阶段（CA）

   • 目标：根据重大需求，确定概念架构。
   • 活动：基于PA阶段的需求分析，设计高层次的架构蓝图，明确主要组件、交互关系和技术选型。考虑功能、质量、约束等所有方面的需求。与项目干系人确认概念架构是否满足业务需求，并根据反馈进行调整。
   • 

   （三）细化架构阶段（RA）

   • 目标：细化架构设计，关注不同视图。
   • 活动：使用5视图方法（逻辑架构、物理架构、开发架构、运行架构和数据架构）详细描述架构的不同方面。确保每个视图都符合CA阶段确定的概念架构，并满足所有功能和非功能需求。验证细化架构是否满足所有功能和非功能需求，特别是性能、安全性、可用性等关键质量属性。
   • 

2. 架构评审与优化：

   • 邀请同行专家或架构师团队对细化架构进行评审。收集他们的反馈和建议，并进行必要的调整。
   • 根据项目进展和实际需求变化，持续优化和演进架构设计。

3. 文档编写与维护：

   • 编写架构设计文档，包括架构描述、设计决策、约束条件、视图说明等。确保文档内容清晰、准确、易于理解。
   • 在项目过程中定期更新文档，以反映架构设计的最新状态。

   三、SAAM（软件架构分析法）

• 确定评估目标：明确评估的焦点，例如可修改性、安全性、性能等。

• 收集信息：收集与架构相关的信息，包括架构描述、设计决策、约束等。

• 场景分析：识别关键的使用场景或修改场景，并分析架构对这些场景的支持程度。

• 评估：基于分析结果，对架构的适应性和满足质量属性的能力进行评估。

• 总结与报告：整理评估结果，提出改进建议，并编写评估报告。

  四、CBAM（成本效益分析法）：

• 确定评估范围：明确评估的对象和范围，例如特定的架构设计或决策。
• 成本分析：估算实现和维护特定架构所需的成本，包括人力、时间、资源等。
• 效益分析：预测采用特定架构可能带来的效益，如提高性能、减少维护成本等。
• 成本效益比较：将成本与效益进行比较，评估架构的经济可行性和长期价值。
• 制定决策：基于成本效益分析结果，制定关于架构选择或优化的决策。

现在我还练习的不是很熟，今后在工作中，再经常看看，熟能生巧。

参考：

1.3.1. Pre-architecture阶段：ADMEMS矩阵方法 · GitBook (tonydeng.github.io)

ATAM软件架构评估方法 - 企业架构设计方法与实践 (tonydeng.github.io)

《软件系统架构师》第八章