如何洞察用户需求

读《匹配度：打通产品与用户需求》-第二部分 探寻用户需求：

第三章 问对问题才能找准需求

一、探索性洞察与问题性洞察

1企业启动需求洞察的目的

探索性洞察， 第一种是企业并不知道有什么问题，一切发展都很正常。但是企业希望能够发掘一些用户的新的需求，建立自身的竞争优势。这种情况下，你并不清楚是否真的存在需求，也没有明确的目标需要解决什么问题，不知道有没有需求。

探索性需求则往往容易被忽略掉——没有明确的目标，不知道最后是否有真正的产出，投入产出比不可预测。

“探索性洞察没有明确的目标需要解决什么问题”

问题性洞察， 第二种是企业明确知道用户的问题，但是对问题的很多具体细节和原因并不了解，希望能够对问题了解得更透彻深入一些。

问题性需求研究在企业内部更常用一些，毕竟这是由问题驱动的，企业内部可以建立明确的机制去跟踪和管控这种需求研究工作。有问题，不知道问题在哪儿。

“有问题，不知道问题在哪儿。”

2疑惑与难题

所谓疑惑，指的是你对事情的运作机制不清楚，不知道事情为什么会发生，你想知道的是问题发生的原因。这种问题常常体现为 “为什么”

所谓难题，指的是你处于一种棘手的状态，你希望能够有办法摆脱这种状态，让事情重新回到轨道或者得到改善。这类问题通常会以 “怎么办” 的方式提出。

“疑惑，先搞清楚愿意，询问为什么。难题，寻找方案，询问怎么办”

3企业想解决难题，首先真正应该花精力搞清楚的往往是疑惑。

当企业开始进行用户研究的时候，常常围绕着难题去想办法解决，但是每一个难题背后其实都有可能有着一些新的疑惑没有得到解决。

企业想解决难题，首先真正应该花精力搞清楚的往往是疑惑。当没有找到用户变化的原因，而围绕着难题制定解决方案的时候，最终结果常常变成头疼医头。

有疑惑，企业照样可以运营，甚至可以很赚钱。每一个疑惑中都有可能隐藏着用户深层次的需求，忽略疑惑，不仅意味着企业没有充分挖掘出用户的价值，还意味着企业留下了隐患——如果有其他企业发现了疑惑的原因，并有针对性地制定策略去竞争，就会抢走你的用户企业由于不理解竞争对手策略背后的原因，虽然有可能去模仿对手的策略，但很有可能“画虎不成反类犬”。

前面提到的企业希望不造成用户流失的情况下涨价

＞需要了解到底是哪些用户在付费？(who)

＞他们从企业获得了什么价值？（what）

＞他们为什么会为获得的这个价值付费？(why)

＞他们觉得他们付费和价值之间匹配吗？(how)

＞他们还愿意为新的衍生需求付费吗？(how)

“企业想解决难题，首先真正应该花精力搞清楚的往往是疑惑。”

4免费+增值服务收费

互联网常规的“免费+增值服务收费”的模式，缺乏对这种策略背后原因的深层次的理解——缺乏对有钱人玩网游动机的洞察。在后期的运营中，巨人网络围绕着有钱人打造的运营模式，仍然很顺利地占据了市场。

“免费+增值服务收费，先提出为什么，找到有钱人付费原因。”

二、该从哪里开始？

不管是探索性洞察，还是问题性洞察，你都面临着各种不确定性。

探索性洞察不必说了，连个问题都没有，即使是问题性洞察，很多情况下，当你刚接手这个问题的时候，也会有一种不知该如何着手的无力感。

在需求洞察的过程中，似乎也存在类似情况：你不知道需求在哪里，你就无法去研究，而你不研究，你就不知道需求在哪里？

“洞察需求，面临着各种不确定性”

1人如何打破这个怪圈

从自己已经掌握的筹码着手，制定你的计划，粗略地确定一下 这次用户研究的范畴、任务和假设 。

[1]范畴。 你需要考虑你到底要在多大范围进行你的用户洞察，你需要关注哪几类用户，你需要挖掘用户的哪些场景，你需要研究用户哪些行为？

“从哪些用户类型、哪些使用场景、哪些用户行为角度确定范围”

[2]任务。 你的用户洞察最终要达到什么样的结果，是找到新的细分市场？新的推广渠道？还是找到问题的原因？或者是验证某个方法是否满足用户需求？

“最终要达到什么样的结果，达到什么目的”

[3]假设。 不要考虑对错，凭你的直觉设想一下你觉得可能会有什么结论：老年人会是新的细分市场？养老院是否会成为新的推广渠道，担心养老院服务不好是否是老人不愿意去养老院的原因？

"提出假设，设想一下你觉得可能会有什么结论"

2第一个计划

你的第一个计划的过程中，你可以把你想到的各种可能情况都写下来，不要担心对错的问题，你需要通过记录尽可能地把你想到的各种信息呈现出来，以帮助你确定下一步的方向。

首先，这个阶段你在做的是初步的计划，这个计划本身并不是一个最终确定的执行方案。任何想法都可以写出来，而且要不停地写，不停地写。

其次，在梳理过程中，范畴、任务、和假设之间要相互补充， 尽可能形成一个闭环的架构 。不要把这个计划看成是一个最终的框架，所有的范畴、任务和假设都肯定会随着你洞察过程地深入而不断调整，目前的内容只是让你迈出第一步。

“第一个计划所有的范畴、任务和假设相互补充，尽可能形成一个闭环的架构。随着你洞察过程地深入而不断调整”。

3当问题明确的时候，请有选择地增加不确定性

当需求本身不清晰的时候，第一步本身就是带着摸索和试探的成分。

一个简单的选择就是就问题解决问题，这样非常直接，也很简单。但我的建议是在不影响解决问题的时间期限基础上，刻意让需求变得更模糊一点。因为当目的性特别明确的时候，你的视野很有可能会被目的束缚住。过于专注，往往会导致你可能会忽略掉一些重要的发现。

“还有什么原因和方案？”

“不注意视盲”

当你完全专注在一件事情上时，就会忽略周遭的其他事物。当你在集中精力考虑如何进行页面优化、改善用户体验的时候，可能一些同用户有关的信息就从你身边悄悄溜走了。

专注能够帮助我们尽快处理紧急的情况，但是用户洞察却不一样，用户洞察希望能够发现的不仅仅是表层的需求，而是更深层次的欲望，这需要我们把注意力的网铺得更大一些。

