当前位置：文档之家 › 软件设计评审表【模板】

软件设计评审表【模板】

  • 格式：doc
  • 大小：90.50 KB
  • 文档页数：2

下载文档原格式

  / 2

合集下载

设计开发输入评审记录表模版

设计开发输入评审记录表模版
评审意见或建议：
设计输入依据、用途、技术标准、同行业借鉴，符合方案设计需求，满足客户和法规的需要。
评审组长：XXX
评审时间：2023.4.5
参加评审人员
姓 名
职务
所属部门
签字/日期
总经理
2023.4.5
副经理
工程技术部
2023.4.5
副经理
综合管理部
2023.4.5
副经理
软件开发部
2023.4.5
设计输入评审记录表
编号
项目名称
项目设计评审记录表
共1页
第1页
评审类别
会议评审评ຫໍສະໝຸດ 阶段输入评审评审内容：
1.设计依据。
2.方案用途及范围。
3.主要技术能力指标是否满足客户要求。
4.国内同类项目水平分析比较。
5.国家标准、行业标准比较。
已完成的主要工作：
完成了同类比较，标准化审查，资源情况分析，成本方面的分析以及适应用户需求、适应本企业发展要求的情况。

软件项目需求评审检查表-模板

软件项目需求评审检查表-模板
功能项（ 系统控制退票只能退回原提出行，税票只能 向指定交换行提出）未在需求说明书中体现，需要补
7充
功能项（能够统计各地区、行别的资金流量流向）有
8 遗漏
功能项（根据机构代码、行别、清算行、地区代码等 条件查询收费信息；根据机构代码、行别、清算行、 地区代码等条件查询提出提入业务量）未在需求说明
9 书中体现，需要补充；
3306951832.xls 第2页 共2页
评审准备表
项目经理 角 色 评审检查者
QA工程师 评审日期
序号
1 跨区代理问题
2020/9/23 缺陷记录
作者
记录人
缺陷总数 缺陷级别 提出人
一般
14 备注
多表实现。其中控制类型只允许条件是否可略去需和
2 用户确认
3
4 进行修改
补充市区操作员和各县区操作员可查询的账户信息范
5围 6 大额交易查询检测功能：用户界面项遗漏行别等字段
12 有遗漏
功能项（已存在的银行类别可以修改，如将农信社改
13 为农合行或农商行）不需要实现批量改
批量导入、导出功能。提供按机构代码、清算行行号 、账号位数批量删除账户信息功能。提供账户批量迁 移功能）原系统中导入Excel、批量删除功能还未实
14 现，需要补充 15
一般 一般 严重 严重
建议
上海畅星智能系统有限公司
提供账户批量迁移功能原系统中导入excel批量删除功能还未实现需要补充功能项一台前置机支持多个清算账户未在需求说明书中体现需要补充功能项交易明细查询可以设置查询金额的范围有遗漏上海畅星智能系统有限公司第2页共5页a1299073341编号项目是否不适用说明1需求划分是否合理是2业务规则是否均有说明

软件设计评审表-模板

软件设计评审表-模板
9
用户接口是否模块化，并且修改时不影响其他程序
10
是否提供了一致的错误处理机制
11
各子系统、模块之间的关系是否描述得清楚
12
系统的设计是否考虑了系统的可扩展性
13
设计是否考虑了重用性
14
重用构件是否进行了标识
15
是否说明了重用模块的获得方式和相关的文档
Байду номын сангаас16
系统的设计是否考虑了系统的易移植性
17
设计是否使用标准的技术，避免使用怪异的、不易理解的方式和方法
设计范围、边界是否清晰，文档中是否清晰阐明了系统的各项特性及预期的结果
15
逻辑性、算法和处理过程是否正确
16
文档是否符合客户的需要
17
设计是否考虑到未来的扩充性
18
设计的系统是否易于维护
评审项目
详细设计说明书
评审日期
评审结果标记
合格不合格TBD待完成 NA 不适用
评审情况
检查项：项；有效检查项：项；通过项：项；通过率：%
18
设计的调用宽度、调用深度、耦合度、内聚度和结构化程序是否进行了描述
追溯性
19
设计是否可以追踪到需求
20
需求是否可追溯到设计
编制： 日期： 审核： 日期： 批准： 日期：
序号
主要检查项
检查结果
说明
标准化
1
有规定的文档标识
2
引用的文档现行有效
3
文档编写的内容、格式符合相关标准、规定的要求
4
文档签署完整
5
设计陈述中的命名、属于和缩写是否上下文一致
完整性
5
文档有独立的版本说明部分

