需求分析中需求规格SRS的非功能性需求的考虑因素
2025年软件资格考试软件过程能力评估师(中级)(基础知识、应用技术)合卷试题及答案指导
2025年软件资格考试软件过程能力评估师(基础知识、应用技术)合卷(中级)自测试题(答案在后面)一、基础知识（客观选择题，75题，每题1分，共75分）1、软件过程能力评估师在进行软件过程评估时，通常会使用哪种方法来识别和量化软件过程中的关键过程域（KPA）？A、专家评审法B、统计分析法C、模型分析法D、过程审计法2、在软件能力成熟度模型集成（CMMI）中，哪个级别是组织软件过程能力成熟度的基础？A、初始级B、已管理级C、已定义级D、已量化级3、题干：在软件开发生命周期中，以下哪个阶段主要负责软件需求的收集和分析？A. 需求分析阶段B. 设计阶段C. 编码阶段D. 测试阶段4、题干：以下哪个不是软件质量保证（SQA）的常用方法？A. 流程分析B. 审计C. 验收测试D. 软件审计5、题目：在软件过程能力成熟度模型（CMM）中，哪一级别代表了组织已经建立了一套持续改进的机制，并且能够对过程进行监控和评估？A、初始级B、可重复级C、已定义级D、管理级6、题目：在软件开发生命周期中，以下哪个阶段通常负责确定项目是否应该继续进行？A、需求分析B、设计C、编码D、验收测试7、软件过程能力成熟度模型（CMM）的五个级别中，哪个级别强调对软件过程进行定量分析和度量？8、在软件项目管理中，以下哪个不是敏捷开发方法的特点？9、题干：在软件工程中，以下哪个活动通常被称为“软件需求工程”？A. 软件设计B. 软件测试C. 软件需求工程D. 软件维护 10、题干：在软件过程能力成熟度模型（CMM）中，以下哪个级别表示组织已经建立了有效的软件过程管理和改进机制？A. 初级（Initial）B. 管理级（Managed）C. 定义级（Defined）D. 精益级（Optimizing）11、题干：在软件过程中，以下哪个阶段不是软件生命周期的标准阶段？A. 需求分析B. 设计C. 编码D. 测试E. 维护12、题干：以下哪种软件工程原则旨在减少系统复杂性，提高软件的可维护性？A. 单一职责原则B. 开放封闭原则C. Liskov替换原则D. 迪米特法则13、在软件过程能力成熟度模型CMM（Capability Maturity Model）中，成熟度级别1的特点是什么？14、敏捷开发方法中，哪个原则强调“尽早地、持续地对软件进行测试，以便及时发现问题并修复？”15、软件过程能力评估模型（CMMI）的成熟度等级分为几个级别？16、在软件项目管理中，下列哪个工具用于跟踪项目进度和资源消耗？17、在软件生命周期模型中，哪一个模型强调了需求获取与定义的重要性，并且在这个阶段收集所有必要的信息来确保后续设计和开发工作的正确性？A. 瀑布模型B. 增量模型C. 螺旋模型D. 敏捷模型18、下列哪一项质量管理原则强调在整个组织内各级人员的积极参与是组织之本？A. 过程方法B. 领导作用C. 全员参与D. 持续改进19、在软件过程能力成熟度模型（CMM）中，以下哪个级别标志着组织已经建立了一套稳定的软件开发过程？A. CMM Level 1：初始级B. CMM Level 2：可重复级C. CMM Level 3：已定义级D. CMM Level 4：管理级 20、在软件项目管理中，以下哪个工具或技术用于评估项目风险的概率和影响？A. 风险矩阵B. Gantt图C.PERT图D.PERT分析21、在软件生命周期模型中，螺旋模型是一种结合了瀑布模型与哪种其他模型的特点，并且包含风险分析的模型？A、增量模型B、快速原型模型C、喷泉模型D、敏捷模型22、在软件工程中，需求分析阶段的主要任务是什么？A、确定软件的功能需求和非功能需求B、设计软件的具体实现细节C、编写程序代码D、测试软件是否满足需求规格说明书的要求23、在软件过程能力成熟度模型（CMM）中，CMM模型将软件过程成熟度分为几个等级？24、敏捷开发方法中，哪一种实践不强调团队间的协作和沟通？25、在软件生命周期中的哪一个阶段，需求分析被归类为一项关键活动？A. 概念定义阶段B. 软件开发阶段C. 需求获取阶段D. 系统维护阶段26、下列哪一项质量管理原则强调了持续改进的重要性？A. 以客户为中心B. 过程方法C. 基于事实的决策方法D. 持续改进的方法27、在软件过程能力成熟度模型（CMM）中，哪个级别代表组织具有持续改进的过程？28、软件需求工程中，以下哪项不是软件需求规格说明书（SRS）的主要目的？29、关于软件生命周期模型的说法，下列哪一项是正确的？A. 增量模型允许在早期阶段实现核心产品。
软件需求工程实验六
实验六需求风险评估与跟踪矩阵
目的：
1、了解软件需求风险评估和跟踪的重要意义和作用；
2、理解软件需求风险评估和需求跟踪的常见模式和流程；
2、掌握软件需求风险和跟踪文档的编写和步骤；
要求：
1、掌握需求风险评估和跟踪意义和作用；
2、对需求规格文档SRS进行风险评估和高风险需求进行实时跟踪处理进展，编写跟踪矩阵文档，以及跟踪文档设定操作；
实验内容：
利用理论知识内容完成SRS的风险评估和跟踪矩阵的输出。
一、评估需求风险需要注意以下几点：
1、需求获取阶段
1)如涉及到非功能需求，需要明确
2)对需求基线的合理建立进行评估
3)是否给出期望的解决办法，如没有需要重点跟进
4)
2、需求分析阶段
1)划分需求优先级，优先级高的重点考虑
2)关注可能带来技术困难的特性
3)对不熟悉的技术、方法、语言、工具或硬件平台进行风险评估
4)
3、需求规格说明
1)对需求的描述和定义不能太过抽象，简单直接明了为上。
2)对具有二义性的术语和用户特有的专业术语解释说明是否到位。
3)
4、需求管理
1)需求变更的处理流程和机制是否双方达成一致
二、需求跟踪矩阵
1、需求跟踪提供了一个与合同或说明文档相一致的方法。
2、需求跟踪通过持续跟进需求任务的进展，不限于需求分析阶段，还包括包括设计、开发、测试等阶段，及时发现问题，达到可以改善软件开发质量，降低维护成本
作业布置：参
考教材和实验指导内容，完成任务
1、需求风险评估时你认为还需要考虑哪些方面？请简述。
2、如果让你对已经完成的需求跟踪矩阵进行管理和跟踪，你将准备如何去跟踪？。
需求分析文档
需求规格说明书软件需求规格说明书（System Requirement Specification，SRS）也叫软件需求分析说明书，它是软件的重要文档之一，软件需求分析说明书对所开发的软件功能、性能、运行环境等做出详细的说明。
它是软件分析设计的最主要依据，验证核实产品能否满足用户要求的唯一标准，它是用户与开发人员双方对软件需求取得共同理解的基础。
下面给出一个简略版的需求规划说明书，以供分析理解。
由于篇幅有限，本说明书部分内容予以省略。
1引言本规格说明详细阐述了宿舍电费管理系统的软件功能、系统特性、非功能性需求以及其它需求。
编写目的详细、准确、全面的定义宿舍电费管理系统的软件需求，指导软件系统的后期开发工作；本文档所描述的软件需求将作为该项目的最终验收的标准与依据。
读者对象本软件需求规格说明书的读者包括：学生用户、系统管理员、收费员、抄表员产品的范围制作本软件的目的是，借助网络向学生提供服务，实现服务向消费者方向的转移，把软件与业务策略相联系。
2.综合描述这部分概述了项目的背景情况、主要功能、运行产品的环境，以及使用该产品的用户等。
2.1产品背景以及目前存在的问题传统的电费管理都是由工作人员查表、抄表完成的，其中要，完成用户电费的收取，每月的抄度，用户购电情况查询，以及列出欠费用户的信息名单之类的信息，其工作强度大，工作流程繁琐，倘若工作人员不细心，将会造成电费收支的错误也是会常有发生的，鉴于以上原因我们有必要开发一种帮助电费管理人员的软件系统，可以完成检查用户用电情况，每月抄度，信息录入以及基本数据维护的各项功能。
随着计算机技术日渐成熟，其强大的功能已为人们所接受，并已进入人类社会的各个领域发挥着越来越重要的作用。
因此，我们设计一种将电费管理与计算机操作相结合的系统。
学生在学校的用电需求日益壮大，往往会超出学校规定的用电范围，超出学校规定的用电，学生需要另外支付费用。
在学校中，宿舍用电的管理工作不仅工作量大，而且时效性强。
srs技术文档说明
本文的目的是描述SRS技术文档，包括对SRS的解释说明、SRS描述规范以及规范的一个范例。
软件需求规格说明书（SRS，Software Requirement Specification）是为了软件开发系统而编写的，主要用来描述待开发系统的功能性需求和非功能性需求，以及系统所要实现的功能和目标，为项目开发人员提供基本思路，明确开发方向，节约时间提高开发效率，降低软件开发风险，节约成本。
SRS主要面向系统分析员，程序员，测试员，实施员和最终用户。
SRS是整个软件开发的依据，它对以后阶段的工作起指导作用，同时也是项目完成后系统验收的依据，还是《用户手册》和《测试计划》的编写依据。
以下是SRS的描述规范：1.功能需求按模块为单位描述功能需求，重复以下几点描述每一模块的功能需求。
1.1 模块1第一个模块。
每个模块用一个用例图表示，在写SRS时，名字使用能够表达模块功能的短语表示，而不用模块1表示。
1.1.1 用例图描述此模块的用例图。
一个用例图中有若干个Actor、用例及其关系，描述包括涉及到的所有Actor、用例及其关系。
其中，Actor是参与者；一个用例描述的是一个功能需求；关系是用例和用例之间的关系。
用例的名字使用能够表达用例目标的动词短语。
1.1.2 业务流程图用例应说明的是系统内发生的事件，而不是事件发生的方式和原因。
一个业务流程图是用来描述1.1.1用例图中的一个用例事件的业务流程操作。
下面是对业务流程图对应的这个用例的描述说明：以下是SRS描述规范的一个范例：1.功能需求1.1业务区管理1.1.1 用例图1.1.2 业务流程图业务区创建范例说明：以上范例是直放站统一通讯管理系统的SRS中的第三章节，是用来描述系统的功能需求的，其中，1.1小节描述了其中一个模块——业务区管理的功能需求。
其中包括了业务区管理这一模块的用例图，以及对这一用例图中由Actor带动的三个用例：业务区创建、业务区管理、业务区删除的业务流程图描述，列出了其中一个用例——业务区创建的业务流程图，以及对这个用例的简要说明、前置条件、后置条件、角色、触发条件、基本事件流、备选事件流、特殊需求等的描述。
需求规格说明书
需求规格说明书随着科技和信息时代的发展，软件行业也越来越重要，其影响范围越来越广泛。
在软件开发过程中，需求规格说明书是一个非常重要的文档。
它定义了软件开发项目中的需求，包括功能、性能、安全、可用性等。
本文将详细介绍需求规格说明书的定义和重要性以及编写需求规格说明书的一些问题。
一、什么是需求规格说明书？需求规格说明书（Software Requirements Specification，简称SRS）是一份详细的软件开发文档，记录了一个软件系统需要满足的功能和性能要求。
它是一个软件开发项目的重要组成部分，决定了开发团队将开发的软件系统的范围和特征。
同时，它也是开发人员、测试人员、业务人员、客户和管理者之间交流的重要媒介。
二、需求规格说明书的重要性1. 确定方向，避免偏差需求规格说明书定义了软件开发项目的范围和要求。
在软件开发的过程中，可能会面临许多决策，如果没有清晰的目标依据，可能会迷失方向，甚至出现开发偏差。
通过编写需求规格说明书，团队成员可以确保对整个软件项目有一个共同的理解，并避免对产品范围的混淆。
同时，它也为项目负责人提供了一个确定开发进程的准确方法。
2. 保持一致性需求规格说明书为所有软件开发项目参与者提供了一致性的参考点。
这将确保所有的团队成员，包括开发人员、测试人员和业务人员，都了解软件项目的目标。
这将确保开发团队按照相同的标准进行开发和测试，而不会出现任何混乱，导致项目时间表的延迟和麻烦。
3. 提高效率，控制开发成本在编写需求规格说明书的过程中，团队成员能够更仔细地审核项目需求。
这样可以避免在开发过程中对问题进行不必要的更改，从而提高团队的工作效率，缩短项目发布时间，同时减少软件开发过程中的成本。
三、如何发挥需求规格说明书的作用为了使需求规格说明书发挥它的作用并达到预期的效果，编写它时需要遵循以下原则：1. 明确而详细地概述需求规格说明书需要提供足够的细节和定义，以便团队成员在理解细节时可以有一个相同的基线。
软件需求规格说明书编写指南
软件需求规格说明书编写指南引言软件需求规格说明书（SRS）是软件开发过程中至关重要的一份文档，是开发团队和客户之间的桥梁，用于明确软件系统的功能和性能需求。
本文旨在为编写RAS提供一个指南，以确保SRS文档的完整性和准确性。
一、背景介绍在这个部分，我们可以简要介绍软件开发的背景和目标。
例如，我们可以提到该软件项目是为了满足特定行业的需求，或者解决某个问题而开发的。
同时，还可以介绍项目的范围和预期用户群体。
二、需求概述在此部分，我们需要对整个软件的基本要求进行总结和概述。
这意味着我们需要列出所有的功能需求、性能需求和其他适用的需求，以便开发团队和客户能够对整个项目的规模和目标有一个清晰的认识。
三、详细需求说明在这个部分，我们需要详细地描述每个功能和性能需求。
可以将这些需求分组，以便于阅读和理解。
我们可以采用以下格式进行描述：功能需求在此部分，我们可以列举每个功能需求，并说明其详细描述、优先级和相关限制。
例如，对于一个在线购物网站的需求，我们可以列举用户注册、商品浏览、购物车管理等功能需求，并详述每个功能的具体要求。
性能需求在这个部分，我们可以列举每个性能需求，并说明其详细描述、优先级和相关限制。
例如，对于一个社交媒体平台的需求，我们可以列举用户同时在线人数、响应时间等性能需求，并说明针对这些需求的具体要求。
四、界面设计在这个部分，我们可以以图表或示意图等形式，展示软件系统的界面设计。
可以包括主页、菜单、按钮和输入框等元素的布局和交互逻辑。
同时，还可以说明每个界面元素的功能和约束。
五、数据模型在此部分，我们可以介绍软件系统的数据模型。
可以使用图表或表格等形式，展示各个实体（如用户、订单）之间的关系和属性。
可以详细说明每个实体的属性和类型，并说明其约束和关联关系。
六、系统规则在这个部分，我们可以概述软件系统中的各种规则和限制。
这些规则可以包括逻辑判断、数据验证和用户权限等方面。
通过详细描述系统规则，可以帮助开发团队更好地理解系统的运作机制。
SRS规范简介
本文的目的是描述SRS技术文档，包括对SRS的解释说明、SRS描述规范以及规范的一个范例。
软件需求规格说明书（SRS，Software Requirement Specification）是为了软件开发系统而编写的，主要用来描述待开发系统的功能性需求和非功能性需求，以及系统所要实现的功能和目标，为项目开发人员提供基本思路，明确开发方向，节约时间提高开发效率，降低软件开发风险，节约成本。
SRS主要面向系统分析员，程序员，测试员，实施员和最终用户。
SRS是整个软件开发的依据，它对以后阶段的工作起指导作用，同时也是项目完成后系统验收的依据，还是《用户手册》和《测试计划》的编写依据。
以下是SRS的描述规范：1.功能需求按模块为单位描述功能需求，重复以下几点描述每一模块的功能需求。
模块1第一个模块。
每个模块用一个用例图表示，在写SRS时，名字使用能够表达模块功能的短语表示，而不用模块1表示。
1.1.1 用例图描述此模块的用例图。
一个用例图中有若干个Actor、用例及其关系，描述包括涉及到的所有Actor、用例及其关系。
其中，Actor是参与者；一个用例描述的是一个功能需求；关系是用例和用例之间的关系。
用例的名字使用能够表达用例目标的动词短语。
业务流程图用例应说明的是系统内发生的事件，而不是事件发生的方式和原因。
一个业务流程图是用来描述用例图中的一个用例事件的业务流程操作。
下面是对业务流程图对应的这个用例的描述说明：以下是SRS描述规范的一个范例：1.功能需求业务区管理1.1.1 用例图1.1.2 业务流程图业务区创建业务区创建简要说明创建给定信息的业务区前置条件输入业务区名称，代码，及其他信息后置条件成功后置条件输出显示到页面上失败后置条件输出不显示到页面上角色系统管理员触发条件将这些信息加入到数据库中的业务区表基本事件流描述、步骤1. 输入业务区名称，代码，及其他信息;2.将这些信息加入到数据库中的业务区表;3.输出显示到页面上备选事件流、步骤无特殊需求无范例说明：以上范例是直放站统一通讯管理系统的SRS中的第三章节，是用来描述系统的功能需求的，其中，小节描述了其中一个模块——业务区管理的功能需求。
需求分析大作业(SRS)文档编制说明[1] (1)
![需求分析大作业(SRS)文档编制说明[1] (1)](https://img.taocdn.com/s3/m/35789a06bb68a98271fefa94.png)
背景
（三）用户对系统提出的功能性需求 本项目拟在本部和B厂（机加工工序）先实施， 二期再推广到异地的三个分厂。 系统功能包括B厂生产过程管理、产品销售管理、 售后服务管理（包含服务的记录和查询）、半成品和 成品仓库管理等等。同时利用这些信息，加强公司对 产品在线的过程监控、质量的监控、生产线（含质量 检验）员工的责任认定和绩效的考核。
主要用户 生产操作者 其他涉众 企业管理者
售后服务人员
分销商
质量检验人员
仓库管理人员
作业要求
参考上述背景，编制 “某机械物联网应用系统” 的SRS。 编写的文件参照模板“需求文档模板一.doc” ， 特别要进行“用例模型”分析。 网上寻找和阅读有关RFID及其应用的文档，文档 中要包含系统的物理架构、软件架构和开发环境 （.NET或J2EE等等）。 文档中包含系统物理设备和配件（主要是RFID电 子标签、RFID读写器、通讯设备、后台服务器） 的选型，选型应尽量降低成本（通过上网找资 料）。
2.产品销售管理方面的需求描述 产品分按订单销售和按库存销售两种方式，需 要系统对各产品的销售情况、销售去向进行准确 地统计，对每个产品的产品情况进行快速地查询 和获取，对经销商的产品销售情况进行记录。 目前依赖人工进行产品销售情况的统计，无 法快速查询单个产品的情况。
3.售后服务管理方面的需求描述
需求获取的部分照片该集团生产的半成品需求获取的部分照片车桥产成品某道工序的加工现场需求获取的部分照片生产过程中的质量跟踪卡需求获取的部分照片生产过程中需返工的产品需求获取的部分照片质量跟踪卡需求获取的部分照片产品保修卡涉众分析涉众stakeholder在软件开发项目中主要是指和这个项目有密切相关利益的人
背景
集团主要产品有5~6大类，规格有180多种。包括 汽车、工程机（装载机、压路机、叉车等）车桥、箱 件等等。 生产过程分铸造和机加工两类大工序。其中产品 铸造先由异地A工厂铸造，再由与总部相邻的B厂进行 机加工。 机加工约十几道工序、不同产品，其加工工 艺都有区别。 目前B厂有两车间，8条生产线，年产 20~30万件。
软件工程中的需求分析和需求规格说明
软件工程中的需求分析和需求规格说明随着科技的发展，信息化的进步不断推进，软件开发业也不断壮大和发展，软件开发模式也逐渐从传统的“瀑布”模型转向敏捷开发模型，而在任何一种软件开发模式中，需求分析都是至关重要的环节，也是资源投入最大的环节之一。
软件需求分析，通常包括以下几个方面：1、了解用户需求：需要通过对用户的需求、能力等基本情况的调查和分析，获知不同用户对软件的需求和期望，以及软件的应用场景和需要达到的目标等等。
2、定义系统的边界：需要通过了解系统的目的和工作原理，对系统的边界进行明确的定义，以免因为没有界限而导致开发盲目和项目失败。
3、给出系统的功能定义清单：需要对系统中所有功能点进行完整的定义和详细的说明，说明这些功能点的作用和功能，以便开发人员能够准确理解系统的功能需求。
4、确定数据和信息的处理方式：需要对数据和信息的流程和处理流程进行详细的规划和定义，并制定相应的数据处理和信息处理方法。
5、制定测试计划：对软件开发过程中的测试计划进行详细的分析和制定，以检测软件性能、功能和稳定性，以确保软件的稳定、可靠和安全。
在软件需求分析中，需求规格说明书（SRS）的编写是必不可少的。
简单地说，需求规格说明书是指定义软件系统需求的文件，具体地讲，它需要包括以下内容：项目概述、定义边界、非功能性需求、功能性需求、用例约定、人员需求、接口需求、性能需求和安全需求等等。
1、项目概述：对软件开发项目的整体情况和项目背景进行详细的概述，包括项目目的、系统特点、技术框架、需求概要等。
2、定义边界：对软件系统要求进行明确的描述，定义边界，明确系统的范围和功能。
同时,还需要对用户所期望的用途、功能点和业务流程等进行详细的定义。
3、功能性需求：详细描述每一个功能点所要实现的功能，以及用户对功能的操作和需求等。
4、非功能性需求：描述系统运行环境和性能指标，包括性能指标、可靠性、可维护性、用户操作和交互等等。
其重要性在于，提供了一个标准来衡量基于功能点的角度的质量和功能点的重要性。
2025年软件资格考试系统集成项目管理工程师(中级)(基础知识、应用技术)合卷试卷与参考答案
2025年软件资格考试系统集成项目管理工程师(基础知识、应用技术)合卷(中级)自测试卷(答案在后面)一、基础知识（客观选择题，75题，每题1分，共75分）1、以下关于软件工程的定义，正确的是：A、软件工程是一门研究如何高效地开发软件的学科B、软件工程是一门研究如何管理软件项目的学科C、软件工程是一门研究如何维护软件产品的学科D、软件工程是一门研究如何测试软件产品的学科2、在软件开发生命周期中，以下哪个阶段通常被认为是软件开发的核心阶段？A、需求分析阶段B、设计阶段C、编码阶段D、测试阶段3、题干：在项目管理中，下列哪一项不属于项目范围管理的过程？A. 范围规划B. 范围确认C. 项目进度控制D. 范围变更控制4、题干：以下关于项目沟通管理的说法中，哪一项是错误的？A. 沟通管理计划是项目管理计划的一部分B. 沟通管理计划定义了项目团队如何进行沟通C. 沟通管理计划包括项目干系人之间的沟通需求D. 项目沟通管理不包括对沟通效果的评估5、在项目管理中，以下哪项工作不属于项目启动阶段的工作内容？A. 制定项目章程B. 确定项目范围C. 识别项目干系人D. 制定项目管理计划6、以下哪项不是项目质量管理计划的关键组成部分？A. 质量标准B. 质量控制方法C. 质量改进计划D. 项目范围7、题目：在项目管理中，以下哪项不是项目风险管理的主要任务？A. 风险识别B. 风险分析C. 风险应对D. 项目验收8、题目：在项目管理中，以下关于敏捷开发方法的描述，错误的是：A. 敏捷开发方法强调快速响应变化B. 敏捷开发方法采用迭代和增量的开发方式C. 敏捷开发方法不强调文档编制D. 敏捷开发方法通常采用Scrum或Kanban等框架9、题干：在项目管理中，风险识别是一个重要的环节。
以下关于风险识别的说法中，错误的是：A. 风险识别需要识别项目可能遇到的所有风险B. 风险识别应该关注项目范围、进度、成本、质量、人力资源、合同和采购等方面C. 风险识别可以通过风险登记册记录识别出的风险D. 风险识别的结果应该包括风险的概率和影响评估 10、题干：在项目沟通管理中，以下关于沟通模型的描述中，不正确的是：A. 沟通模型包括发送者、接收者、信息、通道和反馈等要素B. 信息在传递过程中可能会失真，这是因为通道的干扰C. 沟通模型强调沟通是一个双向过程，需要发送者和接收者之间的互动D. 沟通模型中的信息是指项目团队成员之间的交流11、在系统集成项目管理中，以下哪个阶段不属于项目收尾阶段的工作内容？A. 项目验收B. 项目交付C. 项目总结报告编写D. 项目合同终止12、在项目管理中，以下哪种工具或技术用于识别项目风险？A. 风险分解结构（RBS）B. 网络图（PERT图）C. 甘特图D. 帕累托图13、题目：在项目沟通管理中，以下哪项不是项目管理计划的一部分？A. 沟通管理计划B. 沟通管理记录C. 沟通渠道图D. 沟通策略14、题目：以下哪项不是项目风险管理过程中的一个工具？A. 概率影响矩阵B. 实施风险应对C. 风险审计D. 风险分解结构15、在系统集成项目管理中，下列哪项工作不属于项目范围管理的内容？A. 范围定义B. 范围确认C. 范围控制D. 范围规划16、以下哪个选项不属于项目质量管理中的质量保证活动？A. 编制质量计划B. 进行质量审计C. 执行质量控制D. 进行质量改进17、在软件开发生命周期中，以下哪个阶段是对软件需求进行详细描述和定义的阶段？A. 需求分析阶段B. 设计阶段C. 编码阶段D. 测试阶段18、在项目管理中，以下哪项技术可以帮助项目经理评估项目风险并制定应对策略？A. 敏捷方法B. 软件配置管理C. 概率分析D. 项目评审19、在系统集成项目管理中，以下哪个阶段不属于项目生命周期的典型阶段？A. 规划阶段B. 执行阶段C. 控制阶段D. 结算阶段 20、在系统集成项目管理中，以下哪项不是项目风险识别的常用技术？A. 专家判断B. 趋势分析C. 脚本分析D. 敏感性分析21、在项目管理知识体系中，制定项目范围说明书之前需要完成的关键过程是什么？A. 收集需求B. 创建工作分解结构C. 定义范围D. 确认范围22、在软件生命周期模型中，哪一个模型强调了迭代开发，允许在项目过程中对需求进行细化、管理和控制？A. 瀑布模型B. 增量模型C. 螺旋模型D. 敏捷模型23、以下哪项不是系统集成项目管理工程师需要掌握的项目管理知识领域？A. 范围管理B. 进度管理C. 质量管理D. 项目管理方法论24、在项目风险管理过程中，以下哪种风险应对策略是不正确的？A. 风险规避B. 风险转移C. 风险减轻D. 风险接受25、在项目管理知识体系中，哪一个过程组强调了对整个项目的变更控制？A. 启动过程组B. 规划过程组C. 执行过程组D. 监控过程组E. 收尾过程组26、下列哪一项是软件项目风险管理过程中的第一步？A. 风险识别B. 风险评估C. 风险应对规划D. 风险缓解E. 风险监控27、在项目管理中，以下哪项不属于项目风险管理过程中的活动？A. 风险识别B. 风险规划C. 风险应对D. 项目计划28、以下关于项目章程的描述，不正确的是：A. 项目章程是由项目发起人批准的，正式授权项目成立的重要文件。
需求规格说明书模板
精心整理需求规格说明书(ISO标准版)编者说明：当需求调查、分析工作告一段落时，你就需要将这些需求进行规格化描述，整理成文，即软件需求规格说明书，也就是SRS。
这是在软件项目过程中最有价值的一个文档。
ISO所提供的标准虽然已经时间久远，但还是颇具参考价值的。
1．引言1.1编写的目的[[[2解[33.2.2时间特性要求[说明对于该系统的时间特性要求。
]3.2.3灵活性[说明对该系统的灵活性的要求，即当需求发生某些变化时，该系统对这些变化的适应能力。
]3.3输入输出要求[解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。
对系统的数据输出及必须标明的控制输出量进行解释并举例。
]3.4数据管理能力要求（针对软件系统）[说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。
]3.5故障处理要求[列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
]3.6其他专门要求[如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
]4．运行环境规定4.1设备[列出运行该软件所需要的硬设备。
说明其中的新型设备及其专门功能，包括：a. 处理器型号及内存容量b. 外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量c. 输入及输出设备的型号和数量，联机或脱机；]典型的优势是产品会增加组织在市场上的价值，减少运作成本，或提供更好的客户服务。
这个优势应该是可度量的，这样才能够让您确定交付的产品是否达到目标。
]2.客户、顾客和其它风险承担者2.1客户是为开发付费的人，并将成为所交付产品的拥有者[这一项必须给出客户的姓名，三个以内是合理的。
][客户最终将接受该产品，因此必须对交付的产品满意。
如果你无法找到一个客户的姓名，那么也许你就不应该构建该产品。
]2.2顾客是将花钱购买该产品的人[也给出姓名和相关的信息]2.3其它风险承担者[其他的一些人或组织的名称，他们或者受到产品的影响，或影响产品。
SRS规范简介
本文的目的是描述SRS技术文档，包括对SRS的解释说明、SRS描述规范以及规范的一个范例。
软件需求规格说明书（SRS，Software Requirement Specification）是为了软件开发系统而编写的，主要用来描述待开发系统的功能性需求和非功能性需求，以及系统所要实现的功能和目标，为项目开发人员提供基本思路，明确开发方向，节约时间提高开发效率，降低软件开发风险，节约成本。
SRS主要面向系统分析员，程序员，测试员，实施员和最终用户。
SRS是整个软件开发的依据，它对以后阶段的工作起指导作用，同时也是项目完成后系统验收的依据，还是《用户手册》和《测试计划》的编写依据。
以下是SRS的描述规范：1.功能需求按模块为单位描述功能需求，重复以下几点描述每一模块的功能需求。
1.1 模块1第一个模块。
每个模块用一个用例图表示，在写SRS时，名字使用能够表达模块功能的短语表示，而不用模块1表示。
1.1.1 用例图描述此模块的用例图。
一个用例图中有若干个Actor、用例及其关系，描述包括涉及到的所有Actor、用例及其关系。
其中，Actor是参与者；一个用例描述的是一个功能需求；关系是用例和用例之间的关系。
用例的名字使用能够表达用例目标的动词短语。
1.1.2 业务流程图用例应说明的是系统内发生的事件，而不是事件发生的方式和原因。
一个业务流程图是用来描述1.1.1用例图中的一个用例事件的业务流程操作。
下面是对业务流程图对应的这个用例的描述说明：以下是SRS描述规范的一个范例：1.功能需求1.1业务区管理1.1.1 用例图1.1.2 业务流程图业务区创建业务区创建简要说明创建给定信息的业务区前置条件输入业务区名称，代码，及其他信息后置条件成功后置条件输出显示到页面上失败后置条件输出不显示到页面上角色系统管理员触发条件将这些信息加入到数据库中的业务区表基本事件流描述、步骤1. 输入业务区名称，代码，及其他信息;2.将这些信息加入到数据库中的业务区表;3.输出显示到页面上备选事件流、步骤无特殊需求无范例说明：以上范例是直放站统一通讯管理系统的SRS中的第三章节，是用来描述系统的功能需求的，其中，1.1小节描述了其中一个模块——业务区管理的功能需求。
2024年学习笔记信息系统项目管理师(第四版)第五章-信息系统工程
第五章-信息系统⼯程1-软件⼯程1.1-架构设计1.软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述，构件的相互作用（连接体）、指导构件集成的模式以及这些模式的约束组成。
2.软件架构主要研究内容涉及软件架构描述、软件架构风格。
软件架构评估和软件架构的形式化方法等。
3.研究软件架构的根本目的是解决好软件的复用、质量和维护问题。
4.软件架构设计的一个核心问题是能否达到架构级的软件复用，也就是说，能否在不同的系统中使用同一个架构软件。
软件架构风格是描述某一个特定应用领域找那个系统组织方式的惯用模式。
5.通用软件架构：数据流风格、调用/返回风格、独立构件风格、虚拟机风格和仓库风格。
6.数据流风格：包括批处理序列和管道/过滤器两种风格。
7.调用/返回风格包括主程序/子程序、数据抽象和面向对象，以及层次结构。
8.独立构件风格包括进程通信和事件驱动的系统9.虚拟机⻛格包括解释器和基于规则的系统。
10.仓库⻛格包括数据库系统、⿊板系统和超⽂本系统。
11.在架构评估过程中，评估⼈员所关注的是系统的质量属性。
1.2-需求分析1.虚拟机⻛格包括解释器和基于规则的系统。
需求是多层次的，包括业务需求、⽤户需求和系统需求，这三个不同层次从⽬标到具体，从整体到局部，从概念到细节。
2.业务需求：指反映企业或客户对系统⾼层次的⼀个⽬标追求，通常来⾃项⽬投资⼈、购买产品的客户、客户单位的管理⼈员、市场营销部⻔或产品策划部⻔等。
3.⽤户需求：描述的是⽤户的具体⽬标，或者⽤户要求系统能完成的任务，⽤户需求描述了⽤户能让系统来做什么。
4.系统需求：是指从系统的⻆度来说明软件的需求，包括功能需求，⾮功能需求和设计约束。
5.质量功能部署QFD是⼀种将⽤户要求转化成软件需求的技术，其⽬的是最⼤限度地提升软件⼯程过程中⽤户的满意度。
为了达到这个⽬标，QFD将需求分为三类，分别是常规需求、期望需求和意外需求。
6.需求过程主要包括需求获取、需求分析、需求规格说明书编制、需求验证与确认等。
SRS的名词解释
SRS的名词解释软件需求规格说明书（Software Requirements Specification，简称SRS）是一个软件开发过程中非常关键的文件，用于详细描述和定义开发系统的需求。
本文将通过对SRS中一些常见名词的解释，展示SRS在软件开发中的重要性。
1. 需求需求是指用户对软件系统提出的要求或者期望。
需求可以分为功能需求和非功能需求两个方面。
- 功能需求：指系统需要完成的各项具体功能或者业务逻辑。
- 非功能需求：指系统的性能、安全、可靠性等方面的要求。
2. 可行性研究可行性研究是对软件开发项目进行初步评估的过程。
包括技术可行性、经济可行性和操作可行性三个方面。
- 技术可行性：考虑系统技术实现的可行性，是否有足够的技术手段和资源。
- 经济可行性：评估系统开发和运营的经济成本以及回报。
- 操作可行性：考虑系统在实际操作中的可行性，包括用户接受度、操作复杂度等。
3. 用户需求用户需求是指软件系统使用者提出的需求，可以通过市场调研、用户访谈等方式获取。
用户需求的准确把握对于后续的软件开发和用户满意度至关重要。
4. 功能点功能点是指软件系统中具有独立功能的最小单位。
通过对功能点的量化和统计，可以客观地评估软件系统的复杂度和开发进度。
5. 用例用例是指描述系统功能和用户交互的一种技术手段。
通过用例的编写，可以清晰地表达用户对系统的需求以及系统的响应。
6. 系统设计系统设计是指在需求分析的基础上，对软件系统进行总体架构的设计。
系统设计需要考虑系统的模块划分、接口设计以及数据流程等方面。
7. 验收测试验收测试是对软件系统开发完成后的一项重要测试工作。
通过对系统的功能性能进行测试，以确认系统是否符合用户需求并满足预期要求。
8. 风险分析风险分析是对软件开发过程中可能存在的风险进行评估和分析。
通过对潜在风险的识别和控制，可以减少项目进度延误和不可预测的风险。
9. 迭代开发迭代开发是软件开发中常用的一种开发模式。
软件需求工程选择题
选择题1。
软件生命周期包括哪些阶段?AA。
需求、设计、编码、单元测试、接收测试和维护阶段.B. 设计、编码、单元测试、接收测试和维护阶段。
C. 需求、设计、编码、单元测试和接收测试阶段.D。
需求、设计和编码阶段。
2。
好的软件需求具有哪些特性？AA. 一致性和全面性.B。
易读性和充分性。
C。
充分性。
D。
易读性。
3。
RUP的十大要素是：开发一个前景、达成计划、标识和减小风险、分配和跟踪任务、检查商业理由、设计组件构架、对产品进行增量式的构建和测试、验证和评价结果、_________和_________。
AA. 管理和控制变化及提供用户支持。
B. 迭代的开发和提供用户支持。
C. 迭代的开发和管理和控制变化。
D。
建立模版和迭代的开发.4。
下列哪个不是RUP的核心工作流？CA。
业务建模B。
分析和设计C。
用户需求了解。
D。
需求5.RAD的缺点不包括___D______。
A. 如果用户不能持续地参与整个生命周期中，最终产品会受到负面影响。
B。
要求系统能适当模块化,如果没有可重用的组件，它的效率就会下降。
C。
盲目应用时，会缺乏成本概念和项目完成的时间限制.项目有永远不能完结的风险. D。
工作重点从文档转为构建，所见即所得。
6。
螺旋模型的优点不包括____C______.A。
能够及时找到项目存在的风险,避免因为克服不了的困难而造成大的损失。
B。
使用户能够尽早将信息经常反馈给开发人员,保证了产品的正确性和高质量。
C。
大量的中间阶段会产生额外的内外部文档。
D。
可以方便地评估和验证每次迭代的成果；实现从开发到维护的无缝连接。
7。
迭代方法中的常见问题不包括___B________.A。
过分详细的规划B。
项目收敛C。
回避棘手问题D. 不同的小组按自己的进度进行工作8。
用户故事的书写遵循一定的原则,其中不包括___C_____.A. 作为（系统的一个涉众）B。
我想要（做一件事）C。
是什么（用户的需求是什么）D。
从而(达到一个商业价值）9.指出RUP的核心工作流不包括__D______。
需求规格说明书
需求规格说明书（SRS）是一份描述软件系统应该如何工作以及实现其目标的文件。
它是软件开发的起点，是所有后续工作的基础。
提供了对软件系统的全面和详细的描述，它可以被用来测试和验证软件系统是否符合用户和客户的要求。
1. 的重要性软件开发是一个复杂的过程，涉及到众多的环节。
在软件开发的最初阶段，需求的定义和规范非常关键。
如果需求没有被准确地定义或者规范，软件开发人员将无法构建一个能够满足客户要求的系统。
因此，的撰写非常关键。
它确立了软件系统的目标和意图，使软件开发团队能够更好地理解客户的需求和期望。
2. 的组成通常包括三个主要组成部分：用户需求、系统需求和设计需求。
用户需求是对系统功能和性能方面的描述。
它们是从用户的角度出发，描述了用户对系统提出的具体需求。
系统需求则是对软件系统特性、功能、数据结构、安全性、可靠性和性能等方面的描述。
最后一部分是设计需求，它描述了软件系统的内部设计、架构和接口。
3. 的编写步骤编写需要遵循一些特定的步骤。
首先，需要收集来自客户和最终用户的需求。
这些需求可以通过访谈、问卷调查和聚焦小组讨论等方式获取。
其次，需要将需求进行分类和分析。
这一步骤可以将需求细分为用户需求、系统需求和设计需求，并将它们排列为一个层次结构。
接下来，我们需要开始编写需求文档。
在编写时，需要使用一些特定的标准格式和术语，比如IEEE标准的SRS 样板。
最后，需要对需求文档进行审查和验收。
这一步骤非常重要，可以确保需求文档的准确性和完整性。
4. 的注意事项编写需要注意一些事项。
首先，必须完整、详细和准确。
它必须包含所有必要的细节和清晰的定义。
其次，必须可以测试。
这意味着，所有的需求都必须是可测量的，以便可以测试它们是否被满足。
第三，应该是可追溯的。
每个需求应该有一个独特的标识符，以便跟踪它们的进展。
此外，还应该记录和跟踪每个需求的状态。
最后，必须是易于理解的。
这意味着，它应该使用简单明了的语言、图表和表格。
srs工作过程的四个阶段
srs工作过程的四个阶段SRS（软件需求规格说明）是软件开发过程中的一个重要阶段，用于明确和记录用户对软件系统的需求。
SRS工作过程通常分为四个阶段，包括需求获取、需求分析、需求验证和需求管理。
第一阶段：需求获取（Requirements Elicitation）需求获取是SRS工作过程的起点，旨在从用户、业务代表等相关方获取关于软件系统的需求信息。
通过与用户交流、观察现存系统和相关文档的研究等方式，获取对软件系统功能、性能、可靠性和可维护性等方面的需求描述。
在需求获取阶段，软件工程师需要与用户充分沟通，确保完整获取和理解用户需求。
第二阶段：需求分析（Requirements Analysis）需求分析是对获取到的需求信息进行深入分析和理解的阶段。
在这一阶段，软件工程师需要对需求进行分类、组织和建模，形成可读、可交流和可验证的需求文档。
通常，需求分析会包括对功能需求的详细描述、非功能需求的定义、需求间的关系和优先级等方面的分析。
通过需求分析，软件工程师可以确保对需求的深入理解，并为后续的开发、测试和验收提供指导。
第三阶段：需求验证（Requirements Validation）需求验证是对已经分析的需求进行验证和确认的阶段。
在需求验证阶段，软件工程师需要与用户、业务代表和开发团队进行密切合作，确保需求的一致性、正确性和可实现性。
为了验证需求，可以使用各种技术，如原型开发、案例分析、需求评审和用户验收测试等。
通过需求验证，可以有效减少后续开发阶段中的需求变更和纠正。
第四阶段：需求管理（Requirements Management）需求管理是整个SRS工作过程中的最后一个阶段，旨在确保对需求的有效跟踪、变更控制和版本管理。
在需求管理阶段，软件工程师需要建立和维护需求跟踪表、变更控制文档和需求变更记录等文档。
此外，软件工程师还需要与各方进行沟通，及时更新和审核需求的变更。
需求管理的目标是确保需求的稳定和一致性，以提高软件开发的效率和质量。
软件设计师中的软件需求与规格
软件设计师中的软件需求与规格在软件设计师的工作中，软件需求与规格是至关重要的部分。
它们为软件开发过程提供了基础，并确保最终产品能够满足用户的期望和需求。
本文将探讨软件设计师中的软件需求与规格的重要性以及如何有效地进行需求分析和规格定义。
一、软件需求的定义与重要性软件需求是指在软件系统开发或改进的过程中，从用户、客户和利益相关者那里获得的对软件系统的功能、性能和约束的描述。
软件需求确定了软件系统的范围和目标，为开发团队提供了明确的方向。
正确理解和定义软件需求是软件开发成功的关键一步。
软件需求的定义包括功能需求、非功能需求和用户需求。
功能需求指软件系统应该具备的具体功能或功能组合，如登录、注册、数据查询等。
非功能需求指软件系统应具备的性能、可靠性、安全性等方面的要求，如响应时间、稳定性、数据保密等。
用户需求则是指用户对软件系统的期望和需求，例如用户友好的界面、易用性等。
软件需求的重要性在于它为开发过程提供了基础和指导。
准确的需求定义能够减少沟通误差，减少开发过程中的返工和修改，提高开发效率。
同时，合理的需求定义还能确保最终产品满足用户的期望，提升用户满意度。
二、软件需求分析与规格定义的过程软件需求分析和规格定义是软件设计师进行的关键步骤，它们涉及到对用户需求和系统约束的深入理解和准确描述。
1. 需求收集与分析需求收集是软件设计师与用户、客户和利益相关者进行沟通和交流的过程。
通过开会、调研、面谈和问卷调查等方式，收集到用户的期望和需求。
了解用户需求的背后的目标和关注点，帮助设计师更好地理解需求的本质。
在需求分析阶段，设计师需要将用户需求进行整理和分类，以便更好地进行后续规格定义工作。
可以采用需求分类矩阵、用例图等工具进行需求归纳和整理。
2. 规格定义与规格书编写在需求分析的基础上，软件设计师需要编写详细的规格书，将需求转化为明确的规格定义。
规格书应该包含功能需求、非功能需求以及用户需求的具体描述和要求。
软件工程需求分析
软件工程需求分析
首先，需求获取是需求分析的基础。
开发团队需要与用户沟通，了解用户的实际需求。
可以通过面对面的会议、问卷调查或者用户需求收集工具等方式进行需求获取。
在这个过程中，开发团队需要主动询问用户的需求，以确保他们完全理解用户的期望。
其次，需求分析需要准确明确的目标。
开发团队需要对需求进行分类和排序，以确定哪些需求是最重要的。
在确定需求优先级时，开发团队可以考虑与用户合作确定，也可以参考相似项目的经验。
接下来，需求分析需要制定合适的文档。
在需求分析的过程中，开发团队需要编写软件需求规格说明书(SRS)，以记录各种需求详细信息。
这样的文档需要描述软件的功能需求、性能需求、安全需求以及其他非功能性需求。
编写完整的文档可以确保需求准确传达给开发团队。
此外，需求分析需要广泛的共享和讨论。
开发团队需要与利益相关者进行定期的讨论和交流，以确保需求的理解和沟通。
这样可以在早期的开发阶段发现并解决潜在的问题或错误，降低开发风险。
最后，需求分析需要反馈和验证。
开发团队在开发过程中需要持续地与用户沟通，获取用户的反馈。
这样可以及时调整需求和开发方向，保证软件的质量和用户满意度。
总的来说，软件工程需求分析是软件开发过程中至关重要的一环。
它需要开发团队与用户密切合作，准确获取和理解用户需求。
通过制定合适的文档和定期的讨论，可以确保需求清晰明确并得到广泛共享。
同时，持续的反馈和验证可以及时修正需求和开发方向，提高软件的质量。
SRS工作原理范文
SRS工作原理范文Software Requirements Specification (SRS)，即软件需求规格说明，是软件开发过程中最关键、最重要的一步。
它提供了开发团队和用户之间进行有效沟通的基础，确保开发出一个符合用户需求并可靠、可维护的软件系统。
SRS的工作原理主要包括以下几个方面：1.需求收集和分析：SRS的第一步是收集用户需求。
这可以通过面对面的会议、访谈、问卷调查、用户故事等方式进行。
收集到的需求被记录下来，并进行分析和整理，以便后续的规格说明。
需求分析的目标是确保完整性、准确性和一致性。
2.明确需求：将收集到的需求进行整理和分析后，需要明确需求的主要功能点、性能要求、界面设计以及各种约束条件等。
这些将被写入规格说明中，以便开发团队了解用户的真正需求。
在确定需求时，与用户进行交流和确认也是很重要的一步。
3.编写规格说明书：此阶段是开发团队将整理和分析到的需求编写成规格说明书的过程。
规格说明书是一个详细的文档，用于描述软件的功能、特性、性能和约束条件等。
它通常包括功能需求、非功能需求、用户界面设计、系统设计、性能需求、验收标准等内容。
规格说明书的编写需要遵循一定的结构，以便开发团队和用户能够按照其内部进行理解和执行。
4.审查和验证：为了确保规格说明书的准确性和可行性，开发团队和用户需要对其进行审查和验证。
这可以通过专门的会议、面对面的讨论、邮件往返等方式进行。
审查和验证的目标是确保规格说明书的一致性、可靠性和可行性。
5.变更管理：在开发过程中，需求可能会发生变化。
为了确保开发团队能够跟进这些变化并进行相应调整，需要建立一套变更管理的机制。
这意味着任何变更都必须经过审查和评估，并在变更被认可后，及时更新规格说明书。
6.追踪和跟踪：在软件开发过程中，开发团队需要跟踪和跟进规格说明书中记录的需求。
这可以通过追踪系统、版本管理工具、会议讨论等方式进行。
追踪和跟踪的目的是确保开发团队了解项目的当前状态，并及时更新规格说明书以适应项目的变化。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
需求分析中需求规格SRS的非功能性需求的考虑因素
* 功能性质量因素：正确性，健壮性，可靠性
* 非功能性质量因素：性能，易用性，清晰性，安全性，可扩展性，兼容性，可移植性正确性
* 正确性是指软件按照需求正确执行任务的能力。
“正确性”的语义涵盖了“精确性”。
* 正确性无疑是第一重要的软件质量属性。
* 技术评审和测试的第一关都是检查工作成果的正确性。
* 机器不会主动欺骗人，软件运行出错通常都是人造成的，所以不要找借口埋怨机器有毛病。
健壮性
* 健壮性是指在异常情况下，软件能够正常运行的能力。
* 正确性描述软件在需求范围之内的行为，而健壮性描述软件在需求范围之外的行为。
* 开发者往往把异常情况错当成正常情况而不作处理，结果降低了健壮性。
* 用户才不管正确性与健壮性的区别，反正软件出了差错都是开发方的错。
所以提高软件的健壮性也是开发者的义务。
* 健壮性有两层含义：一是容错能力，二是恢复能力。
可靠性
* 可靠性是指在一定的环境下，在给定的时间内，系统不发生故障的概率。
* 可靠性本来是硬件领域的术语。
比如某个电子设备在刚开始工作时挺好的，但由于器件在工作中其物理性质会发生变化（如发热），慢慢地系统的功能或性能就会失常。
所以一个从设计到生产完全正确的硬件系统，在工作中未必就是可靠的。
* 软件在运行时不会发生物理性质的变化，人们常以为如果软件的某个功能是正确的，那么它一辈子都是正确的。
可是我们无法对软件进行彻底地测试，无法根除软件中潜在的错误。
平时软件运行得好好的，说不准哪一天就不正常了，如有千年等一回的“千年虫”问题，司空见惯的“内存泄露”问题、“误差累积”问题等等。
* 时隐时现的错误一般都属于可靠性问题，纠错的代价很高。
性能
* 性能通常是指软件的“时间-空间”效率，而不仅是指软件的运行速度。
人们总希望软件的运行速度高些，并且占用资源少些。
* 性能优化的关键工作是找出限制性能的“瓶颈”
* 可以通过优化数据结构、算法和代码来提高软件的性能。
易用性
* 易用性是指用户使用软件的容易程度。
* 现代人的生活节奏快，干啥事都想图个方便。
所以把易用性作为重要的质量属性对待无可非议。
* 导致软件易用性差的根本原因：
o 理工科大学教育存在缺陷：没有开设人机工程学、美学、心理学这些必修课，大部分开发人员不知道如何设计易用的软件产品。
o 开发人员犯了“错位”的毛病：他以为只要自己用起来方便，用户也就会满意。
* 软件的易用性要让用户来评价。
当用户真的感到软件很好用时，一股温暖的感觉油然而生，于是就用“界面友好”、“方便易用”等词来评价软件产品。
清晰性
* 清晰意味者所有的工作成果易读、易理解，可以提高团队开发效率，降低维护代价。
* 开发人员只有在自己思路清晰的时候才可能写出让别人易读、易理解的程序和文档。
* 可理解的东西通常是简洁的。
一个原始问题可能很复杂，但高水平的人就能够把软件系统设计得很简洁。
如果软件系统臃肿不堪，它迟早会出问题。
所以简洁是人们对工作“精益求精”的结果，而不是潦草应付的结果。
* 千万不要把在学校里“造文章”的手法用于开发产品！
安全性
* 这里安全性是指信息安全，英文是Security而不是Safety。
* 安全性是指防止系统被非法入侵的能力，既属于技术问题又属于管理问题。
* “道高一尺，魔高一丈” ，绝对安全的信息系统几乎不存在。
* 开发商和客户愿意为提高安全性而投入的资金是有限的，他们要考虑值不值得。
* 究竟什么样的安全性是令人满意的呢？
o 一般地，如果黑客为非法入侵花费的代价（考虑时间、费用、风险等因素）高于得到的好处，那么这样的系统可以认为是安全的。
可扩展性
* 可扩展性反映软件适应“变化”的能力。
* 在软件开发过程中，“变化”是司空见惯的事情，如需求、设计的变化，算法的改进，程序的变化等等。
由于软件是“软”的，是否它天生就容易修改以适应“变化”？关键要看软件的规模和复杂性。
* 现代软件产品通常采用“增量开发模式”，不断推出新版本，获取增值利润。
可扩展性越来越重要。
可扩展性是系统设计阶段重点考虑的质量属性。
兼容性
* 兼容性是指两个或两个以上的软件相互交换信息的能力。
* 兼容性的商业规则：弱者设法与强者兼容，否则无容身之地；强者应当避免被兼容，否则市场将被瓜分。
示例：
o 中国联通和中国移动的手机互联互通问题
o 金山软件公司的WPS与微软的Word之争
可移植性
* 可移植性是指软件运行于不同软硬件环境的能力
* 编程语言越低级，其程序越难移植，反之则容易。
软件设计时应该将“设备相关程序”与“设备无关程序”分开，将“功能模块”与“用户界面”分开。