过于认真负责反而可能阻碍一个人获得好运。一般人认为“认真负责”能确保一个人的执行力，是成功的重要因素，但是由于我们把所有精力都投入到了一个方向上，最后反而导致我们错过了意料之外的成功途径，我们可能因为专注过头而适得其反。

“用户洞察发现更深层次的欲望，需要我们把注意力的网铺得更大一些。过于认真负责反而可能阻碍一个人获得好运。”

发现新用户

企业总是希望能够 发现用户新的需求 ，可是最起码你也该把目光从用户现在的需求上挪开，先去看一下用户的其他需求，不是吗？所以在研究中针对问题尽可能多的增加需求的不确定性。

4提出一个好的问题

提出好问题就相当于问题解决了一半。提出好问题的过程本身就是一个思考深入的过程

目的性需求的问题修改模板-难题

第一步，将问题中涉及的解决方案的部分暂时去掉。过早地明确解决方案不利于需求的洞察。

在问题中“我们应该如何设计积分体系，才能降低用户流失率呢？”积分体系属于解决方案，修改后的问题变成“我们应该如何才能降低用户流失率”。

第二步，如果问题是“难题”模式问题，统一改为“疑惑”模式问题。（为什么？）

如果问题是询问“怎么办”或者“如何”，统一改为“为什么”。因为，首先洞察问题的原因，才能更好地洞察用户的需求。

所以问题“我们应该如何才能降低用户流失率”改为“为什么用户流失率会这么高？”

第三步，修改第一步的问题，询问问题的目的——我们为什么要降低用户流失率？（为什么要？）

我们把目的性需求的问题修改为：

[1]为什么用户流失率会这么高？

[2]为什么要降低用户流失率？

“针对难题应该先问“为什么”寻找原因，再“为什么要”动机”

探索性需求的问题修改模板-疑惑

探索性需求的问题的修改不是基于你原来提出的问题，而是从企业内部的运营内容上开始着手考虑。

第一步：说明一下你理发店的核心产品是什么。即使是拓展新的业务，也不能彻底放弃你的核心业务。

你的核心服务——为顾客理发。（是什么？）

第二步：在核心产品基础上问一个为什么，只要问一个为什么就可以了（为什么要？）

你的问题变成“用户为什么要理发？”

最后你给出的结论是“保持形象和心情”。

第三步：在第二步的基础上问一个“还有什么”。这个问题是拓展用户需求的范围。（还有什么？）

在这里可以问“还有什么服务或产品可以保持形象和心情？”

第四步：仍然在第二步的基础上问一个“意味着什么”

这个问题是探索满足用户需求的价值，在这里可以问“保持好心情对用户来说意味着什么”？（意味什么？）

只用4个步骤，得出两个问题。

[1]还有什么服务或产品可以保持形象和心情？

[2]保持好心情对用户来说意味着什么？

“从是什么？-明确自己的核心产品、为什么要？-明确用户价值？还有什么？-其他方案，意味什么？-用户价值观”

第一个问题，扩展了你研究的范围。

为什么我建议只问一层为什么呢（在标准咨询方法看来其实要求问5个为什么）？因为通过第一层的为什么，其实是要把与你相关的第一层的间接竞争者给考虑进来。

考虑间接竞争者以后，你对竞争的范畴就会有了不一样的看法。这个问题尤其适合两种类型的市场：

[1]市场竞争激烈 ，整个市场是一片红海的市场。通过这样的问题，能够帮助企业跳出红海来看问题。

[2]利润丰厚 ，监管逐步减少的市场。通过这样的问题，能够帮助企业发现潜在的挑战者。

第二个问题则是让你思考价值和意义。

其核心目的是希望让用户的回答能够更发散，能够更聚焦于意义，能够阐释出更多的关联关系，而不仅仅是因果关系。

“核心目的是希望让用户的回答能够更发散，能够更聚焦于意义”

如何完成关键的第二步骤

，第一步、第三步、第四步都相对比较简单，在实际 *** 作中最难把握的就是第二步，针对核心产品问一个为什么。

"用户为什么要？"回答这个为什么的时候，需要保持三个原则

[1]不要回答客观现象，而要回答用户感受。

在描述原因的时候不要去讲现实的客观情况，而是要讲用户的目的

[2]不要讲产品，而是要讲变成的价值和作用

不要说“用户想要加湿器”，而是要说“用户想要保持空气湿润”。

[3]价值要体现在对自己的好处上。

你需要进一步把这种过程变成对自己有着直接好处的结果。例如从“想要保持空气湿润”变成“想让皮肤更有d性”。

以滴滴打车为例

[1]核心产品是什么：协助打车服务。（是什么？）

[2]为什么打车？因为我们要出行，我们要去某个地方。（为什么要？）

[3]还有什么服务和产品可以帮助出行，如私家车、火车、飞机、自行车……（还有什么？）

[4]出行对人们意味着什么——旅游、奔波、回家、远离、告别、期待相逢……（意味什么？）

当提出新问题的时候，可以发现，我们对痛点的理解已经进入到了一个更高层次的需求

[1]更广泛的市场。

站在出行的角度去考虑更广泛的市场，我们可以把所有的出行工具都考虑进来，甚至于包括马车、宇宙飞船。这时候你考虑的是如何用同样的算法和服务去适应更广泛的市场。你的算法，效率水平都在向更广的市场延展。

[2]更深层次的理解。

你还可以同时去匹配深度和广度的理解——用不同的出行手段去匹配不同的出行意义，满足人们的深层次的心理需求。

无论是探索性需求的问题模板还是目的性需求的问题模板，都不一定只有这一种唯一的问题优化方法，每个人都可以设计开发出自己的模板框架

[1]好的问题能够帮助你发现新的认识需求的角度。

[2]好的问题能够激发去探究更深层次的原因和意义。

[3]好的问题能够引发范围和层次更广的思考。

三、重点不是答案，而是问题背后的意义

真正有价值的是在解决问题过程中对问题的反思：

问题本身提出是否有问题？

是否还有其他的问问题的方式？

为什么要从这个角度提出问题？

是否还有其他的诠释角度？

寻找答案的过程就是在思考问题本质，发现问题内涵的过程。真正的洞察就像埋在沙砾中的真金一样，在一次次的打磨淘沥中，在一次次的反复思辨中从众多的假设中脱颖而出，沉淀下来。

"寻找答案的过程就是在思考问题本质，发现问题内涵的过程"

