简述

当进行需求分析时，通常着重考虑三个主要层次：业务需求、用户需求和功能需求。业务需求关注项目与组织战略目标的一致性，用户需求明确最终用户的期望，而功能需求定义具体的系统功能和特性。这三个层次为项目管理和软件工程提供了关键的指导，确保项目成功地满足用户和业务需求。需求分析的重点通常集中在这三个层次，以确保项目的成功交付。

此外，还包括系统需求、性能需求、可用性需求、安全性需求、数据需求、界面需求以及法规和合规性需求等。这些层次共同构成全面的需求分析，有助于确保项目满足各种技术、业务和用户方面的需求，以达到项目成功。

业务需求（ Business requirement ） 

表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（ vision and scope ）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（ project charter 或 market requirement ）文档。

例如有个公司，一定要做一款“智能硬件”，其目的也许不是为了销售，只是正好上市，打造一个概念“涉足智能硬件”的概念，务必使用新技术，或者涉足新领域，便于资本市场炒作。那么这个产品需求分析的时候，就不能按部就班，按常理出牌。步子就是要大，哪怕扯到蛋，也要步子大。这就是“业务需求”的一种体现。所以在产品的需求分析阶段，要把“指导思想”搞清楚。

再例如我在华为做IPC的时候，指导思想是“华为要做监控安防领域的苹果”，占领技术制高点、产品制高点，避免同质化，避免陷入价格战。那么在这款产品的市场定位上，首先定义为“平安城市”+“高端园区”，所以在特殊功能，性能指标方面，追求极致；而在成本，复杂度上面做出妥协。

研发的人员一般也担心风险，进度，对于有挑战的需求往往会望而生畏。而且每个人的理念不一样。当时一位同事做廉价产品做出过成绩，降成本很有心得，所以死扣这款产品的成本。但是这款产品的指导思想很清晰，所以设计理念得以落实。这个产品的市场经理当时根据室外环境、园区环境供电距离远的特点，提出了“穷凶极恶”的概念（在恶劣的情况下能够正常工作），实际上会增加成本，也会增加电路的设计难度。但是为了差异化竞争，为了占领高端市场。

虽说需求都是可以讨论，但是如果研发理解了需求背后的原因，可能更容易去权衡各个需求的优先级。“多快好省”肯定是不可能兼得的，但是理解需求背后的原因之后，就可以更好的进行取舍和排序。

用户需求（ User requirement ） 

描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。

首先，对于用户需求，不要“意淫”，有的研发人员往往意淫出一些需求，因为程序员、硬件攻城狮往往会把自己放在客户的角色上，但是开发人员往往不具备客户的行业经验，或者不具备客户使用产品的场景。用主观意识去使用和认知产品，往往就往往不符合客户需要的原本的模样。

另外，对于运营商产品，客户的表述往往就是用户需求，因为客户是长期从事相关产品的使用，属于专业人员，专业能力较强，而且产品往往配套培训和材料；但是对于个人消费品或者是一些企业用户，用户说的往往并不是用户需求。因为

由于开发人员往往会把自己放置在用户的角度思考，往往就会出现需求的范围蔓延，无端的增加了很多原本没有讨论过的需求。避免需求在开发过程中的走样。往往我们需要进行“范围管理”。

项目范围的管理也就是对项目应该包括什么和不应该包括什么进行相应的定义和控制。它包括用以保证项目能按要求的范围完成所涉及的所有过程，包括：确定项目的需求、定义规划项目的范围、范围管理的实施、范围的变更控制管理以及范围核实等。项目范围是指产生项目产品所包括的所有工作及产生这些产品所用的过程。项目干系人必须在项目要产生什么样的产品方面达成共识，也要在如何生产这些产品方面达成一定的共识。

范围管理的目的是在项目开发过程中，出现范围蔓延。制约一个项目的条件是项目“三约束条件”——范围、时间、成本。

范围的蔓延，势必影响项目的时间和成本。