软件设计评审表-模板

软件设计评审表-模板
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

软件设计评审表模板

软件设计评审表模板

XXXXXXXXXXXX 单位名称软件设计评审表项目名称型号规格软件产品设计人评审人员部门职务或职称评审人员部门职务或职称评审项目概要设计说明书评审日期评审结果标记合格x 不合格TBD 待完成NA 不适用评审情况检查项：项；有效检查项：项；通过项：项；通过率：% 序号主要检查项检查结果说明标准化1 有规定的文档标识2 引用的文档现行有效3 文档编写的内容、格式符合相关标准、规定的要求4 文档签署完整完整性5 文档有独立的版本说明部分6 有文档的文字目录页7 有总体设计部分8 有功能设计9 有接口设计10 有性能设计追溯性11 设计是否可以追踪到需求12 需求是否可追溯到设计符合性13 是否每个设计都是可测试的或以别的方式可以确定的设计范围、边界是否清晰，文档中是否清晰阐明了系统14的各项特性及预期的结果15 逻辑性、算法和处理过程是否正确16 文档是否符合客户的需要17 设计是否考虑到未来的扩充性18 设计的系统是否易于维护评审项目详细设计说明书评审日期评审结果标记合格x 不合格TBD 待完成NA 不适用评审情况检查项：项；有效检查项：项；通过项：项；通过率：% 序号主要检查项检查结果说明标准化1 有规定的文档标识2 引用的文档现行有效3 文档编写的内容、格式符合相关标准、规定的要求4 文档签署完整5 设计陈述中的命名、属于和缩写是否上下文一致完整性5 文档有独立的版本说明部分6 每个设计是否都有相应的标识7 每个设计的输入/输出是否进行了描述8 关键的用户接口是否进行了描述9 用户接口是否模块化，并且修改时不影响其他程序10 是否提供了一致的错误处理机制11 各子系统、模块之间的关系是否描述得清楚12 系统的设计是否考虑了系统的可扩展性13 设计是否考虑了重用性14 重用构件是否进行了标识15 是否说明了重用模块的获得方式和相关的文档16 系统的设计是否考虑了系统的易移植性设计是否使用标准的技术，避免使用怪异的、不易理解17的方式和方法设计的调用宽度、调用深度、耦合度、内聚度和结构化18程序是否进行了描述追溯性19 设计是否可以追踪到需求20 需求是否可追溯到设计编制：日期：审核：日期：批准：日期：。

软件评审检查表-计分

软件评审检查表-计分
15
交互性要求
简易位，一致性;反馈性;容错性图形化.
人机交互简单、形象输入、输出方面的-致性对用户的操作及时作出皮馈;对可能出现的错误迸行检测、报告和处理.
15
软件性能
响应性要求
页面转焕的响应性 ;
载入时间的短时间要求
短时启动时间要求;
负裁指标明确化.
页面转换快捷;媒体装入时间简短;有确定的负载性能指标.
部署后是否可以正常使用.
5
运行环境
环境适用性.
运行环镜是否与软件愿景说明书一致
5
界面
界面布局
界面布局的合理性.
布局合理，层次清晰
2
界面美观设计
界面的美观性.
界面美观.
3
界画元素
界面元素的-致性.
窗口、菜单、图标、按钮等元素的-性.
5
功能要求
技术运用
技术运用的合理性;内容实现的正确性.
各种技术表现与具体内容结合 ，各种媒体使用协调;多媒体信息的呈现可控，链接准确、无死链.
100分
评审结论：
5ห้องสมุดไป่ตู้
稳定性要求
帮助机制的完备性;
错误处理机制完备性;
确认退出出机制的完备性.
每个操作都有联机帮助或提示;
联机帮助易读、易懂
处理用户可能出现的任何错误操作;
避免出现数据未保留而退出.
5
安全性要求
访问安全性，使用安全
性
用户身份管理和访问控制
数据安全性
10
软件文档
文档资料
完整性
规范性
软件过程文件目录
20
分数
软件产品评审表
评审时间：
评审人员：评审组长（），评审成员（）