直接关注答案的后果，直接关注答案最容易引发的就是抄袭。这种一窝蜂不探讨原因的“解决方法”通常都不会真正解决问题，因为他们缺乏成功者前期的深入思考，缺乏对自己所处场景差异的比较。有时候，不仅别人会抄袭成功者的答案，成功者自己也会抄袭自己的答案。当成功者第一次找到痛点，并成功满足痛点的时候，就很容易把这种痛点移植到其他领域。

成功者对成功因素的总结虽然具有一定价值，但是成功者只有在经历失败以后，才能更清楚地认识到当年成功中的各种必然、偶然因素，才能对用户的需求有更透彻的洞察。

"当成功者第一次找到痛点，并成功满足痛点的时候，就很容易把这种痛点移植到其他领域。"

四、用问题去了解用户

1你需要开始规划你的研究提纲，明确需要了解的用户信息。

围绕着你最终想知道的问题，把你的问题一层层分解开，逐步与用户的经历关联起来。你需要设计一套了解用户的问题提纲，帮助你在后续分析过程中能够获得必要的用户信息。

在用户洞察中，你的提纲是可以随着洞察的深入不断修改的。把新的想法再一次融入你的提纲中，并在与新的用户交流时使用。你的提纲要保持灵活性和可拓展性。

规划问题提纲的时候，你需要设计一个结构体系，一层层地分出目录结构，这样能够帮助你清晰地展现问题的层次。问题提纲可以按照从普遍到具体、从行为到心理、从现象到原因，从理性到感性的层次来设计。

“设计一套了解用户的问题提纲，问题提纲可以按照从普遍到具体、从行为到心理、从现象到原因，从理性到感性的层次来设计。”

在线教育问题的框架示例

1核心问题：

[1]用户是如何理解教育的？（what、why）

[2]教育的在线化对用户意味着什么？

"最核心是背后的意义"

2基本情况：

[1]姓名、年龄、性别、职业、职位、学历

[2]平时的时间安排。

[3]目前是处于一种什么样的状态之中。

[4]希望有什么改变。

[5]目前这个生活阶段的生活重心。

[6]希望学习、提升的内容。

“现阶段状况包括时间、任务、心态等”

3使用情况：

[1]电脑、网络电视、手机使用情况。

[2]教育类型、选择的标准和依据、教育带来的价值、希望实现的目标（短期、长期）。

[3]教育场景（家庭内、家庭外）、学习频次。

[4]针对每一种场景描述：过程中的环节描述，环节之间的行为逻辑，过程中的问题，原因是什么？

[5]过程前后的附加环节（比如：参加辅导班来回的交通）。

[6]过程中的情绪：愤怒、沮丧、放弃、绝望/惊喜、认可、轻松。

[7]最认可的内容，最不认可的内容。

“目标、不同场景心态等”

4在线教育决策：

[1]对在线教育所包含内容的理解。

[2]是否考虑过在线教育，哪些内容会考虑使用在线教育的方式。

[3]购买价格和决策。

[4]购买前后最担心的问题，最看重在线教育的优势是什么？

[5]哪些情况会让你坚持下来。

问题框架可以帮助研究者把希望研究的核心问题分解成希望了解的用户的问题。

问题提纲六个方面的内容

1基本情况。

用户的基本人口学特征、家庭情况、工作情况、兴趣爱好、日常情况等。

说明：了解用户基本情况，对用户可以初步打上特征标签，能够帮你确认是否用户能够满足研究需求，在后续分析过程中，也可以作为分类标签进行使用。

“了解用户基本情况，对用户可以初步打上特征标签”

2行为描述。

用户的决策、购买、使用流程如何（包含现在的和期望的），每一个环节有什么更细分的子环节，每一个子环节包含的动作及与其他内容的互动，以及消耗的时间。

说明：了解用户的行为及场景能够更好地与用户接触、引发用户注意，同时能够最大限度地减少用户的交易成本，促使用户选择。

“实际调研获取行为信息，线上埋点获取行为数据”

3场景及影响因素描述。

用户行为发生的场景是什么样的，不同场景是否对行为有影响，除了场景因素，用户购买和行为还会受到哪些因素的影响，不同因素的影响力差异如何。

说明：了解场景及影响因素能够更好地把握用户需求产生的外因，了解什么驱动用户购买，什么阻止用户行动，了解用户需求产生的真实动机。

“了解场景及影响因素能够更好地把握用户需求产生的外因，需求产生于场景”

4心理及情绪描述。

用户的情绪类型，用户在行为或者互动过程中的每一个环节的情绪变化，用户对产品整体的感觉和认可程度。

说明：了解用户的情绪能够更好地判断用户在使用过程中的痛点，有助于了解用户真正的需求以及对不同需求的渴望程度。

“了解用户的情绪能够更好地判断用户在使用过程中的痛点，不同需求的渴望程度--动机”

5偏好及思维模式描述。

用户思考问题的方式，是信息决策，还是凭直觉决策；是自己独立判断还是参考别人的经验。在不同的场景下，用户思维模式是不同的。

说明：用户的思维模式是用户的基础，虽然不同的人有着不同的思维模式，但是对不同细分人群而言，其用户的思维模式还是具有一定的共同性。这种思维模式，一定程度上决定了用户的决策和判断的机制和方式。

“由于群体效应，导致群体无自主思维，”

6生活模式及价值观描述。

主要指用户坚持的原则、用户决策的依据、用户理解风险和价值大小的看法。

说明：用户的生活模式和价值观决定了用户的选择标准。不同价值观的人对同一件事情的价值判断有可能是不一样的。比如用户不太愿意被打扰，那么说明文档就要做得简单易懂，如果用户需要随时咨询，那么呼叫电话就比较重要。

对问题的每一个模块都可以由大到小，层层深入地进行规划。看看用户对不同层次的概念，在行为与价值观上有什么差异。

“重点在于问题框架”

五、匹配问题的方法和计划

有了好的问题，并且围绕核心问题形成一套问题框架后，接下来就是需要考虑你的研究方法了。二手资料研究主要就是案头研究，一手资料研究最常用的是访谈与观察，除此之外还有痕迹物分析、日记法等其他方法。

访谈能够了解到用户行为的原因，但是在用户描述过程中可能会出现隐藏真实行为的情况。而观察则能够看到用户的所有真实行为，但却不能够获得用户行为背后的原因和解释。

[1]工作阶段和时间计划。列出项目的主要阶段和各阶段的计划时间。

