需求分析之六大原则

合集下载

需求设计的原则

需求设计的原则
1. 需求可追溯性：每个需求都应该能够追溯到业务需求的来源和目标，以便能够有效地评估和控制需求变更。

2. 需求清晰和明确：需求描述应该简洁明了，避免模糊、歧义或多解。

3. 需求可测量性：需求应该能够进行量化评估和验证，以便能够确定需求的完成程度。

4. 需求可扩展性：需求设计应该具有一定的弹性和可扩展性，以适应未来的变化和需求的增加。

5. 需求可验证性：需求应该能够通过测试和验收验证，以确保它们满足用户的期望和需求。

6. 需求一致性：需求之间应该相互一致，避免冲突或相互矛盾的情况。

7. 需求可实现性：需求设计应该考虑到技术和资源的可行性，以确保需求可以在给定的限制和条件下得到实现。

8. 需求可交付性：需求应该能够被准确地传递给开发团队，并能够被他们理解和实施。

9. 需求的优先级和重要性：需求应该有明确的优先级和重要性，以便能够合理安排资源和确定开发的顺序。

10. 需求的可维护性：需求设计应该具有良好的可维护性，以便能够随时进行需求的修改和调整。

优秀系统分析师必读：需求分析20条原则[1]

优秀系统分析师必读：需求分析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：客户和用户要区别对待客户是客户，用户是用户，有时候一致，有时候分离，这是我们首先要搞清楚的。

需求分析的六个原则(三)转述需求的人也是客户

需求分析的六个原则（三）转述需求的人也是客户大部分行业的大部分产品经理必须承认，其实我们很少能有机会能够和终端客户面对面的，原因很多，时间上的，精力上的，市场上的，这其实就给产品经理出了一个自相矛盾的问题：既然市场客观要求我们要亲自接触客户，但是现实的情况却往往不能提供这样的条件。

对于从事企业消费类产品管理的朋友来说，对于需求的获取或许还稍微好一些，并且也会有更多的机会能够直接接触到终端客户，但是对于从事大众消费类产品管理的朋友们来说，这样的机会就少之又少了。

我个人现在也在为这个事情头疼，虽然说公司也强调产品经理应该尽可能多的处于一线，但是往往许多公司内的事情就把产品经理们折腾个够呛了，对于跑一线的事情往往是心有余而力不足了。

因此，对于大部分的产品经理来说，我们获得市场需求的主要途径就是经过第三方的反馈。

这个第三方所涉及的范围就比较大了，有代理商的，有经销商的，有销售部门的，有技术部门的，也会有高层的，总之，他们对产品的需求犹如洪水一样会不断的朝你涌来，面对这样的情况，我们又该如何应对呢？在这种情况下，我们通常会面对一个最为核心的问题：这些第三方往往认为他提的需求就是市场最需要，应该在新产品中必须要实现的。

也就是说，第三方喜欢并且习惯于充当产品设计者的角色。

01年的时候，我负责一款大众消费类的桌面软件，因为有一款软件已经在市场上占据了绝对的优势，无论是从品牌知名度，还是产品本身的性能上，我们都无法与其直接抗衡，但是，这个产品是基于公司整体竞争战略的，属于冲击市场的产品，是为我们的主力产品服务的，一般来说，对于这种产品，公司往往会重点考虑成本而不是产品本身，但是中国许多软件公司（包括许多互联网公司）的情况大家都比较清楚，基本上都是技术起家，一把手基本上都是技术高智商，业务低智商，他们习惯于对每一个产品指手画脚，把自己的一些想法或影或软的加入到新产品中去，而那些往往是思路不错，但是市场并不需要的想法。

如何做好需求分析

如何做好需求分析编辑导语：在设计一个产品的时候，我们首先要透过现象看本质，明白我们是要为谁，解决什么问题？分析的结果，将会直接影响到方案的好坏。

那么要如何做好需求分析呢？一起来看一下吧。

一、需求分析原则设计本质上是我们看待世界的一种思维方法，其目的是为了解决问题。

在实践中，我们总要知道，我们要为谁？在什么环境或条件下，解决什么问题？如何解决？其分析的结果，直接影响到解决方案的好与坏，成或败。

