武威信息网
科技
当前位置:首页 > 科技

开发时怎样进行需求评审

发布时间:2019-08-13 15:02:37 编辑:笔名
问题描述:我们公司快要成立测试部了,之前我们一直是研发部下的测试小组,在成立之前,我们测试组集体讨论了下测试组成立前后的一些问题。其中一个难题就是需求,我们几个都没有相关的经验,所以我在此求助大家,邀大家来讨论下:如何进行需求评审?怎样的需求评审机制才是有效的? 精彩回答: 关于需求评审,首先我觉得应该解决的是可用的评审可用资源问题,只有把这个问题解决了,其评审结果才可以采信,否则不过形式尔耳。 关于需求评审的一些必备资源,我这里选列了相关角色,如下列: * 业务专家或是熟悉该业务的人员(通常也叫业务方代表) * 文档审查人员 * 架构师 * 需求分析师 * 需求评审组织人员及记录人员 当然,除了人员意外,必要的时间、场地和上层决策者的支持也是不可或缺的。 这些资源一旦准备停当,接下来就是如何安排评审事宜的问题了。我这里简单列下以往曾做过的一轮需求评审的过程: * 准备阶段(P) o 争取上层决策者的支持与谅解 o 筹备相关的资源,包括人力、时间计划,评审场地 o 在正式评审之前,将相关的需求记录(文档或其他形式)发布给每个参与评审的人员手中,并确保其有足够的时间可以通阅需求并做好评审前的相关质疑与确认记录 o 在正式评审之前,会议组织者应先收集相关评审人员的各项需求评审建议和意见,对存在争议和疑惑的需求说明必须做好讨论的安排 o 发布经确认后的评审计划或时间表 * 实施阶段(D) o 由评审组织者召集各评审人员集中评议,可以以正式的会议等形式组织,此处以会议为形式做说明 o 与会人就某具体的问题进行讨论,讨论的优先级如下所列 * 最重要的业务内容,一般是按流程、功能、细节来排定 * 争议或疑问较多的地方 * 部分有争议的地方 * 对于没有提出疑义的地方,可以快速流过 o 最后,要注意一定要回顾已提出问题和有结论的地方 o 由会议记录人员整理会议的纲要,记录各与会人员的相关意见,并在会后递交纪要 * 检查再实施阶段(C) o 对评审得出结论的问题进行再次确认和修正补充 o 确定下次评审的时间 o 按照第一阶段的流程再次进行组织,并确认结果 o 对大多数组织,两次评审可以解决大部分的问题,对于悬而未决的问题,如影响范围有限,则可以延后讨论解决 * 总结阶段(A) o 就以上内容做最后的确认,需求定稿,各方签字确认。 o 今后的变更转入需求变更流程,其后产生的评审为小范围内评审。 给出了一项检查清单,作为文档审查人员审查需求的参考检查表使用,大家可以在进行需求评审时参考使用。 建议一:分层次评审 我们知道用户的需求是可以分层次的,一般而言可以分成如下的层次: * 目标性需求:定义了整个系统需要达到的目标; * 功能性需求:定义了整个系统必须完成的任务; * 操作性需求:定义了完成每个任务的具体的人机交互; 目标性需求是企业的高层管理人员所关注的,功能性需求是企业的中层管理人员所关注的,操作性需求是企业的具体操作人员所关注的。对不同层次的需求,其描述形式是有区别的,参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求,可能会很容易地导致“捡了芝麻,丢了西瓜”的现象,如果让高层的管理人员也去评审那些操作性需求,无疑是一种资源的浪费或者就会出现案例三的情形。 建议二:正式评审与非正式评审结合 正式评审是指通过开评审会的形式,组织多个专家,将需求涉及到的人员集合在一起,并定义好参与评审人员的角色和职责,对需求进行正规的会议评审。而非正式的评审并没有这种严格的组织形式,一般也不需要将人员集合在一起评审,而是通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。2种形式各有利弊,但往往非正式的评审比正式的评审效率更高,更容易发现问题。因此在评审时,应该更灵活地利用这2种方式。 建议三:分阶段评审 应该在需求形成的过程中进行分阶段的评审,而不是在需求最终形成后再进行评审。分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审,降低了需求返工的风险,提高了评审的质量。比如可以在形成目标性需求后进行一次评审,在形成系统的初次概要需求后进行一次评审,当对概要需求细分成几个部分,对每个部分进行各个评审,最终再对整体的需求进行评审。 建议四:精心挑选评审员 需求评审可能涉及的人员包括:需方的高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管;供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等等。在这些人员中由于大家所处的立场不同,对同一个问题的看法是不相同的,有些观点是和系统的目标有关系的,有些是关系不大的,不同的观点可能形成互补的关系。为了保证评审的质量和效率,需要精心挑选评审员。首先要保证使不同类型的人员的都要参与进来,否则很可能会漏掉了很重要的需求。其次在不同类型的人员中要选择那些真正和系统相关的,对系统有足够了解的人员参与进来,否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。 建议五:对评审员进行培训 在很多情况下,评审员是领域专家而不是进行评审活动的专家,他们没有掌握进行评审的方法、技巧、过程等,因此需要对评审员进行,同样对于主持评审的管理者也需要进行培训,以便于参与评审的人员能够紧紧围绕评审的目标来进行,能够控制评审活动的节奏,提高评审效率,避免发生案例一和案例二中出现的现象。对评审员的培训也可以区分为简单培训与详细培训2种。简单培训可能需要十几分钟或者几十分钟,需要将在评审过程中的需要把握的基本原则,需要注意的常见问题说清楚。详细培训则可能要需要对评审的方法、技巧、过程进行正式的培训,需要花费较长的时间,是一个独立的活动。需要注意的是被评审人员也要被培训。 建议六:充分利用需求评审检查单 需求检查单是很好的评审工具,需求检查单可以分成2类:需求形式的检查单和需求内容的检查单。需求形式的检查可以由QA人员负责,主要是针对需求文挡的格式是否符合质量标准来提出的,需求内容的检查是由评审员负责的,主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等,这是需求评审的重点。检查单可以帮助评审员系统全面地发现需求中的问题,检查单也是随着工程财富的积累逐渐丰富和优化的。 建议七:建立标准的评审流程 对正规的需求评审会需要建立正规的需求评审流程,按照流程中定义的活动进行规范的评审过程。比如在评审流程定义中可能规定评审的进入条件,评审需要提交的资料,每次评审会议的人员职责分配,评审的具体步骤,评审通过的条件等等。通过评审流程执行可能会避免出现案例五之类的问题。 建议八:做好评审后的跟踪工作 在需求评审后,需要根据评审人员提出的问题进行评价,以确定哪些问题是必须纠正的,哪些可以不纠正,并给出充分的客观的理由与证据。当确定需要纠正的问题后,要形成书面的需求变更的申请,进入需求变更的管理流程,并确保变更的执行,在变更完成后,要进行复审。切忌评审完毕后,没有对问题进行跟踪,而无法保证评审结果的落实,使前期的评审努力付之东流。 建议九:充分准备评审 评审质量的好坏很大程度上取决于在评审会议前的准备活动。常出现的问题是,需求文档在评审会议前并没有提前下发给参与评审会议的人员,没有留出更多更充分的时间让参与评审的人员阅读需求文档。更有甚者,没有执行需求评审的进入条件,在评审文档中存在大量的低级的错误或者没有在评审前进行沟通,文档中存在方向性的错误,从而导致评审的效率很低,质量很差。对评审的准备工作,也应当定义一个检查单,在评审之前对照检查单落实每项准备工作。幽门螺旋杆菌感染好不好治
幽门螺旋杆菌感染好不好治
冠心病什么症状
便秘可以长期吃泻药吗