目启动阶段、案头研究阶段、访谈（或观察）准备阶段、用户访谈阶段、分析阶段、汇报展示阶段

访谈准备由于需要确定访谈对象标准，提前预约访谈对象，有时候访谈对象还会放你鸽子，所以这部分在时间上要规划得多一些。

但是用户洞察后续需要不断地和其他部门沟通，吸取他人的意见，不断优化你的分析成果，这个时间是比较长的。在实际运营项目的过程中，我的经验是根据项目范围，直觉上会有一个最快的完成时间，然后我会在这个时间基础上乘以2，这样基本上是一个相对比较靠谱的项目时间。

[2]人员配置及分工。

稍微大一点的用户洞察项目，一般会分多个小组，每个小组配备2～3个人，同期进行执行。

[3]样本数量。

那么应该选择多少人呢？理论上只要一个用户就可以完成研究

在研究过程中，你才能知道需要多少的样本量。不过根据我的经验，如果必须要估计一个数量规模，那么每一个项目平均完成10～20个用户研究是一个比较基本合理的样本数据。

“每一个项目平均完成10～20个用户研究”

[4]辅助安排。 部分内容包括工具、场地等方面的内容。

[5]成本预算。 成本预算是你完成用户洞察的花费。

[6]执行提纲。 执行提纲和问题提纲不一样，它是可 *** 作问题提纲的细化

需求收集的常见方法有：

1、用户访谈：找寻目标用户并近距离接触，最好是以会面的形式，也可以采取电话沟通等途径增进了解，目的是通过交谈了解用户真实感受。

2、调查问卷：通过线上问卷的形式（有实体的也可以线下收集，但会增加统计工作量），设置一些有关产品功能、使用方面的问题。最终通过统计收集来的问卷信息，获取用户需求分布并直观解读各项数据情况。

3、可用性测试：制作高保真demo或可 *** 作原型提供给目标用户试用，观察用户 *** 作使用过程，并诱导用户说出 *** 作原因。

4、数据分析：对前端、后端设置埋点，统计并记录用户与产品相关联的数据信息，如按钮点击、UV、PV等。

扩展资料：

需求收集阶段完成后，你就会惊喜的发现，需求铺天盖地而来，但面对五花八门的需求该如何取舍，这可就是一门学问了。

在需求分析阶段，我们要做的是对需求初步挖掘，目的是找出用户的实际心理需求。在此过程中，实现对需求从标到本的剖析，探究表象背后的真实目的。虽然看上去很高深，其实，最终的分析结果只决定该需求是否有被记录下来的必要。

就像用户需要一匹马（需求），在对用户进行全方位的了解之后，发现他其实是想更快的前往某地（目标）。而我们的工作，正是服务于那些有出行要求的人。我们有能力满足他们的需求，在此基础之上，让用户能通过我们提供的方式更好的出行。那么，这个需求就有必要被记录下来。

而恰逢年底，招聘部一位主管在与一家客户进行置换时却发现对方关注的不仅是当期，还有长远的一些需求。在与这位主管聊及此事时，便又联及关于“用户需求挖掘”的思考。作为销售人员，在销售过程当中都要关注到用户资讯、用户需求、产品价值、用户关系、价格以及用户体验度这几个关键要素。一般情况下销售人员在与用户建立关系后往往就单刀直入开始销售产品，如果客户正有需求，那么销售成功概率会大些，但通常情况下用户对销售人员销售的产品可能有一些深度或者细节方面的需求，这就要求我们销售人员要悉心去挖掘。上年秋初，付遥老师来青岛授课，在谈到“大客户销售策略与管理”当中对于挖掘用户需求方面举过一个李亚鹏何以追到王菲的例子，作为王菲这样大牌明星，在金钱是断定不缺的情况下，除了有个所谓爱她的人，还有很重要是另一半要为她的女儿靖童所喜欢并接受，在这方面李亚鹏就做得非常好，他首先打动的是王菲女儿，然后王菲才慢慢接受李亚鹏，最后结为秦晋之好。当然，举名人的例子在授课当中可以加深映象，事实是否真如此也非我等关心。倒是那个关于“老太太买李子的故事”或许对挖掘用户需求有些启发：话说老太太去楼下菜市场买水果。来到第一个小贩水果摊前问：李子怎么样？小贩说：又大又甜，特别好吃。老太太摇摇头走了。又去另一个小贩摊前，问：你的李子好吃吗？小贩说：我这里是李子专卖，什么样的的李子都有。老太太说：我要酸一点儿的。小贩指着一只篮子说：这篮李子就不错，酸得流口水，您要多少？老太太说：来一斤吧。买完后老太太继续在市场里转悠，看到一家的李子又大又好，就上前问：“你这个李子多少钱？”小贩说：“您好，您问的是哪种李子？”老太太说：“酸一点的。”小贩看了看老太太：“别人都要又大又甜的，怎么你还要酸李子呢？”老太太答：“我儿媳妇要生孩子了，想吃酸的。”小贩笑着说：“老太太，您对儿媳妇真体贴，想吃酸的，说明她一定能给您生个大胖孙子。您称多少？”“再来一斤吧。”老太太被小贩说得很高兴，又买了一斤。小贩一边称李子，一边继续问：“您知道孕妇最需要什么营养吗？”老太太摇摇头，“孕妇特别需要补充维生素，您知道哪种水果维生素营养最丰富吗？”老太太又摇摇头，“猕猴桃含有多种维生素，特别适合孕妇。您要给您儿媳妇天天吃猕猴桃，她一高兴，说不定给您生一对双胞胎。”老太太一听，太高兴了，又称上一斤猕猴桃。小贩一边称猕猴桃一边说：“您人真好，谁摊上您这样的婆婆，一定有福气。我每天都在这里摆摊，水果都是当天从批发市场新鲜批来的，您媳妇要是吃好了，您再来。”“好啊”老太太很高兴的付了账。小贩从此又多了一个老主顾。三个小贩的表现，和我们许多销售人员在销售过程当中遇到的问题一样。比如第一个小贩，只是一味的夸自己产品好，根本不了解顾客需要什么样的产品；第二个小贩产品虽然丰富，仍然是被动等着客户来挑选。只有第三个小贩，非常善于提问，一部部去深层次了解顾客需求，老太太买酸李子本身不仅是为了获得小贩称赞她疼儿媳妇，她的目标和愿望是儿媳妇生下又白又胖的孙子，而第三个小贩抓住这个需求，适时得拉到了一个长期顾客。就好比与销售主管说起的那位用户，他们的需求与我们的需求之间有一些距离，我们的需求仅仅是对方能满足和达成的一部分，对方有更多的目标和愿望需要我们去挖掘和助其达成，而那些潜在需求得到满足时，这种显性需求自然而然便被解决。且在挖掘用户需求时，变陈述句为疑问句是比较关键的方法，通过提问，获得用户究竟“要什么？”、“为什么要”、“其他需要”，讲究提问方式和技巧，以同理心去倾听，在倾听过程当中将提问引导到容易回答，多回答一些“yes”，从而达成最终结果是“yes”，以促成销售结果。在越来越理性消费的今天，用户的需求非到是燃眉之急，通常都需要我们能准确判断用户表面的显性需求和懂得深挖潜在需求。尽管多数的领导层或者决策层更关心和结果或者说关心用户当下需求，但作为销售人员，一定要沉得住气，善于分析并挖掘用户更深层次需求，助其达成销售方案辅以实施，销售才得以顺利达成。这是销售高手玩得转的销售!

