第七章-有效的需求评审实践

第七章有效的需求评审实践郭树行13910325526，[e-mail]中央财经大学信息学院讲师北京航空航天大学软件工程研究所博士具体内容•评审的目的•评审的若干方法•评审的失败案例•评审的建议需求评审的重要•需求评审的重要性：•1.软件需求是软件开发最重要的一个输入，好的开始是成功的一半!所以，需求的质量很大程度上决定了项目质量或产品质量。•2.需求风险常常是软件开发过程中最大的一个风险，要降低需求阶段带来的风险，就要把需求评审做好。•3.需求评审做不好的后果：–需求变更–需求不明确–需求不可测–需求不可实现–导致后续工作难于开展或经常出现变更。到底为什么？•不识庐山真面目，只缘身在此山中，需求是自己写的，容易受到固定思维的限制，所以，需要一双没有看过这个需求的眼睛来检查一下，有什么问题。评审最大难题•在做需求评审的时候，应该根据不同的需求层次，进行不同的评审。–目标性需求：定义了整个系统需要达到的目标;-高层关注–功能性需求：定义了整个系统必须完成的任务;-中层关注–操作性需求：定义了完成每个任务的具体的人机交互;-执行人员关注评审中常见的问题•因为经常参加需求评审会议，所以对需求评审中常见的问题有所了解，现在举一些例子：•1、某产品经理在主持需求评审会，评审开始时间不长，就被一位主管打断，明确指出此方案与企业业务发展方向不符，不能实施。紧接着其他与会人员纷纷发言表示同意，结果评审会无法继续进行，需求最终被否决。•原因何在？•问题所在：缺乏初步沟通，目标性需求尚未明确，功能性需求和操作性需求无从谈起。•2、某次需求评审会，主要是公司内部相关领域的专家参加，在评审会开始后不久，某专家就对需求中的某个具体问题提出了自己的不同意见，于是，与会人员纷纷就该问题发表自己的意见，大家争执不下，结果，致使会议出现了混乱状况，主持人无法控制局面，会议大大超出了计划评审时间。•原因何在？•问题所在：•前期沟通和准备不够，缺乏应对不同意见的准备，难以化解争执。•主持者不能有效把握会议目标，会议讨论过于关注细节，导致评审失控。•3、某产品经理主持需求评审会，在讲解需求说明书时，与会人员似懂非懂，没有提出任何有价值的问题，致使会议没有得到预期效果，不得不改日重新进行。•问题何在？•问题所在：•前期准备和沟通不够，评审变成了培训。•没有选择合适的评审人员，无法获得有价值的信息。•4、某需求评审会，与会人员各抒己见，气氛热烈，产品经理忙于收集意见，结果散会时发现对需求有价值的并不多，并且遗漏了许多要评审的问题，评审效果不佳。与会人员在离开会议室后，私下也认为评审没有多少实际效果，完全是在走过场。•问题何在？•问题所在：•评审缺乏有效依据和规范，不能保证评审的覆盖率和有效性。•产品经理没有把握好会议主题，评审变成了头脑风暴。需求评审常见问题汇总•目标性需求没有沟通好，后面的需求变成空中楼阁。•缺乏评审的可操作依据，遗漏评审内容。•没有作好前期准备工作，导致评审时间长，效率低。•没有选择合适的评审人员，无法获得有价值的反馈。•参加人员过多，容易陷入细枝末节的讨论，会议演变成一场人人自由的混战。具体内容•评审的目的•评审的若干方法•评审的失败案例•评审的建议评审的若干方法•对需求规格说明的正确性进行评审•对需求规格说明的实践性进行评审•对需求规格说明的完整性进行评审•对需求方案的可行性和成本预算进行评审•对需求的质量属性进行评审•对需求的可实施性进行评审•对需求包含的用例文档进行评审需求规格说明的正确性评审需求规格说明的正确性体现在：是否有需求与其他需求相互冲突或者重复？是否清晰、简洁、无二义地表达了每个需求?是否每个需求都通过了演示、测试、评审，分析是否得到了验证?是否每个需求都没有内容和语法上的错误?在现有的资源内,是否能实现所有的需求?是否每个需求都在项目的范围内?每一条特定的错误信息，是否都是唯一的和具有含义的?需求规格说明的实践性评审•实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度,而非源于分析师们经验主义的臆测。•有经验的系统分析师通常会迷信自己的经验,把从前的经验嫁接到目前的企业需求分析中。也许由于行业性质相同,但如果不经过当前的实践调研则给出需求，仍然会无法体现出企业自身的特征。因而不能为企业带来真正的价值,也会造成与用户需求的鸿沟。需求规格说明的完整性评审•编写的所有需求，其详细程度是否一致和合适?•需求是否能为设计提供足够的基础?•所有对其他需求的内部引用是否正确?•是否包含了每个需求的实现优先级?•是否定义了功能说明的内在算法?•是否包含了所有已知的客户需求或系统需求?•是否遗漏了必要的信息?如果有遗漏的话,把他们标记为待确定的问题(TBD)?•是否对所有预期的错误条件所产生的系统行为都编制了文档?需求方案的可行性和成本预算评审•需求方案的可行性和成本预算评审的目的，是从需求的多项方案中选择最优化的或者是性价比最高的方案。一般而言,需求说明书可以给出同一个问题的几种方案，并给出各自的优缺点和成本差异,经过比较由决策者作出最终选择。•如果可行性高,则还要考虑它需要哪些资源和预算。我们需要确定技术是否确实满足业务需求,同时,也要考虑整个产品成本,包括开发人员、服务器、许可和升级费用,还需要考虑初始硬件、软件和支持、基础结构和培训的费用。需求的质量属性评审我们需要评审需求规格说明是否合理地确定了所有的性能目标，是否合理地确定了安全性方面要考虑到的问题。用户通常难以忍受运行或响应速度过慢的系统。系统的安全性也是一个很重要的指标,尤其是作为企业级的系统,它的安全考量完全继承于组织对安全的基本诉求。需求的可实施性评审•是否对每个需求都设置了维一性标志并且可以正确地识别它？是否每个功能需求都可以跟踪到高层需求•需求必须可以测试,每个需求在特定的输入条件下应当能给出已知的输出结果。•同时,需求应当层次分明,需要把单个需求下面的相关需求综合在一起形成一组需求功能。•需求的可实施性除了可跟踪性还包括可测试性。需求包含的用例文档评审•用例的目标或价值度量是否明确?•用例是否是独立的分散任务?•是否明确说明可用用例会给哪些参与者带来用处?•编写用例的详细程度是否恰当?是否有不必要的设计和实现细节?•所有预期的分支过程是否都编写了文档说明?•所有预估的异常过程是否都编写了文档说明?•是否存在一些普通的动作序列可以分解成独立的用例?•每个路径的步骤是否都清晰明了,无歧义而且完整?•用例中的每个参与者和步骤是否都与所执行的任务有关?•用例中定义的每个可选路径是否都可行和可验证?•用例的前置条件和后置条件是否合理?•上述需求评审的关键方法都是可选、可裁减的。•各企业根据项目周期、规模、类型灵活调整需求评审会的过程和结束标准•审查期间评审员们提出的所有问题都已经解决。•相关文档中的所有更改都已经正确完成。•修订过的文档进行了拼写检查。•所有标识为TBD(待确定)的问题已经全部解决,或者已经对每个TBD的问题的解决过程、计划解决的目标日期和责任解决人等编制了文档。•需求文档正式进入了配置库。具体内容•评审的目的•评审的若干方法•评审的失败案例•评审的建议案例一某领域专家A先生就某企业的成本管理系统做用户需求报告的评审工作，在评审会开始时间不长，就被在场的某企业的一位副总B先生打断，认为A先生提出的方案不适合本企业，A先生提出的管理改进方案在企业中无法实施。该副总提完意见后，与会的用户方人员纷纷跟随B先生的提出了他们的反对意见，致使评审会无法再进行下去，最终该报告被用户否决。案例二•某软件公司为某公司A做业务流程管理系统的需求评审会，当项目组人员在会议上宣读多达上百页的需求报告时，用户明确提出听不懂，致使会议不得不改日进行。案例三•某软件公司在用户处开完物资管理系统的需求评审会后，与会人员在离开会议室时纷纷摇头，认为本次会议没有多少实际效果，完全是在走过场。案例四•某软件公司在公司内部举行产品的需求评审会时，需求报告的执笔人与产品策划的主要策划人员的想法差别很大，致使需求评审会没有必要继续进行下去。具体内容•评审的目的•评审的若干方法•评审的失败案例•评审的建议建议一：分层次评审我们知道用户的需求是可以分层：目标性需求：定义了整个系统需要达到的目标；功能性需求：定义了整个系统必须完成的任务；操作性需求：定义了完成每个任务的具体的人机交互；建议二：正式评审与非正式评审结合•正式评审是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。•非正式的评审并没有这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。建议三：分阶段评审应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。建议四：精心挑选评审员首先要保证使不同类型的人员的都要参与进来，否则很可能会漏掉了很重要的需求。其次在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。建议五：对评审员进行培训•简单培训可能需要十几分钟或者几十分钟，需要将在评审过程中的需要把握的基本原则，需要注意的常见问题说清楚。•详细培训则可能要需要对评审的方法、技巧、过程进行正式的培训，需要花费较长的时间，是一个独立的活动。需要注意的是被评审人员也要被培训。建议六：充分利用需求评审检查单需求检查单可以分成两类：需求形式的检查可以由QA人员负责，主要是针对需求文挡的格式是否符合质量标准来提出的需求内容的检查是由评审员负责的，主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等，这是需求评审的重点。建议七：建立标准的评审流程对正规的需求评审会需要建立正规的需求评审流程，按照流程中定义的活动进行规范的评审过程。比如在评审流程定义中可能规定评审的进入条件、评审需要提交的资料、每次评审会议的人员职责分配、评审的具体步骤、评审通过的条件等等。通过评审流程执行可能会避免出现案例中的问题。建议八：做好评审后的跟踪工作•在需求评审后，需要根据评审人员提出的问题进行评价，以确定哪些问题是必须纠正的，哪些可以不纠正，并给出充分的客观的理由与证据。当确定需要纠正的问题后，要形成书面的需求变更的申请，进入需求变更的管理流程，并确保变更的执行，在变更完成后，要进行复审。切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流。建议九：充分准备评审评审质量的好坏很大程度上取决于在评审会议前的准备活动。常出现的问题是，需求文档在评审会议前并没有提前下发给参与评审会议的人员，没有留出更多更充分的时间让参与评审的人员阅读需求文档。更有甚者，没有执行需求评审的进入条件，在评审文档中存在大量的低级的错误或者没有在评审前进行沟通，文档中存在方向性的错误，从而导致评审的效率很低，质量很差。对评审的准备工作，也应当定义一个检查单，在评审之前对照检查单落实每项准备工作。本部分课程的目标•请贵单位设置项目需求管理员专岗负责人灵活运用需求评审的若干方法，确定当前的评审目的，制定规范的评审流程，区分需求层次、选择合适的评审员参加。End