如何做需求分析

墨蓝 2023-10-13 21:41 11阅读 0赞

**目录**

核心理念：

主要目的：

具体思路：

注意事项：

--------------------

## **核心理念：** ##

首先需要想清楚一个问题：作为一个测试，有没有把需求当作产品中的一个组成部分，然后尽到一个测试的责任与义务？只有建立这样的意识和规则，才能够把挖掘需求的事情做好，否则始终抱着“需求是产品负责，我不关心”的心态，那接下来的事情就无法进行。

## **主要目的：** ##

挖掘需求问题，有两大核心目的：

1. **提升产品质量**通过挖掘需求中的问题，解决需求中的问题，完善产品需求，从而完善产品，提升产品的质量。

**2.****提高项目效率**通过挖掘需求中的问题，尽早查漏补缺、解决分歧，避免问题遗留到项目中后期，导致返工、进度delay等风险，从而提高项目的效率。

## **具体思路：** ##

由于专业度上的差别，测试同学在挖掘产品需求问题时，确实存在一定的困难。但基于以往的经验，还是能够总结出一套思路，具体可以从以下几个角度进行：**1.****需求描述层面的问题：**

a) **错别字、病句等**

需求文档中难免会存在一些错别字、病句等文案错误，此类问题我们有必要给产品同学指正（但不要带着嘲讽的心态），因为有些时候这种错误一样会对产品、需求理解造成影响，例如：“未进行”和“为进行”，一字之差，谬之千里。又如：“账号”和“帐号”，用字用户提示中，影响产品的专业度问题。

b) **描述存在歧义**

需求描述的含义必须明确，描述存在二义性甚至多义性的问题，比较严重，可能会导致多方理解的不一致，导致开发、测试等团队的产出物不正确，进而返工，增加项目成本。我们需要与产品确认，并要求产品进行更正。例如：分身添加两个动作之间需要间隔字数的需求，需求描述为：4（以默认语速1.0为基准，覆盖4个字符）乘以语速（0.7～1.3）\*视频长度取值（四舍五入）。产品和测试前期讨论的方式为：（4个字符\*语速）取值四舍五入\*视频长度。开发的实现结果为：（4个字符\*语速\*视频长度）取值四舍五入。结果就导致结果与预期不符。

c) **需求内容遗漏**

此处不等于需求遗漏，而是指需求已经明确，但产品没有写入需求文档的情况。对下游团队，尤其是测试团队，需求文档是极为重要的依据，我们需要检查产品的需求文档是否编写完整，如果存在没有写入的情况，需要要求产品同学补充。例如：经过讨论已经规定该文本框中输入的最大字符数为100，但需求文档中没有更新。

2. **需求覆盖度的问题：**

a) **缺少流程节点**

在需求中涉及功能流程的地方，需要重点关注是否缺少某些流程节点，流程中的各个环节是否能够顺利连通。例如：用户没有权限使用某个功能时，应该给出跳转到购买该权益的入口，但需求中没有提供这个入口。

b) **缺少逻辑分支**

在需求中设计判断分支的地方，需要重点关注是否分支路径是否覆盖全面，是否存在分支路径的缺失。例如：提示用户购买高级会员，只规定了进行购买的后续流程，但没有规定用户取消购买的后续流程

c) **缺少需求定义**

在需求中涉及需求定义的地方，需要重点关注定义是否考虑充分，是否存在遗漏。例如：规定了高级会员有什么权益、普通会员有什么权益，但没有规定同时具备高级会员和普通会员的情况。

d) **缺少用户场景**

平时用户使用过程中经常出现的场景，在需求中是否有明确说明。例如：用户播放音频过程中，进行程序的前后台切换操作、手机锁屏状态下该如何处理等等。

e) **缺少异常处理和容错机制**

需要关注需求中，是否针对异常处理有约定的处理方式，用来提升程序的健壮性。例如：视频聊天过程中手机来电、断网，或者进行获取数据时服务器异常等等。

**3.****需求预期的问题：**

**a)****预期结果不明确**

需要关注需求中的内容是否都有明确的预期结果，需要让其提供明确的预期结果。例如：当网络出现异常的时候，弹出错误提示，但没有个出错误提示的具体内容。

**4.****需求合理性的问题**

**a)****必要性**

需要针对需求的必要性进行评估，要把产品的目标和用户的实际情况进行结合，综合考虑需求的必要性。例如：用户对转写结果的准确率要求极高，但本地转写的准确率又极差，那么添加本地转写这个需求的必要性，就需要探讨。

**b)****与目标的一致性**

需要关注需求中的内容，能否实现产品的目标。例如：产品需要收集用户是否主动关闭某个功能的数据，但该功能的入口做的非常的深，一般用户发现不了，那么这种需求就很难实现目标。

