软件需求分析评审表
项目管理软件选型评审表
参与部门: 演示单位： 产品名称： 姓名 Nhomakorabea 日期:
（10分：非常好；8分：好；6分：及格，4: 较差 2: 差 0:非常差）
1、软件流程是否合理？与业务流程相似度如何？流程是否能自定义？
2、数据完整性，工作界面的字段信息是否完整？界面字段是否能可配置？
3、易用性，用户操作是否方便？界面是否友好？ （例如：字体大小；字体颜色；界面长时间观看是否容易疲劳；数据录入是否方便）
10、产品的品牌效应及口碑（在国际及国内的产品美誉度）
11、对该软件产品的其他要求及建设性意见
4、软件系统集成性，是否能和其他业务系统对接？ （财务K3系统，单点登录等）
5、数据展示，系统已有查询、报表和统计分析功能是否完整？ 是否满足业务要求？
6、可维护性，用户是否能自己对查询、报表及统计报表进行增加或修改？是否需要软件 公司的定制开发？
7、系统部署方式及部署周期
8、系统购置及实施费用
9、系统开发的平台、数据库及硬件要求；
软件功能需求分析表
软件功能需求分析表1.引言本文档旨在对软件功能需求进行详细分析，以确保软件开发团队对于开发的软件具备清晰的理解。
本文档将梳理用户需求并将其转化为软件功能需求的具体描述，为软件开发的下一阶段提供有效的指导。
2.背景在进行软件功能需求分析之前，我们需要明确软件的背景信息。
本软件是一款面向企业管理的综合软件，旨在提升企业管理效率、优化流程，并提供实时可视化数据分析。
软件主要应用于中小型企业，覆盖人力资源管理、财务管理、销售管理等多个功能模块。
3.用户需求基于对用户需求的深入调研和访谈，我们总结出以下用户需求：3.1 人力资源管理- 员工信息管理：包括员工基本信息、薪资信息、考勤记录、绩效评估等。
- 招聘管理：支持发布招聘岗位、管理应聘者信息、安排面试等。
- 培训管理：提供培训计划、培训材料、培训成绩记录等功能。
3.2 财务管理- 资金管理：包括银行账户余额、收支记录、费用报销等。
- 会计管理：支持录入和管理帐务凭证、科目余额表、利润表等。
- 税务管理：提供税务申报、税务审计、税务报表等功能。
3.3 销售管理- 客户管理：包括客户基本信息、联系记录、销售机会管理等。
- 销售订单管理：支持销售订单的录入、审核、发货、关联收款等。
- 销售数据分析：提供销售额统计、客户分析、销售趋势图等功能。
4.功能需求描述在明确了用户需求后，我们将其转化为具体的功能需求描述，以便开发团队进行开发和测试。
4.1 人力资源管理4.1.1 员工信息管理- 支持录入、修改和查询员工的基本信息，包括姓名、性别、年龄、联系方式等。
- 薪资信息管理：可记录员工的薪资变动情况，并提供薪资计算和发放功能。
- 考勤管理：支持记录员工的上下班打卡记录，统计工时和考勤异常情况。
- 绩效评估：提供员工绩效评估模板，支持评估记录和统计分析。
4.1.2 招聘管理- 岗位发布：管理员工发布招聘岗位信息，并提供招聘描述、薪资待遇等详细信息。
- 应聘者管理：支持记录应聘者的基本信息，并提供筛选、面试安排等功能。
软件设计评审表-模板
引用的文档现行有效
3
文档编写的内容、格式符合相关标准、规定的要求
4
文档签署完整
完整性
5
文档有独立的版本说明部分
6
有文档的文字目录页
7
有总体设计部分
8
有功能设计
9
有接口设计
10
有性能设计
追溯性
11
设计是否可以追踪到需求
12
需求是否可追溯到设计
符合性
13
是否每个设计都是可测试的或以别的方式可以确定的
14
9
用户接口是否模块化，并且修改时不影响其他程序
10
是否提供了一致的错误处理机制
11
各子系统、模块之间的关系是否描述得清楚
12
系统的设计是否考虑了系统的可扩展性
13
设计是否考虑了重用性
14
重用构件是否进行了标识
15
是否说明了重用模块的获得方式和相关的文档
16
系统的设计是否考虑了系统的易移植性
17
设计是否使用标准的技术，避免使用怪异的、不易理解的方式和方法
设计范围、边界是否清晰，文档中是否清晰阐明了系统的各项特性及预期的结果
15
逻辑性、算法和处理过程是否正确
16
文档是否符合客户的需要
17
设计是否考虑到未来的扩充性
18
设计的系统是否易于维护
评审项目
详细设计说明书
评审日期
评审结果标记
合格不合格TBD待完成 NA 不适用
评审情况
18
设计的调用宽度、调用深度、耦合度、内聚度和结构化程序是否进行了描述
追溯性
19
设计是否可以追踪到需求
20
软件需求规格说明书的评审检查单
软件需求规格说明书的评审检查单软件需求评审，作为一种软件产品验证的活动之一，通过及早地从软件产品中识别并消除缺陷，从而减少后期的返工，加快开发进度，提高产品的质量。
在需求阶段，发现一个需求缺陷的价值是多大呢？业内有个缺陷修复成本比例，需求阶段：设计阶段：测试阶段：上市阶段＝N：10N：100N：1000N；方案一一、注意对需求规格说明的正确性进行评审需求规格说明的正确性通常可以从如下方面得以体现：1是否有需求与其他需求相互冲突或者重复？2是否清晰、简洁、无二义地表达了每个需求?“清晰”是让人能够读懂；“简洁”是让人愿意去读；“无二义”决定”读”的效果,是让大家对需求描述的理解能够达成一致。
3是否每个需求都通过了演示、测试、评审，分析是否得到了验证?4是否每个需求都在项目的范围内?5是否每个需求都没有内容和语法上的错误?6在现有的资源内,是否能实现所有的需求?7每一条特定的错误信息，是否都是唯一的和具有含义的?二、注意对需求规格说明的实践性进行评审所谓实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度,而非源于分析师们经验主义的臆测。
实践性是判断需求规格说明是不是理论联系实践、密切和用户联系的一个关键性指标。
三、注意对需求规格说明的完整性进行评审我们经常由下面的问题清单来评审需求说明书是否”完整”。
1编写的所有需求，其详细程度是否一致和合适?2需求是否能为设计提供足够的基础?3所有对其他需求的内部引用是否正确?4是否包含了每个需求的实现优先级?5是否定义了功能说明的内在算法?6是否包含了所有已知的客户需求或系统需求?7是否遗漏了必要的信息?如果有遗漏的话,把他们标记为待确定的问题(TBD) ?8是否对所有预期的错误条件所产生的系统行为都编制了文档?需求说明的完整性主要体现在需求说明的详细程度上，我们怎样判断该需求的描述是否详细呢?我认为需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应，等等。
软件功能需求分析表
软件功能需求分析表(标题) 软件功能需求分析表(正文)软件功能需求分析表是一种重要工具，用于确定软件系统各项功能的详细要求。
通过对用户需求的分析和理解，我们可以将功能需求具体化，并制定相应的解决方案。
本文将就软件功能需求分析表的结构、内容和使用方法进行介绍，并论述其重要性和作用。
1. 简介软件功能需求分析表旨在整理并详细记录软件系统的各项功能需求。
它是软件开发过程中的关键文档之一，对于项目的成功实施和用户满意度至关重要。
通过该表，可以清晰明确地定义软件系统的功能范围，并为开发人员提供明确的指导。
2. 结构和内容软件功能需求分析表通常包含下列重要内容：(1) 项目概述：对软件系统的背景、目标和预期效果进行简要说明。
(2) 参与方角色：列出项目中各个参与方的角色和职责，明确他们对软件系统的期望。
(3) 功能需求：将软件系统的各项功能需求一一列出，并进行详细描述。
例如，对于一个电商平台，功能需求可能包括用户注册、商品浏览、购物车管理等。
(4) 功能优先级：对每一项功能需求进行优先级排序，明确功能的重要程度和开发优先顺序。
(5) 使用案例：根据功能需求，编写用户使用软件系统的典型案例，并列出每个案例所需的功能。
(6) 非功能需求：除了功能需求外，还要考虑软件系统的非功能需求，如性能、安全性、可维护性等方面的要求。
(7) 接口需求：确定软件系统需要与外部系统或硬件设备进行集成的接口要求。
(8) 数据需求：明确软件系统使用的相关数据，包括输入、输出、存储和处理等方面的要求。
(9) 约束条件：列出对软件开发和实施过程中的各项约束条件，如时间、成本、技术限制等。
(10) 附录：列出与软件功能需求相关的补充信息，如参考资料、图表或其他附加说明。
3. 使用方法软件功能需求分析表不仅是一个文档，更是一个工具，它能够指导项目团队进行软件开发的各个阶段。
在实际使用中，可以按照以下步骤进行：(1) 收集需求：与用户、业务分析师等沟通，了解需求并进行收集。
软件功能需求分析表
软件功能需求分析表一、引言软件功能需求分析表是一种用于梳理和记录软件项目中各个功能需求的工具。
通过这个表格，可以清晰地了解项目中所需的各种功能，便于开发人员理解和实现软件系统的具体要求。
本文将详细介绍软件功能需求分析表的结构和使用方法，并给出一个具体案例。
二、软件功能需求分析表结构软件功能需求分析表通常包含以下几个关键部分：1. 功能模块在这一部分列出软件系统中各个功能模块的名称，每个功能模块可以是系统的一个子系统或是一项独立的功能。
2. 功能描述对于每个功能模块，在功能描述栏中详细描述该功能模块的具体功能和特点。
描述要尽量准确、清晰，避免模棱两可或重复。
3. 输入需求针对每个功能模块，明确列出该功能模块所需要的输入数据，包括数据的类型和格式等。
4. 输出需求对于每个功能模块，明确列出该功能模块的输出结果，包括数据的类型和格式。
5. 功能优先级根据项目的需求和重要性，对每个功能模块进行优先级排序。
常见的优先级可以分为高、中、低三个等级。
6. 测试要求在实现功能模块后，针对该功能模块需要进行的测试项进行记录，包括功能测试、性能测试等。
7. 备注对于每个功能模块存在的特殊要求或其他需要说明的事项，可以在备注栏中进行描述。
三、使用方法在实际使用软件功能需求分析表时，我们可以按照以下步骤进行：1. 确定功能模块根据项目需求和系统设计，明确需要包含哪些功能模块，并在表格中添加对应的行。
2. 描述功能模块针对每个功能模块，仔细分析其功能和特点，并在表格中填写相应的功能描述。
3. 确定输入和输出需求根据功能模块的功能描述，确定该功能模块所需的输入数据和输出结果，并填写在表格中。
4. 设置功能优先级根据项目需求和重要性，为每个功能模块设置相应的优先级，填写在表格中。
5. 确定测试要求根据功能模块的具体功能和特点，确定相应的测试要求，并记录在表格中。
6. 添加备注对于功能模块存在的特殊要求或其他需要说明的事项，可以在表格的备注栏中进行记录。
需求分析评审记录表
会议室
主持人
XXX
参加部门及人员
A部门：李xxx;
评审内容
1．无歧义性
2．完整性
3．可验证性
4．一致性
5．可使用性
6．符合《需求分析报告编写规范》的要求
评审过程综述
分析人员要在用户和软件设计人员的配合下对自己生成的需求规格说明和初步的用户手册进行复核，同时向参与评审的成员对要开发系统的目标性、功能性以及操作性方面进行简要的介绍，评审成员依据自己的理解提出不同意见，这样才能确保软件需求的完整、准确、清晰、具体，最终使用户和软件设计人员对需求规格说明和初步的用户手册的理解达成一致。一旦发现遗漏或模糊点，必须尽快更正，再行检查。
评审结论
通过评审，可以进入下一阶段
改进、纠正和
预防措施及
责任部门
1．分析人员收集评审数据，记录评审结果。
2．做好评审后的跟踪工作。
3．记录需求经评审后改动的部分，如实现优先级、加入和裁减了哪些。
编制：崔xx审核：宋xx批准： 日期：2020.07.10
软件需求说明书评审检查单
37 内部交叉引用是否正确、明确（读者应能在1分钟之内定位被引用的内容）？ 38 外部引用是否正确、明确（具有权限的读者应能在10分钟之内定位被引用的内容）？ 可追踪性 39 使用的图片是否是“嵌入型”的而不是其它如“浮于文字上方”？ 40 与需求相关的表格的使用是否符合要求（即不可以使用n (2 =< n < 全部) 个单元格描述 一个需求）？ 其它 41 已经描述的、本文涉及的术语、定义及缩略语正确、完整？ 42 是否已可基于需求进行设计？ 43 是否已可基于需求进行系统测试方案及系统测试用例的编写？ 44 是否已可基于需求编写用户类文档（初稿）？ 45 是否考虑了初始状态和特殊状态（例如：冷启动、异常终止）？
功能需求需要满足的公共检查项 1 需求描述中是否未遗漏“业务规则”？（业务规则（或逻辑）是指操作规则，如“操作 的先后次序”、“什么人在特定环境下可以进行何种操作”、合法性/一致性定义等）
2 功能需求中是否描述了必须的特殊需求？ 3 功能需求的所有输入是否都是必需的，而且足够满足执行要求操作的需要？ 4 是否详细罗列了功能需求的输出内容（如顺序、排序、结果对应的条件等）？这些结果 是否都是必然的（即是否多或少了输出）？
14 对于满足软件的目标来说，功能需求是否足够？ 15 对于满足软件的目标来说，性能需求是否足够？ 16 对于满足软件的目标来说，质量属性需求是否足够？ 17 对于满足软件的目标来说，外部接口需求（外部接口需求可能单独成文。下同。评审时 应一道评审）是否足够？
18 对于满足软件的目标来说，标准化要求是否足够？ 19 对于满足软件的目标来说，设计和实现于满足软件的目标来说，国际化需求是否足够？ 22 模板编写指导中列出的内容是否都有所体现？（如果文档中基本没有编写指导中列出需 要考虑的内容，则该需求说明书可能是不完整的）
软件功能需求分析表
软件功能需求分析表在软件开发过程中，功能需求分析是至关重要的一步。
它有助于明确软件的功能和特性，确保开发团队明白用户和系统之间的期望和要求。
本文将针对软件功能需求进行分析，以期将这一过程更加合理化和有序。
一、背景介绍在开始软件功能需求分析之前，有必要对软件项目进行一些背景介绍。
这部分内容可以包括软件的名称、发展背景、所属领域和目标用户等。
二、需求概述软件功能需求的概述部分应该对开发团队和用户清晰地描述软件的功能需求。
这一部分可以按照不同的功能模块进行分述，确保内容的逻辑性和条理性。
1. 功能模块一功能模块一的描述应该包括以下内容：- 功能名称- 功能描述- 功能的重要性和优势- 功能的实现方式- 功能的输入和输出2. 功能模块二功能模块二的描述也应包含以上相同的内容。
可以根据实际软件的需求，合理增加或修改功能模块的数量。
三、详细需求分析在需求概述的基础上，我们需要对每个功能模块进行更加详细的需求分析。
这一部分的目的是确保所有功能的具体需求都得到了准确的描述和分析。
1. 功能模块一详细需求分析在这部分，我们可以对功能模块一的需求进行更加具体的描述和分析。
可以采用文字描述、流程图、用例图等方式，以便开发团队更好地理解需求。
2. 功能模块二详细需求分析同样地，这一部分应着重对功能模块二的需求进行详细的描述和分析。
确保开发团队能够清楚地了解每个功能模块的需求。
四、其他需求除了功能需求分析，软件开发过程中还会有其他类型的需求。
这些需求可能包括性能需求、安全需求、可维护性需求等。
在这一部分，我们将简要列举一些相关的需求。
1. 性能需求- 软件的响应时间限制- 数据库读写速度要求2. 安全需求- 用户权限管理- 数据加密要求3. 可维护性需求- 易于维护和升级的软件设计- 结构清晰的代码注释五、总结本文对软件功能需求分析进行了详细的介绍。
通过背景介绍、需求概述、详细需求分析和其他需求的讨论，可以确保开发团队和用户对软件的功能需求有清晰的了解。
OA-项目阶段评审表-1-软件需求评审报告
OA-项目阶段评审表-1-软件需求评审报告OA系统 1.0软件需求评审报告文件控制文档编号分册名称?受控?不受控O A-1701 版本号附录1.0O A项目开发-软件需求评审报告第1册/共1册总页数编制6页正文审批4页无江华谭璨生效日期2014/02/25修改变更记录：更改条款及内容更改人审批人更改日期1.0 江华谭璨2014/02/25声明在软件开发过程中的适当阶段对软件阶段产品进行评审，是确保软件产品最终质量的重要方法。
阶段评审可以对某个开发阶段的阶段产品进行评审，也可以对某几个开发阶段的阶段产品进行综合评审。
在每次阶段评审中，必须履行正式手续，填写必要的评审表格，以利于项目管理工作，利于产品验收时的质量检查工作。
项目阶段评审表由三张子表组成，表 1是对评审中指标问题记录RPL(review problem log)；表2是评审总结报告RSR(review summary report)；表3是评审小组成员登记与签字表。
表1 评审问题记录（RPL ）1 登记号2014/2/25 RPLOA 系统项目评审问题记录评审日期评审性质项目编号评审√复审□1 项目名编号 OA 系统项目问题摘要问题类型是否解决文档结构检验是文档内容结构问题1 2 与规范的一致性与规范的一致性知识产权问题是是是与合同约定的开发范围一致性与合同附件的一致性 3 是否有知识产权问题 4 文档覆盖程度检查是文档覆盖程度检查是文档覆盖程度检查是文档覆盖程度检查是文档覆盖程度检查是文档覆盖程度检查是文档覆盖程度检查是文档覆盖程度检查是是否满足系统设计阶段的需要是否满足客户方需求验证过程的需要是否满足测试方案与用户手册编写需要是否包括所有业务部门的所有需求是否包括企业领导者的所有需求是否包括 IT 部门的所有需求 5 6 7 8 9 10 11 12 13 是否包括企业其他用户的所有需求是否描述了系统的使用与维护限制条件数据，接口，性能等重要任务是否描述清晰。
软件功能需求核对表
软件功能需求核对表一、用户界面1、整体布局界面是否简洁、直观，易于操作？各功能模块的布局是否合理，符合用户的使用习惯？2、导航导航菜单是否清晰明确，易于找到所需功能？页面之间的跳转是否流畅，没有卡顿或错误？3、输入和输出输入框的格式和验证规则是否正确？输出的信息是否清晰、准确、易于理解？4、响应式设计在不同的设备（如电脑、平板、手机）上显示是否正常？界面是否能够自适应不同的屏幕尺寸和分辨率？二、功能模块1、登录/注册登录和注册流程是否简单快捷？密码强度要求和验证机制是否合理？2、个人资料管理用户能否方便地修改个人信息？个人信息的安全性和隐私保护措施是否到位？3、数据录入支持的数据类型是否齐全（如文本、数字、日期等）？数据录入的效率和准确性如何？4、数据查询查询条件设置是否灵活？查询结果的显示是否准确、完整？5、数据编辑能否对已有的数据进行修改和删除操作？数据编辑的权限控制是否合理？6、数据导出/导入支持的数据格式是否满足需求？导出/导入过程是否稳定，数据是否完整？7、报表生成报表的种类和格式是否符合业务需求？报表的数据准确性和及时性如何？8、通知提醒是否能够及时向用户发送重要的通知和提醒？通知的方式（如邮件、短信、弹窗）是否可配置？三、性能和稳定性1、响应时间主要操作的响应时间是否在可接受的范围内？在高并发情况下，系统的性能是否稳定？2、资源占用软件运行时对 CPU、内存等资源的占用是否合理？是否存在内存泄漏等问题？3、错误处理对各种可能的错误（如网络错误、数据库错误等）是否有恰当的处理机制？错误提示信息是否清晰、易懂，能够帮助用户快速解决问题？4、兼容性软件是否兼容主流的操作系统和浏览器？与其他相关软件（如办公软件、杀毒软件等）的兼容性如何？四、数据安全1、用户认证和授权用户的身份认证机制是否安全可靠？不同用户的权限划分是否明确，能否有效防止越权操作？2、数据加密敏感数据（如用户密码、财务数据等）是否进行了加密存储和传输？加密算法的强度是否足够？3、备份和恢复是否有定期的数据备份计划？数据恢复的流程是否简单、可靠？4、安全审计系统是否记录了用户的操作日志，以便进行安全审计？审计日志的保存时间和查询方式是否满足要求？五、用户体验1、操作流程软件的操作流程是否简单、流畅，没有繁琐的步骤？用户能否快速上手并熟练使用软件？2、帮助文档是否提供了详细的帮助文档和操作指南？帮助文档的内容是否准确、清晰，易于查找？3、反馈机制用户能否方便地向开发团队反馈问题和建议？对用户的反馈是否能够及时处理和回复？六、可扩展性1、架构设计软件的架构是否具有良好的可扩展性，便于后续功能的添加和修改？技术选型是否考虑了未来的发展趋势？2、接口设计对外提供的接口是否规范、易于集成？接口的参数和返回值是否清晰明确？七、测试用例1、功能测试是否覆盖了所有的功能需求，包括正常流程和异常流程？测试用例的执行结果是否符合预期？2、性能测试性能测试的场景是否具有代表性？测试结果是否满足性能指标要求？3、安全测试安全测试是否发现了潜在的安全漏洞？对发现的安全漏洞是否有有效的修复措施？4、兼容性测试兼容性测试的覆盖范围是否全面？在不同的环境下软件的运行是否稳定？八、其他1、法律法规合规性软件的功能和数据处理是否符合相关的法律法规要求？如涉及隐私政策，是否明确、合规？2、成本和预算开发软件的成本是否在预算范围内？后续的维护和升级成本是否可承受？3、项目进度软件的开发进度是否符合项目计划？是否存在影响项目进度的风险和问题？。
软件项目设计评审检查表
技能水平及其他因素？
1.3
系统架构是否考虑了性能、安全、可扩展 、维护性等因素
1.4
系统架构是否有利于充分发挥现有硬件资 源的效能？
系统架构是否有利于在应用环境中的部
1.5
署？是否有利于系统管理员进行管理、维
护？
各个层的划分是否合理，各个层之间是否
1.6
有清晰的功能划分？是否符合主流的分层 规则（界面、业务逻辑、业务对象、数据
3.15 表或实体设计命名是否符合规范？
4
界面设计
是否描述项目所需要实现的各种典型界面
4.1
并给出界面demo？
是否遵循软件界面设计指南的要求？界面
4.2
风格的美学要求？
界面操作是否足够的人性化，能够获得交 好的用户体验？ 4.3
版本号：2 修订号：0
第3页 共3页
访问等）？
系统功能模块的划分是否合理，是否符合
1.7
用户的实际业务操作方式？是否与用户的
岗位分工保持一致？
1.8
每个模块的功能、职责是否定义清楚？
1.9
各个模块的接口（通信界面）是否定义清 楚，以利于与其它系统的交互以及集成？
1.10
是否充分考虑到架构或组件的复用。
1.11
是否充分考虑了系统实现技术上的风险和 解决办法？
2
模块设计
版本号：2 修订号：0
缺陷描述第1页 共3页 Nhomakorabea 2.1
功能模块的设计文字说明是否清晰，比 较好的表达问题？
界面类设计布局及界面包含元素是否合
理，界面的显示或功能操作是否涵盖对
2.2
应的模块功能？是否能够满足人机交互 的友好性？界面类是否耦合了业务逻辑
软件需求分析评审检查单
软件评审记录
工程代号 项目名称
评审日期
年月日
评审性质
序
评审项目
合格 不合格 不适用
号
1. 文 档 文档齐全
2. 规范 文档编制规范
需求分析方法 3.
工具使用正确
4.
软 件 功能需求
5.
需 求 性能要求
6.
ቤተ መጻሕፍቲ ባይዱ
内容 接口要求
7.
完整、 数据要求
8. 软件 正确 环境要求
9. 需求 软 件 实时性需求
计划
22.
验证计划安排明确、合理可行
23.
确认计划安排明确、合理可行
24. 软件质量保证计划明确、完整
25. 软件 测试的范围和内容明确
26. 配置 测试结果评价准则明确、可行
项 测 测试的组织、人员、进度安排
27. 试计 合理、明确
划
评审 □ 复审 □ 备注
10. 规格 需 求 正确性要求
11. 说明 合理、 完备性要求
12.
可行 一致性要求
13.
无二义性要求
14.
可验证性要求
15.
可追踪性要求
16.
可靠性要求明确
17.
数据安全和保密要求明确
18.
阶段划分明确
19.
计划安排明确、合理、可行
软件
20.
软件配置管理要求明确
开发
21.
安全计划安排明确、合理可行
软件需求评审记录表
软件需求评审记录表项目名称：评审人：时间：1、兼容性界面需求是否使软硬件系统具有兼容性？2、完备性需求定义是否包含了有关文件（指质量手册、质量计划以及其他有关文件）中所规定的需求定义所应该包含的所有内容？需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有需求？功能性需求是否覆盖了所有非正常情况的处理？是否已对各种操作模式（如正常、非正常、有干扰等）下的环境条件都作规定？是否识别出了所有与时间因素有关的功能？它们的时间准则是否都明了？时间准则的最大、最小执行时间是否都定义了？是否识别定义了在将来可能会变化的需求？是否定义了系统的所有输入？是否标识清楚了系统输入的来源？是否识别了系统的输出？是否说明了系统输入、输出的类型？是否说明了系统输入、输出的值域、单位、格式等？是否说明了如何进行系统输入的合法性检查？是否定义了系统输入、输出的精度？在不同负载情况下，系统的生产率如何？在不同的情况下，系统的响应时间如何？系统对软件、硬件或电源故障必须作什么样的反应？是否充分定义了关于人机界面的需求？3、一致性各个需求之间是否一致？是否有冲突和矛盾？所规定的模型、算法和数值方法是否相容？是否使用了标准术语和定义形式？需求是否与其软硬件操作环境相容？是否说明了软件对其系统和环境的影响？是否说明了环境对软件的影响？4、正确性需求定义是否满足标准的要求？算法和规则是否有科技文献或其它文献作为基础？有哪些证据说明用户提供的规则或规定是正确的？是否定义了对在错误、危险分析中所识别出的各种故障模式和错误类型所需的反应？是否参照了有关标准？是否对每个需求都给出了理由？理由是否充分？对设计和实现的限制是否都有论证？5、可行性需求定义是否使软件的设计、实现、操作和维护都可行？所规定的模式、数值方法和算法是否对待解问题合适？是否能够在相应的限制条件下实现？是否能够达到关于质量的要求？6、易修改性对需求定义的描述是否易于修改？例如是否采用良好的结构和交叉引用表等等？是否有冗余的信息？是否一个需求被定义多次？7、健壮性是否有容错的需求？8、易追溯性是否可以从上一阶段的文档查找到需求定义中的相应内容？需求定义是否明确地表明前阶段中提出的有关需求的设计限制都已被覆盖？例如，使用覆盖矩阵或交叉引用表？需求定义是否便于向后继开发阶段查找信息？9、易理解性是否每一个需求都只有一种解释？功能性需求是不是以模块方式描述的，是否明确地标识出其功能？是否使用了形式化或半形式化的语言？语言是否有歧义性？需求定义是否只包含了必要的实现细节而不包含不必要的实现细节？是否过分细致了？需求定义是否足够清楚和明确使其已能够作为开发设计规约和功能性测试数据基础？需求定义的描述是否将对程序的需求和所提供的其它信息分离开来? 10、易测试性和可验证性需求是否可以验证？是否对每一个需求都指定了验证过程？数学函数的定义是否使用了精确定义的语法和语法符号？11、评审意见：（通过、不通过）注：前10条的所列的各小条目，都以（是/否）记录。
软件设计评审检查表
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
可维护性
单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任 何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
是否在内存访问的时候执行了边界检查（例如：数组、数据结构、指针等）来 确保只是改变了目标存储位置？
Y:是TBD:不确定N:不是NA:不适用
检查项
Y/TBD/N/NA
清晰性
系统的目标是否已定义？
是否对关键术语和缩略语进行定义和描述？
所使用的术语是否和用户/客户使用的一致？
需求的描述是否清晰，不含糊？
是否有对整套系统进行功能概述？
是否已详细说明了软件环境（共存的软件）和硬件环境（特定的配置）？
如果有会影响实施的假设情况，是否已经声明？
完成软件确认测 试说明、执行软件 确认测试、进行测 试分析、编写确认 测试报告
完成系统测试 说明、执行系 统测试、进行 测试分析、编 写系统测试报 告
是否将需求分别陈述，因此它们是独立的并且是可检查的？
是否所有需求都可以回溯到相应的需求素材，反之亦然？
是否已详细说明需求变更的过程？
Y:是TBD:不确定N:不是NA:不适用