软件需求设计评审注意事项总结.doc

软件需求设计评审注意事项总结 1931 年, 中共中央代表欧阳钦在向党中央报告说明中央苏区情况时, 具体地说明了红一方面军的“三大纪律八项注意”, 此后三大纪律八项正式成为了全军和地方武装的纪律。本文所讨论的“八项注意”是对于软件需求设计评审工作的一些情况的说明。现在让我们把目光聚焦到软件需求设计评审上来, 我们已经知道如何去获取需求, 也知道了撰写需求规格说明书。现在的问题是, 我们所撰写的需求规格说明书是否能让用户接受呢? 而用户又如何对需求说明书作出理性和客观的评审和确认呢? 事实上, 当我们撰写需求规格说明书的时候不妨站在用户的角度去评写, 唯其如此方能事先避免一些问题。本文探讨用户应该如何去“评审”软件需求说明书, 并因此提出了需求评审的”八项注意”,以飨同仁。需求确认是需求开发过程的第四个阶段, 前三个阶段按顺序分别为需求获取、需求分析、编写需求规格说明。需求确认活动要力图确保如下几点:1 需求规格说明正确描述了预期的、满足各方涉众需求的系统能力和特征。 2 所述之软件需求是由系统需求、业务规格和其他来源中正确推导而来的。 3 需求是完整和高质量的。 4 需求的表示在所有地方都是一致的。 5 需求为产品设计和构造提供了基础。需求确认活动可以确保需求符合优秀需求陈述的特征,包括完整、正确、可行、必要、具有优先级、无二义性和可验证, 同时亦符合好的需求规格说明的特征,即完整性、一致性、易修改和可跟踪性。一般而言, 我们通过需求评审活动去实现需求确认的目标, 参与评审者应包括各级客户、开发人员和测试人员, 在整个审查过程中, 我们会有诸多“注意”。事实上, 在实践活动中, 每个企业会根据自身的情况存在更多的检查事项, 在此列出的八项亦属于最基本的要素。一、注意对需求规格说明的正确性进行评审需求规格说明的正确性通常可以从如下方面得以体现: 1 是否有需求与其他需求相互冲突或者重复? 通常一份长达几百页的需求规格说明书都不会是一蹴而就的, 它可能是系统分析师几个夜晚的心血之作。正是因为撰写过程的连续性,可能导致同一份文档中前后名词定义不一致, 前后观点上有重叠或差异的情况出现, 这需要我们在撰写报告前首先要在思想上形成统一概念, 可使术语列表贯穿整份文档以达提纲挈领之效。谈及此点, 让我想起在“商机管理系统”需求评审会上,火眼金睛的用户们发现了我的需求说明书中关于系统用户角色定义部分出现了前后不一致的情况。在该报告前文中我定义了该系统有二种角色,即“商机成员”、“商机管理成员”, 但在功能需求中我的报告中居然新生出一种“商机监理”角色,导致出现尴尬局面。事后总结其主要原因是在撰写报告的前期和后期阶段, 需求分析的思路有了明显的异动, 但却没有把文档前后更新一致, 这个教训是深刻的, 时至今日记忆犹新。 2 是否清晰、简洁、无二义地表达了每个需求? “清晰”是让人能够读懂;“简洁”是让人愿意去读;“无二义”决定”读”的效果, 是让大家对需求描述的理解能够达成一致。需求陈述是“三重门”, 这三扇门是否开启决定了需求说明书的质量高低。我们尤其要拒绝“二义性”的名词术语的出现, 似是而非的概念定义是需求书应该避免的。换句话说, 如果一份需求说明书没能给人以清晰、简洁和无二义的阐述,则需求评审是没有进行下去的必要,同时也无法进行下去。需求评审的前提是用户读懂了需求说明, 并且用户的理解内容就是分析师们所描述的内容。 3 是否每个需求都通过了演示、测试、评审,分析是否得到了验证? 需求应该是可以测试的, 通常通过测试去验证它是不是正确。比如我们完成了“销售员客户佣金提成规则”需求的撰写, 如果需求书未能经过原型测试通过, 则需求评审是不能得到通过的。面对相当复杂的业务需求, 经过测试或演示是让用户信任的一个必要过程。试想一下, 如果连需求都不能很好地被确认, 则开发实现阶段更是没有把握控制了。 4 是否每个需求都在项目的范围内? 划分项目范围和区分系统边界同样是需求说明书的一个任务, 不要对需求书作出超范围的论述和延伸,要知道需求书不是分析师卖弄概念、展示时尚的场所,它是软件工程的一个重要环节。 5 是否每个需求都没有内容和语法上的错误? 按照传统的需求列表方式, 需求像菜单一样被一条条列出来, 构成需求项的主要栏位包括: 需求 ID、需求描述、优先级、来源和状态等。通常需求首先要经过“拼写检查”, 保证没有拼写上的问题, 然后通过逐行浏览修改那些在内容或行文上出现问题的需求。 6 在现有的资源内, 是否能实现所有的需求? 需求规格说明要考虑可行性的问题。事实上, 分析师的关注层面是价值驱动和成本驱动方面。分析师应该明白不是所有的需求都要去实现, 一些看上去很明显与涉及用户有冲突的、费力不讨好的需求应该果断地舍弃。国内有专家提出, 搞需