评审活动指南(需求规格说明书评审)(1).docVIP

中国科学院研究生院 计算与通讯工程学院 第 PAGE 第 PAGE 1页(共 NUMPAGES 7页) 需求规格说明书评审 活动指南 目录 TOC \o 1-5 \h \z 1 前言 3 2 概述 3 3 目的 3 4 评审时机 5 5 评审方式 6 6 评审角色与职责 6 7 其他 7  前言 本指南的写作目的是对需求规格说明书评审活动进行解释和建议，有少量的强制性规定。主要内容包括需求规格说明书评审的目的、方式、时机、参与角色和职责等，供项目组中相关人员阅读参考，也可在评审时作为附件供评审员参考。 概述 需求规格说明书评审是技术评审活动的一种，对于技术评审，《技术评审规程》是组织级的活动规程，SQA工程师将依据《技术评审规程》对评审活动进行检查，本文中包含黑体“必须”字样的内容为强制性规定，与《技术评审规程》具有同等效力，也是SQA工程师检查的依据。 对一个成功的软件项目来说，最重要的是理解需要解决的问题和如何解决它。需求规格说明书正是项目组对于需要解决的问题的理解，正确的理解用户的需求，是项目成功的基础。 需求规格说明书是项目组对于用户需求进行分析后的产物，是问题域到解域的映射，产生的过程主要依赖于作者的智力活动和沟通交流。这个过程的质量，通常比较难以控制，评审是对其质量进行检查的一种方式。 对于不同生命周期的项目，本文中的“需求规格说明书”的含义是不一样的。 对于瀑布式生命周期，需求规格说明书是需求分析阶段结束后的工作产品； 对于原型法生命周期，通常需求规格说明书和原型一起做为需求分析活动的工作产品，本文中的“需求规格说明书”可以理解为需求规格说明书和原型的统称； 对于USDP（统一软件开发过程），由于整个需求是在多次迭代中分别进行考虑的，不同的迭代中，考虑的需求内容不同，本文中的“需求规格说明书”可以理解为本次迭代中准备考虑的需求的规格说明。 目的 需求规格说明书（简称“SRS”）评审的目的包括：一、通过评审，发现缺陷和问题，提高需求规格说明书的质量；二、通过评审，使得需求规格说明书在评审人员中达成一致；三、确定需求规格说明书是否可以作为下一阶段开发活动的基础。 需求规格说明书的质量包括两个方面，一是其中每个需求项的说明质量；二是整个需求规格说明书的质量。 需求项的说明质量，包括以下属性： 完整性 每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。 正确性 每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如用户或高层的需求需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。只有用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。没有用户参与的需求评审将导致此类说法：“那些毫无意义，这些才很可能是他们所想要的。”其实这完全是评审者凭空猜测。 可行性 每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求，最好在获取（elicitation）需求（收集需求）过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。 必要性 每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。 划分优先级 给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度。 无二义性 对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。 可验证性 检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的。 需求规格说明书的质量属性包括： 完整性 不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务而不是系统的功能将有助于你避免不完整性。如果知道缺少某项信息，用TBD (“待确定” )作为标准标识来标明这项缺漏。在开始开发之前，必须解决需求中所有的TBD项。 一致性 一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。在开发前必须解决所有需求间的不一致部分。只有进行一番调查研究，才能知道某一项需求是否确实正确。 可修改性 在必要时或为维护每一需求变更历