细说需求过程

需求的定义和分类都搞清楚了，但是这些只是理论。最终怎么表示出来呢？业界常用的需求描述技术有：特性、用户故事、用例故事。那么有啥差异呢，我在写文档的时候怎么选择和使用呢。

需求工程是对涉及的一个产品（或系统、软件）的所有需求工作的统称，一般可以分为需求开发、需求管理两部分。

都说需求重要？那么为啥重要呢？

首先产品需求工作（分析、描述或定义）是处于产品开发的上游，可以说是系统开发工作的导火索。并且，一旦需求工作没有做好，后续的工作会受到极大影响，进行改正的机会也耗费巨大。是以必须对需求工作给以足够的重视。

产品的需求主要来自产品的干系人（“利益相关者”），那么干系人是啥呢？

根据行业内认识，可以定义如下：一个产品（或项目、系统、软件）的干系人是影响该产品、或是受到该产品影响，或者自认为受到该产品影响的一个个人、团体或组织，这里的影响主要指改产品的各种决策、活动或者成果的影响。

干系人的概念、范畴比用户大的多，几乎囊括了所有与某件产品有关的各类人群，既包括产品的开发与运营等组织的外部用户，也包括这些组织内部的相关人员，包括内部用户、管理者、开发者、测试者、运维者等。

需要注意的是，干系人不一定都会产品产生积极、正面的影响。比如银行ATM的干系人通常包括企图拆解、破坏的非法分子，应专门针对这些非正常干系人的意图和行为进行分析，加强产品、系统的安防设计。从干系人入手，而不是从用户开始，主要是为了保证

产品需求分析的全面性，一旦遗漏了一些重要需求，会导致后续加班、扰乱进度等各种麻烦。根据所承担的需求工作职责或任务的不同，可以进行如下划分：

需求任务	主要干系人
需求的来源	客户与用户代表（外） 市场分析师、营销代表 客户经理、与业务经理 运维代表 产品经理、项目经理 行业监管部门（外）
需求的定义 （分析与设计）	产品经理、项目经理 产品设计师 业务分析师 需求分析师 交互设计师 系统架构师、软件架构师
需求的实现	交互设计师、UI设计师 程序设计师 数据库设计师、DBA 系统架构师、软件架构师 开发经理
需求的确认与验证	客户与用户代表（外） 产品经理、项目经理 需求评审员 系统架构师、软件架构师 测试经理、测试员 第三方评测机构

 

总体上需求过程分为需求开发和需求管理，由产品经理带领业务分析师、需求分析师和用户代表等各方面干系人代表组成的需求小组，通过有效交流沟通来协作完成。

成熟的需求过程应该是迭代的、演进式的。迭代是当前敏捷开发的一个基础与核心实践。基本做法是把产品、项目的开发工期分为多个连续的时间片——迭代周期，每个迭代长度介于1-6周，团队在每个迭代中都会同时（或并行）开展需求、设计、编程、测试等各方面的工作。

• 需求开发，主要为以下几个工作或任务
  • 需求提取  明确待开发产品的具体范围，了解其未来的使用与运行环境。识别用户与主要干系人，并对其分类和排序。开展产品的业务分析、通过明确业务目标、收集业务流程、业务规则等方面来构建一个业务模型，以明确用户需要利用当前产品来执行、完成的具体任务和目标，并以此提取系统功能。直接与用户代表等干系人直接进行交流、访谈，收集各种需求。
  • 需求分析  对已提取的各项需求进行梳理和归来（功能需求、质量属性、业务规则、设计约束等）。对高层次、大的需求进行分解。对于低层、小的需求进行合并。
  • 需求定义 编写需求规格说明，常用的需求文档有愿景文档、产品需求文档、系统需求规约、软件需求规约。文档中出现的功能需求可以用UML来表示。常用的基于UML的需求模型有 用例模型（除了用例图、主要用活动图、序列图来描述系统功能的执行与交互流程）、领域模型（类图描述各种信息实体与其关系）
  • 需求验证  

• 需求管理   主要指通过需求开发获得的各种需求文档、模型等进行及时和有效的管理与维护，从而保证产品的需求模型的质量。主要工作包括:
  • 需求基线管理 （在开发进程中，定期的定义和维护一套相对稳定、经过评审的需求集——需求基线版本，以驱动本轮周期的开发与发布）
  • 需求关系管理 （建立并维护各个需求项之间的依赖关系）
  • 需求状态管理  (监控需求项的属性和状态，如已设计、已实现、已测试、已发布、已暂停等）
  • 需求的追溯链管理（建立并维护需求项与其设计方案、实现代码和测试程序等其他工件之间的可追溯性）
  • 需求变更管理（对对变更需求的流程和行为进行规范和管控）沿着追溯链对变更可能造成的影响进行评估）