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

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