在一个项目中这三个条件是相互影响、相互制约的，而且往往是由于范围影响了时间和成本。项目一开始确定的范围小，那么它需要完成的时间以及耗费的成本必然也小，反之亦然。很多项目在开始时都会粗略地确定项目的范围、时间以及成本，然而在项目进行到一定阶段之后往往会变得让人感觉到不知道项目什么时候才能真正结束，要使项目结束到底还需要投入多少人力和物力，整个项目就好像一个无底洞，对项目的最后结束谁的心里也没有底。这种情况的出现对于公司的高层来说，他们是最不希望看到的，然而这样的情况出现并不罕见。造成这样的结果就是由于没有控制和管理好项目的范围。可见项目的三个约束条件中最主要还是范围的影响。

产品工程过程分为需求分析、概要设计、详细设计、编码、测试、安装试运行、验收等七个阶段，项目保障过程包括项目计划、项目跟踪与监督、需求管理、质量保证、配置管理、同行评审等保障性工作过程。上图也体现了各个环节对需求的控制和理解，这个过程管理的。

功能需求（ Functional requirement ） 

规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（ behavioral requirement ），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。

对于硬件项目，在项目启动后，会写一个《需求规格跟踪表》。

需求为什么需要文档化呢？如果你开发出来的产品，被别的同事质疑，这也没有那也没有时，你一肚子委屈过，你就非常能够理解。

Ø开发人员通过文档化的过程查错补遗；

Ø便于评审，在早期发现技术上的问题；

Ø后续阶段开发任务可能由他人承担，输出文档便于他们开展工作；

Ø维护人员开展维护工作需要；

Ø文档是必要的交付件；

“所有的过程分析都要形成文档。我们现在有一个严重的问题是，大家好像不喜欢写文档，对于需要的实现方案，通常都是一个负责人在脑袋里想想该怎么实现，然后邮件或电话找几个相关人员讨论一下就算可以了，可能连个会议材料或会议纪要都没有。

而老外可不是这样的，他们非常非常重视文档，他们认为一个人在脑袋里想的东西是不清晰也不全面的，有时候心里想的认为很正确的方案实际上可能存在致命缺陷。他们要求必须把心里的想法形成文档才能有效地避免这种问题。写文档的过程中，可以更加有效的、更进一步去整理您原来心里的思路，很多问题在您写过文档的过程中您就能发现；

另外，文档写作多使用图表，浪费口水的文字尽量少用，和我们一起工作的系统工程师在系统架构分析中就画了五六十张图，就算看不懂他写的英文，从图中我们就能够很清晰的指导整个产品的系统架构。”

——摘自一位华为员工的瑞典出差报告

上面的表单的后面几列是在开发的各个阶段去检查，原先确定的需求、规格等数据是否变化。例如在原理图、PCB、测试阶段，去检查是否出现了需求丢失，或者发生需求变更。如果发生需求变更，需要记录原因，决策者。

- 系统需求（ System requirement ） 

用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。最终决定市场对产品的综合评价是否满意。

对有很多子系统的巨大产品进行跟踪能力管理是一项巨大的工程，但这很必要。并不是所有的公司都会因为软硬件问题而造成严重的结果，然而应该严肃地对待需求跟踪，尤其对涉及你业务核心的信息系统。考虑了应用技术的成本和不使用的风险后，才能决定是否使用任何改进的需求工程实践。随着产品的发展，要把时间投向回报丰厚的地方。

需求管理系统包括模型管理、与WBS关联、版本管理、条目化管理、需求追踪、需求控制、模板管理、统计查询功能，系统组成结构如下图所示。

需求管理和需求跟踪是研发工程师的入口，所以我们需要重视和理解。

需求分配过程其实是一个多层次的循环过程，需要循环几次，取决于两个因素，一个是需求的复杂度，一个是企业研发组织的大小和组织方式。

我们举个复杂点的例子来看看这个过程。图3.4是一个企业的研发组织结构：

