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