需求分析之六大原则
需求分析之六大原则
需求分析的六个原则（一）永远不要显得比客户更聪明
1、需求分析第一个原则：永远不要显得比客户更聪明。
聪明反被聪明误，这样的事情太多了，我们产品经理都是有智慧的人，而不是耍小聪明的人。
2、原则第一点：了解需求，而不是去批评客户。
产品经理不是批评家，心理上要重视客户，行动上要尊重客户，平等对待每一个客户。
3、原则第二点：客户比你更熟悉业务的环境。
产品经理熟悉的仅仅是产品本身，但是，产品经理要做的却不仅仅是产品本身。
4、原则第三点：真正的问题只有客户知道，我们要做的就是让客户愿意说出来。
客户会给你反馈，但是这些反馈有些是真实的，有些是敷衍的，你希望真实还是敷衍，请参考原则第一点。
需求分析的六个原则（二）尊重用户的现实选择
1、需求分析第二个原则：尊重用户的现实选择。
产品是客观的，用户是客观的，使用是客观的，需求也是客观的，一切都是现实的。
2、原则第一点：客户永远是对的。
客户不是我们的敌人，客户不会害我们，客户提出的需求看似在为难我们，但本质上是为了让客户自己更好的使用产品，因此，客户不会为难自己。
3、原则第二点：提供最合适的解决方案，而非最好或最贵的方案。
我们能够做的不一定是最好的，我们不想做的有时候往往是客户最需要的，找到最合适客户的，而不是最合适我们的。
4、原则第三点：不要把客户当傻瓜。
这个世界上没有傻瓜，自以为对方是傻瓜的人才真的是傻瓜，不要忽悠客户，不要欺骗客户，如果非要在这个前面加上一个期限的话，我希望是“永远”。
需求分析的六个原则（三）转述需求的人也是客户
1、需求分析第三个原则：第三方也是我们的客户。
只要是对我们的产品和业务提出需求，就是我们的客户，应该一视同仁。
2、原则第一点：第三方一般会把自己想象成设计者。
他们对产品或许很熟悉，但是对整个业务可能不熟悉，因此，他们成不了设计者。
3、原则第二点：第三方可能会遗漏或补充一些额外的需求。
3、原则第二点：第三方可能会遗漏或补充一些额外的需求。
每个人都期望产品能做好，这种强烈的成功心理容易让人们产生日晕心理，从而影响我们对需求的筛选。
4、原则第三点：对第三方的自由发挥不应抱怨和生气，而是将其视为客户。
客户是第一位的，而他们又是我们的客户，因此，我们应该心平气和的对待他们的想法，无论这些想法是出于公还是出于私的。
需求分析的六个原则（四）客户和用户要区别对待
1、需求分析第四个原则：客户和用户要区别对待。
客户是客户，用户是用户，有时候一致，有时候分离，这是我们首先要搞清楚的。
2、原则第一点：产品为最终用户设计，需求的功能转换为最终用户的使用要求而确定。
用户决定产品，我们需求工作基于用户，始于用户，归于用户。
3、原则第二点：为客户寻找价值上的需求。
客户是多样的，价值导向也是多样的，我们的产品能否承载多样化的客户价值决定了产品能否实现最终的交换。
4、原则第三点：用户的利益高于一切。
产品的最终价值是通过用户来体现的，脱离了用户的产品，就是“皮之不存，毛将焉附”。
需求分析的六个原则（五）用最简单的文字工具记录需求
1、需求分析第五个原则：用最简单的文字工具记录需求。
客户并不麻烦，需求也不复杂，麻烦的是我们把一切做的太复杂了。
2、原则第一点：所有人都能懂的东西，最不容易出错。
没有人喜欢复杂的东西，需求也不例外。
3、原则第二点：不需要再学习的东西，最不容易出错。
产品是需求的表现，没有人喜欢复杂的产品，要做到这一点，就从需求开始吧。
4、原则第三点：不要希望客户能花更多的时间来了解需求转换后的原型。
我费些事，客户就可以省些事，客户省事了，我们最终也就省事了。
5、原则第四点：保持沟通的通畅，是了解需求的保障
要实现需求的清清楚楚，就要做到沟通的反反复复。
需求分析的六个原则（六）天下没有免费的午餐
1、需求分析第六个原则：天下没有免费的午餐。
要得到就一定要付出，付出的量并不一定和得到的量相等，作为产品经理来说，就是要让客户尽量少的付出，尽量多的得到，但永远不会是免费的。
2、原则第一点：客户从来没有不合理的需求。
客户的需求都是现实的，都是合理的，因为这些需求都是客观的，但我们通常习惯于用主观去看待客观。
3、原则第二点：客户的要求都是可以实现的。
没有不可以实现的需求，只有我们了解的不够深入的需求。
4、原则第三点：我们能做这事－这是所需的费用。
成本第一还是需求第一，客户把这个问题交给了我们，我们就用用我们的智慧去解决这个问题。
来源:网络
人人都是产品经理（）中国最大最活跃的产品经理学习、交流、分享平台。
需求设计的原则
需求设计的原则
1. 需求可追溯性：每个需求都应该能够追溯到业务需求的来源和目标，以便能够有效地评估和控制需求变更。
2. 需求清晰和明确：需求描述应该简洁明了，避免模糊、歧义或多解。
3. 需求可测量性：需求应该能够进行量化评估和验证，以便能够确定需求的完成程度。
4. 需求可扩展性：需求设计应该具有一定的弹性和可扩展性，以适应未来的变化和需求的增加。
5. 需求可验证性：需求应该能够通过测试和验收验证，以确保它们满足用户的期望和需求。
6. 需求一致性：需求之间应该相互一致，避免冲突或相互矛盾的情况。
7. 需求可实现性：需求设计应该考虑到技术和资源的可行性，以确保需求可以在给定的限制和条件下得到实现。
8. 需求可交付性：需求应该能够被准确地传递给开发团队，并能够被他们理解和实施。
9. 需求的优先级和重要性：需求应该有明确的优先级和重要性，以便能够合理安排资源和确定开发的顺序。
10. 需求的可维护性：需求设计应该具有良好的可维护性，以便能够随时进行需求的修改和调整。
优秀系统分析师必读：需求分析20条原则[1]
![优秀系统分析师必读：需求分析20条原则[1]](https://360docs-1393072327.cos.ap-beijing.myqcloud.com/b77ccde0551810a6f5248678.webp)
优秀系统分析师必读：需求分析20条原则[1]需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。
客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进"软件需求报告"中去。
对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。
怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。
软件开发的意义也就在于此。
而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。
经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。
通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。
另外，我们也得为政府部门提供关于商品营运的报告。
”分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。
”经理觉得奇怪：“我不是刚告诉你我的需求了吗？”分析员：“实际上，您只说明了整个项目的概念和目标。
这些高层次的业务需求不足以提供开发的内容和时间。
我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。
”经理：“业务人员都在招商。
他们非常忙，没有时间与你们详细讨论各种细节。
你能不能说明一下你们现有的系统？”分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。
我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。
需求设计的原则
需求设计的原则以需求设计的原则为标题，我们将探讨在项目开发过程中，如何遵循一些原则来进行需求设计，以确保项目的成功和满足用户的需求。
以下是我们要讨论的一些原则。
1. 明确需求：需求设计的首要原则是确保需求明确。
这意味着从项目的一开始就要明确用户的需求和期望。
通过与用户沟通和了解他们的真正需求，我们可以设计出更准确的需求，从而避免项目后期的修改和重新设计。
2. 可追溯性：需求设计的另一个重要原则是确保需求可以被追溯。
这意味着每个需求都应该有一个唯一的标识符，并且与其他相关文档和设计元素进行关联。
这样做可以方便项目团队和利益相关者跟踪每个需求的状态和进展。
3. 一致性：需求设计中的一致性原则要求确保所有需求之间的一致性。
这意味着不同需求之间的定义、术语和标准应该是一致的，以避免混淆和误解。
一致性还包括确保需求与项目的整体目标和约束条件相一致。
4. 可测试性：需求设计的一个重要原则是确保需求是可测试的。
这意味着每个需求都应该具备明确的测试标准和方法，以便在项目实施过程中进行验证和确认。
可测试性有助于确保项目团队和利益相关者对需求的理解是一致的，并可以评估需求是否得到了满足。
5. 可行性：需求设计中的可行性原则要求确保项目的需求是可行的。
这意味着需求应该考虑到项目的技术、资源和时间限制，以便在实际实施中能够得到满足。
可行性分析可以帮助项目团队评估每个需求的可行性，并在需求设计过程中作出相应的调整和决策。
6. 可变性：需求设计中的可变性原则要求允许需求的变化和调整。
在项目开发过程中，需求可能会发生变化，可能是由于技术进展、利益相关者的新需求或其他因素。
因此，需求设计应该具备足够的灵活性，以便在需求变化时进行调整和更新。
7. 可理解性：需求设计的另一个原则是确保需求易于理解。
这意味着需求应该使用简洁、清晰的语言和术语来表达，避免使用模糊或复杂的表达方式。
可理解性有助于确保项目团队和利益相关者对需求的理解是一致的，并避免误解和错误的实施。
需求描述规则
需求描述规则
需求描述规则是指在进行需求分析和规划时，需要遵循的一些准则和规定。
这些规则包括：
1. 精确性：需求描述应该清晰明确，避免模糊和不确定性。
2. 可测性：需求描述应该能够被测量和验证，以确保实现的可行性。
3. 可追踪性：需求描述应该能够追踪到相关的业务目标和功能要求，以确保满足需求。
4. 一致性：需求描述应该与其他相关文档和规范保持一致，避免冲突和误解。
5. 可理解性：需求描述应该简单易懂，避免过于复杂或难以理解。
6. 可演化性：需求描述应该能够适应未来的变化和扩展，以确保系统的可持续性。
7. 可重用性：需求描述应该能够被其他项目和系统所重复利用，提高效率和降低成本。
需求描述规则是需求分析和规划的基础和核心，遵循这些规则可以有效提高项目的成功率和质量。
- 1 -。
需求分析的六个原则(四)客户和用户要区别对待
需求分析的六个原则（四）客户和用户要区别对待客户和用户根据产品的定位有时候是一致的，有时候则是分离的，这个大家都很清楚，通常来说，做企业级消费产品的客户和用户通常是分离的，做大众级消费产品的客户和用户通常是一致的，但也不是绝对，例如公务用轿车，应该是大众消费类产品，但是它多所面对的客户和用户通常是分离的，客户是各类政府公务部门，用户则是具体的操作者，也就是这些单位的工作人员。
具体什么是客户，什么是用户，我就不花很大的篇幅来介绍了，我想大家肯定都非常熟悉他们之间的区别的，其实简单一句话就可以概括：客户一定是掏钱的，用户不一定是掏钱的。
作为产品经理，其实在规划一个产品的时候，需要重点考虑的就是基于产品而要面对的这两类人群（其实还有一类，叫buyer，可以翻译成购买者，看了一些这方面的资料，感觉国内是把客户和购买者合为一体了，这样做其实也有好处，就是可以把抽象的客户概念在营销过程中具体成一个实际的人）。
04年的时候，我在一家为企业提供信息化服务的公司，负责企业信息化产品的管理，一次，我们的一个销售谈了一家半官方性质的公益组织，他们找到我们想用我们的产品搭建一套企业信息系统，包含内部信息管理和外部信息发布，但是那个销售人员只会拉单，对于具体的产品则不是很熟悉，因此，在确定了基本意向和他们的大致需求后，我就陪同这个销售人员一起去见这个准客户。
和政府客户谈单与企业谈单就是不一样，企业客户会直入主题，深入了解你产品的方方面面，但是政府客户就不一样了，本来想着花半天时间和客户沟通一下就可以了，结果一上午过去了，都没谈到实质的内容，客户倒是挺热情，中午的时又是他买单（呵呵，其实都是公家的钱）请客吃饭，搞的我们都觉得要是这单子不给对方优惠，我们都对不住人家。
下午继续聊呗，下午的时候他才找了一个他们单位里负责硬件维护的人和我们谈，离开的时候，热情的拉着我的手，对我们说“你们谈吧，具体的我就不管了，XX（维护硬件的那个人），你好好和小X（我的姓）他们了解一下，以后这个系统就是你的工作了”，说完，端着茶杯就到自己的屋子里醒酒去了。
需求分析原理
需求分析原理需求分析是软件工程中非常重要的一个环节，它是软件开发过程中的第一步，也是最关键的一步。
需求分析的目的是明确用户的需求，确定软件系统的功能和性能要求，为软件设计和实施提供依据。
需求分析原理是指在需求分析过程中所遵循的基本原则和方法，下面我们就来详细介绍一下需求分析原理。
首先，需求分析原理的核心是以用户为中心。
在进行需求分析时，必须充分尊重用户的意见和需求，充分了解用户的工作环境、工作流程和工作习惯，深入挖掘用户的真实需求。
只有站在用户的角度去思考问题，才能真正理解用户的需求，才能设计出符合用户期望的软件系统。
其次，需求分析原理要注重全面性和一致性。
在进行需求分析时，需要全面考虑各个方面的需求，不能片面地看问题。
同时，各个需求之间要保持一致性，不能出现相互矛盾的情况。
只有全面考虑和保持一致性，才能确保最终设计出的软件系统是完整、合理的。
另外，需求分析原理还要注重可行性和实用性。
在进行需求分析时，需要充分考虑软件系统的可行性和实用性，不能设计出无法实现或者无法满足用户实际需求的系统。
需求分析的结果必须是切实可行的，能够被开发团队所接受和实现，同时也能够真正解决用户实际问题。
此外，需求分析原理还要注重灵活性和可修改性。
在进行需求分析时，需要充分考虑到软件系统的未来发展和变化，不能将系统设计得过于死板，而应该具有一定的灵活性和可修改性，能够随着用户需求的变化而进行相应的调整和修改。
最后，需求分析原理还要注重交流和沟通。
在进行需求分析时，需要与用户进行充分的交流和沟通，及时了解用户的需求和反馈，不断修正和完善需求分析的结果。
只有通过有效的交流和沟通，才能确保需求分析的准确性和有效性。
总之，需求分析原理是软件工程中非常重要的一部分，它直接关系到软件系统的最终质量和用户满意度。
只有遵循需求分析原理，充分尊重用户，全面考虑各方面需求，注重可行性和实用性，保持灵活性和可修改性，加强交流和沟通，才能设计出符合用户期望的高质量软件系统。
需求分析的六个原则(五)
用最简单的文字工具记录需求需求是信息的具体表现，我们知道，一个信息进行一次传递,需要具备以下5个条件：1、信息本身2、信息发出者3、信息承载介质4、信息接收者5、信息所处的环境这5个条件的综合作用决定了这个信息最终的质量。
具体到需求这种和产品经理每日息息相关的信息上，我们都必须面对一个非常现实的问题，就是：如何来保证我们获得的信息的衰减性是最小，并且我们又如何能把这种信息尽量少衰减的传递给下一个接收者。
既然本章的标题是“用最简单的文字工具记录需求”，并且在本系列的第三章中,我提供了一个自己整理的《需求反馈文档》模板，属于记录市场需求的第一个工具，因此，在本章里，就以这个模板工具为例，详细来说明一下如何把需求记录好。
第一部分：这个部分比较简单，主要是说明原始需求提出者的信息，具体包括三项：1、需求来源：我这里是以我所在公司的情况写的,大家可以根据自己情况来定，其实这部分就是说明需求的市场细分，这个需求是个人终端客户提出的，还是企业级客户提出的。
2、来源方名称：说明需求提出者的名称，如果是个人,就是姓名，如果是企业,就是企业名称。
3、来源时间：说明需求提出者的反馈时间.这项比较关键，因为咱们通常会发现，客户向公司的是市场人员反馈了一个需求后，市场人员往往不能及时反馈给我们，要么是想起来的时候才说，要么就是等着开会的时候才说，要么就是右耳朵进，左耳朵出,根本没放在心上。
因此,我在公司里一直强调有需求一定要及时通过这个文档反馈给产品部，当然，要让相关部门的每个人都真正重视起来，一是需要时间，二是需要规范.第二部分：这个部分就是针对内部第三方的了，主要是说明需求获取方的信息，在前面的文章说过了，许多行业的产品经理很少有直接面对客户的机会，因此，我们往往还是通过第三方来得到市场需求，具体包括5项:1、需求提交人：这里用需求提交人，而不是需求来源，就是为了区别客户和第三方。
2、提交时间：说明这个需求是第三方什么时候加入到需求池中的。
产品规划师经理D进行需求分析的六个原则
产品规划师经理D进行需求分析的六个原则The document was prepared on January 2, 2021产品规划师/经理(PD)进行需求分析的六个原则需求分析的六个原则（一）永远不要显得比客户更聪明不知道大家想过没有，为什么要把这条作为产品经理进行需求分析的第一原则呢我个人觉的，之所以这条作为第一原则，就是告诉我们这些产品经理一个对待客户的基础态度，是什么呢就是“平等”。
有朋友会说了，我们提供能够满足客户的产品和服务，客户付费享受这些，这肯定是平等的呀，有什么好说的呢果然如此吗02年的时候，我在一家软件公司做产品经理，当时我们公司为了能够让我们的客户更贴近公司产品，最好是参与到公司产品设计中（联盟里好像有这样一篇文章：《让顾客参与产品设计》）成立了一个叫“用户实验室”的部门，这是一个常设部门，专门有一个人在进行管理，主要的工作就是不定期的邀请一些公司的用户来体验公司的最新产品，并让他们提出自己的意见和建议，以方便产品部门进行进一步的改进，目的是在上市的时候，尽量能够达到用户期望的指标。
这个部门的运作就不具体说了，具体说一个案例吧。
有一次，公司另一个产品的产品经理组织了一次新产品用户体验，当时来了大概不到30个用户参与新产品的试用，大家想了，能够耽误个人时间来参加这次试用的用户肯定是公司或者产品的铁杆支持者了，因此，这些用户都显得非常认真，每一个细节都不放过，并且在试用完成后，都非常精心的完成了公司准备好的问卷，至少从我一个旁观者的角度来说，我觉的这次用户试用还是非常有成效的。
但是过了几天，我和那个产品经理闲暇聊天，问他看了那天的用户问卷，对产品有什么新的想法吗，他说“不瞒你说，你是没看那些问卷，那些人（指用户）的想法真幼稚呀，我就不信了，用户会提那样的问题出来”，我说“那你考虑去改进一下目前的产品吗”，他说“改什么改，我设计的产品我还不知道，要是按照那些人的想法做，这产品成什么了，我和你说啊，那些人来就是一个噱头，咱们该怎么做还是怎么做”。
需求分析20条原则
需求分析中科永联高级技术培训中心（）需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。
（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。
需求分析阶段结束后，要求得到：1.SRS文档(System Requirement Specification); 2.DRM 文档；3.Acceptance Plan.从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上理解：需求分析指需求的分析、定义过程。
一、为什么要需求分析需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死.需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型软件系统的开发中,他的作用要远远大于程序设计.二、需求分析的任务简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求.三、需求分析的过程需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审.问题识别就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标.分析与综合逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型).制订规格说明书即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交.评审对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。
产品需求分析的六大“错误”原则
产品需求分析的六大“错误”原则独立思考有时是很重要的，来看看被很多人奉为教条的用户需求分析六大原则，现在真的还站得住脚吗？废话少说，我们来看看这六大原则都说了些什么：原则1：永远不要显得比客户更聪明了解需求，而不是去批评客户。
你熟悉的是产品和技术，而客户客户比你更熟悉业务的环境，客户总是知道问题在哪儿，你的工作就是要让他们自己愿意说出来，而且要深入的去挖掘问题的本质和客户的潜在需求。
产品经理应该有逐步成为领域专家的意识，只有这样业务和产品才可能真正匹配。
评点：你看上去就不比客户更聪明，客户凭什么会愿意花时间向你反映问题？原则2：尊重用户的现实选择客户永远是对的，许多客户提出的需求，在经过了我们人为的过滤之后，被打上“不现实”、“不可能”的印记而束之高阁。
想法一定是建立在客观上的。
因为我们的产品是客观的，用户的使用也是客观的，他们的想法也是客观的，客观的就一定是存在的，存在的就一定是合理的。
我们不要轻易否定用户的需求，不要轻易向用户说：你的想法是错误的。
根据现状，我们需要提供最合适的解决方案，而非最好或最贵的方案。
我们能够做的不一定是最好的，我们不想做的有时候往往是客户最需要的，找到最合适客户的，而不是最合适我们的。
不要把客户当傻瓜。
这个世界上没有傻瓜，自以为对方是傻瓜的人才真的是傻瓜，不要忽悠客户，不要欺骗客户，如果非要在这个前面加上一个期限的话，我希望是“永远”。
评点：如果现实的选择就可以解决问题，那只能说明客户从头到尾都并不需要你？原则3：转述需求的人也是客户只要是对我们的产品和业务提出需求，就是我们的客户，应该一视同仁。
转述者一般会把自己想象成设计者，但是他们对产品或许很熟悉，但是对整个业务可能不熟悉，因此，他们成不了设计者。
因此要考虑到第三方可能会遗漏或补充一些额外的需求。
每个人都期望产品能做好，这种强烈的成功心理容易让人们产生日晕心理，从而影响我们对需求的筛选。
评点：问题是转述需求的人往往都不是客户，你需要找个客户还是找个真正的客户？原则4：客户和用户要区别对待客户是客户，用户是用户，有时候一致，有时候分离，这是我们首先要搞清楚的。