《软件需求设计评审注意事项总结》由会员分享，可在线阅读，更多相关《软件需求设计评审注意事项总结（7页珍藏版）》请在金锄头文库上搜索。
1、软件需求设计评审注意事项总结.txt22 真诚是美酒，年份越久越醇香浓型；真诚是焰火， 在高处绽放才愈是美丽；真诚是鲜花，送之于人手有余香。一颗孤独的心需要爱的滋润；一 颗冰冷的心需要友谊的温暖；一颗绝望的心需要力量的托慰；一颗苍白的心需要真诚的帮助； 一颗充满戒备关闭的门是多么需要真诚这一把钥匙打开呀！1931 年，中共中央代表欧阳钦 在向党中央报告说明中央苏区情况时，具体地说明了红一方面军的“三大纪律八项注意”, 此后三大纪律八项正式成为了全军和地方武装的纪律。本文所讨论的“八项注意”是对于软 件需求设计评审工作的一些情况的说明。 现在让我们把目光聚焦到软件需求设计评审上来, 我们已经知道
2、如何去获取需求,也知道了 撰写需求规格说明书。现在的问题是,我们所撰写的需求规格说明书是否能让用户接受呢? 而用户又如何对需求说明书作出理性和客观的评审和确认呢? 事实上，当我们撰写需求规格 说明书的时候不妨站在用户的角度去评写，唯其如此方能事先避免一些问题。本文探讨用户 应该如何去“评审”软件需求说明书，并因此提出了需求评审的”八项注意” ，以飨同仁。 需求确认是需求开发过程的第四个阶段,前三个阶段按顺序分别为需求获取、需求分析、编 写需求规格说明。需求确认活动要力图确保如下几点: 1 需求规格说明正确描述了预期的、满足各方涉众需求的系统能力和特征。 2 所述之软件需求是由系统需求、业务规格
3、和其他来源中正确推导而来的。 3 需求是完整和高质量的。 4 需求的表示在所有地方都是一致的。 5 需求为产品设计和构造提供了基础。 需求确认活动可以确保需求符合优秀需求陈述的特征，包括完整、正确、可行、必要、具有 优先级、无二义性和可验证, 同时亦符合好的需求规格说明的特征，即完整性、一致性、易 修改和可跟踪性。 一般而言，我们通过需求评审活动去实现需求确认的目标, 参与评审者应包括各级客户、开 发人员和测试人员, 在整个审查过程中，我们会有诸多“注意” 。事实上,在实践活动中,每 个企业会根据自身的情况存在更多的检查事项, 在此列出的八项亦属于最基本的要素。 一、 注意对需求规格说明的正确
4、性进行评审 需求规格说明的正确性通常可以从如下方面得以体现： 1 是否有需求与其他需求相互冲突或者重复？ 通常一份长达几百页的需求规格说明书都不会是一蹴而就的，它可能是系统分析师几个夜晚 的心血之作。正是因为撰写过程的连续性，可能导致同一份文档中前后名词定义不一致，前 后观点上有重叠或差异的情况出现，这需要我们在撰写报告前首先要在思想上形成统一概念, 可使术语列表贯穿整份文档以达提纲挈领之效。 谈及此点,让我想起在“商机管理系统”需求评审会上，火眼金睛的用户们发现了我的需求 说明书中关于系统用户角色定义部分出现了前后不一致的情况。在该报告前文中我定义了该 系统有二种角色，即“商机成员” 、 “
5、商机管理成员”,但在功能需求中我的报告中居然新生 出一种“商机监理”角色，导致出现尴尬局面。 事后总结其主要原因是在撰写报告的前期 和后期阶段,需求分析的思路有了明显的异动，但却没有把文档前后更新一致，这个教训是 深刻的，时至今日记忆犹新。 2 是否清晰、简洁、无二义地表达了每个需求? “清晰”是让人能够读懂；“简洁”是让人愿意去读；“无二义”决定”读”的效果,是让 大家对需求描述的理解能够达成一致 。 需求陈述是“三重门”,这三扇门是否开启决定了需求说明书的质量高低。 我们尤其要拒绝“二义性”的名词术语的出现, 似是而非的概念定义是需求书应该避免的。 换句话说,如果一份需求说明书没能给人以清
6、晰、简洁和无二义的阐述，则需求评审是没有 进行下去的必要，同时也无法进行下去。需求评审的前提是用户读懂了需求说明,并且用户 的理解内容就是分析师们所描述的内容。 3 是否每个需求都通过了演示、测试、评审，分析是否得到了验证? 需求应该是可以测试的,通常通过测试去验证它是不是正确。比如我们完成了“销售员客户 佣金提成规则”需求的撰写,如果需求书未能经过原型测试通过,则需求评审是不能得到通过 的。 面对相当复杂的业务需求,经过测试或演示是让用户信任的一个必要过程。试想一下, 如果连需求都不能很好地被确认，则开发实现阶段更是没有把握控制了。 4 是否每个需求都在项目的范围内? 划分项目范围和区分系统
7、边界同样是需求说明书的一个任务，不要对需求书作出超范围的论 述和延伸，要知道需求书不是分析师卖弄概念、展示时尚的场所，它是软件工程的一个重要 环节。 5 是否每个需求都没有内容和语法上的错误? 按照传统的需求列表方式，需求像菜单一样被一条条列出来，构成需求项的主要栏位包括： 需求 ID、 需求描述、优先级、来源和状态等。 通常需求首先要经过“拼写检查” ，保证没 有拼写上的问题，然后通过逐行浏览修改那些在内容或行文上出现问题的需求。 6 在现有的资源内, 是否能实现所有的需求? 需求规格说明要考虑可行性的问题。事实上，分析师的关注层面是价值驱动和成本驱动方面。 分析师应该明白不是所有的需求都要
8、去实现，一些看上去很明显与涉及用户有冲突的、费力不讨好的需求应该果断地舍弃。国内有专家提出，搞需求也要讲“和谐”即是此中道理。 举例而言，企业中的用户可分为三种类型：决策层用户、管理层用户、操作层用户。每种用 户所代表的价值取向是不同的，决策和管理层希望系统处理业务是业务安全优先的，而操作 系统用户则是更多地考虑方便性的。国内某电子贸易公司，从自身业务安全考虑，规定了系 统不允许“借货”,意即代理商的产品直接发到客户根本不经过本贸易公司的物流部门。如 果操作层用户提出了这样的“借货”需求,倒是可以方便他的日常处理,但却违背了公司的根 本利益。很显然，这样的需求肯定是有所不为的。 7 每一条特定
9、的错误信息，是否都是唯一的和具有含义的? 不要忽视错误信息的定义, 它必须具有唯一性。如果过于笼统地定义错误信息则和没有定义 的效果是一样的。 二、 注意对需求规格说明的实践性进行评审 所谓实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度,而非源于分析师 们经验主义的臆测。实践性是判断需求规格说明是不是理论联系实践、密切和用户联系的一 个关键性指标。如果需求规格说明和用户实践脱离,即使看上去写得再天花乱坠,也会使需求 说明如同无根之树、无源之水,会大大减低用户对需求报告本身的信任度。 有经验的系统分析师通常会迷信自己的经验,把从前的经验嫁接到目前的企业需求分析中。 也许由于行业性质
10、相同,但如果不经过当前的实践调研则给出需求，仍然会无法体现出企业 自身的特征。因而不能为企业带来真正的价值,也会造成与用户需求的鸿沟。 笔者也曾经“轻实践重抽象” ，我认为系统分析师的工作特点是站在具体案例上的深度抽象， 前提是必须获得本企业的一手具体业务背景、流程和规则。 我们在分析比如“任务跟踪”之类的系统时，由于系统的抽象模型是已知的(通过大量同类 软件的分析得知)，但还是需要分析师把抽象模型演绎到企业当前业务现状。这样的需求分 析才会有“实话实说”之效,才能引发评审者的共鸣。否则，在需求评审中评审者是很难读 懂你的意图，自然不会立即通过你的需求报告，导致需要重新返工撰写需求报告。 这使
11、我想到毛主席当年倡导“理论联系实际”的深刻内涵。任何时刻,我们都要记住一个原 则，即密切联系用户。诚然，需求分析需要方法也要理论支持,但最关键点仍然在于它本身 是一种实践,需求分析实践直接来源于和用户的直接沟通和互动。三、 注意对需求规格说明的完整性进行评审 我们经常由下面的问题清单来评审需求说明书是否”完整” 。 1 编写的所有需求，其详细程度是否一致和合适? 2 需求是否能为设计提供足够的基础? 3 所有对其他需求的内部引用是否正确? 4 是否包含了每个需求的实现优先级? 5 是否定义了功能说明的内在算法? 6 是否包含了所有已知的客户需求或系统需求? 7 是否遗漏了必要的信息?如果有遗漏
12、的话,把他们标记为待确定的问题(TBD) ? 8 是否对所有预期的错误条件所产生的系统行为都编制了文档? 需求说明的完整性主要体现在需求说明的详细程度上，我们怎样判断该需求的描述是否详细 呢?我认为需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、 需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应，等等。 让我们看一个功能需求例子,“FR1: 销售出货要考虑到信用额度” 。 乍看显得过于简单和含糊,我们把它修改成”FR1: 1 销售出货的前提是该客户拥有超过出货 价值的信用额度, 否则,系统提示该客户信用额度不足,不予出货! 2 正式出货后系统将 扣减其信用额度
13、” 。 很显然,修改后的需求把出货和信用额度的来由去向和系统的具体反应都说明清楚了。 当然传统的需求描述也能够与用例中的参与者和系统响应等内容映射的。四、 注意对需求方案的可行性和成本预算进行评审 需求方案的可行性和成本预算也是需求评审中的两个重要方面。 需求方案的可行性和成本预算评审的目的，是从需求的多项方案中选择最优化的或者是性价 比最高的方案。一般而言,需求说明书可以给出同一个问题的几种方案，并给出各自的优缺 点和成本差异,经过比较由决策者作出最终选择。 当我们理解了需求说明,我们下一步需要对其分析是否有可行性。 如果可行性高,则还要考虑它需要哪些资源和预算。我们需要确定技术是否确实满足
14、业务需 求,同时, 也要考虑整个产品成本,包括开发人员、服务器、许可和升级费用,还需要考虑初 始硬件、软件和支持、基础结构和培训的费用。 五、 注意对需求的质量属性进行评审 我们需要评审需求规格说明是否合理地确定了所有的性能目标，是否合理地确定了安全性方面要考虑到的问题。 系统性能需求之所以在概念阶段即被要求,是因为现实的教训。君不见很多功能已经完善的 系统因为性能上不达标,而被用户束之高阁用户通常难以忍受运行或响应速度过慢的系 统。 系统的安全性也是一个很重要的指标,尤其是作为企业级的系统,它的安全考量完全继承于组 织对安全的基本诉求 。除了功能权限、字段级别权限外,数据间的授权关系也是必须
15、考虑的,这 本身也是一种业务规则。在”商机管理系统”需求分析中,“业务员 A 不能够查看业务员 B 下达的订单或相关信息” 。所以,诸如此类的安全性需求在需求规格说明中是否被完整的描述， 也是需求评审过程的一个硬性指标。总的说来,安全性包含了身份验证、访问控制、加密和 审核等考虑事项。 六、 注意对需求的可实施性进行评审 是否对每个需求都设置了惟一性并且可以正确地识别它？是否每个功能需求都可以跟踪到高 层需求（比如系统需求或用例）? 需求必须可以测试,每个需求在特定的输入条件下应当能给出已知的输出结果。同时,需求应 当层次分明,需要把单个需求下面的相关需求综合在一起形成一组需求功能。 需求的可
16、实施性除了可跟踪性还包括可测试性。事实上, 分析人员和测试人员在编写代码以 前把需求模型,分析模型和测试用例综合起来通盘考虑，检查出遗漏的、错误的和不必要的 需求。软件需求在概念上的测试是一种很必要的技术，它可以在项目早期阶段发现需求的歧 义和错误。 正如 Ross Collard 所言：“用例和测试用例以两种方式协同作, 如果系统用例是完整的,准 确而清晰的。那么测试用例的衍生过程就简明易懂。如果系统用例条理不清,那么要从中测 试出来测试用例这一做法本身也将会帮助我们排除用例中的错误” 。 七、 注意对需求包含的用例文档进行评审 用例是参与者对系统和参与者的交互过程所达成的一种契约。需求说明书基于用例的分析方 法是也是当前较为流行的需求开发方式。用例文档作为需求重要的成果性文档也是需求评审 主体之所在。需求评审确认的重点是对关键用户的最常用和最重要的用例进行深入和细致的 评审,首先要通过测试用例的主干过程。而我们是否撰写有效的用例则要从以下方面着手评 审。 1 用例的目标或价值度量是否明确? 这一点是考察用例的编写是从用户角度还是从系统角度出发的。必须保证用例从用户角度
