软件需求设计评审 八项要点需注意[2]

    三、 注意对需求规格说明的完整性进行评审
    我们经常由下面的问题清单来评审需求说明书是否”完整” 。
    1、编写的所有需求，其详细程度是否一致和合适?
    2、需求是否能为设计提供足够的基础?
    3、所有对其他需求的内部引用是否正确?
    4、是否包含了每个需求的实现优先级?
    5、是否定义了功能说明的内在算法?
    6、是否包含了所有已知的客户需求或系统需求?
    7、是否遗漏了必要的信息?如果有遗漏的话,把他们标记为待确定的问题(TBD) ?
    8、是否对所有预期的错误条件所产生的系统行为都编制了文档?

    需求说明的完整性主要体现在需求说明的详细程度上，我们怎样判断该需求的描述是否详细呢?我认为需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应，等等。
    让我们看一个功能需求例子,“FR1: 销售出货要考虑到信用额度”。
    乍看显得过于简单和含糊,我们把它修改成”FR1: 1 销售出货的前提是该客户拥有超过出货价值的信用额度, 否则,系统提示‘该客户信用额度不足,不予出货!’ 2 正式出货后系统将扣减其信用额度” 。
    很显然,修改后的需求把出货和信用额度的来由去向和系统的具体反应都说明清楚了。
    当然传统的需求描述也能够与用例中的参与者和系统响应等内容映射的。

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

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

    六、 注意对需求的可实施性进行评审
    是否对每个需求都设置了惟一性并且可以正确地识别它？是否每个功能需求都可以跟踪到高层需求（比如系统需求或用例）?
    需求必须可以测试,每个需求在特定的输入条件下应当能给出已知的输出结果。同时,需求应当层次分明,需要把单个需求下面的相关需求综合在一起形成一组需求功能。
    需求的可实施性除了可跟踪性还包括可测试性。事实上, 分析人员和测试人员在编写代码以前把需求模型,分析模型和测试用例综合起来通盘考虑，检查出遗漏的、错误的和不必要的需求。软件需求在概念上的测试是一种很必要的技术，它可以在项目早期阶段发现需求的歧义和错误。
    正如Ross Collard所言：“用例和测试用例以两种方式协同作, 如果系统用例是完整的,准确而清晰的。那么测试用例的衍生过程就简明易懂。如果系统用例条理不清,那么要从中测试出来测试用例这一做法本身也将会帮助我们排除用例中的错误” 。

    七、 注意对需求包含的用例文档进行评审
    用例是参与者对系统和参与者的交互过程所达成的一种契约。需求说明书基于用例的分析方法是也是当前较为流行的需求开发方式。用例文档作为需求重要的成果性文档也是需求评审主体之所在。需求评审确认的重点是对关键用户的最常用和最重要的用例进行深入和细致的评审,首先要通过测试用例的主干过程。而我们是否撰写有效的用例则要从以下方面着手评审。
    1、用例的目标或价值度量是否明确?
    这一点是考察用例的编写是从用户角度还是从系统角度出发的。必须保证用例从用户角度出发,用例才有正确的目标。也就是说用例实际上是把用户作为参与者，以第一人称“我”与系统做种种交互的过程。而其中对过程的描述要让用户看上去很熟悉,如果用户看上去是如此的陌生，则说明你和用户的 沟通还没能达成“契约”。
    2、用例是否是独立的分散任务?
    3、是否明确说明可用用例会给哪些参与者带来用处?
    不要以为用例能给所有的涉众者带来用户,它只对当前的参与者和相关参与者带来价值,这就是用例的范围。事实上，分析师应该清楚所有涉众者对系统和用例的主要价值态度及其约束条件。
    4、编写用例的详细程度是否恰当?是否有不必要的设计和实现细节?
    用例不应该有任何的设计细节,更不能出现UI设计。 我们要确保参与者是以黑盒子看系统的,这样化繁为简的思路,正是系统分析分层次目的所在。
    5、所有预期的分支过程是否都编写了文档说明?
    参与者的动作和系统的响应构成用例过程的主题,所以必须是尽可能的客观和详细的。
    6、所有预估的异常过程是否都编写了文档说明?
    参与者异常过程将转化成设计的异常处理机制,所以是必不可少的,我们绝对不敢使用没有任何异常处理的应用程序的。
    7、是否存在一些普通的动作序列可以分解成独立的用例?
    用例之间也有可复用的,能够把公共的动作序列独立出来，用例达到可复用的目标也是用例撰写要考虑的。
    8、每个路径的步骤是否都清晰明了,无歧义而且完整?
    用例中的主干过程、分支过程、异常处理的每个步骤都建议使用主动结构来陈述,即参与者要干什么、系统要响应什么,一步一步地描述直到完成整个用例流程。这个用例通常会是参与者完成了一个业务或任务流程。
    9、用例中的每个参与者和步骤是否都与所执行的任务有关?
    要防止用例目标和用例描述出现了文不对题或牛头马面的现象。
    10、用例中定义的每个可选路径是否都可行和可验证?
    用例描述与用例图的每个动作序列保持一致，是可以经过验证和系统执行通过的。
    11、用例的前置条件和后置条件是否合理?
    分析师必须确认用例的前置条件和后置条件准确界定了用例的边界范围,区分了用例和用例之间的界限。
    分析师经常会发现在检查一个包含九个步骤的用例时,发现执行完第六个步骤就满足了后置条件,第七、八、九在用例的边界之外,很显然是不必要的。同样,用例的前置条件必须是启动在第一个步骤就已经满足。

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

    本文阐述了需求评审和确认的一些”注意”事项，一旦完成需求评审将表示进入了需求设计阶段，欲知需求设计如何实现，且听下文为您分解。

原文转自：http://www.ltesting.net