司空图有言：“超以象外，得其圜中”。

意思大概是说，要「越过事物表象，得其核心要义」，即透过现象看本质。

亦正如柳冠中老师在演讲中所说：“现象之外才是核心，设计真正的功夫是在设计之外。

”在实际工作中，我们能接触到的只是事物所呈现出来的表面特征，而触发这一结果的原因，或事物背后所隐藏的目的却不那么显而易见，这就需要我们从现象出发，从结果出发，一步步地分析现象，探寻现象背后的原因。

例如：用户要一个杯子，我们就要知道用户想要造杯子背后的目的、原因，是蓄水？饮水？还是送礼？先谋事，再造物。

先确定目标，再寻找路径和方法。

二、需求分析方法那么如何得知用户在谋什么事？如何探知现象背后的原因？现象背后潜藏的目的或动机？这就需要我们结合用户当时的处境（什么地点？什么时间？），其所扮演的角色，所表现出的行为出发，一步步探寻。

同样拿“我想要一个杯子”举例，在接到这个需求之后，应结合用户当时的处境，分析用户所处的场景、所扮演的角色，所表现出的行为，由此探知到用户需求背后的目的/动机。

1. 角色即用户的身份、角色，可以是个体用户，也可以是一个组织团体，如学校、企业、政府部门。

2. 场景包含具体的时间、地点。

3. 行为即用户具体做了什么事情，比如：1）个体用户所做的事情可通过具体的行为、语言表现出来，在前期调研访谈的时候，我们要重点关注用户的行为动作，这是因为个体用户不总是言行一致，有时候其口中所说的可能跟真实情况会有偏差，这并不是用户可以说谎，而是有些时候，用户对自己可能并非十分了解。

需求分析的六个原则

需求分析的六个原则（一）永远不要显得比客户更聪明不知道大家想过没有，为什么要把这条作为产品经理进行需求分析的第一原则呢？我个人觉的，之所以这条作为第一原则，就是告诉我们这些产品经理一个对待客户的基础态度，是什么呢？就是“平等”。

有朋友会说了，我们提供能够满足客户的产品和服务，客户付费享受这些，这肯定是平等的呀，有什么好说的呢？果然如此吗？02年的时候，我在一家软件公司做产品经理，当时我们公司为了能够让我们的客户更贴近公司产品，最好是参与到公司产品设计中（联盟里好像有这样一篇文章：《让顾客参与产品设计》）成立了一个叫“用户实验室”的部门，这是一个常设部门，专门有一个人在进行管理，主要的工作就是不定期的邀请一些公司的用户来体验公司的最新产品，并让他们提出自己的意见和建议，以方便产品部门进行进一步的改进，目的是在上市的时候，尽量能够达到用户期望的指标。

这个部门的运作就不具体说了，具体说一个案例吧。

有一次，公司另一个产品的产品经理组织了一次新产品用户体验，当时来了大概不到3 0个用户参与新产品的试用，大家想了，能够耽误个人时间来参加这次试用的用户肯定是公司或者产品的铁杆支持者了，因此，这些用户都显得非常认真，每一个细节都不放过，并且在试用完成后，都非常精心的完成了公司准备好的问卷，至少从我一个旁观者的角度来说，我觉的这次用户试用还是非常有成效的。

但是过了几天，我和那个产品经理闲暇聊天，问他看了那天的用户问卷，对产品有什么新的想法吗，他说“不瞒你说，你是没看那些问卷，那些人（指用户）的想法真幼稚呀，我就不信了，用户会提那样的问题出来”，我说“那你考虑去改进一下目前的产品吗？”，他说“改什么改，我设计的产品我还不知道，要是按照那些人的想法做，这产品成什么了，我和你说啊，那些人来就是一个噱头，咱们该怎么做还是怎么做”。

既然不是我负责的产品，我也就不好太多说什么，这件事情就这样过去了，直到看到这个原则了，我的头脑中才又浮现出这个事情。

需求分析的原理

需求分析的原理
需求分析的原理是为了确定产品或服务的功能和特性，并确保满足用户的需求。

