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

创新中心任务管理系统 需求分析说明书评审报告文件状态： 草稿 正式发布 正在修改文件标识：当前版本：1.0作 者：软件评审第一小组完成日期：2012-2-24修订历史记录日期版本说明作者 目 录1.基本信息42.缺陷识别43.评审结论与意见84.评审问答记录95.评审过程中需要进一步确认的疑问101. 基本信息待评审的工作成果创新中心任务管理系统需求分析说明书技术评审方式小组讨论评审时间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疑问：在评审的过程中我们是否可以补充我们觉得需要，但是需求分析说明书中没有的需求项？ 初步讨论结果：在评审过程中，我们在一定程度上需要补充一些普遍应该有，但是系统所缺的需求项，或者对一些需求项要求进一步详细说明。疑