软件需求评审记录表

软件需求评审记录表

软件需求评审记录表项目名称：评审人：时间：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:不适用

软件产品评审表

软件产品评审表
4.事件化、情绪化、故事化、游戏化
25
软件性能
响应性要求
页面转换的响应性；
互动过程中的响应性；
页面转换快捷；
对用户的操作及时作出交互反馈；
5
稳定性要求
帮助机制的完备性；
错误处理机制完备性；
确认退出机制的完备性。
每个操作都有帮助或提示并易于理解；
保证处理用户项目名称
策划人
评审项目
评审细项
评审指标
（评审要点）
指标说明
（评审要点说明）
最高
分值
分值
产品内容
产品内容
内容的完整性
内容的趣味性
相对完整的完成软件愿景说明书上的功能；
保证软件使用过程中的趣味性
10
软件定位
使用者的明确性。
学习或娱乐目的的明确性
有明确的使用者定位。
有明确的学习目的，或者娱乐目的
5
界面
5
软件文档
文档资料
文档资料的完整性；
文档资料的规范性。
有功能说明书、开发计划说明书、需求规格说明书、架构设计说明书、详细设计说明书、测试报告等开发文档；
有开发过程管理文档；
有用户手册；
文档编写符合标准和要求。
20
总计
100
评审项目
会议时间
评审组
成员
评审
负责人
主审人
主审人
评审人
评审人
评审人
评审人
评审会议记录
第一反应原则；
阿童木原则；
非局域化原则；
引导原则；
互动性原则；
1.做什么事情有关联的针对性反应及语言（不用人联想）。与当前操作是一对一的对应关系，不拐弯抹角，让用户无法理解。
  1. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
18
设计的调用宽度、调用深度、耦合度、内聚度和结构化程序是否进行了描述
追溯性
19
设计是否可以追踪到需求
20
需求是否可追溯到设计
编制： 日期： 审核： 日期： 批准： 日期：
XXXXXXXXXXXX单位名称
软件设计评审表
项目名称
型号规格
软件产品
设计人
评审人员
部门
职务或职称
评审人员
部门
职务或职称
评审项目
概要设计说明书
评审日期
评审结果标记
合格不合格TBD待完成 NA 不适用
评审情况
检查项：项；有效检查项：项；通过项：项；通过率：%
序号
主要检查项检查结果说明Fra bibliotek标准化
1
有规定的文档标识
2
引用的文档现行有效
3
文档编写的内容、格式符合相关标准、规定的要求
4
文档签署完整
完整性
5
文档有独立的版本说明部分
6
有文档的文字目录页
7
有总体设计部分
8
有功能设计
9
有接口设计
10
有性能设计
追溯性
11
设计是否可以追踪到需求
12
需求是否可追溯到设计
符合性
13
是否每个设计都是可测试的或以别的方式可以确定的
14
9
用户接口是否模块化，并且修改时不影响其他程序
10
是否提供了一致的错误处理机制
11
各子系统、模块之间的关系是否描述得清楚
12
系统的设计是否考虑了系统的可扩展性
13
设计是否考虑了重用性
14
重用构件是否进行了标识
15
是否说明了重用模块的获得方式和相关的文档
16
系统的设计是否考虑了系统的易移植性
17
设计是否使用标准的技术，避免使用怪异的、不易理解的方式和方法
序号
主要检查项
检查结果
说明
标准化
1
有规定的文档标识
2
引用的文档现行有效
3
文档编写的内容、格式符合相关标准、规定的要求
4
文档签署完整
5
设计陈述中的命名、属于和缩写是否上下文一致
完整性
5
文档有独立的版本说明部分
6
每个设计是否都有相应的标识
7
每个设计的输入/输出是否进行了描述
8
关键的用户接口是否进行了描述
设计范围、边界是否清晰，文档中是否清晰阐明了系统的各项特性及预期的结果
15
逻辑性、算法和处理过程是否正确
16
文档是否符合客户的需要
17
设计是否考虑到未来的扩充性
18
设计的系统是否易于维护
评审项目
详细设计说明书
评审日期
评审结果标记
合格不合格TBD待完成 NA 不适用
评审情况
检查项：项；有效检查项：项；通过项：项；通过率：%