什么是需求	都有哪些需求
	需求的生命周期	需求工作流程
	需求相关的角色	需求相关的工件
	需求质量评价标准和方法

什么是需求

需求是客户或者用户向产品的提供者表达的请求，产品提供者为了明确客户的要求或者期望向客户进一步 收集的各种信息，双方经过协商对产品所形成的契约，可以是正式的需求文档或者非正式的需求描述。

需求的产生过程：

客户在业务工作中遇到的问题，发出需求请求，经过客户代表和需求员的共同分析，成为正式需求，交给开发团队，构造一个系统或者系统的部件，应用到业务中，实现需求。客户如果不满意，会推动下一次的需求。

1.需求工作的主要目的：让开发出来的产品满足客户需求。

2.需求工作的辅助目的：为开发者提供必要的约束信息，明确开发的要求。

都有哪些需求：从业务需求到系统需求

需求是从业务视角提出到系统视角落地的过程。业务需求是系统需求的目标，系统需求是业务需求的结果。

需求包括三个不同的层次 ：

• 业务需求（business requirement）是业务性的本质要求，是产品面向的业务层面的问题与解决办法。
• 用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务。
• 系统需求 (System requirement)= 功能需求+非功能需求：定义了开发人员必须实现的软件系统能力，
  使得用户能完成他们的任务，从而满足了业务需求。

业务需求包括：

用户需求包括

系统需求包括：

需求的生命周期

需求从提出到实现的完整生命周期如下：

  首先是用户在工作或生活中遇到问题，产生愿望

整体需求的状态

需求从产生到稳定的定义，需要一个思考、反馈和调整的过程。

所以应该为需求准备这方面的时间，我们可以称之为“发酵期”，可以从必要发酵时间的角度对需求作 分类，当一个具体的需求产生后，按照其所属的分类，执行发酵，这样可以有效地降低时间仓促带来的 风险。 这样可能有人会问“发酵期是否意味着时间的浪费，乏味的等待或者杞人忧天的持续的焦虑”， 这种情况的确可能会发生，不过如果我们注意到需求的多重性，就应该认识到，需求有很多，每个都是 一个需求的单元，我们可以把需求适当的分解切割，然后按照一个队列的工作方式，不断地让某些需求 经过发酵期，持续的输送给开发团队，这样既能保证需求的质量，也能保持整个生产线的持续运行。所 以软件的开发过程，应该考虑如何定一个持续的需求链条，驱动整个项目的工作。

需求工作流程

过程由多个视角进行描述：

• 专业视角，也就是从需求工作本身的逻辑顺序进行的工作流程。
• 协作视角：描述如何多个人协作，完成工作。
• 资源视角：描述如果是多个同类工作，如何展开。

需求的专业视角工作流程如下：

 

工作	说明
客户愿景	客户对项目或者产品的总体期望，关键期望，可能涉及：涉及：产品定位，潜在用户，功能要求，关键特性，涉及约束，实施的条件和约定，设计约束，法律约束，社会条件。
需求计划	对需求的开发和管理工作进行计划，包括需求的进度、需求管理的属性，需求的类型，需求的工件，需求的团队成员，需求的变更控制方式，需求的行动路线图。
需求获取	从客户那里进行需求收集，例如：需求调查，现场访谈，需求研讨会，文档调查，竞争分析。
需求分析	对获得的原始用户需求进行分析，以便给出需求的准确、详细的定义。
需求规格	编写需求有关的文档，从读者的角度，用无二义、完整、一致的方式描述需求。
需求验证	对规格化为文档的需求进行技术评审，对于最终交付的系统进行确认，以及2者的过渡中的各种客户和开发方的需求确认工作。
变更控制	对需求的变化进行控制，一方面开放变化入口，一方面控制变化的出口，保持系统的发展中的稳定性。
版本管理	对需求不同阶段的版本进行标示，列出更新列表，对版本进行固化控制，建立版本的追溯关系和升级条件。

 

需求的多人协作工作流程视角如下：

 

说明如下：

