需求分析之六大原则
需求设计的原则
需求设计的原则
1. 需求可追溯性：每个需求都应该能够追溯到业务需求的来源和目标，以便能够有效地评估和控制需求变更。
2. 需求清晰和明确：需求描述应该简洁明了，避免模糊、歧义或多解。
3. 需求可测量性：需求应该能够进行量化评估和验证，以便能够确定需求的完成程度。
4. 需求可扩展性：需求设计应该具有一定的弹性和可扩展性，以适应未来的变化和需求的增加。
5. 需求可验证性：需求应该能够通过测试和验收验证，以确保它们满足用户的期望和需求。
6. 需求一致性：需求之间应该相互一致，避免冲突或相互矛盾的情况。
7. 需求可实现性：需求设计应该考虑到技术和资源的可行性，以确保需求可以在给定的限制和条件下得到实现。
8. 需求可交付性：需求应该能够被准确地传递给开发团队，并能够被他们理解和实施。
9. 需求的优先级和重要性：需求应该有明确的优先级和重要性，以便能够合理安排资源和确定开发的顺序。
10. 需求的可维护性：需求设计应该具有良好的可维护性，以便能够随时进行需求的修改和调整。
优秀系统分析师必读：需求分析20条原则[1]
![优秀系统分析师必读：需求分析20条原则[1]](https://img.taocdn.com/s3/m/b77ccde0551810a6f5248678.png)
优秀系统分析师必读：需求分析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个用户参与新产品的试用，大家想了，能够耽误个人时间来参加这次试用的用户肯定是公司或者产品的铁杆支持者了，因此，这些用户都显得非常认真，每一个细节都不放过，并且在试用完成后，都非常精心的完成了公司准备好的问卷，至少从我一个旁观者的角度来说，我觉的这次用户试用还是非常有成效的。
但是过了几天，我和那个产品经理闲暇聊天，问他看了那天的用户问卷，对产品有什么新的想法吗，他说“不瞒你说，你是没看那些问卷，那些人（指用户）的想法真幼稚呀，我就不信了，用户会提那样的问题出来”，我说“那你考虑去改进一下目前的产品吗”，他说“改什么改，我设计的产品我还不知道，要是按照那些人的想法做，这产品成什么了，我和你说啊，那些人来就是一个噱头，咱们该怎么做还是怎么做”。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
需求分析之六大原则
需求分析的六个原则（一）永远不要显得比客户更聪明
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、原则第三点：我们能做这事－这是所需的费用。
成本第一还是需求第一，客户把这个问题交给了我们，我们就用用我们的智慧去解决这个问题。
来源:网络
人人都是产品经理（）中国最大最活跃的产品经理学习、交流、分享平台。