1. 目的

通过定义需求开发和管理过程，规范公司软件开发项目的需求开发和管理活动，提高需求质量，从而提高软件生产率，降低开发成本，改进软件质量。

应调查用户的需求，通过需求分析工作将用户需求转化为软件需求，同时评审需求的正确性，获得需求的承诺；应控制需求的变更，并确保项目计划、工作产品与需求的一致性。

2．需求开发阶段的工作文件

3．需求开发阶段工作流程

1. 入口准则

项目立项、合同签定

2. 出口准则

用户确认需求

3. 输入

用户的需求

4. 输出

1、软件需求规格说明书

       2、需求变更表

5. 主要步骤

6.1 需求获取

1．明确需求获取的信息。

需求分析师应在需求获取前明确需要获取的需求信息，以确保在实施需求获取时有的放矢。通常需求获取要获取的信息包括三大类：

l  与问题域相关的背景信息（如业务资料，组织结构图，业务处理流程等）；

l  与要求解决的问题直接相关的信息；

l  用户对系统的特别期望与施加的任何约束信息。

2．明确需求信息的来源。

需求分析师在明确了所需要获取的信息之后，应确定获取需求信息的来源与渠道，以提高需求分析师在需求获取阶段的工作效率，使得所收集的信息更加有价值、更加全面。需求信息的来源通常包括：

l  来自客户的需求

l  实施所满足的需求

l  竞争对手的产品优势与不足

3．获取需求信息的方法。

在明确须获取什么需求、需求的来源与获取渠道后，应选择至少一种需求获取技术获取相关的需求，作为需求分析的依据。需求获取技术包括但不限于：

l  客户访谈

l  客户调查

l  现场观摩用户的工作流程，观察用户的实际操作

l  需求讨论会

4．需求信息的保管。

根据所采用的需求获取技术，在需求获取过程中将产生不同的记录和原始资料，项目组应将这些记录纳入开发库进行配置管理。需求获取的记录与资料包括但不限于：

l  用户编写的原始需求文档；

l  用户填写的需求调查表；

l  用户访谈的访谈纪要；

l  需求研讨会的会议纪要；

l  相关的政策法规文件，业务规则文件以及行业标准文件；

l  需求原型。

5．需求分析工作方法。

根据以往的工程经验，需求分析工作方法，应该定位在“三个阶段”（也称“三步法”）。

第一阶段：“访谈式”（Visitation）

这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局，最好能指定本次项目的接口人。

       实现手段：访谈、调查表格

       输出成果：调查报告、业务流程报告

第二阶段：“诱导式”（Inducement）

这一阶段是在承建方已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际、客观的信息基础上，结合现有的硬件、软件实现方案，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。用户可以操作简单演示的DEMO，来感受一下整个业务流程的设计合理性、准确性等等问题，及时地提出改进意见和方法。

       实现手段：拜访（诱导）、原型演示

       输出成果：调研分析报告、原型反馈报告、业务流程报告

第三阶段：“确认式”（Afirm）

这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统，来提出反馈意见，并对已经可接受的报告、文档签字确认。

       实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统

       输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档）

需求分析的三个阶段是需求调研中不可忽视一个重要的部分，三个阶段或者说三步法的实施和采用，对用户和承建方都同样提供了项目成功的保证。当然在系统建设的过程中，特别在采用迭代法的开发模式时，需求分析的工作需一直进行下去，而在后期的需求改进中，工作则基本集中在后两个阶段中。

6．需求分析应注意的问题。

需求说明书应该对于那些只想了解宏观需求的领导，和需要了解细节的技术员都合适。在写需求说明书时应该注意两个问题：

1.最好为每个需求注释“为什么”，这样可让程序员了解需求的本质，以便选用最合适的技术来实现此需求。

2.需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。

7．获取需求过程中的原则

       原则１ 永远不要显得比客户更聪明

              第一条：了解需求，而不是去批评客户；

              第二条：客户比你更熟悉业务的环境；

              第三条：客户总是知道问题在哪儿，你的工作就是要让他们自己愿意说出来；

       原则２ 尊重用户的现实选择

              第一条：客户永远是对的；

              第二条：提供最合适的解决方案，而非最好或最贵的方案；

              第三条：不要把客户当傻瓜；

       原则３ 转述需求的人也是客户

              第一条：转述者一般会把自己想象成设计者；

              第二条：转述者可能会遗漏或补充一些额外的需求；

              第三条：对转述者的自由发挥不应抱怨和生气，而是将其视为客户；

       原则４ 客户和用户要区别对待

              第一条：产品为最终用户设计，需求的功能转换为最终用户的使用要求而确定；

              第二条：为客户寻找价值上的需求；

              第三条：用户的利益高于一切；

       原则５ 用最简单的文字工具记录需求

              第一条：所有人都能懂的东西，最不容易出错；

              第二条：不需要再学习的东西，最不容易出错；

              第三条：不要希望客户能花更多的时间来了解需求转换后的模型；

              第四条：保持沟通的通畅，是了解需求的保障；

       原则６ 天下没有免费的午餐

              第一条：客户从来没有不合理的需求；

              第二条：客户的要求都是可以实现的；

              第三条：我们能做这事－这是所需的费用；

