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

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

《创新中心任务管理系统需求评审报告第一小组 最终版.docx》由会员分享，可在线阅读，更多相关《创新中心任务管理系统需求评审报告第一小组 最终版.docx（13页珍藏版）》请在冰点文库上搜索。

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

创新中心任务管理系统

需求分析说明书评审报告

文件状态：

[]草稿

[√]正式发布

[]正在修改

文件标识：

当前版本：

1.0

作者：

软件评审第一小组

完成日期：

2012-2-24

修订历史记录

日期

版本

说明

作者

<2012年2月24日>

<1.0>

<详细信息>

<姓名>

目录

1.基本信息4

2.缺陷识别4

3.评审结论与意见8

4.评审问答记录9

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

1.基本信息

待评审的工作成果

创新中心任务管理系统需求分析说明书

技术评审方式

小组讨论

评审时间

2012年2月24日

评审地点

北京交通大学学生活动中心三层

评审所需设备

组内成员自带电脑

参加技术评审的人员

类别

名字

工作单位

职称、职务：

主持人

组长

评审

小组

成员

成员

成员

成员

成员

成员

成员

成员

记录员

成员

作者

评审时间

2小时

2.缺陷识别

已识别的缺陷

缺陷描述

建议缺陷解决方案

1.引言

1.1编写目的不明确，忽略了该文档为需求方和测试人员提供参考的作用。

添加本文档为对需求方、测试人员、今后需求的变更提供的参考作用。

1.2项目背景阐述不明确，文中的该部分仅仅是简单对系统本身进行简单介绍，不够详细，对任务管理系统提出的具体原因、产品的使用环境等情况都为具体阐述。

具体说明SDC项目组提出该系统的需求原因、系统将来运行的环境以及需求方的工作条件。

1.3在1.3中“定义”不明确，不清楚本项定义的是任务管理系统的stakeholders,还是参与本系统开发的公司或部门的人员定义。

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

1.4在1.4中，《架构设计说明书》、《数据库设计说明书》不能作为参考资料.

《架构设计说明书》、《数据库说明书》都是在确认需求之后的设计阶段写的，不能作为参考资料；参考资料可以是项目组为之前做的需求分析说明书、双方签定的合同、需求方提供的公司内部机制说明等。

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秒以内”不够简练。

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

9.3在3.6中没有对系统处理登录、分解任务、删除等操作时的响应时间作说明。

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

10.故障处理要求

10.1在3.7中没有说明系统可能发生的故障以及不同故障处理所需要的时间范围。

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

10.2在3.7中数据库要求备份机制，但没有对备份间隔时间、方式等做说明。

详细说明数据库备份机制，对备份间隔时间（如：

一天一次备份还是一月一次备份等）每次备份数据所需时间，备份方式等做详细说明。

11.运行环境

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

在项目背景中应该详细说明本系统与工作环境中其它系统、软件的关系，并在运行环境中4.2申明与这些系统或软件的接口。

12．没有期望

12.1没有对系统完成之后给需求方带来的后期回报和对系统的期望做分析。

应该对项目完成后，系统带来的影响以及需求方的期望做简略分析。

13.没有包含用例文档

13.1本需求分析说明书中没有包含用例文档

3.评审结论与意见

评审结论

工作成果不合格，需要作比较大的修改，之后必须重新对其评审。

意见

修改《创新中心任务管理系统需求分析说明书》时的几点意见：

1.在改进应注意表述语言的准确性，并且注意描述功能点时应该从普通读者的角度出发，而不是需求分析员或者技术人员的角度，语言要浅显易懂。

2.修改一下文档的格式，或者换一个模版，文档的标题应该准确且有条理；为了能够直观、准确的展示系统整体流程，应该对系统每一个业务过程用流程图来建模，在描述功能时，应该详细、准确、全面。

对页面划分时应该对页面进行简单建模，以图形方式直观展现。

3.在表述系统要达到的标准时，尽量用数字明确说明，不要有模糊、大概的词语，避免二义性。

4.再详细了解系统需求方的工作环境、工作流程，并明确说明与其他系统或者软件的交互方式等。

5.因为本系统的需求方也是一个软件开发组织，文中阐述将需求方与自身混淆，导致很多表述有歧义。

所以在修正过程中要讲需求方与自身明确区别。

负责人

签字

签字：

日期：

2012年2月26日

4.评审问答记录

记录1

问：

文档编写目的是否明确、准确？

答：

依据需求分析说明书的标准，得出该文档的标准规范性不合要求，文档编写目的描述不全面，忽略了对需求分析面向客户的一方面，且不够详细、具体，忽略了需求分析说明书对测试人员和需求方（即客户）的作用。

记录2

问：

项目背景应该阐明哪些内容，本文项目背景部分是否明确、完整？

答：

项目背景偏离背景的主线，不明确，未提出项目进行的原因、项目环境，没有进行的项目必要性及项目的价值分析。