可以通过问卷调查和深度访谈的方法来获取用户的需求。

①问卷调查

问卷调查法的好处是利用线上平台，社交平台等多重分享，达到涉及范围广、参与人数多，误差小等特点。

百格活动的线上问卷调查，可以让参会者快速参与填写，进行提交。主办方可通过数据统计中心，将各类数据进行整合，选择不同的图表形式进行呈现出来，同时可以进行在线交叉分析和筛选。也可以导出Excel表格进行个性化分析，更能客观、清晰地分析出参会者的实际的需求。

②深度访谈

深度访谈是一种一对一的交流方式，可以在访谈之中与用户进行更长时间、更深入的交流。直接挖掘用户的需求，并且能够针对这些用户的需求，现场做出回馈反应。

1概念

需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求

关键的问题是一定要编写需求文档我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起系统的分析人员说:"我们想与你谈谈你的需求"客户的第一反应便是:"我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统"

百事通

而实际上,UGGs,需求并未编写成文档,因此新的分析人员不得不从头做起所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白用户的需求,那完全是自欺欺人

需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明"有些需求分析专家拓展了这个概念:"从系统外部能发现系统所具有的满足于用户的特点、功能及属性等"这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的而下面的定义则从用户需要进一步转移到了系统特性:

需求是指明必须实现什么的规格说明它描述了系统的行为、特性或属性,是在开发过程中对系统的约束

从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的"需求"术语存在,真正的"需求"实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识

任何文档形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述

2需求分析的任务

开发软件系统最为困难的部分就是准确说明开发什么最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软件系统的接口同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难

目前,国内产品的庞杂,一家企业可能有几个系统并立运行,它们之间接口是系统开发人员最头痛的问题

对于商业最终用户应用程序,企业信息系统和软件作为一个大系统的一部分的产品是显而易见的但是对于我们开发人员来说,并没有编写出客户认可的需求文档,我们如何知道项目于何时结束而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢

然而,即便并非出于商业目的的软件需求也是必须的例如库、组件和工具这些供开发小组内部使用的软件当然你可能偶尔勿需文档说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发生

近来,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件不幸的是,当他们开发完这个工具后,发现这个工具不能打印出源代码文件,使用者当然希望有这个功能结果这个小组只好手工抄写源代码文档以供代码检查这说明那怕需求明确无误并构思准确,如果我们没有编写文档,软件达不到期望目标也只能是咎由自取了

相反的情况,我曾见一个要集成到"错误跟踪系统"中的简单界面写了一页需求说明而 *** 作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误

事实上,需求文档在开发过程中一直起指导作用

3需求分析过程

可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适,如图4-1所示:

图4-1 需求工程域的层次分解示意图

需求开发可进一步分为:问题获取、分析、编写规格说明和验证四个阶段这些子项包括软件类产品中需求收集、评价、编写文档等所有活动需求开发活动包括以下几个方面:

确定产品所期望的用户类别

获取每个用户类的需求

了解实际用户任务和目标以及这些任务所支持的业务需求

分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息

将系统级的需求分为几个子系统,并将需求中的一部份分配给软件组件

了解相关质量属性的重要性

商讨实施优先级的划分

将所收集的用户需求编写成文档和模型

评审需求规格说明,确保对用户需求达到共同的理解与认识,并在整个开发小组接受说明之前将问题都弄清楚

需求管理需要"建立并维护在软件工程中同客户达成的合同" 这种合同都包含在编写的需求文档与模型中客户的接受仅是需求成功的一半,开发人员也必须能够接受他们,并真正把需求应用到产品中通常的需求管理活动包括:

定义需求基线(迅速制定需求文档的主体)

评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它

以一种可控制的方式将需求变更融入到项目中

使当前的项目计划与需求一致

估计变更需求所产生影响并在此基础上协商新的承诺,这种承诺具体体现在项目解决方案上

让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪

在整个项目过程中跟踪需求状态及其变更情况

以上几点说明是我总结了成功实施项目后系统分析人员的经验,同时也根据国内外的其他系统实施的相关成功经验,进行了总结

4需求的类型

下面这些定义是需求工程领域中常见术语的定义

软件需求包括三个不同的层次:业务需求、用户需求和功能需求(也包括非功能需求)

1业务需求(business requirement)反映了组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明

2用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务,这在使用实例(use case)文档或方案脚本说明中予以说明

3功能需求(functional requirement)定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求

在软件需求规格说明书 (SRS)中说明的功能需求充分描述了软件系统所应具有的外部行为软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用对一个大型系统来说,软件功能需求也许只是系统需求的一个子集,因为另外一些可能属于子系统(或软件部件)

作为功能需求的补充,软件需求规格说明还应包括非功能需求,它描述了系统展现给用户的行为和执行的 *** 作等它包括产品必须遵从的标准、规范和合约;外部界面的具体细节;性能要求;设计或实现的约束条件及质量属性所谓约束是指对开发人员在软件产品设计和构造上的限制质量属性是通过多种角度对产品的特点进行描述,从而反映产品功能多角度描述产品对用户和开发人员都极为重要

下面以一个字处理程序为例来说明需求的不同种类业务需求可能是:"用户能有效地纠正文档中的拼写错误",该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器而对应的用户需求可能是"找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词"同时,该拼写检查器还有许多功能需求,如找到并高亮度提示错词的 *** 作;显示提供替换词的对话框以及实现整个文档范围的替换

