2.15需求管理

● 需求基线

1.需求获取：积极地与用户进行交流，捕捉、分析和修正用户对目标系统的需求，并提炼出符合解决问题的用户需求，产生《用户需求说明书》。

2.需求分析。对各种需求信息进行分析并抽象描述，为目标系统建立一个概念模型。

3.需求定义。根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《需求规格说明书》。系统设计人员将依据《需求规格说明书》开展系统设计工作。

4.需求确认。开发方和用户共同对需求文档评审，经双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。

5.需求管理：收集需求的变更和变更的理由，并且维持对原有需求和所有产品构件需求的双向跟踪。

需求基线：经评审批准，这些文档就定义了开发工作的需求基线，这个基线在客户和开发人员之间就构筑了计划产品功能需求和非功能需求的一个约定。

● 需求变更控制

需求主管人员把需求变更的优先级分为5级

建立一个需求决策数据库，根据数据库内容指导变更决策。

任何变更都需要通过变更控制流程进行管理。

变更分析流程需考虑：设计问题核对，影响软件元素核对，评估变更工时、评估工作值总和、任务顺序、变更对路径的影响，对进度成本的影响、优先级等。

● 需求版本控制

● 需求跟踪

上图说明了四类需求跟踪能力链。

客户需求可向前追溯到需求，这样就能区分出开发过程中或开发结束后由于需求变更受到影响的需求。这也确保了需求规格说明书包括所有客户需求。

从需求回溯相应的客户需求，确认每个软件需求的源头。如果用使用实例的形式来描述客户需求，图的上半部分就是使用实例和功能性需求之间的跟踪情况。

图的下半部分指出：由于开发过程中系统需求转变为软件需求、设计、编写等，所以通过定义单个需求和特定的产品元素之间的（联系）链可从需求向前追溯。这种联系链使你知道每个需求对应的产品部件，从而确保产品部件满足每个需求。

从产品部件回溯到需求，使你知道每个部件存在的原因。绝大多数项目不包括与用户需求直接相关的代码，但对于开发者却要知道为什么写这一行代码。如果不能把设计元素、代码段 或测试回溯到一个需求，你可能有一个“画蛇添足的程序”。然而，若这些孤立的元素表明了一个正当的功能，则说明需求规格说明书漏掉了一项需求。

3.信息系统项目管理高级知识

QA：质量保证人员。检查工作产品及过程与规划的符合性。

PM：项目经理。组织对概要设计同行评审。

SEPG：软件工程过程小组。组织对软件过程的改进。

CMO：配置管理员。文件版本管理。

事件管理：回复协商一致的服务或响应服务请求。

问题管理：对事件原因的主动识别、分析和管理，直到问题关闭

发布管理：交付、分发并追踪一个或多个变更。

变更管理：以受控的方式，确保变更得到评估、批准、实施和评审。