创新中心任务管理系统需求评审报告—第一小组 (最终版)

创新中心任务管理系统

需求分析说明书评审报告

修订历史记录

目 录

1. 基本信息 2. 缺陷识别 3. 评审结论与意见 4. 评审问答记录

5. 评审过程中需要进一步确认的疑问

4 4 8 9

10

1. 基本信息

2. 缺陷识别

1.3 在 1.3 中“定义”不明确，不清楚 本项定义的是任务管理系统的 stakeholders,还是参与本系统开发的公 司或部门的人员定义。 1.4 在 1.4 中，《架构设计说明书》、 《数据库设计说明书》不能作为参考资 料.

在 1.3 标题中申明是“XX 定义”,内容中 也应重新分类，不能将开发方与需求方混 淆。

《架构设计说明书》、《数据库说明书》 都是在确认需求之后的设计阶段写的，不 能作为参考资料；参考资料可以是项目组 为之前做的需求分析说明书、双方签定的 合同、需求方提供的公司内部机制说明 等。 将标题“任务概述”改为“项目概述” 应该对该项目进行全面的成本估算

2.任务概述

2.1 本部分的标题命名不够准确 2.2 在本部分中没有对项目成本进行估 算

3.模块以及功 能的划分

3.1 在 3.1.1“页面划分”中缺少了 “管理员登录”页面的设计，因为管理 员在系统中的操作与组员和组长进行的 操作不一样，管理员应该有更高层次的 操作权限 3.2 在 3.1.1“页面划分”中“组长登 录”-“员工任务管理”下缺少了“任务 删除”界面的划分。

3.3 在 3.1.2 模块划分“任务流程”中 缺少“任务删除”操作。 3.4 在 3.1.2 整体的模块划分中缺少了 “任务日志”和“任务日历”两个模 块。 3.5 在 3.1.3 功能权限分配中，组长权 限中缺少组长对组员任务的任务删除权 限，管理员权限中没有“删除用户”和 “删除组”的操作。 3.6 在 3.1.4 中的图没有清晰的说明整 个任务审批的流程。

在用户登录中添加“管理员”登录， “管理员登录”下对管理员进行的操作进 行分解。

添加“组长登录”—“员工任务管理”下 添加“任务删除”界面。

在“任务流程”中添加“任务删除”

在模块划分整体第二层添加“任务日志” 和“任务日历”两个模块。

在组长功能列表中添加“组员任务删 除”,在管理员功能列表中添加“删除用 户”和“删除组”

应该改用标准流程图来对审批流程进行分 解建模

4.权限分配

4.1 在 3.2 权限分配中对节点的定义与 “界面划分”以及“功能权限分配”中 不一致，在前面两项中一直称“组长” 和“组员”,而在这里却称为“员工” 和“领导”

将“员工”改为“组长”,将“领导”改 为“组长”

5.任务提醒

5.1 在 3.3 任务提醒中，对任务提醒功能 阐述不够详细、明确，比如在个人设置 提醒方式的时候具体如何设置，怎样修 改提醒内容，各种提示信息包括哪些等 都没有明确说明；并且缺少对任务提醒 这一过程的直观展现。

对提示信息的类型、提醒方式和内容 设置等进行详细、准确的说明。 可以使用流程图对任务提醒的功能进 行一个直观展示，有助于理解。

6.任务报表

6.1 在 3.3 中任务报表导出结果为 “excel”,格式过于局限。 6.2 在 3.3 中没有涉及到报表以及相关 材料的导入问题，缺少交互。

导出的结果文件格式可以为其他常见文件 格式可选 添加导入功能，使系统能够完成与系统外 部的交互，并且对报表进行分类，对每种 报表的导出、导入格式进行说明。

7.详细功能设 定

7.1 任务日历和任务日志详细功能设定相 互矛盾(是否能修改日志内容)。 7.2 人任务管理和员工任务管理的业务 描述在是否能修改的定义上相互矛盾、 重复。 7.3 系统应该可以定期清理数据库中的 任务，避免数据量堆积，给数据库造成 压力。 7.4 详细功能设定不够详细，没有说明 功能划分中的全部功能点。 7.5 详细功能设定中没有优先级划分。 7.6 “任务日志”和“任务日历”两个 功能点重复又相互矛盾.

