我的ITblog我作主　　关注→　『伊波拉』→　测试　SzDlinXie- ITblog　　 　　

　软件需求过程包括了5个主要活动：需求获取、需求分析和确认、编写需求规格说明书、需求验证和需求管理。

　需求获取

　需求的收集、分析、细化、核实并组织的步骤，并将它编写成文档。这个活动包括了编写项目视图和范围文档、用户群分类、选择用户代表、建立核心队伍、确定使用实例、召开联合会议、分析用户工作流程、确定质量属性、检查问题报告和需求重用10个具体任务，文章将在后面进行详细的阐述。

　需求分析

　根据需求获取中得到的需求文档，分析系统实现方案。这个活动需要完成下面几个任务：
　　
　   1、绘制关联图，用于定义系统与系统外部实体间的边界和接口的简单模型；

　2、创建开发原型，当开发人员或用户不能明确某些需求时，开发一个系统原型，这样使得许多概念和可能发生的事更为直观明了；

　3、分析可行性，在允许的成本、性能要求下，分析每项需求实施的可行性，明确每项需求实现相联系的风险，包括与其它需求的冲突，涉及各类用户的利益平衡，对外界因素的依赖和技术障碍；

　4、确定需求优先级：分析方法来确定使用实例、系统特性或单项需求实现的优先级别，以优先级为基础确定产品版本将包括哪些特性或哪类需求；

　5、为需求建立模型，为需求建立图形分析模型是软件需求规格说明极好的补充说明，可以为系统需求从多个角度建模；

　6、编写数据字典，创建数据字典数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义；

　7、应用质量功能调配，将系统特性、属性与对客户的重要性联系起来，提供了一种分析方法以明确哪些是客户最为关注的特性。
　编写需求规格说明书

　需求开发的最终成果是客户和开发小组对将要开发的产品达成一致协议，这一协议就是通过文档化的需求规格说明书来体现。需求规格说明书包括项目视图和范围文档说明了系统的业务需求，而使用实例文档则说明了用户需求。这个活动需要完成下面几个任务：

　1、采用模版,在你的组织中要为编写软件需求规格说明书等文档定义一种标准模板,该模板为记录系统需求和各种其它与需求相关的重要信息提供了统一的结构；

　2、指明需求来源，为了让所有项目风险承担者明白需求规格说明书中为何提供这些功能需求，要能追溯每项需求的来源，来源可能是一种使用实例或其它客户要求，也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源，这些来源应该记录在需求的跟踪能力矩阵中；

　3、为每项需求注上标号，为了需求的可跟踪性和可修改性的质量标准，必须唯一确定每个软件需求，为制定一种惯例来为需求规格说明书中的每项需求提供一个独立的可识别的标号或记号;

　4、记录业务规范，是指关于系统的操作原则，比如谁能在什么情况下采取什么动作,将这些编写成需求规格说明书中的一个独立部分，或一独立的业务规范文档;

　5、创建需求跟踪能力矩阵，建立一个矩阵把每项需求来源、定义与实现、测试它的设计和代码部分联系起来,这样有利于需求的管理和需求变更影响范围的评估。

　需求验证

　需求的验证是为了确保需求说明准确、完整，表达必要的质量特点,需求将要作为系统设计和最终验证的依据,因此一定要保证它的正确性。需求验证务必确保符合完整性、正确性、灵活性、必要性、无二义性、一致性、可跟踪性及可验证性这些良好特征。这个活动需要完成下面几个任务：

　1、审查需求文档，对需求文档进行正式审查是保证软件质量的有效的方法。组织一个由不同代表（如用户，分析人员，设计人员，测试人员）组成的小组，对需求规格说明书及相关模型进行仔细的检查；

　2、依据需求编写测试用例，根据用户需求所要求的产品特性写出系统的功能测试用例作为系统测试依据；

　3、编写用户手册，在需求开发早期即可起草一份用户手册，用它作为需求规格说明的参考并辅助需求分析;

　4、确定合格的标准，需求说明中描述什么样的产品才算满足用户的要求和适合他们使用的，将合格的测试建立在使用情景描述或使用实例的基础之上。

　需求管理

　需求管理是组织、控制和文档化需求的系统方法，也是一种建立和维护用户和开发组织对于改变系统功能的协议。需求开发的结果经验证批准就定义了开发工作的需求基线,这个基线在客户和开发人员之间就构筑了一个需求约定，需求管理包括在项目进展过程中维持需求约定一致性和精确性的活动。现在很多商业化的需求管理工具都能很好的支持需求管理活动。这个活动需要完成下面几个任务：

　1、确定变更控制过程,确定一个选择、分析和决策需求变更的过程,所有的需求变更都需遵循此流程;

　2、建立软件变更控制委员会(SCCB，Software Change Control Board),组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来评估和确定需求变更;

　3、进行变更影响分析,评估需求变更对项目进度、资源、工作量和项目范围以及其它需求的影响;

　4、跟踪变更影响的产品,当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计文档、源代码和测试用例，这些相关部分可能也需要修改；

　5、建立基准和控制版本,需求文档确定一个基线，这是一致性需求在特定时刻的快照，之后的需求变更就遵循变更控制过程即可;

　6、维护变更的历史记录,记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等情况;

　7、跟踪每项需求的状态,这里状态包括"确定"、"已实现"、"暂缓"、"新增"、"变更"　等。建立一个数据库，其中每一条记录记录一项需求;

　8、衡量需求稳定性,记录基线需求的数量和每周或每月的变更（添加、修改、删除）数量。

　需求获取是在问题及其最终解决方案之间架设桥梁的第一步，是软件需求过程的主体。一个项目的目的就是致力于开发正确的系统，要做到这一点就要足够详细地描述需求，也就是系统必须达到的条件或能力，使用户和开发人员在系统应该做什么，不应该做什么方面达成共识。我们都知道开发软件系统最为困难的部分就是准确说明开发什么，最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。

　获取需求就是为了解决这些问题，它必不可少的成果就是是对项目中描述的用户需求的普遍理解，一旦理解了需求，分析者、开发者和用户就能探索出描述这些需求的多种解决方案。这一阶段的工作一旦做错，将最终会给系统带来极大损害的部分，由于需求获取事物造成的对需求定义的任何改动，都将导致设计、实现和测试上的大量返工，而这时花费的资源和时间将大大超过仔细精确获取需求的时间和资源。