软件需求设计评审须知的8大注意

一、 注意对需求规格说明的正确性进行评审
　　需求规格说明的正确性通常可以从如下方面得以体现：
　　是否有需求与其他需求相互冲突或者重复？通常一份长达几百页的需求规格说明书都不会是一蹴而就的，它可能是系统分析师几个夜晚的心血之作。正是因为撰写过程的连续性，可能导致同一份文档中前后名词定义不一致，前后观点上有重叠或差异的情况出现，这需要我们在撰写报告前首先要在思想上形成统一概念， 可使术语列表贯穿整份文档以达提纲挈领之效。
　　是否清晰、简洁、无二义地表达了每个需求？ “清晰”是让人能够读懂；“简洁”是让人愿意去读；“无二义”决定”读”的效果，是让大家对需求描述的理解能够达成一致。需求陈述是“三重门”，这三扇门是否开启决定了需求说明书的质量高低。我们尤其要拒绝“二义性”的名词术语的出现， 似是而非的概念定义是需求书应该避免的。换句话说，如果一份需求说明书没能给人以清晰、简洁和无二义的阐述，则需求评审是没有进行下去的必要，同时也无法进行下去。需求评审的前提是用户读懂了需求说明，并且用户的理解内容就是分析师们所描述的内容。
　　是否每个需求都通过了演示、测试、评审，分析是否得到了验证？ 需求应该是可以测试的，通常通过测试去验证它是不是正确。比如我们完成了“销售员客户佣金提成规则”需求的撰写，如果需求书未能经过原型测试通过，则需求评审是不能得到通过的。面对相当复杂的业务需求，经过测试或演示是让用户信任的一个必要过程。试想一下， 如果连需求都不能很好地被确认，则开发实现阶段更是没有把握控制了。
　　是否每个需求都在项目的范围内？ 划分项目范围和区分系统边界同样是需求说明书的一个任务，不要对需求书作出超范围的论述和延伸，要知道需求书不是分析师卖弄概念、展示时尚的场所，它是软件工程的一个重要环节。
　　是否每个需求都没有内容和语法上的错误？按照传统的需求列表方式，需求像菜单一样被一条条列出来，构成需求项的主要栏位包括：需求ID、 需求描述、优先级、来源和状态等。 通常需求首先要经过“拼写检查”，保证没有拼写上的问题，然后通过逐行浏览修改那些在内容或行文上出现问题的需求。
　　在现有的资源内， 是否能实现所有的需求？ 需求规格说明要考虑可行性的问题。事实上，分析师的关注层面是价值驱动和成本驱动方面。分析师应该明白不是所有的需求都要去实现，一些看上去很明显与涉及用户有冲突的、费力不讨好的需求应该果断地舍弃。国内有专家提出，搞需求也要讲“和谐”即是此中道理。
　　每一条特定的错误信息，是否都是唯一的和具有含义的？ 不要忽视错误信息的定义， 它必须具有唯一性。如果过于笼统地定义错误信息则和没有定义的效果是一样的。

　　二、 注意对需求规格说明的实践性进行评审
　　所谓实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度，而非源于分析师们经验主义的臆测。实践性是判断需求规格说明是不是理论联系实践、密切和用户联系的一个关键性指标。如果需求规格说明和用户实践脱离，即使看上去写得再天花乱坠，也会使需求说明如同无根之树、无源之水，会大大减低用户对需求报告本身的信任度。
　有经验的系统分析师通常会迷信自己的经验，把从前的经验嫁接到目前的企业需求分析中。也许由于行业性质相同，但如果不经过当前的实践调研则给出需求，仍然会无法体现出企业自身的特征。因而不能为企业带来真正的价值，也会造成与用户需求的鸿沟。
　　笔者也曾经“轻实践重抽象”，我认为系统分析师的工作特点是站在具体案例上的深度抽象，前提是必须获得本企业的一手具体业务背景、流程和规则。
　　我们在分析比如“任务跟踪”之类的系统时，由于系统的抽象模型是已知的（通过大量同类软件的分析得知），但还是需要分析师把抽象模型演绎到企业当前业务现状。这样的需求分析才会有“实话实说”之效，才能引发评审者的共鸣。否则，在需求评审中评审者是很难读懂你的意图，自然不会立即通过你的需求报告，导致需要重新返工撰写需求报告。