修改矛盾

重新对业务进行描述，注意两个业务之间 的关系

注明系统功能重要部分和扩展部分并对优 先级进行说明。 合并这两个功能点为一个，因为这两个功 能点基本功

能相互联系很密切。

8.精度

8.1 在 3.5 中对操作精度的需求说明不 完整 8.2 在 3.5 中第三点说明过于局限，系 统涉及到的计算问题不仅仅只有完成度 计算，对计算错误的规定也不够明确。

应当详细说明系统在进行删除、查询、修 改、添加等操作时不允许在因为系统故障 导致重复或者不成功操作。 详细说明系统所涉及到的所有计算问题， 并相应说明所要求的计算准确度，比如误 差不超过多少等。

9.时间特性要 求

9.1 在 3.6 中“多人操作的时候，时间 和相应的要求同上”中的“多人”不明 确。 9.2 在 3.6 中有阐述语法错误，第三行 中“返回 50 行数据以内的数据，单次操 作响应时间要求在 3 秒以内”不够简 练。 9.3 在 3.6 中没有对系统处理登录、分解 任务、删除等操作时的响应时间作说 明。

应当用具体数据范围说明

改为“返回 50 行以内的数据，单次操作 响应时间在 3 秒以内”

应该对系统对各项合理操作的响应时间做 出说明。

10.故障处理 要求

10.1 在 3.7 中没有说明系统可能发生的 故障以及不同故障处理所需要的时间范 围。 10.2 在 3.7 中数据库要求备份机制，但 没有对备份间隔时间、方式等做说明。

应添加更新系统可能出现的故障，并对处 理时间说明。

详细说明数据库备份机制，对备份间隔时 间(如：一天一次备份还是一月一次备份 等)每次备份数据所需时间，备份方式等 做详细说明。

11.运行环境

11.1 在 4.2 中忽略了系统与需求方公司 内部所使用的其他系统和常见项目管理 使用软件之间接口的定义。

在项目背景中应该详细说明本系统与工作 环境中其它系统、软件的关系，并在运行 环境中 4.2 申明与这些系统或软件的接 口。 应该对项目完成后，系统带来的影响以及 需求方的期望做简略分析。

12.没有期望

12.1 没有对系统完成之后给需求方带来 的后期回报和对系统的期望做分析。 13.1 本需求分析说明书中没有包含用例

13.没有包含

3. 评审结论与意见

4. 评审问答记录

5. 评审过程中需要进一步确认的疑问

初步讨论结果：两者不是同一份文档，《需求规格说明书》对软件系统各个功 能、执行情况的说明，而《需求分析说明书》偏向于对业务层次的分析。《需求 规格说明书》是《需求分析说明书》的进一步输出，它也不能作为《需求分析说 明书》的参考资料。

疑问：在评审的过程中我们是否可以补充我们觉得需要，但是需求分析说明书中 疑问 没有的需

求项？ 疑问 2 初步讨论结果：在评审过程中，我们在一定程度上需要补充一些普遍应该 有，但是系统所缺的需求项，或者对一些需求项要求进一步详细说明。

疑问 3

疑问：在需求分析评审的时候，我们应该抱着“鸡蛋里面挑骨头”心态，还是宽 疑问 容的心态？如果在评审的过程中，文档中有些需求的说明不明确，组内部分成员 有疑问或者歧义，但是在组内讨论之后才能清楚所表述的问题，这样的情况下是 否需要提出缺陷。 初步讨论结果：需求评审是对需求分析说明书做测试，所以我们不能以宽容 的心态去看待，要以提出问题的心态去做，而不是讨论问题原因。也不能过于挑 剔，因为《需 求分析说明书》不仅是给项目开发技术人员看，还要给需求方 看，所以语言表述必须准确、易懂，要能够使得需求方一看便明了，所以文档表 述使人产生异议，也是缺陷点。

本文来源：https://www.bwwdw.com/article/68jm.html