软件需求设计评审的八项要点需注意

《软件需求设计评审的八项要点需注意》由会员分享，可在线阅读，更多相关《软件需求设计评审的八项要点需注意（8页珍藏版）》请在金锄头文库上搜索。

1、软件需求设计评审的/顷要点需注意软件需求设计评审的八项要点需注意引言：本文所讨论的“八项注意”是对于软件需求设计评审工作 的一些情况的说明。现在让我们把目光聚焦到软件需求设计评审上来，我们已经知道 如何去获取需求，也知道了撰写需求规格说明书。现在的问题是，所 撰写的需求规格说明书是否能让用户接受呢？而用户又如何对需求说 明书作出理性和客观的评审和确认呢？事实上，当我们撰写需求规格 说明书时，不妨站在用户的角度去评写，如此可事先避免一些问题。 本文探讨用户应该如何去评审”软件需求说明书，并因此提出了需 求评审的“八项注意”，以飨同仁。需求确认是需求开发过程的第四个阶段，前三个阶段按顺序分别 为需

2、求获取、需求分析、编写需求规格说明。需求确认活动要力图确 保如下几点：1.需求规格说明正确描述了预期的、满足各方涉众需求 的系统能力和特征。2. 所述之软件需求是由系统需求、业务规格和其他来源中正确推 导而来的。3. 需求是完整和高质量的。4. 需求的表示在所有地方都是一致的。5. 需求为产品设计和构造提供了基础。需求确认活动可以确保需求符合优秀需求陈述的特征，包括完整、 正确、可行、必要、具有优先级、无二义性和可验证，同时亦符合好的需求规格说明的特征，即完整性、一致性、易修改和可 跟踪性。一般而言，我们通过需求评审活动去实现需求确认的目标，参与 评审者应包括各级客户、开发人员和测试人员，在整

3、个审查过程中， 我们会有诸多“注意”。事实上，在实践活动中，每个企业会根据自 身的情况存在更多的检查事项，在此列出的八项亦属于最基本的要素。一、注意对需求规格说明的正确性进行评审需求规格说明的正确性通常可以从如下方面得以体现：1是否有 需求与其他需求相互冲突或者重复？通常一份长达几百页的需求规格说明书都不会是一蹴而就的，它 可能是系统分析师几个夜晚的心血之作。正是因为撰写过程的连续性， 可能导致同一份文档中前后名词定义不一致，前后观点上有重叠或差 异的情况出现，这需要我们在撰写报告前首先要在思想上形成统一概 念，可使术语列表贯穿整份文档以达提纲挈领之效。谈及此点，让我想起在商机管理系统”需求评

4、审会上，火眼金 睛的用户们发现了我的需求说明书中关于系统用户角色定义部分出现 了前后不一致的情况。在该报告前文中我定义了该系统有二种角色， 即商机成员”、“商机管理成员”，但在功能需求中我的报告中居 然新生出一种商机监理”角色，导致出现尴尬局面。事后总结其主 要原因是在撰写报告的前期和后期阶段，需求分析的思路有了明显的异动，但却没有把文档前后更新一致，这个教训是深刻的， 时至今日记忆犹新。2是否清晰、简洁、无二义地表达了每个需求？“清晰”是让人能够读懂：“简洁”是让人愿意去读：“无二义 决定读”的效果，是让大家对需求描述的理解能够达成一致.需求陈 述是三重门”，这三扇门是否开启决定了需求说明书

5、的质量高低。我们尤其要拒绝二义性的名词术语的出现，似是而非的概念 定义是需求书应该避免的。换句话说，如果一份需求说明书没能给人 以清晰、简洁和无二义的阐述，则需求评审是没有进行下去的必要， 同时也无法进行下去。需求评审的前提是用户读懂了需求说明，并且 用户的理解内容就是分析师们所描述的内容。3是否每个需求都通过了演示、测试、评审，分析是否得到了验 证？需求应该是可以测试的，通常通过测试去验证它是不是正确。比 如我们完成了 销售员客户佣金提成规则”需求的撰写，如果需求书 未能经过原型测试通过，则需求评审是不能得到通过的。面对相当复 杂的业务需求，经过测试或演示是让用户信任的一个必要过程。试想 一