通过需求分析，可以将用户的需求转化为具体、明确的产品或服务要求，为后续的设计和开发提供指导。

在需求分析过程中，需要采取以下原理：
1. 明确需求：需求分析的第一步是确保对用户的需求有清晰的理解。

要与用户进行沟通，了解他们的期望、问题和希望得到满足的情况。

通过访谈、调查、问卷调查等方法，收集用户的需求，确保有准确的需求基础。

2. 分解需求：将整体需求分解为可管理和实现的小模块。

这种拆分可以使需求更具体明了，并确定每个需求的优先级和相关性。

3. 确定需求的关联性：需求之间可能存在关联性，相互之间可能会影响。

通过分析需求之间的关联性，可以确保最终产品或服务的整体逻辑和功能的完整性。

4. 提出优先级：在需求分析过程中，应根据重要性和急迫性确定需求的优先级。

这有助于决定哪些需求先实现，哪些需求可以推迟或移除。

5. 结果确认：需求分析的最终目标是合理地将用户期望转化为产品或服务的功能和特性。

因此，在需求分析过程的每个阶段，都要与用户进行确认和验证，以确保需求的准确性和有效性。

需求分析的原理可以帮助项目团队设计出符合用户需求的产品或服务。

通过合理地分析和管理需求，可以提高产品或服务的质量，减少项目的风险，并最终满足用户的期望。

一、需求分析的概念和原则

⼀、需求分析的概念和原则3.1 需求分析的概念和原则需求分析是发现、求精、建模和规约的过程。

这⼀过程包括：详细精化最初由系统分析员建⽴并在软件项⽬计划中确定的软件范围，创建所需数据流、控制流以及操作⾏为的模型，在此基础上选择的解决⽅案。

在可⾏性研究之后，我们对值得开发的软件进⾏需求分析。

3.1.1 需求分析需求分析是⼀种软件⼯程活动，使得系统分析员能够刻划出软件的功能和性能、指明软件和其他系统元素的接⼝、并建⽴软件必须满⾜的约束。

需求分析是软件设计师进⾏软件分解的基础，需求分析建造了软件处理的数据模型、功能模型和⾏为模型。

需求分析为软件设计师提供了可被翻译成数据、体系结构、界⾯和过程设计的模型，最后，需求规约为软件设计师和客户提供了软件建造完后，进⾏质量评估的依据。

1.软件需求的概念和分类在我们分析需求之前，先要了解需求的类别，在获取需求时，按类别来处理就不容易遗漏。

对需求有很多种不同的分类⽅法，其中的⼀种分类⽅法告诉我们需求应该包括：1. 第⼀是功能需求，这⽅⾯的需求指定系统必须提供的服务，通过需求分析应该划分出系统必须完成的所有功能；2. 第⼆是性能需求，性能需求指定系统必须满⾜的定时约束或容量约束，通常包括速度（响应时间）、信息量速率、主存容量、磁盘容量、安全性等⽅⾯的需求；3. 第三是可靠性和可⽤性需求，可靠性和可⽤性需求即需求定量地指定系统的可靠性与可⽤性；4. 第四是出错处理需求，这类需求说明系统对环境错误应该怎样响应，例如，如果⼀个系统接收到从另⼀个系统发来的违反协议格式的消息，该系统应该做什么？5. 第五是接⼝需求，接⼝需求描述应⽤系统与其环境通信的格式，常见的接⼝需求有⽤户接⼝需求、硬件接⼝需求、软件接⼝需求和通信接⼝需求；6. 第六是约束，约束描述了应⽤系统应遵守的限制条件，在需求分析阶段提出这类需求，并不是要取代设计（或实现）过程，这只是反映了⽤户或环境强加给项⽬的限制条件，常见的约束有：精度约束、⼯具和语⾔约束、设计约束、应该使⽤的标准、应该使⽤的硬件平台等；7. 第七是逆向需求，逆向需求说明了软件系统不应该做什么。

需求分析的六个原则(六)