角色	工作	活动
客户/用户	原始请求	基于商业和工作需要，提出问题或者期望。
产品经理	产品构想	分析为什么做产品，产品面向什么用户，提供什么，面临什么竞争，将如何发展。
业务分析师	业务调研	对业务进行调研、分析和问题解决方案涉及。
系统分析师	系统分析	基于业务解决方案，确定系统的边界，并分析系统的每个功能都有什么，质量属性（性能、可靠性、扩展性）如何保证。
开发工程师	开发	按照需求实现系统
测试工程师	测试	按照系统需求进行测试，报告bug。
系统分析师	系统验证	确认系统需求都被实现
业务分析师	业务验证	确认业务都被实现
客户/用户	用户验证	让用户试用，确认符合需要。
产品经理	产品确认	基于产品构想对产品进行确认，可能会调整需求。

需求工作流程（资源视角）

如果不是只有一份需求，而是多分需求，需求的资源工作流程视角如下：

 

本流程会体现出来多个需求的展开、跟踪和集成过程。

阶段	工作	说明
产品定义	概要需求	因为需求的首要目的就是确定项目范围，然后才能估算成本和开发可行性，所以概要需求应该能够覆盖需求的大部分范围，并对每个需求给出关键要求。
	概要设计	需求需要通过设计方案评估可行性和成本，所以需求概要做完后，进行概要设计，然后权衡可行性，进行需求的取舍和方案调整，最后概要需求和概要设计一起确定下来。
迭代开发	需求细化-实现-验证	在每次迭代开发中，对此次迭代开发的需求进行细化、设计、实现，然后进行测试验证。如果不是迭代开发，而是并行开发，也基本如此，只是时间上是多个人或者小组同时展开。
验证与交付	需求整体验证	当系统整体开发完成后，进行完整的系统测试和需求验证，主要评价角度有功能范围是否都被实现、系统集成后是否能够满足功能和质量要求。
	按照需求交付	把符合用户需要的系统部署到用户使用环境下，并对使用情况进行记录、调查，手机用户的反馈，完善和优化需求。

需求相关的角色

角色	工作	交付物
产品经理	产品构想 产品商业需求分析 产品市场需求分析 竞品分析 产品关键特性管理 产品发布管理 产品验证和宣传	产品商业需求文档 产品市场需求分析
业务分析师	业务调研 业务现状分析 业务改进分析 确定业务模型 编写《业务需求说明书》 业务需求验证	业务需求说明书 业务模型
系统分析师	系统需求调研 系统需求分析 系统需求建模       功能       非功能 编写《系统需求说明书》 系统需求验证	系统需求说明书 系统模型
质量经理	参考需求质量标准 建立功能验收标准 建立非功能需求验收标准 讨论验收标准 确认验收标准	《需求质量标准》
需求变更控制委员会	建立需求基线 建立需求属性矩阵 建立需求跟踪矩阵 控制需求变更 管理需求版本	变更需求

需求相关的工件

需求原件	职责
原始请求	来自于客户、用户的原始请求
产品前景	对产品的前瞻性展望，包括：产品定位、竞争分析、市场分析、实施计划、资源分析。
业务需求说明书	从业务视角，对业务相关的角色、流程、实体、规则等的描述，包括业务现状、业务问题和解决方案。
系统需求说明书	从系统视角，对系统的功能和非功能需求进行的描述，包括：用例、功能需求、接口需求、数据需求、性能需求、可靠性需求、可支持需求、设计约束等。
系统原型	对系统的界面、逻辑的模拟性质的样例，用户可以通过样例提前了解系统的最终形态，并反馈进一步的需求。
需求变更集	对系统的变更条目组成的需求变更集和。

需求质量评价标准和方法

产品的质量标准	说明
有用	产品可以帮助用户解决工作中的问题，提升业务能力，有用的。
能用	产品在用户环境下质量合格，能够使用。
好用	产品易于学习和使用，用户体验好。
需求形式标准	说明
完整	覆盖了用户的所有需要，包括功能、非功能需求。
一致	需求多个相关的描述是一致的。
规范	需求的描述符合文档模板格式要求。
需求交接标准：	说明
客户确认满足需求	客户视角对需求的评价，也就意味系统能够满足业务需要，达到预期目标。
开发确认明确、可行	开发视角接收需求，并确认需求的开发可行性。