6、下，如果连需求都不能很好地被确认，则开发实现阶段更是没有把 握控制了。4是否每个需求都在项目的范围内？划分项目范围和区分系统边界同样是需求说明书的一个任务，不 要对需求书作出超范围的论述和延伸，要知道需求书不是分析师卖弄 概念、展示时尚的场所，它是软件工程的一个重要环节。5是否每个需求都没有内容和语法上的错误？按照传统的需求列表方式，需求像菜单一样被一条条列出来，构 成需求项的主要栏位包括：需求ID、需求描述、优先级、来源和状态 等。通常需求首先要经过拼写检查”，保证没有拼写上的问题，然 后通过逐行浏览修改那些在内容或行文上出现问题的需求。6在现有的资源内，是否能实现所有的需求？需求规格说明要

7、考虑可行性的问题。事实上，分析师的关注层面 是价值驱动和成本驱动方面。分析师应该明白不是所有的需求都要去 实现，一些看上去很明显与涉及用户有冲突的、费力不讨好的需求应 该果断地舍弃。国内有专家提出，搞需求也要讲和谐”即是此中道 理。举例而言，企业中的用户可分为三种类型：决策层用户、管理层 用户、操作层用户。每种用户所代表的价值取向是不同的，决策和管 理层希望系统处理业务是业务安全优先的，而操作系统用户则是更多 地考虑方便性的。国内某电子贸易公司，从自身业务安全考虑，规定 了系统不允许“借货”，意即代理商的产品直接发到客户根本不经过 本贸易公司的物流部门。如果操作层用户提出了这样的“借货”需求，

8、 倒是可以方便他的日常处理，但却违背了公司的根本利益。很显然， 这样的需求肯定是有所不为的。7每一条特定的错误信息，是否都是唯一的和具有含义的？不要忽视错误信息的定义，它必须具有唯一性。如果过于笼统地 定义错误信息则和没有定义的效果是一样的。二、注意对需求规格说明的实践性进行评审所谓实践性是指需求本身是否来源于目前企业的相关业务规则和 文件制度，而非源于分析师们经验主义的臆测。实践性是判断需求规 格说明是不是理论联系实践、密切和用户联系的一个关键性指标。如 果需求规格说明和用户实践脱离，即使看上去写得再天花乱坠，也会 使需求说明如同无根之树、无源之水，会大大减低用户对需求报告本 身的信任度。有

9、经验的系统分析师通常会迷信自己的经验，把从前的经验嫁接 到目前的企业需求分析中。也许由于行业性质相同，但如果不经过当 前的实践调研则给出需求，仍然会无法体现出企业自身的特征。因而 不能为企业带来真正的价值，也会造成与用户需求的鸿沟。笔者也曾经轻实践重抽象”，我认为系统分析师的工作特点是 站在具体案例上的深度抽象，前提是必须获得本企业的一手具体业务 背景、流程和规则。我们在分析比如“任务跟踪”之类的系统时，由于系统的抽象模 型是已知的（通过大量同类软件的分析得知），但还是需要分析师把 抽象模型演绎到企业当前业务现状。这样的需求分析才会有“实话实 说”之效，才能引发评审者的共鸣。否则，在需求评审中

10、评审者是很难读懂你的意图，自然不会立即通过你的需求报告，导致需要重 新返工撰写需求报告。这使我想到毛主席当年倡导理论联系实际”的深刻内涵。任何 时刻，我们都要记住一个原则，即密切联系用户。诚然，需求分析需 要方法也要理论支持，但最关键点仍然在于它本身是一种实践，需求 分析实践直接来源于和用户的直接沟通和互动。三、注意对需求规格说明的完整性进行评审我们经常由下面的问题清单来评审需求说明书是否完整”.1编 写的所有需求，其详细程度是否一致和合适？2需求是否能为设计提供足够的基础？3所有对其他需求的内部引用是否正确？4是否包含了每个需求的实现优先级？5是否定义了功能说明的内在算法？6是否包含了所有已

11、知的客户需求或系统需求？7是否遗漏了必要的信息？如果有遗漏的话，把他们标记为待确 定的问题（TBD）？8是否对所有预期的错误条件所产生的系统行为都编制了文档？ 需求说明的完整性主要体现在需求说明的详细程度上，我们怎样 判断该需求的描述是否详细呢？我认为需求需要精化，而不是仅仅提 出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、 受什么业务规则和条件限制、系统会有什么响应，等等。让我们看一个功能需求例子，“FR1：销售出货要考虑到信用额 度”。乍看显得过于简单和含糊，我们把它修改成“FR1： 1销售出货 的前提是该客户拥有超过出货价值的信用额度，否则，系统提示该 客户信用额度不足，