天下没有免费的午餐在前面的文章中，已经说到了这个问题，客户向我们提出的需求都是他内心最期望我们能够满足的，我看到一个朋友的留言，我觉的非常好，他是这么说的：“客户不是我们的竞争对手，他没有理由来欺骗我们，因为欺骗我们的最终结果就是使我们做出不符合他们需求的产品”，“如果说我们的产品有问题，那么首先应该从我们身上找问题，而不是客户”。

我非常赞同这位朋友的观点，这个观点其实也表明了需求分析原则六所强调的第一点：客户从来没有不合理的需求。

理解这点其实很简单。

客户购买我们的产品，是由各种各样的因素决定的，有价格的因素，有服务的因素，但从根本来看，还是因为我们的产品能够比其他的同类产品更好地解决客户的问题（当然，最终的购买还是多个因素综合作用的结果，也就是所谓的“性价比”），客户在使用我们产品的过程中，一方面自身会有新的需求产生，另一方面则发现我们目前的产品无法满足或者有效的满足这些需求，因此，他就会把这些新的需求反馈给我们，并期望我们能够在接下来的产品中能有所改进。

这是一个再正常不过的逻辑，我想没有一个客户会向我们提出不合理甚至是虚假的需求，因为这样做的结果最终只能是两败俱伤，只有我们的竞争对手会这样做。

有朋友会说了，嗯，你说的这点没有问题，但是，我却感觉客户提出的好多需求虽然真实，合理，但是却是不现实的，这又该如何解决呢？果然如此吗？要回答这个问题，得从两个方面来考虑。

1、客户提出的需求有不现实的吗？何为现实呢？客观存在的就是现实的，也就是说，只要客户提出了一个需求，那么就说明客户肯定是有这样的需求的。

之所以我们认为某个需求不现实，根本在于我们没有搞清楚这个客观是基于哪一方的。

这里强调一点，这种客观是基于客户一方的，而非我们一方的。

也就是说，有时候我们认为这个需求不现实，仅仅是从我们自己的角度来看待的，我们不是客户，不应该替客户判断某个需求的现实性。

还有一种情况是什么呢？就是有些需求在我们看起来似乎是不现实的，但是往往我们一下子就否掉了，说“这个需求太不现实了，无法满足”。

需求分析之六大原则

需求分析之六大原则需求分析的六个原则（一）永远不要显得比客户更聪明1、需求分析第一个原则：永远不要显得比客户更聪明。

聪明反被聪明误，这样的事情太多了，我们产品经理都是有智慧的人，而不是耍小聪明的人。

2、原则第一点：了解需求，而不是去批评客户。

产品经理不是批评家，心理上要重视客户，行动上要尊重客户，平等对待每一个客户。

3、原则第二点：客户比你更熟悉业务的环境。

产品经理熟悉的仅仅是产品本身，但是，产品经理要做的却不仅仅是产品本身。

4、原则第三点：真正的问题只有客户知道，我们要做的就是让客户愿意说出来。

客户会给你反馈，但是这些反馈有些是真实的，有些是敷衍的，你希望真实还是敷衍，请参考原则第一点。

需求分析的六个原则（二）尊重用户的现实选择1、需求分析第二个原则：尊重用户的现实选择。

产品是客观的，用户是客观的，使用是客观的，需求也是客观的，一切都是现实的。

2、原则第一点：客户永远是对的。

客户不是我们的敌人，客户不会害我们，客户提出的需求看似在为难我们，但本质上是为了让客户自己更好的使用产品，因此，客户不会为难自己。

3、原则第二点：提供最合适的解决方案，而非最好或最贵的方案。

我们能够做的不一定是最好的，我们不想做的有时候往往是客户最需要的，找到最合适客户的，而不是最合适我们的。

4、原则第三点：不要把客户当傻瓜。

需求分析的六个原则（三）转述需求的人也是客户1、需求分析第三个原则：第三方也是我们的客户。

只要是对我们的产品和业务提出需求，就是我们的客户，应该一视同仁。

2、原则第一点：第三方一般会把自己想象成设计者。

他们对产品或许很熟悉，但是对整个业务可能不熟悉，因此，他们成不了设计者。

3、原则第二点：第三方可能会遗漏或补充一些额外的需求。