需求开发是指通过对用户需求进行分析，开发产品需求的过程。需求开发在于把面向用户的需求转换为面向研发团队的需求的过程，回答研发团队“我们要做什么样的产品”的问题。需求开发直接面向研发团队，是用户需求传递到研发团队中的必要一环。本文主要阐述在项目需求开发过程中涉及的主要规程、可能存在的问题、分析这些问题并提出相应的改进措施。
在轻量级过程改进系列的上下文中，关于需求管理和需求开发的区别和联系已经在“需求管理”这一改进域中有明确说明，这里不再展开。该上下文可能每个团队都有不同的理解和诠释，但需求开发的主要任务就是让研发团队获取产品的需求并根据产品需求进行系统设计和实现，需求开发通常也是一项跨职能团队的活动，通常包括的规程有：
需求开发在本系列文章中属于产品管理范畴，主要是以产品经理为代表的产品管理团队进行工作展开，产品管理难度很大，除了需求开发过程还有产品平台、标准化等多项工作，所以这里的产品需求开发只从需求分析定义的角度出发进行讨论，相对比较简单，主要涉及的是需求分析的工具和方法论，存在的问题可能有：
需求定义普遍存在的一个问题是需求的粒度和维度问题，也就是我们如何进行需求分解和描述的问题。不合理的需求定义粒度会加大研发工作的管理难度，因为研发范围的管理通常都会以产品需求的定义粒度为基准，粒度太大不便信息同步，粒度太小则加大管理成本。从维度上讲，一份对非功能性需求以及其他辅助性需求有明确定义的需求会对研发工作的展开和度量起到促进作用，反之则需要一定的协调工作才能对这些需求进行定义和开发。
有时候需求定义的表现形式很重要，无论是用户体验驱动的互联网产品还是业务领域驱动的企业级应用，找到合适的需求定义方式并不容易，需要根据具体产品进行灵活把握。但无论何种产品需求定义，采用多样化的表现形式往往能更好的表达需求本身的含义，确保研发团队能够快速直观的进行需求理解。很多需求难以理解和维护就是因为其表现形式过于单一，不利于团队充分把握需求的细节。
需求分析过程中进行需求建模是必要的，建模的程度可能视系统特点和复杂性而异，但我们都应该采用一种被团队普遍认可的、统一的建模方式进行需求的梳理。缺少需求建模的结果就是每个需求定义人员都可能有自身的一套规则和方法，可能导致不同的人对同一份需求有不同的理解和维护方式，在团队协作环境下就形成一种无形的壁垒从而降低了工作效率。
需求开发更多涉及的是对如何高效的把用户需求和产品特点展现给研发人员的过程，对需求开发过程改进的切入点包括：
需求分解的通用原则无论对用户需求和产品需求都同样有用，但通常产品需求的粒度和维度都会比用户需求更加需要斟酌，因为产品需求是开发人员对产品理解的主要来源，直接影响研发团队的开发计划和系统设计。关注产品需求分解也是一个裁剪的过程，需要根据团队认知的现状以及产品开发的特点达到一种平衡。
本质上需求分析可以理解为一个系统建模的过程，系统建模也是一个很大的领域，无论是结构化分析方法还是面向对象的建模手段都能够为我们提供一个系统模型。在需求开发的改进过程中，使用统一的系统建模工具能够确保产品需求符合目前业界主流的分析和定义风格，确保团队成员尤其是研发人员对产品需求得到充分认识，消除不必要的歧义和误解。
不同团队可以使用不同的需求表现形式，但需确保团队理解和认同这种表现形式。上文提到的需求定义展现方式单一的问题是改进过程中的一个关注点。另一方面，表现形式务必做到统一。
针对上述切入点，我们梳理需求管理过程改进的模式和实践包括：
需求管理中提到的对需求的配置管理理念和流程同样适用于需求开发过程，这里不再展开。
产品经理手中应有一些产品需求开发的武器，这些武器从不同的方面对产品需求进行展现，这里列举几项个人认为比较重要又容易把握的武器：
系统建模的方法论有很多，如结构化分析、面向对象、领域驱动等，作为这些方法论的支持性工具，UML是目前主流的系统建模工具。UML既可以作为需求分析建模，也可以进行系统设计建模，这里举UML顺序图作为需求分析建模的一个例子，如下图：
产品需求说明书主要包括以下要点：
需求开发属于产品管理类改进域，相比需求管理更加偏向于团队内部的规范。需求开发通常会与产品平台和标准化建设紧密结合，改进过程中也主要关注产品需求的定义和表现形式。但产品管理远不止需求开发，关于产品的定位分析、产品功能的优先级等决策等我们将在后续产品管理类改进域中进行详细阐述。
原文地址：http://blog.csdn.net/lantian08251/article/details/40779079
