需求开发是指通过对用户需求进行分析，开发产品需求的过程。需求开发在于把面向用户的需求转换为面向研发团队的需求的过程，回答研发团队“我们要做什么样的产品”的问题。需求开发直接面向研发团队，是用户需求传递到研发团队中的必要一环。本文主要阐述在项目需求开发过程中涉及的主要规程、可能存在的问题、分析这些问题并提出相应的改进措施。
一．需求开发的规程
在轻量级过程改进系列的上下文中，关于需求管理和需求开发的区别和联系已经在“需求管理”这一改进域中有明确说明，这里不再展开。该上下文可能每个团队都有不同的理解和诠释，但需求开发的主要任务就是让研发团队获取产品的需求并根据产品需求进行系统设计和实现，需求开发通常也是一项跨职能团队的活动，通常包括的规程有：
1. 需求分析
- 目的：需求分析就是一个产品需求定义的过程，通过分析来自项目线的各项需求并结合产品线现有功能进行产品需求开发和管理，确保产品需求能够满足产品平台建设和项目线的需求管理。
- 主要角色：产品经理主导
- 主要步骤：产品管理团队需要收集产品需求，一方面来自于项目线的输入，另一方面也需要进行市场分析。在现有产品需求的基础上，使用需求分析和定义的工具方法进行系统建模，并形成《产品需求说明书》。
2. 需求评审
- 目的：对于产品需求和用户需求一样同样需要应用评估策略以确保需求的正确性，用户需求我们使用需求确认和客户达成一致，对产品需求而言我们使用的则是正式的评审。需求评审确保产品需求对现有产品结构以及未来的产品战略起到补充和完善作用。
- 主要角色：产品经理主导，各研发小组的负责人参与
- 主要步骤：召开需求评审会议，由产品经理主导会议议程，项目、技术、运营等团队参与需求会议并对产品需求进行评审，评审结果形成正式的《产品需求说明书》。
二．需求开发中的问题
需求开发在本系列文章中属于产品管理范畴，主要是以产品经理为代表的产品管理团队进行工作展开，产品管理难度很大，除了需求开发过程还有产品平台、标准化等多项工作，所以这里的产品需求开发只从需求分析定义的角度出发进行讨论，相对比较简单，主要涉及的是需求分析的工具和方法论，存在的问题可能有：
1. 需求定义的粒度和维度不合理
需求定义普遍存在的一个问题是需求的粒度和维度问题，也就是我们如何进行需求分解和描述的问题。不合理的需求定义粒度会加大研发工作的管理难度，因为研发范围的管理通常都会以产品需求的定义粒度为基准，粒度太大不便信息同步，粒度太小则加大管理成本。从维度上讲，一份对非功能性需求以及其他辅助性需求有明确定义的需求会对研发工作的展开和度量起到促进作用，反之则需要一定的协调工作才能对这些需求进行定义和开发。
2. 需求定义的展现方式太单一
有时候需求定义的表现形式很重要，无论是用户体验驱动的互联网产品还是业务领域驱动的企业级应用，找到合适的需求定义方式并不容易，需要根据具体产品进行灵活把握。但无论何种产品需求定义，采用多样化的表现形式往往能更好的表达需求本身的含义，确保研发团队能够快速直观的进行需求理解。很多需求难以理解和维护就是因为其表现形式过于单一，不利于团队充分把握需求的细节。
3. 缺乏统一的需求建模过程
需求分析过程中进行需求建模是必要的，建模的程度可能视系统特点和复杂性而异，但我们都应该采用一种被团队普遍认可的、统一的建模方式进行需求的梳理。缺少需求建模的结果就是每个需求定义人员都可能有自身的一套规则和方法，可能导致不同的人对同一份需求有不同的理解和维护方式，在团队协作环境下就形成一种无形的壁垒从而降低了工作效率。
三．需求开发的过程改进
需求开发更多涉及的是对如何高效的把用户需求和产品特点展现给研发人员的过程，对需求开发过程改进的切入点包括：
1. 关注产品需求的分解
需求分解的通用原则无论对用户需求和产品需求都同样有用，但通常产品需求的粒度和维度都会比用户需求更加需要斟酌，因为产品需求是开发人员对产品理解的主要来源，直接影响研发团队的开发计划和系统设计。关注产品需求分解也是一个裁剪的过程，需要根据团队认知的现状以及产品开发的特点达到一种平衡。
2. 关注建模工具的使用
本质上需求分析可以理解为一个系统建模的过程，系统建模也是一个很大的领域，无论是结构化分析方法还是面向对象的建模手段都能够为我们提供一个系统模型。在需求开发的改进过程中，使用统一的系统建模工具能够确保产品需求符合目前业界主流的分析和定义风格，确保团队成员尤其是研发人员对产品需求得到充分认识，消除不必要的歧义和误解。
3. 关注需求的表现形式
不同团队可以使用不同的需求表现形式，但需确保团队理解和认同这种表现形式。上文提到的需求定义展现方式单一的问题是改进过程中的一个关注点。另一方面，表现形式务必做到统一。
针对上述切入点，我们梳理需求管理过程改进的模式和实践包括：
1. 确立配置管理理念和流程
需求管理中提到的对需求的配置管理理念和流程同样适用于需求开发过程，这里不再展开。
2. 灵活应用各种“武器”
产品经理手中应有一些产品需求开发的武器，这些武器从不同的方面对产品需求进行展现，这里列举几项个人认为比较重要又容易把握的武器：
- Feature列表：Feature列表是产品需求的一种分解模式，也是一种量化方式，通过需求->模块->功能线->功能点的分析形成的Feature列表，能够帮助整个研发团队对产品需求形成一致认识，也为研发团队进行研发任务拆分、计划安排和过程管理提供基础，Feature列表参考下图：
- User Case：用例是对功能的一种有效描述，而用例本身的表现形式多种多样，这里不展开讨论，大家可以参考Alistair Cockburn的《Writing Effective Use Cases》，下面是其中的一种表现形式：
- 系统原型：系统原型是一种产品需求的可视化表现形式，为研发团队甚至客户提供一份系统视觉和用户交互上的产品需求，常见的系统原型开发工具有Axure RP和Mockups等，使用Mockups开发的系统原型类似：
3. 开展系统建模工作
系统建模的方法论有很多，如结构化分析、面向对象、领域驱动等，作为这些方法论的支持性工具，UML是目前主流的系统建模工具。UML既可以作为需求分析建模，也可以进行系统设计建模，这里举UML顺序图作为需求分析建模的一个例子，如下图：
四．需求开发的过程资产
1. 产品需求说明书
产品需求说明书主要包括以下要点：
- 产品整体介绍，包括产品的目的、用户群体、范围、角色、分解的原则、表现形式等
- 系统功能性需求，包括界面风格、各个功能模块和功能点介绍
- 系统非功能性需求，包括软硬件环境、质量要求等
五． 小结
需求开发属于产品管理类改进域，相比需求管理更加偏向于团队内部的规范。需求开发通常会与产品平台和标准化建设紧密结合，改进过程中也主要关注产品需求的定义和表现形式。但产品管理远不止需求开发，关于产品的定位分析、产品功能的优先级等决策等我们将在后续产品管理类改进域中进行详细阐述。