12、不予出货！ 2正式出货后系统将扣减其信用额 度.很显然，修改后的需求把出货和信用额度的来由去向和系统的具 体反应都说明清楚了。当然传统的需求描述也能够与用例中的参与者和系统响应等内容 映射的。四、注意对需求方案的可行性和成本预算进行评审需求方案的可行性和成本预算也是需求评审中的两个重要方面。需求方案的可行性和成本预算评审的目的，是从需求的多项方案 中选择最优化的或者是性价比最高的方案。一般而言，需求说明书可 以给出同一个问题的几种方案，并给出各自的优缺点和成本差异，经 过比较由决策者作出最终选择。当我们理解了需求说明，我们下一步需要对其分析是否有可行性。如果可行性高，则还要考虑它需要哪些资源和

13、预算。我们需要确 定技术是否确实满足业务需求，同时，也要考虑整个产品成本，包括 开发人员、服务器、许可和升级费用，还需要考虑初始硬件、软件和 支持、基础结构和培训的费用。五、注意对需求的质量属性进行评审我们需要评审需求规格说明是否合理地确定了所有的性能目标， 是否合理地确定了安全性方面要考虑到的问题。系统性能需求之所以在概念阶段即被要求，是因为现实的教训。 君不见很多功能已经完善的系统因为性能上不达标，而被用户束之高 阁用户通常难以忍受运行或响应速度过慢的系统。系统的安全性也是一个很重要的指标，尤其是作为企业级的系统， 它的安全考量完全继承于组织对安全的基本诉求.除了功能权限、字段 级别权限外

14、，数据间的授权关系也是必须考虑的，这本身也是一种业 务规则。在商机管理系统”需求分析中，业务员A不能够查看业 务员B下达的订单或相关信息”。所以，诸如此类的安全性需求在需 求规格说明中是否被完整的描述，也是需求评审过程的一个硬性指标。 总的说来，安全性包含了身份验证、访问控制、加密和审核等考虑事 项。六、注意对需求的可实施性进行评审是否对每个需求都设置了惟一性并且可以正确地识别它？是否每 个功能需求都可以跟踪到高层需求（比如系统需求或用例）？需求必须可以测试，每个需求在特定的输入条件下应当能给出已 知的输出结果。同时，需求应当层次分明，需要把单个需求下面的相 关需求综合在一起形成一组需求功能。

15、需求的可实施性除了可跟踪性还包括可测试性。事实上，分析人 员和测试人员在编写代码以前把需求模型，分析模型和测试用例综合 起来通盘考虑，检查出遗漏的、错误的和不必要的需求。软件需求在概念上的测试是一种很必要的技术，它可以在项目早期阶段发 现需求的歧义和错误。正如Ross Collard所言：用例和测试用例以两种方式协同作， 如果系统用例是完整的，准确而清晰的。那么测试用例的衍生过程就 简明易懂。如果系统用例条理不清，那么要从中测试出来测试用例这 一做法本身也将会帮助我们排除用例中的错误”.七、注意对需求包含的用例文档进行评审用例是参与者对系统和参与者的交互过程所达成的一种契约。需 求说明书基于用

16、例的分析方法是也是当前较为流行的需求开发方式。 用例文档作为需求重要的成果性文档也是需求评审主体之所在。需求 评审确认的重点是对关键用户的最常用和最重要的用例进行深入和细 致的评审，首先要通过测试用例的主干过程。而我们是否撰写有效的 用例则要从以下方面着手评审。1用例的目标或价值度量是否明确？这一点是考察用例的编写是从用户角度还是从系统角度出发的。 必须保证用例从用户角度出发，用例才有正确的目标。也就是说用例 实际上是把用户作为参与者，以第一人称我”与系统做种种交互的 过程。而其中对过程的描述要让用户看上去很熟悉，如果用户看上去 是如此的陌生，则说明你和用户的沟通还没能达成契约”。2用例是否是独立的分散任务？3是否明确说明可用用例会给哪些参与者带来用处？