任何一款产品最初都来源于一个抽象的想法，这个抽象想法关注的可能只是产品的功能，即这款产品能做哪些很酷的事，而不会考虑产品的具体特征，比如尺寸、颜色、电池续航时间等。
在这个阶段，我们通常都会假设它们都处于最理想的状态，即，尺寸恰到好处，颜色人见人爱，电池可以一直供电等。
需求计划是把抽象想法转变为产品真实特征的过程，在这个过程中，你需要尽可能早地为这些特征撰写需求，当产品下线后，你碰到意外问题的可能性就会大大降低。
通常情况下，当产品开发人员对产品的功能有清晰的了解时，就会直接进入设计开发阶段。
当你拥有早期概念验证原型后，就可以向利益相关者展示你的想法。
但是，在概念验证阶段之后，如果工程师开始挑选组件并设计原理图，而没有先对功能、行为、操作参数和设备的预期性能进行形式化，就会出现问题。
什么是产品需求？
产品需求只是你的设备打算做什么的定义，它是对产品预期功能的正式描述，也就是指产品上市销售之前必须要做到的一组事。
以笔者负责过的指纹 U 盘产品为例，其需求大致如下：
- 具备双分区：一个公共盘区，一个加密盘区；
- 支持录入指纹、识别指纹的能力。
在项目开始时，相关人员共同讨论，确定产品必须做到哪些事情，这些事情反映在文档上就形成了需求。
需求文档主要有以下两个用途：
1）在产品制造之前，原则上任何人都可以查看产品需求，从中了解产品主要用途以及有关尺寸、重量、可靠性等特征的信息。
需要注意的是，在产品开发过程中，需求可能会发生变化，随着不断获取新信息，应该经常更新需求。
需求更新过程应该确保以下几点：
- 相关人员都要参与，也都会收到变更通知，以便对变化做出相应调整；
- 考虑每个需求变更给其他需求造成的影响；
- 考虑每个需求变更对测试造成的影响。
随着开发的推进，那些“可选”需求和“亮点”需求最终会变成真实的产品特征。同时，测试也需要需求来驱动，明确要测试什么。
2）产品开发工程师会把需求文档看作一系列指示，用来指导他们应该做什么。在项目最后会对产品进行测试，以确定产品能否上市销售，这种测试主要验证产品需求是否得到落实。
有关需求计划的术语很多，也很容易让人困惑。你需要区分几个基本概念，包括需求、目标和规格，它们都可以描述产品功能。
1）需求：是指那些可量化且产品必须做到的事情。
2）目标：是你要尽量实现的事情，但是很难量化，也不容易做到。
比如，你对电池续航的需求可能是“连续供电不少于 5 小时”，而你确定的目标可能是 7 小时，这有助于你在产品开发过程中把精力放在那些“有了会更好”的事情上。
3）规格：是一些可以量化的描述，来自开发过程的某个部分。
比如，经过测试，你开发的产品（如，蓝牙耳机）满电情况下可以连续可靠地运行 6 个小时，你可以把这一点写在产品的宣传资料和用户手册中。
那么，此时“充电一次运行 6 小时”就变成了产品规格，它描述的是产品实际能做到什么。
规格可以变成需求，需求也可以变成规格。比如，如果之前选用的电池停产了，那么你可能会选其他续航时间不低于 6 小时的电池。
你必须使用技术术语和口语术语，需要尽可能用一句话来描述你的电子产品创意。
举个例子，下面是你与某位对工程学有所了解的朋友的对话：
朋友：“你的产品灵感是什么？”
你：“我喜欢种植自己的辣椒。但是，我经常旅行，所以我不能总是给它们浇水，很多时候也没办法照顾它们。昨晚突发灵感，我可以构建一种可以自动浇水并照顾植物的设备……”
朋友：“那么你打算如何做呢？”
你：“我将建立一个用于监视关键参数的盒子（例如。土壤湿度、光照和温度），然后根据植物的需要打开灯或给植物浇水，通过将此设备连接到互联网，我可以远程监控这些参数。”
从产品的简单描述中，你已经可以提取一些功能要求，例如，感知土壤湿度、环境光和温度的能力。
需求是描述产品应该做什么，而不是产品如何做的结构化语句。
为什么需求有用？
需求不仅仅是公司用来确保其设计团队履行设计开发任务的正式文书，而且对于设计工程师和项目经理来说都是非常有用和必要的工作指南，它们可以为你节省金钱和额外的工作。
通过正确分类和定义电子产品的功能、特性、属性和约束，你可以更清晰地了解实际需要设计的内容。
此外，需求还允许你分离和模块化管理产品功能，以便可以让研发设计人员自行研究和实现它们。
在一个有多个人工作的项目中，拥有定义了所有功能，属性和约束的需求文档非常有用，可以清晰定义所需开发的内容。
对于项目经理或团队负责人而言，产品功能和技术需求的结构分解可用于为团队设置任务，或使用甘特图等工具跟踪项目。
一旦成功满足所有产品要求，它也可以充当交付里程碑，以指示该项目已完成。
最后一点，良好的需求计划可以减少产品开发风险，即尽早确定并解决问题，而不是把问题拖到以后再去解决，那样付出的成本就太大了。
来看一个简单但常见的产品开发失败的例子：由于需求缺失导致产品开发失败。
假设销售人员头脑里有了一个想法，他们想把装有嵌入式软件的新产品最先在国内发布，之后在欧洲发布。
但是，他们并没有把这个想法以需求的形式告知软硬件开发者，这会造成什么后果呢？
如果你在产品开发早期忽视了产品的国际化问题，直到产品开发快结束才意识到，就很有可能会出现以下一些不良后果。
1）所选的软件平台，如，操作系统，可能过于精简，以至于无法轻松地通过语言包来更换文字界面。
在根据用户语言更换不同的文本文件时，软件平台也没有提供任何内置方法。在这种情况下，开发者需要为每种语言手动构建新的显示布局，这会大大增加产品开发和测试的工作量。
2）产品可能把一些用户数据通过互联网集中存到了某个中心数据库。
由于不同国家有关数据安全的法律不同，后端数据库可能需要重新设计架构，重新开发，以确保从各国收集的重要个人数据只存储在相应国家的数据中心。
需求的类型
需求可以通过许多不同的方式进行分类，但是有两种主要类型：
- 功能需求：系统应该执行或提供的功能；
- 非功能性需求：指产品必须具备的某些属性或质量要求，即系统必须满足的条件或系统运行的约束。
例如，移动电源具有测量电池温度的功能需求，并且具有能够在 0 到 40 摄氏度的温度范围内工作的非功能需求。
需求必须遵循一些规则和结构：
1. 独特的
2. 明确的
需求的所有读者应该对需求的内容有相同的理解，只能有一种解释。
3. 可验证的
如果不能正确验证需求，那么工程师将如何确定他们已满足需求呢？
通常，你将进行内部验证，测试工程师会进行测量以检查硬件是否正常运行并符合其设计规格和要求。
然后进行设计验证，在该测试中，将对产品的外壳，不同温度和湿度条件下进行更严格的测试，该验证阶段还包括 EMC 测试。
最后，该产品将在实际操作条件下进行现场测试，或者将其集成到更大的系统中，或者使其与其他设备进行交互。
4. 属性
应该给需求赋予属性以支持前面提到的规则要求：
- 标题：需求的描述性标题；
- ID：不能重复的唯一标识；
- 与安全相关：在某些安全性很重要的产品中，将需求分类为与安全相关是一种良好做法；
- 优先级：在某些情况下，无法实现所有需求，因为它们会相互冲突。分配优先级可为设计人员提供信息，以选择最相关的需求；
- 来源：这是指需求的来源，是客户，承包商还是外部的；
- 理由/目的：对需求及其存在原因的简短描述；
- 验证方法：该需求将如何验证、测试和分析；
- 跟踪信息：需求必须是可追溯的。
通常情况下，在产品需求完成之前可能会修改原产品需求的 50％ 以上的内容，例如，可能会突然出现需要结合新技术或者新法规的情况，这会迫使你更改设计。
需求变更需要由需求工程师，系统工程师或项目经理解决和管理，一般情况下，工程师可以使用工具或软件来寻求帮助。
需求工具可以自动化并保留可追溯性和历史更改的记录，同时支持需求验证结果的记录。
管理新出现的需求也很重要，这些需求仅在系统组合在一起时出现，很难预见，必须在其它需求的基础背景下分配它们，以避免孤立需求。
5. 电子产品的需求文档
电子产品的需求文档没有单一的格式，每个设备都有其自己的规格和特殊性，当然，大多数电子产品可以遵循以下需求类别：
- 产品说明：产品的一般高级描述，最好附有系统级框图；
- 设计要求：产品在组件和设计方面需要具备的功能；
- 功能要求：产品要执行的功能；
- 环境和功能性环境要求：与对环境的影响及其在何处执行功能有关；
- 机械要求：外壳相关要求；
- 使用寿命要求：工作时间和工作温度；
- 测试要求：产品需要通过的相关测试。
如何写出好的需求？
产品需求既能成就产品，也能毁掉产品。那么你如何才能写出好的需求呢？
1. 产品需求是设计的约束
一方面，产品需求是技术人员要实现的目标；另一方面，它也是设计的约束条件，因为它排除了产品的其他呈现方式。
例如，你喜欢在设备中使用可更换电池，比如，5 号电池。
它们个头小，价格低，又能提供足够的电能。与那些采用可充电电池供电的设备相比，如果可更换电池设备的电量用尽，可以轻松更换新电池，让设备立即运行，而不必找插座去充电。
你可以买很多 5 号电池备用，着急的时候，你可以去任何一家超市或便利店买一次性电池来用。
如果要你为一款便携式产品写需求，你可能加上这样一条需求，“必须使用可更换的 5 号电池供电”。
但是，这个看似简单的需求会给设计带来如下诸多影响，这个需求限定了产品的最小尺寸，产品必须装得下电池，产品外壳必须设计有电池仓盖，电池仓内部要有相应装置供电池装载，这些都会增加设计时间。
如果电池仓盖合上时不用螺丝，而采用扣紧的方式，那么可选用的外壳材料也可能会受限，可选用的成型工艺也会受限。
这个需求会影响产品的机械架构，电池需要放置在靠近外壳的地方，以便于更换，而这可能会导致一些元件布局方式无法实现，比如，某些布局可以有效地减小产品尺寸、提高散热效率等。
在某些场景下，确实需要指定电池类型，必须保证可以更换电池。例如，相机或其他高耗电的便携产品。
但是，除非你真的觉得更换电池这项功能非常重要，否则最好不要把能够更换电池写进需求里。
以便设计师设计电源时满足那些真正对产品至关重要的需求，比如产品尺寸、重量、电池续航时间等。
编写需求时，要认真提要求，只提那些真正重要的内容，让设计师在这些约束下发挥创造力，创造出更好的产品。
2. 需求必须是可测试的
好需求的显著标志之一就是意思清晰、不含糊。这样的需求得到满足时，应该不会有人提出任何异议，需求应该是可测试的。
“这款产品应该是安全的”这类说法在很大程度上只是反映了我们的美好愿望，它太过笼统，不能算作产品需求。
“安全”由谁定义？如何测试产品是否安全？你如果想把上述说法换成标准的产品需求，应该修改成这样：这款产品要符合目标销售地区的所有安全法规。
这样一来，定义“安全”的担子就转移到了监管部门，这样做是有意义的，因为你需要满足法律法规的要求。
比如有一款便携产品，使用时人们主要把它放在口袋里。为此，你编写了这样一个需求，“这款产品应该适合装在口袋里”。
然而，口袋形状各异，尺寸也不一样，既有衬衫上的小口袋，也有工作服上的大口袋，口袋是各种各样的，上述需求就模糊不清了。
你可以为该产品估计一个大致的尺寸，使之适合装入大多数口袋，比如：“这款产品的尺寸应该不超过 8 cm×10 cm×2 cm。”
虽然这样做可能会导致产品尺寸过大或过小，但是设计师至少有了设计依据可参照。
另外，还有一种方法，可以为产品编写合适的尺寸需求，即从用户角度去描述它，比如“经过测试，在目标市场中有 90% 的用户认为这款产品应该很容易装进他们的口袋里”。
这就是一个“好的需求”，因为归根结底，所谓的“好”与“不好”，都是用户对产品的看法，而不是你对产品的看法。
像这样一个需求还蕴含着其他细节，比如产品应该可以很轻松地放入或拿出口袋。
从不利的方面看，要测试是否实现了这个需求，需要召集一大群人，让他们亲身体验产品，然后询问他们的使用体验，这远比拿把尺子来测量要费力得多。
3. 需求是以接口为中心的
本质上，产品就是一组接口，这些接口与外部世界相通，产品内部“填充”着让这些接口正常工作的“东西”。
产品需求应该主要关注产品和外部世界之间的接口：
- 产品和用户之间的接口，如，用户界面；
- 产品和其他产品之间的接口，如，USB 端口、互联网服务等 。
与接口有关的需求一般是指你想让产品做什么，而与产品内部“填充物”有关的需求是指你如何让产品做它应该做的事情。
大部分需求是前一种，后一种需求通常用来告诉设计师和开发者如何去做自己的工作，这是他们需要做的事，编写需求应该尽量围绕你想让产品做的事情展开。
提前把人机接口需求做完美相当困难，与人机界面一样，在产品开发过程中，物物接口也需要早做测试。
有些接口更容易指定。例如，如果你的产品通过蓝牙和计算机通信，那么蓝牙接口要统一好。但是，如果上升到蓝牙通信内容这个层面，问题会变得更复杂，复杂程度取决于通信的内容。
在蓝牙通信中，有些类型的数据是有固定标准的，比如耳机和手机、音乐播放器和无线音箱等。
但是，如果标准蓝牙接口规范不支持传送的数据，你就需要重新自定义高层数据格式和协议，以便发送方和接收方能够相互理解。
其他“标准”接口的标准化也存在很大差异。例如，类似于蓝牙，USB 这个通信“管道”也支持某些高层接口定义，在某些使用场景中对传送的信息进行解释和标准化，比如键盘、鼠标、游戏控制器、大容量存储器等。
但是，即便产品的 USB 通信符合其中一个场景，从供电和耗电来说，USB 设备还是非常复杂的。
电力标准有很多种，许多USB 设备遵守这些标准。对产品中所有使用 USB 与任何其他设备连接的接口尽早进行测试。
你从零开始对任何接口所提出的初始需求，比如内部子系统之间的接口需求，很有可能是不完整、有歧义的，甚至是完全错误的。
接口设计是一门技术活儿，除非你先前设计过并且投产过非常相似的接口，否则，一般会或多或少出一些岔子。
在开始开发产品之前，合理提出这些需求是非常重要的。此外，还应尽早为测试子系统做好规定，并随着开发推进更新规定。
在项目刚开始时忽视需求的做法是愚蠢的，但是那种一开始就认为自己完全能够做出完美需求的想法也好不到哪儿去。
随着产品开发的进展以及将产品暴露给外界，原来的产品需求会发生变化。因此，你要尽早并经常向外界暴露产品，以此完善需求。
结论
需求代表了工程师要实现的一组设计目标，并且代表了管理人员评估成本和项目时间的一种方式。
还需要使用工具来适当地管理需求，特别是在项目规模大且许多人都在使用它的情况下。
就一款产品来说，确定需求细节看似简单，实际上却并非如此。
花时间做需求计划可能要比实际实现需求更痛苦，不过有一点可以确认：在需求计划上花费的每一秒，都会为以后实现需求省下大量时间。
这一点对于硬件产品来说尤为重要，因为电路或机械部件的调整往往需要耗费几周甚至几个月的时间。
在开发之前，先把所有细节整理好有助于避免以后反复修改，这可以为整个项目节省大量时间和支出。
—————— / END / ——————
若有收获，就点个赞吧
0 人点赞