　　三、 注意对需求规格说明的完整性进行评审
　　我们经常由下面的问题清单来评审需求说明书是否“完整”。
　　1 编写的所有需求，其详细程度是否一致和合适？
　　2 需求是否能为设计提供足够的基础？
　　3 所有对其他需求的内部引用是否正确？
　　4 是否包含了每个需求的实现优先级？
　　5 是否定义了功能说明的内在算法？
　　6 是否包含了所有已知的客户需求或系统需求？
　　7 是否遗漏了必要的信息？如果有遗漏的话，把他们标记为待确定的问题（TBD）？
　　8 是否对所有预期的错误条件所产生的系统行为都编制了文档？
　　需求说明的完整性主要体现在需求说明的详细程度上，我们怎样判断该需求的描述是否详细呢？我认为需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应，等等。

四、 注意对需求方案的可行性和成本预算进行评审

　　需求方案的可行性和成本预算也是需求评审中的两个重要方面。需求方案的可行性和成本预算评审的目的，是从需求的多项方案中选择最优化的或者是性价比最高的方案。一般而言，需求说明书可以给出同一个问题的几种方案，并给出各自的优缺点和成本差异，经过比较由决策者作出最终选择。当我们理解了需求说明，我们下一步需要对其分析是否有可行性。如果可行性高，则还要考虑它需要哪些资源和预算。我们需要确定技术是否确实满足业务需求，同时， 也要考虑整个产品成本，包括开发人员、服务器、许可和升级费用，还需要考虑初始硬件、软件和支持、基础结构和培训的费用。

　　五、 注意对需求的质量属性进行评审
　　我们需要评审需求规格说明是否合理地确定了所有的性能目标，是否合理地确定了安全性方面要考虑到的问题。系统性能需求之所以在概念阶段即被要求，是因为现实的教训。君不见很多功能已经完善的系统因为性能上不达标，而被用户束之高阁——用户通常难以忍受运行或响应速度过慢的系统。
　　系统的安全性也是一个很重要的指标，尤其是作为企业级的系统，它的安全考量完全继承于组织对安全的基本诉求 。除了功能权限、字段级别权限外，数据间的授权关系也是必须考虑的，这本身也是一种业务规则。在“商机管理系统”需求分析中，“业务员A不能够查看业务员B下达的订单或相关信息”。所以，诸如此类的安全性需求在需求规格说明中是否被完整的描述，也是需求评审过程的一个硬性指标。总的说来，安全性包含了身份验证、访问控制、加密和审核等考虑事项。

　　六、 注意对需求的可实施性进行评审
　　是否对每个需求都设置了惟一性并且可以正确地识别它？是否每个功能需求都可以跟踪到高层需求（比如系统需求或用例）？
　　需求必须可以测试，每个需求在特定的输入条件下应当能给出已知的输出结果。同时，需求应当层次分明，需要把单个需求下面的相关需求综合在一起形成一组需求功能。
　　需求的可实施性除了可跟踪性还包括可测试性。事实上， 分析人员和测试人员在编写代码以前把需求模型，分析模型和测试用例综合起来通盘考虑，检查出遗漏的、错误的和不必要的需求。软件需求在概念上的测试是一种很必要的技术，它可以在项目早期阶段发现需求的歧义和错误。

　　七、 注意对需求包含的用例文档进行评审
　　用例是参与者对系统和参与者的交互过程所达成的一种契约。需求说明书基于用例的分析方法是也是当前较为流行的需求开发方式。用例文档作为需求重要的成果性文档也是需求评审主体之所在。需求评审确认的重点是对关键用户的最常用和最重要的用例进行深入和细致的评审，首先要通过测试用例的主干过程。

　　八、 注意需求评审会的过程和结束标准
　　通常，需求评审会都不是件容易的事情，业务审查人员分散在各个地域和时间上的不一致性是困难产生的所在。在很多情况下，我们可以使用分布式需求评审软件从网络上对需求文档进行预先评审，而在评审会中则要注意不要使评审会演变成了“业务会”或“技术研讨会”。同时，需求评审会的结果是对需求规格书完成了评审过程，那我们又如何判断审查的结束标准呢？请看如下几条建议：
　　1、审查期间评审员们提出的所有问题都已经解决。
　　2、相关文档中的所有更改都已经正确完成。
　　3、修订过的文档进行了拼写检查。
　　4、所有标识为TBD（待确定）的问题已经全部解决， 或者已经对每个TBD的问题的解决过程、计划解决的目标日期和责任解决人等编制了文档。
　　5、需求文档正式进入了配置库。