二、 注意对需求规格说明的实践性进行评审

    所谓实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度,而非源于分析师们经验主义的臆测。实践性是判断需求规格说明是不是理论联系实践、密切和用户联系的一个关键性指标。如果需求规格说明和用户实践脱离,即使看上去写得再天花乱坠,也会使需求说明如同无根之树、无源之水,会大大减低用户对需求报告本身的信任度。

    有经验的系统分析师通常会迷信自己的经验,把从前的经验嫁接到目前的企业需求分析中。也许由于行业性质相同,但如果不经过当前的实践调研则给出需求，仍然会无法体现出企业自身的特征。因而不能为企业带来真正的价值,也会造成与用户需求的鸿沟。

    笔者也曾经“轻实践重抽象”，我认为系统分析师的工作特点是站在具体案例上的深度抽象，前提是必须获得本企业的一手具体业务背景、流程和规则。

    我们在分析比如“任务跟踪”之类的系统时，由于系统的抽象模型是已知的(通过大量同类软件的分析得知)，但还是需要分析师把抽象模型演绎到企业当前业务现状。这样的需求分析才会有“实话实说”之效,才能引发评审者的共鸣。否则，在需求评审中评审者是很难读懂你的意图，自然不会立即通过你的需求报告，导致需要重新返工撰写需求报告。

    这使我想到毛主席当年倡导“理论联系实际”的深刻内涵。任何时刻,我们都要记住一个原则，即密切联系用户。诚然，需求分析需要方法也要理论支持,但最关键点仍然在于它本身是一种实践,需求分析实践直接来源于和用户的直接沟通和互动。

    三、 注意对需求规格说明的完整性进行评审

    我们经常由下面的问题清单来评审需求说明书是否”完整” 。

    1 编写的所有需求，其详细程度是否一致和合适?

    2 需求是否能为设计提供足够的基础?

    3 所有对其他需求的内部引用是否正确?

    4 是否包含了每个需求的实现优先级?

    5 是否定义了功能说明的内在算法?

    6 是否包含了所有已知的客户需求或系统需求?

    7 是否遗漏了必要的信息?如果有遗漏的话,把他们标记为待确定的问题(TBD) ?

    8 是否对所有预期的错误条件所产生的系统行为都编制了文档?

    需求说明的完整性主要体现在需求说明的详细程度上，我们怎样判断该需求的描述是否详细呢?我认为需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应，等等。

    让我们看一个功能需求例子,“FR1: 销售出货要考虑到信用额度”。

    乍看显得过于简单和含糊,我们把它修改成”FR1: 1 销售出货的前提是该客户拥有超过出货价值的信用额度, 否则,系统提示‘该客户信用额度不足,不予出货!’ 2 正式出货后系统将扣减其信用额度” 。

    很显然,修改后的需求把出货和信用额度的来由去向和系统的具体反应都说明清楚了。

    当然传统的需求描述也能够与用例中的参与者和系统响应等内容映射的。

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

    需求方案的可行性和成本预算也是需求评审中的两个重要方面。

    需求方案的可行性和成本预算评审的目的，是从需求的多项方案中选择最优化的或者是性价比高的方案。一般而言,需求说明书可以给出同一个问题的几种方案，并给出各自的优缺点和成本差异,经过比较由决策者作出最终选择。

    当我们理解了需求说明,我们下一步需要对其分析是否有可行性。

    如果可行性高,则还要考虑它需要哪些资源和预算。我们需要确定技术是否确实满足业务需求,同时, 也要考虑整个产品成本,包括开发人员、服务器、许可和升级费用,还需要考虑初始硬件、软件和支持、基础结构和培训的费用。

    五、 注意对需求的质量属性进行评审

    我们需要评审需求规格说明是否合理地确定了所有的性能目标，是否合理地确定了安全性方面要考虑到的问题。

    系统性能需求之所以在概念阶段即被要求,是因为现实的教训。君不见很多功能已经完善的系统因为性能上不达标,而被用户束之高阁——用户通常难以忍受运行或响应速度过慢的系统。

    系统的安全性也是一个很重要的指标,尤其是作为企业级的系统,它的安全考量完全继承于组织对安全的基本诉求 。除了功能权限、字段级别权限外,数据间的授权关系也是必须考虑的,这本身也是一种业务规则。在”商机管理系统”需求分析中,“业务员A不能够查看业务员B下达的订单或相关信息”。所以,诸如此类的安全性需求在需求规格说明中是否被完整的描述，也是需求评审过程的一个硬性指标。总的说来,安全性包含了身份验证、访问控制、加密和审核等考虑事项。