d) **连贯性**

需要关注需求持续迭代过程中的连贯性，前后的风格或操作习惯尽量保持统一，否则每个版本都在变，增加用户熟悉的成本。例如：之前版本中的页面都支持右滑返回上一页，而新版本中的新增页面，则不支持右滑返回上一页。

**d)****耦合度**

需要关注需求中不同功能之间的耦合度，尽量简单处理，保证各功能之间的相对独立性，如果耦合度太高，会导致功能复杂度变高，增加开发和测试的成本，也增加出现bug的几率。例如：文件存在语音转写和文件存储两部分功能，尽量让转写和存储这两部分的功能策略保持独立，不要把转写状态和存储状态增加组合的策略，如未转写状态只能按照条件1的情况存储、转写中状态只能按照条件2的情况存储、已转写状态可以按照条件1和2和3的情况存储。

**5.** **需求的用户体验问题**

a) **易操作性**

需要考虑需求中的功能是否容易操作。包括不限于：

i. 操作行为是否简单（如：单手点击）

ii. 操作路径是否简短（如：一键生效）

iii. 操作入口是否直观（如：开关放在设置首页，而不是三级菜单中）

iv. 是否符合用户习惯（如：继承用户之前的设置风格）

v. 是否符合系统环境的标准规范（如：Windows的支持键盘操作、iOS下确认弹窗中按钮的左右摆放规则）

**b)****易理解性**

需要考虑需求中对功能或名词的定义是否容易理解，用户能够一看就明白具体是怎么回事。如果不易理解，是否有清晰的解释说明。

b) **吸引力**

需要关注需求中的功能，是否对用户有足够的吸引力。例如：抽奖活动的需求，奖品的价值以及中奖的概率，是否足够诱人。

c) **交互反馈**

需要关注需求中的功能，在用户触发后，是否能够给用户对应的反馈，让用户清楚当前的状态。例如：点击下载，显示loading状态或这下载进度；触碰按钮，按钮状态发生相应的变化。

**6.** **需求的可行性问题**

a) **开发实现的可行性**

对于需求中的某些内容，需要关注开发实现层面的可行性，如果缺乏可行性，就需要提前指出。例如：语音识别准确率需要达到100%，这种在现有技术水平的状态下，根本无法实现。又如：整体功能逻辑与微信的效果对齐，这种在较短的项目周期内，根本无法实现。

b) **测试的可验证性**

对于需求中的某些内容，需要关注测试的可验证性，如果无法操作或者无法验证，就需要提前指出。例如：最大支持上传音频的个数为无上限，这种就明显无法验证。

7. **需求版本管理问题：**

**a)****需求版本标记不清晰**有时候需求文档中会同时存在多个版本的需求，或者因为工期问题导致同一个需求拆分成多个项目版本进行，这种情况下，就涉及到对需求版本的管理问题，需要关注需求的版本信息是否标记清晰、明确，能否清楚的掌握当前版本需要关注的需求范围。

## **注意事项：** ##

1. 要勇于提出问题。虽然测试在产品的专业度上有欠缺，但我们也是用户，而且是最早体验产品的用户，因此对需求有疑问，一定要勇于指出。

2. 不能为了提问题而提问题，要加入自己的思考，要带着提这个问题的原因和目的。例如：这个弹窗上放5个按钮不合理，原因：太挤了、或者用户找不到重点。

3. 在挖掘需求问题的时候，需要跳出需求的思维和角度，基于用户的习惯或者测试的视角，去审核需求，否则容易陷入产品的思路，觉得哪都是对的。

4. 提出的需求问题，建议通过邮件的形式公示，产品不接受或者不解决，也可做到备忘；其中测试认为比较严重的问题，可以在后续的进度或者测试报告中，作为项目风险进行公示。

在发掘用户体验性问题的时候，可以借鉴优秀的竞品，通过审视竞品的效果如何，来评估我们的需求处理是否存在问题。

--------------------

**以下是我收集到的比较好的学习教程资源，虽然不是什么很值钱的东西，如果你刚好需要，可以评论区，留言【777】直接拿走就好了**

![c1653dd19f35495583cef3678b57b6b0.png][]

![775632765b6744fbbecbd8fdd097d1ab.png][]

**各位想获取资料的朋友请****点赞 + 评论 + 收藏****，三连！**

**三连**之后我会在评论区挨个私信发给你们~

[c1653dd19f35495583cef3678b57b6b0.png]: https://img-blog.csdnimg.cn/c1653dd19f35495583cef3678b57b6b0.png
[775632765b6744fbbecbd8fdd097d1ab.png]: https://img-blog.csdnimg.cn/775632765b6744fbbecbd8fdd097d1ab.png