6.2 需求分析的内容

6.3 需求分解

按照功能结构图进行分解，原则上以每一条完成工作的实际业务流程为一个需求最小单位（原子级需求），单个流程以下的作为该需求的功能，不向下细分。每个原子级需求必须满足以下条件：

1）仅存在一条主要业务流程；

2）操作同一业务数据；

6.4 需求定义

1．标识需求

为了确保需求的易跟踪、易修改，需求分析师应通过需求编号的方式唯一标识每一个软件需求，明确需求的跟踪粒度，并体现于软件需求分析文档。

编码规则：<系统代码>-XQ-<1级需求编号>.<版本号>[-<2级需求编号>.<版本号>…]

例：设备系统（EMS）的第一个功能“基础数据管理”的第二个功能“供应商管理的第3版需求编号为：EMS-XQ-1.1-2.3

说明：需求编号按照合同方案中排列顺序编排，如合同方案中未出现的功能需求则排在合同所列所有需求之后。

2．定义需求优先级别

需求分析师应确定每个需求的优先级并写入软件需求分析文档，需求的优先级的评价标准如下：

3．定义需求与现有管理的差异级别（流程差异性）优先级的定义有利于帮助项目组在项目的范围、进度、资源、预算等相关制约因素之间产生冲突时，能够正确地对需求实现的范围或实现的优先程度做出取舍。一个实现这种权衡的方法是：当接受一个新的高优先级的需求或者其它项目环境变化时，删除低优先级的需求，或者把它们推迟到下一版本中去实现。

需求分析师应确定每个需求实现的管理流程与客户现行管理流程间的差异性大小并写入软件需求分析文档，流程差异性的评价标准如下：

4．编写需求分析文档

需求分析师在需求分析过程中根据分析步骤逐步编制形成《软件需求分析文档》（其中《产品功能列表》可作为附件提交）。编写需求分析文档应遵循以下规则：

l  相关的需求都得到了识别与描述，以确保需求的完整性；

l  各个需求之间不冲突，算法之间不相互矛盾，以确保需求的一致性；

l  正确描述系统需求，引用的资料有正规的出处，以确保需求的正确性；

l  定义必要的术语，适当结合图形、结构图等方式进行描述，以确保需求无二义性；

l  使用较好的文档结构与需求标识，使需求能够方便地与其它工作产品相对应，以确保需求易于追溯；

l  确保所描述的需求可以通过适当的手段得到验证，即需求的可测试性；

l  考虑了各个层次的需求，确定了需求的优先级，以确保需求的可行性。

6.4需求确认

1．需求评审

应对所形成的需求文档进行评审，以便作为下一阶段工作的基础。需求评审的方式为“部门评审会议”。

部门评审成员：

评审组长：项目经理

1．测试代表

2．开发代表

3．项目经理

4．客户代表

2．需求承诺

项目经理将评审通过的《软件需求规格说明书》提交给客户（或客户代表）、系统关联项目组进行确认，确认的方式可以是以下方式之一：

直接签字：由承诺方在评审报告上直接签字或盖章确认

3．建立基线

项目的软件需求分析文档经过评审与确认后，应根据要求建立需求基线。

6.5需求变更

对一个软件项目来说，无论最初的需求分析有多么明确，开发过程中的需求变化也还是不可避免的。这主要有以下几种原因：

l  软件所应用的外部环境发生变化；

l  随着用户对软件的熟悉和应用，又提出新的需求；

l  项目组进行需求分析时未能彻底分析用户的需求，或分析错误；

l  用户在开始时不能很全面的知道所需软件的功能。

1、需求变更申请

项目组外的需求变更，由变更申请人通过填写《需求变更申请单》向项目组提出进行；项目组内部的需求变更通过《软件变更申请单》提出。

当项目组接收到项目管理部门的《需求变更申请单》时，应先根据要求进行需求的评估，判断需求的类型、分析需求变更影响到的范围、估算需求实现的工作量（含需求、设计、编码、测试、用户文档编写）、预计可以完成的时间等内容，填写于《需求变更申请单内部评审表》，并回复项目管理部门。若估算的开发工作量大于10人月时，项目组可以根据《立项管理过程》的要求向项目管理部提出项目立项申请；若小于10人月，且评估结果与申请部门达成共识，则开发项目组根据《变更管理规程》实施变更，若无法达成共识，则提交研发部进行最终裁定。

2、需求变更的实施

在变更完成后，若需要发布新的需求基线，项目组应根据《S_CM000_配置管理过程》中“基线发布”的要求重新建立需求基线，并通知相关的人员。

6.6需求跟踪

对一个软件项目来说，当需求确定下来以后，应该保证在软件设计过程中每个需求都被实现，且项目的其它工作产品与需求保持一致。

需求分析文档经过评审后，需求开发人员负责建立需求跟踪矩阵。

在软件开发的各阶段（设计、编码及测试），相关的开发人员应负责维护需求跟踪矩阵。