记录3

问：

1.3中定义这些角色的目的是什么？

这些角色到底是系统参与者还是对开发团队人员进行说明或是系统使用者分类？

答：

在1.3中“定义”不明确，不清楚本项定义的是任务管理系统的stakeholders,还是参与本系统开发的公司或部门的人员定义。

记录4

问：

需求规格说明书和需求分析说明书是否有差别，这两个文档的完成是否有先后？

参考资料表述是否正确、完整？

答：

需求规格说明书和需求分析说明书不能同日而语，需求规格说明书也不能作为本文当的参考资料。

《架构设计说明书》、《数据库设计说明书》是在确认需求之后才完成，不能作为本文当的参考资料。

记录5

问：

需求分析中是否需要对项目成本进行评估？

答：

需求分析中要对项目成本进行估算，通过成本估算才能够明确项目花费是多少，是否值得去做，也能够让需求方明了完成该项目的成本。

记录6

问：

本系统中管理员权限与组长权限是否一致？

管理员是否需要单独的操作界面？

答：

系统中管理员权限高于组长权限，管理员界面相当于是后台操作，需要单独界面。

记录7

问：

在界面划分中，删除操作是否需要界面？

答：

删除需要界面。

记录8

问：

管理员是否有删除系统用户和任务组的权限？

答：

管理员负责管理系统中的用户，既然有添加用户和添加组的权限，就应该有删除组和删除用户的权限。

记录9

问：

文档中对系统用户的划分出现“组长”、“组员”和“员工”、“领导”两种方式，哪种方式更准确？

答：

系统用户中每一个员工既可是组长也可是组员，而“领导”则太广泛，不明确。

系统用户的比较准确的划分应该用“组长”和“组员”。

记录10

问：

在对某些系统功能的阐述中，因为我们并不能明了其具体的操作，例如：

在3.3任务提醒功能中，只知道可以对任务提醒方式、内容进行设置，却没说明如何设置，有哪些设置项。

这样的情况下是否需要补充说明，并且详细到每个操作点？

答：

需要，因为需求分析说明书要明确客户的所有需求，只有详细描述每一个操作，才能让客户明确系统是否满足工作的需要。

记录11

问：

当我们通过对平时我们所使用的系统的了解，认为有一些需求客户没有提出，但是却是比较需要的功能是否需要完善？

例如：

在3.3中任务报表导出结果为“excel”，但是我们考虑到项目开发过程中的一些不适合excel格式展现的文档，像需求分析说明书、概要设计等等也会需要导出，我们是否需要添加导出其他格式的功能？

答：

需要。

客户不可能想到所有潜在需求，这个时候需要我们来帮助提出一些需求。

记录12

问：

某些功能点相互之间关系密切，而且本身功能相似性很大的时候，是否需要提出将功能点合并？

答：

需要。

记录13

问：

需求中是否应该对系统的最大承载量、相关操作响应时间、相关计算精确度等做出明确说明？

答：

需要，这些都是系统的重要指标，这些数据指标不同，开发成本、时间、后期维护等都会有很大出入，所以应该明确数据指标，而不能只有模糊、大概的估量。

记录14

问：

需求中是否需要说明将来会与系统交互的系统，以及双方的交互方式？

答：

需要，因为只有在需求中提出这些需求项，才会在系统设计中考虑这些问题。

记录15

问：

对于系统完成投入使用之后为需求方（客户）带来的经济利益或者工作效率等的改善是否需要说明？

答：

需求中要对系统本身对需求方带来的期望做阐述，才能让需求方明确该系统是否达到自己期望的结果，是否值得做。

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

疑问1

疑问：

《需求分析说明书》与《需求规格说明书》是否是同一份文档？

《需求规格说明书》是否能作为《需求分析说明书》的参考资料？

初步讨论结果：

两者不是同一份文档，《需求规格说明书》对软件系统各个功能、执行情况的说明，而《需求分析说明书》偏向于对业务层次的分析。

《需求规格说明书》是《需求分析说明书》的进一步输出，它也不能作为《需求分析说明书》的参考资料。

疑问2

疑问：

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

初步讨论结果：

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

疑问3

疑问：

在需求分析评审的时候，我们应该抱着“鸡蛋里面挑骨头”心态，还是宽容的心态？

如果在评审的过程中，文档中有些需求的说明不明确，组内部分成员有疑问或者歧义，但是在组内讨论之后才能清楚所表述的问题，这样的情况下是否需要提出缺陷。

初步讨论结果：

需求评审是对需求分析说明书做测试，所以我们不能以宽容的心态去看待，要以提出问题的心态去做，而不是讨论问题原因。

也不能过于挑剔，因为《需求分析说明书》不仅是给项目开发技术人员看，还要给需求方看，所以语言表述必须准确、易懂，要能够使得需求方一看便明了，所以文档表述使人产生异议，也是缺陷点。