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

简介: 软件非功能需求包括性能、可靠性、安全性、易用性、可维护性、可移植性、兼容性、可重用性、可扩展性和可观察性。质量属性分为开发期和运行期,如易理解性、可扩展性、可测试性等是开发期质量,性能、安全性、易用性等是运行期质量。评估方法有ATAM(架构评估技术)、ADMEMS矩阵方法、SAAM(软件架构分析法)和CBAM(成本效益分析法)。ATAM包括建立评估小组、获取架构信息、风险承担者观点和形成最终报告四个阶段。

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

  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阶段形成最终报告,对后续活动做出规划,评估组织在此阶段实现文档和经验的更新。

  • 参与者:评估小组和主要涉及人员
  • 输出:最终的评估报告,报告内容如下:
  • 架构简要介绍
  • 业务目标
  • 以质量属性场景表示的带优先级的质量属性需求
  • 效用树
  • 系列风险点和非风险点
  • 风险主题
  • 架构决定与质量需求之间的映射
  • 敏感点、权衡点
  • 在公司里面的流程如下:


二、ADMEMS矩阵方法

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

1、预备架构阶段(PA)

  • 目标:与项目干系人沟通,收集业务需求、技术需求和非功能需求,对需求进行分类和优先级排序,确保架构设计关注最重要的方面。把握需求特点,确定架构设计驱动力。
  • 活动:分析项目需求,识别关键业务场景和技术约束,建立ADMEMS矩阵,将需求分类并映射到矩阵中。

2、概念架构阶段(CA)

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

3、细化架构阶段(RA)

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

并进行如下步骤:

1)架构评审与优化

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

2)文档编写与维护

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

三、SAAM(软件架构分析法)

  • 确定评估目标:明确评估的焦点,例如可修改性、安全性、性能等。
  • 收集信息:收集与架构相关的信息,包括架构描述、设计决策、约束等。
  • 场景分析:识别关键的使用场景或修改场景,并分析架构对这些场景的支持程度。
  • 评估:基于分析结果,对架构的适应性和满足质量属性的能力进行评估。
  • 总结与报告:整理评估结果,提出改进建议,并编写评估报告。

四、CBAM(成本效益分析法):

  • 确定评估范围:明确评估的对象和范围,例如特定的架构设计或决策。
  • 成本分析:估算实现和维护特定架构所需的成本,包括人力、时间、资源等。
  • 效益分析:预测采用特定架构可能带来的效益,如提高性能、减少维护成本等。
  • 成本效益比较:将成本与效益进行比较,评估架构的经济可行性和长期价值。
  • 制定决策:基于成本效益分析结果,制定关于架构选择或优化的决策。
目录
相关文章
|
3月前
|
缓存 算法 Java
非功能需求的测试
非功能需求的测试
37 2
|
测试技术
软件需求分析
一、软件需求分析 软件需求分析是软件工程中的一个关键过程,它旨在理解和明确用户对软件系统的需求,为后续的设计和开发提供基础。软件需求分析包括以下几个主要步骤: 1. 需求收集:需求收集是指通过与用户和利益相关者的沟通和交流,获取软件系统的需求信息。这可以通过面谈、访谈、问卷调查、观察等方式进行。需求收集的目标是获得用户的需求和期望,以及软件系统所需的功能和性能要求。 2. 需求分析和建模:需求分析是对收集到的需求进行分析和整理,以理解其背后的意图和目标。需求建模则是将需求信息以图形或文本形式进行描述和表达,以便于理解和沟通。常用的需求建模技术包括用例图、活动图、状态图等。 3. 需求验证和确认
426 1
|
6月前
|
运维 测试技术 API
产品服务的详细设计与开发阶段
产品服务的详细设计与开发阶段
99 2
|
11月前
【电商系统】—项目缺陷管理(二)
【电商系统】—项目缺陷管理(二)
|
测试技术
测试理论--需求分析
需求分析就是要弄清楚用户需要的是什么功能,用户会怎样使用系统。这样测试时才能更清楚的知道系统该怎么样运行,才能更好的设计测试用例,才能更好的测试。
255 0
|
存储 数据可视化 数据库
项目需求分析 | 学习笔记
快速学习项目需求分析
227 0
OA系统模块设计方案
OA系统模块设计方案
158 0
如何做需求分析
什么是需求? 通俗些来讲需求就是现实和想象的差距,差距越大,需求越大。 来源网络,侵权删 如上图理想中的男朋友和现实中的男朋友,因为有差距,所以就有了类似于“如何让男人宠爱一生”之类的书、情感专栏等产品产生。
1386 0