从以上定义可以发现,需求并未包括设计细节、实现细节、项目计划信息或测试信息需求与这些没有关系,它关注的是充分说明你究竟想开发什么项目也有其它方面的需求,如开发环境需求或发布产品及移植到支撑环境的需求尽管这些需求对项目成功也至关重要,但它们并非本书所要讨论的

5需求分析的原则

不重视需求过程的项目队伍将自食其果需求工程中的缺陷将给项目成功带来极大风险,这里的"成功"是指推出的产品能以合理的价格、及时地在功能、质量上完全满足用户的期望下面将讨论一些需求风险

不适当的需求过程所引起的一些风险:

1 无足够用户参与

客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫,开发人员可能也不重视用户的参与究其原因:一是因为开发人员感觉与用户合作不如编写代码有意思;二是因为开发人员觉得已经明白用户的需求了在某些情况下,与实际使用产品的用户直接接触很困难,而客户也不太明白自己的真正需求但还是应让具有代表性的用户在项目早期直接参与到开发队伍中,并一同经历整个开发过程

系统人员在实践过程中,也有些感觉,在实施一家公司的项目时,若无足够的用户参与,系统人员获得的需求是片面的,不完整的,这样系统在需求之初就埋下风险

2 用户需求的不断增加

在开发中若不断地补充需求,项目就越变越庞大以致超过其计划及预算范围计划并不总是与项目需求规模与复杂性、风险、开发生产率及需求变更实际情况相一致,这使得问题更难解决实际上,问题根源在于用户需求的改变和开发者对新需求所作的修改

要想把需求变更范围控制到最小,必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明,并将此说明作为评价需求变更和新特性的参照框架说明中包括了对每种变更进行变更影响因素分析的变更控制过程,有助于所有风险承担者明白业务决策的合理性,即为何进行某些变更,相应消耗的时间、资源或特性上的折中

产品开发中不断延续的变更会使其整体结构日渐紊乱,补丁代码也使得整个程序难以理解和维护插入补丁代码使模块违背强内聚、松耦合的设计原则,特别是如果项目配置管理工作不完善的话,收回变更和删除特性会带来问题如果你尽早地区别这些可能带来变更的特性,你就能开发一个更为健壮的结构,并能更好地适应它这样设计阶段需求变更不会直接导致补丁代码,同时也有利于减少因变更导致质量的下降

3 模棱两可的需求

模棱两可是需求规格说明中最为可怕的问题它的一层含义是指诸多读者对需求说明产生了不同的理解;另一层含义是指单个读者能用不止一个方式来解释某个需求说明

模棱两可的需求会使不同的风险承担者产生不同的期望,它会使开发人员为错误问题而浪费时间,并且使测试者与开发者所期望的不一致一位系统测试人员曾告诉我,她所在的测试组经常对需求理解有误,以致不得不重写许多测试用例并重做许多测试

处理模棱两可需求的一种方法是组织好负责从不同角度审查需求的队伍仅仅简单浏览一下需求文档是不能解决模棱两可问题的如果不同的评审者从不同的角度对需求说明给予解释,但每个评审人员都真正了解需求文档,这样二义性就不会直到项目后期才被发现,那时再发现的话会使得更正代价很大

4 不必要的特性

"画蛇添足"是指开发人员力图增加一些"用户欣赏"但需求规格说明中并未涉及的新功能经常发生的情况是用户并不认为这些功能性很有用,以致在其上耗费的努力"白搭"了开发人员应当为客户构思方案并为他们提供一些具有创新意识的思路,具体提供哪些功能要在客户所需与开发人员在允许时限内的技术可行性之间求得平衡,开发人员应努力使功能简单易用,而不要未经客户同意,擅自脱离客户要求,自作主张

同样,客户有时也可能要求一些看上去很"酷",但缺乏实用价值的功能,而实现这些功能只能徒耗时间和成本为了将"画蛇添足"的危害尽量减小,应确信:你明白为什么要包括这些功能,以及这些功能的"来龙去脉",这样使得需求分析过程始终是注重那些能使用户完成他们业务任务的核心功能

5 过于精简的规格说明

有时,客户并不明白需求分析有如此重要,于是只作一份简略之至的规格说明,仅涉及了产品概念上的内容,然后让开发人员在项目进展中去完善,结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况但在大多数情况下,这会给开发人员带来挫折(使他们在不正确的假设前提和极其有限的指导下工作),也会给客户带来烦恼(他们无法得到他们所设想的产品)

6 忽略了用户分类

大多数产品是由不同的人使用其不同的特性,使用频繁程度也有所差异,使用者受教育程度和经验水平也不尽相同如果你不能在项目早期就针对所有这些主要用户进行分类的话,必然导致有的用户对产品感到失望例如,菜单驱动 *** 作对高级用户太低效了,但含义不清的命令和快捷键又会使不熟练的用户感到困难

7 不准确的计划

据统计,导致需求过程中软件成本估计极不准确的原因主要有以下五点:频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规格说明和不完善的需求分析

对不准确的要求所提问题的正确响应是"等我真正明白你的需求时,我就会来告诉你"基于不充分信息和未经深思的对需求不成熟的估计很容易为一些因素左右要作出估计时,最好还是给出一个范围未经准备的估计通常是作为一种猜测给出的,听者却认为是一种承诺因此我们要尽力给出可达到的目标并坚持完成它

6需求分析人员和用户的合作关系

优秀的软件产品是建立在优秀的需求基础之上的而高质量的需求来源于客户与开发人员之间有效的交流与合作通常,开发人员与客户或客户代理人,如市场人员间的关系反而会成为一种对立关系双方的管理者都只想自己的利益而搁置用户提供的需求从而产生摩擦,在这种情况下,不会给双方带来一点益处

只有当双方参与者都明白要成功自己需要什么,同时也应知道要成功合作方需要什么时,才能建立起一种合作关系由于项目压力与日渐增,所有风险承担者有着一个共同的目标这一点容易被遗忘其实大家都想开发出一个既能实现商业价值,又能满足用户需要,还能使开发者感到满足的优秀软件产品

软件客户需求权利书列出了十条关于客户在项目需求工程实施中与分析人员、开发人员交流时的合法要求每一项权利都对应着软件开发人员、分析人员的义务而软件客户需求义务书也列出了十条关于客户在需求过程中应承担的义务如果愿意,可以将其作为开发人员的权利书