假设研发中心和下面4个部门都有需求管理团队［或需求管理人员（专职或兼职均可）］，金融产品与解决方案部收到一个客户需求，经过分析，需要云计算业务部、通用技术开发部一起合作才能完成，但又无法直接调动这两个业务部的开发团队。因此需求首先要上升到研发中心层面进行决策（由需求管理团队1组织），云计算业务部、通用技术开发部的需求管理团队参与决策；决策通过后，再详细分析需求并进行需求的分发，确定需求的哪些内容由哪个部门完成，这个时候一个需求分解成了若干个子需求并分配到了各个责任部门。接到子需求的部门需对需求进行分析，确认技术可行性、实现的方案及交付团队（很有可能不止一个团队参与，这个时候需要再次分解分配，指导需求无法再分解）、交付版本及时间，并最后作出承诺，这才算这一条需求完成了所有的分发、分析、分解分配与决策过程。

因此，在组织复杂、需求复杂的情况，我们要制定需求的优先级排序及决策规则。同时为了快速地推出产品，就必须界定产品的范围，也就是说，不是所有的需求都能一次性实现，这也需要我们对需求进行优先级排序，并且设计针对跨产品线需求与产销矛盾的需求决策机制。

多数情况下，客户需求他们打算购买或正在使用的产品或服务具备一系列他们期望的特点、功能和特征。然而，在客户决定购买或再次购买产品或服务时，这些因素的影响力却不尽相同。无论他们有没有意识到，客户总会优先排序产品/服务特点，并根据排序结果进行决策。

相对重要性是描述客户优先级的一个方法。客户的各种期望在客户作出购买决定时占有什么样的重要地位。优先级排序结果是客户对某产品/服务的各项功能性特点的相对重要性衡量的结果。

有了客户优先级，公司也应有一个独立的评估。对客户而言重要的需求未必对公司重要。需求可以是必须的（承诺的）或非必须的（承诺的）。公司对非必须性需求的优先级排序按照高、中、低的尺度进行，排序时至少应考虑以下要素：

（1）客户优先级

（2）对公司的益处（最好是定量的）

（3）工作量（如粗略估计编码行）

（4）风险（高/中/低）

比较完善的考虑维度，在实际使用时，也可以酌情裁判。

如果是一个初创公司，想去做教育领域的机器人，我们的思路是什么？如果是一个大型的教育商业机构，想拓展新的业务，想拓展教育机器人领域，我们的思路是什么？如果是一个公立学校，想提高学生的素质，开展机器人教育，我们的思路又是什么？请注意，这三者的客户群体可能有很大程度上的重合交叠。但是需求的分析结果一定是大相径庭的。我们在做需求分析的时候需要考虑的三大要素是：

第一个要考虑的要素：组织的战略目标是什么。战略是公司应对商业问题的态度和基本面，决定投入资源的多少、切入市场的策略等。资源的多寡，往往决定我们解决问题的方式。切入市场的策略，往往决定我们的时间成本。

初创公司纵有豪情驰骋天下，但也得面对现金流的问题；获得巨额投资的企业，没有短期现金流的问题，但要面对股东、资本的巨大压力，也要考虑烧钱之后是否还有生命力的问题；公立学校看似没有挣钱的压力，但有行政指标的压力，其不比资本压力小。

第二个考虑的要素就是项目的目标是什么，越具体越好。我是初创公司，我的第一个产品只是解决有无的问题，也许不完美，但是可以销售的产品（实物和教案），竞争力在市场上属于中等。配合合适的营销策略，可以解决第一步的生存问题，预计销售额多少，面对的客户群里是多大年龄、什么学校的学生……现实一点没什么不好，饭要一口口吃，活要一件件做。千万不要成为一些莫须有的理想和柏拉图世界的牺牲品。

第三个考虑的要素是环境因素。比如说教育行业的政策变化，未来几年的行业变化趋势，周边社区的环境、法律的约束、行业要求等。简单地说一下，现在面对低龄孩子的教育机器人行业，能很好规避国家对学生减负的要求。工业产品销售的时候，只要客户没有要求就可以不做3C认证。如果是消费类产品，不管最终用户有没有提3C认证，只有在中国销售的产品，都需要做3C认证。