客户有如下权利:

1:要求分析人员使用符合客户语言习惯的表达

需求讨论应集中于业务需要和任务,故要使用业务术语,你应将其教给分析人员,而你 不一定要懂得计算机的行业术语

2:要求分析人员了解客户的业务及目标

通过与用户交流来获取用户需求、分析人员才能更好地了解你的业务任务和怎样才能使产品更好地满足你的需要这将有助于开发人员设计出真正满足你的需要并达到你期望的优秀软件为帮助开发人员和分析人员,可以考虑邀请他们观察你或你的同事是怎样工作的如果新开发系统是用来替代已有的系统,那么开发人员应使用一下目前的系统,这将有利于他们明白目前系统是怎样工作的,其工作流程的情况,以及可供改进之处

3:要求分析人员编写软件需求规格说明

分析人员要把从你和其他客户那里获得的所有信息进行整理,以区分开业务需求及规范、功能需求、质量目标、解决方法和其它信息通过这些分析就能得到一份软件需求规格说明而这份软件需求规格说明便在开发人员和客户之间针对要开发的产品内容达成了协议软件需求规格说明书可以用一种你认为易于翻阅和理解的方式组织编写要评审编写出的规格说明以确保它们准确而完整地表达了你的需求一份高质量的软件需求规格说明能有助于开发人员开发出真正需要的产品

4:要求得到需求工作结果的解释说明

分析人员可能采用了多种图表作为文字性软件需求规格说明的补充因为如工作流程图那样的图表能很清楚地描述出系统行为的某些方面所以需求说明中的各种图表有着极高的价值虽然它们不太难于理解,但是你很可能对此并不熟悉因此可以要求分析人员解释说明每张图表的作用或其它的需求开发工作结果和符号的意义,及怎样检查图表有无错误及不一致等

5:要求开发人员尊重你的意见

如果用户与开发人员之间不能相互理解,那关于需求的讨论将会有障碍,共同合作能使大家"兼听则明"参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间同样,客户也应对开发人员为项目成功这一共同目标所作出的努力表示尊重与感激

6:要求开发人员对需求及产品实施提供建议,拿出主意

通常,客户所说的"需求"已是一种实际可能的实施解决方案,分析人员将尽力从这些解决方法中了解真正的业务及其需求,同时还应找出已有系统不适合当前业务之处,以确保产品不会无效或低效在彻底弄清业务领域内的事情后,分析人员有时就能提出相当好的改进方法有经验且富有创造力的分析人员还能提出增加一些用户并未发现的很有价值的系统特性

7:描述产品易使用的特性

你可以要求分析人员在实现功能需求的同时还要注重软件的易用性因为这些易用特性或质量属性能使你更准确、高效地完成任务例如,客户有时要求产品要"用户友好"或"健壮"或"高效率",但这对于开发人员来说,太主观了并无实用价值正确的应是:分析人员通过询问和调查了解客户所要的友好、健壮、高效所包含的具体特性

8:调整需求,允许重用已有的软件组件

需求通常要有一定的灵活性分析人员可能发现已有的某个软件组件与你描述的需求很相符在这种情况下,分析人员应提供一些修改需求的选择以便开发人员能够在新系统开发中重用一些已有的软件如果有可重用的机会出现,同时你又能调整你的需求说明,那就能降低成本和节省时间,而不必严格按原有的需求说明开发所以说,如果想在产品中使用一些已有的商业常用组件,而它们并不完全适合你所需的特性,这时一定程度上的需求灵活性就显得极为重要了

9:获得满足客户功能和质量要求的系统

每个人都希望项目获得成功但这不仅要求你要清晰地告知开发人员关于系统"做什么"所需的所有信息,而且还要求开发人员能通过交流了解清楚取舍与限制一定要明确说明你的假设和潜在的期望否则,开发人员开发出的产品很可能无法让你满意

客户有下列义务:

1:给分析人员讲解你的业务

分析人员要依靠你给他们讲解的业务概念及术语但你不能指望分析人员会成为该领域的专家,而只能让他们真正明白你的问题和目标不要期望分析人员能把握你们业务的细微与潜在之处,他们很可能并不知道那些对于你和你的同事来说理所当然的"常识"

2:抽出时间清楚地说明并完善需求

客户很忙,经常在最忙的时候还得参与需求开发但无论如何,你有义务抽出时间参与"头脑风暴"会议的讨论,接受采访或其它获取需求的活动有时分析人员可能先以为明白了你的观点,而过后发现还需要你的讲解这时,请耐心一些对待需求和需求的精化工作过程中的反复,因为它是人们交流中的很自然的现象,何况这对软件产品的成功极为重要

3:准确而详细地说明需求

编写一份清晰、准确的需求文档是很困难的由于处理细节问题不但烦人而且又耗时,故很容易留下模糊不清的需求但是,在开发过程中,必须得解决这种模糊性和不准确性而你恰是为解决这些问题作出决定的最佳人选不然的话,你就只好靠开发人员去正确猜测了在需求规格说明中暂时加上待定(to be determined, TBD也可采用汉语拼音略写"DQD:待确定")的标志是个不错的办法用该标志可指明了哪些需要进一步探讨、分析或增加信息的地方不过,有时也可能因为某个特殊需求难以解决或没有人愿意处理它而注上TBD标志尽量将每项需求的内容都阐述清楚,以便分析人员能准确的将其写进软件需求规格说明中如果你一时不能准确表述,那就得允许获取必要的准确信息这样一个过程通常使用所谓的原型技术通过开发的原型,你可以同开发人员一起反复修改,不断完善需求定义

4:及时地作出决定

正如一位建筑师为你修建房屋,分析人员将要求你做出一些选择和决定这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等有权做出决定的客户必须积极地对待这一切,尽快做处理、做决定因为开发人员通常只有等你做出了决定才能行动,而这种等待会延误项目的进展

5:尊重开发人员的需求可行性及成本评估

所有的软件功能都有其成本价格,开发人员最适合预算这些成本(尽管许多开发人员并不擅长评估预测)你所希望的某些产品特性可能在技术上行不通,或者实现它要付出极为高昂的代价而某些需求试图在 *** 作环境中要求不可能达到的性能或试图得到一些根本得不到的数据,开发人员会对此作出负面的评价意见,你应该尊重他们的意见有时,你可以重新给出一个在技术上可行、实现上便宜的需求,例如,要求某个行为在"瞬间"发生是不可行的,但换种更具体的时间需求说法("在50ms以内",但若没有准确的技术分析不能轻易下结论),这就可以实现了

6: 划分需求优先级别

大多数项目没有足够的时间或资源来实现功能性的每个细节决定哪些特性是必要的,哪些是重要的,哪些是好的,是需求开发的主要部分只能由你来负责设定需求优先级,因为开发者并不可能按你的观点决定需求优先级开发者将为你确定优先级提供有关每个需求的花费和风险的信息当你设定优先级时,你帮助开发者确保在适当的时间内用最小的开支取得最好的效果在时间和资源限制下,关于所需特性能否完成或完成多少应该尊重开发人员的意见尽管没有人愿意看到自己所希望的需求在项目中未被实现,但毕竟是要面对这种现实的业务决策有时不得不依据优先级来缩小项目范围或延长工期,或增加资源,或在质量上寻找折衷

7:评审需求文档和原型

正如我们将在第1 4章讨论的,无论是正式的还是非正式的方式,对需求文档进行评审都会对软件质量提高有所帮助让客户参与评审才能真正鉴别需求文档是否的确完整、正确说明了期望的必要特性评审也给客户代表提供一个机会,给需求分析人员带来反馈信息以改进他们的工作如果你认为编写的需求文档不够准确,就有义务尽早告诉分析人员并为改进提供建议通过阅读需求规格说明,很难想象实际的软件是什么样子的更好的方法是先为产品开发一个原型这样你就能提供更有价值的反馈信息给开发人员,帮助他们更好地理解你的需求必须认识到:原型并非是一个实际产品,但开发人员能将其转变、扩充成功能齐全的系统

8:需求出现变更要马上联系

不断的需求变更会给在预定计划内完成高质量产品带来严重的负面影响变更是不可避免的,但在开发周期中变更越在晚期出现,其影响越大变更不仅会导致代价极高的返工,而且工期也会被迫延误,特别是在大体结构已完成后又需要增加新特性时所以一旦你发现需要变更需求时,请一定立即通知分析人员

9:应遵照开发组织处理需求变更的过程

为了将变更带来的负面影响减少到最低限度,所有的参与者必须遵照项目的变更控制过程这要求不放弃所有提出的变更,对每项要求的变更进行分析、综合考虑,最后作出合适的决策以确定将某些变更引入项目中

10:尊重开发人员采用的需求工程过程

软件开发中最具挑战性的莫过于收集需求并确定其正确性分析人员采用的方法有其合理性也许你认为需求过程不太划算,但请相信花在需求开发上的时间是"很有价值"的如果你理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术,那么整个过程将会更为顺利尽管去询问分析人员为什么他们要收集某些信息,或参与与需求有关的活动

系统分析人员在开发过程中可能会遇到以下问题,一些很忙的客户可能不愿意积极参与需求过程,而缺少客户参与将很可能导致不理想的产品故一定要确保需求开发中的主要参与者都了解并接受他们的义务如果遇到分歧,通过协商以达成对各自义务的相互理解,这样能减少今后的摩擦

7需求文档

需求开发的最终成果是:客户和开发小组对将要开发的产品达成一致协议协议综合了业务需求、用户需求和软件功能需求就像我们早先所看到的,项目视图和范围文档包含了业务需求,而使用实例文档则包含了用户需求你必须编写从使用实例派生出的功能需求文档,还要编写产品的非功能需求文档,包括质量属性和外部接口需求只有以结构化和可读性方式编写这些文档,并由项目的风险承担者评审通过后,各方面人员才能确信他们所赞同的需求是可靠的

你可以使用以下三种方法编写软件需求规格说明:

用好的结构化和自然语言编写文本型文档

建立图形化模型,这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系

编写形式化规格说明,这可以通过使用数学上精确的形式化逻辑语言来定义需求

由于形式化规格说明具有很强的严密性和精确度,因此,所使用的形式化语言只有极少数软件开发人员才熟悉,更不用说客户了虽然结构化的自然语言具有许多缺点,但在大多数软件工程中,它仍是编写需求文档最现实的方法包含了功能和非功能需求的基于文本的软件需求规格说明已经为大多数项目所接受图形化分析模型通过提供另一种需求视图,增强了软件需求规格说明

如果解决了您的问题请采纳！

如果未解决请继续追问

关于需求分析的文章相信大家都看过不少了，而且对于如何获取用户需求的方式方法也很多，最常用的就是报告了。今天，昌平IT培训主要就来简单讲解一下，当我们获得这些用户需求之后，如何根据不同的商业目的进行需求分类整理呢？

我们在进行需求分类的时候，一般有两种方式同时进行。

一、横向分类

首先来说，为什么我们拿到需求后，要把需求进行分类因为产品在不同时期，对于不同类别的需求，会有不同的权重。我们常说，产品有起步期、发展期、稳定期。而需求根据每个公司或者产品经理的定义，可能将需求分类为：功能类、bug修复类、体验类、运营类、数据类等。

(1)产品的起步期

在产品的起步期，我们会将核心功能的需求放在权重高一些的位置，把产品的地基打好，骨架搭好，快速上线来验产品模式。别连房子还没盖好，就在纠结地砖的颜色。此时的产品经理一定要控制好自己完美偏执狂的内心冲动，对于增加新功能和体验上的需求要做好排序，此时开发核心功能，快速投入市场试错才是我们的目标。

(2)产品的发展期

到了发展期会让产品尽快做完善，或根据市场反馈对产品方向进行一定的调整，此时bug修复类、运营类的需求就放在首位了。产品投入市场后，可以收集各渠道的用户反馈，有没有切实解决目标用户的问题产品的方向是不是正确的在产品发展期，完善产品的过程中，对于需求更是要有把控力，做需求分析最后输出的结果就是做需求决策，学习乔帮主做简约主义者，决定不做什么比决定做什么更加重要，往往鸡肋需求，开发出来上线容易，但是要去掉，就没那么容易了。

(3)产品的稳定期

再到了产品的稳定期，产品趋于成熟，用户数也多起来了，产品不断迭代，此时提升用户体验和数据类的需求就变得很重要了。比如A/Btest，在用户量小的时候，得到的数据会有较大的出入，是不可取的。在产品的稳定期，有比较大的用户量时，可以用数据来驱动产品的迭代。

以上就是关于如何洞察用户需求全部的内容，包括:如何洞察用户需求、需求收集的常见方法有哪些、如何挖掘用户需求等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！