- 综合排序
- 最热优先
- 最新优先
- 来自专栏用户1337634的专栏
需求评审 - 如何全面理解需求
需求评审时，为了保证需求真实，必要，研发应该问哪些问题 功能描述 痛点：解决了用户什么痛点 场景：用户在什么场景下，以何种方式使用该功能，达到什么目的 闭环：有哪些用户使用该功能，是否能够形成闭环
70820编辑于 2022-08-23 - 来自专栏sylan215 的软件测试技术学习
需求评审之隐性需求
前两周，我分别通过两篇文章《测试人员参与需求评审的价值是什么？》和《需求评审之实战演练》对需求评审阶段要做的事情做了大概的说明，今天是第三篇，主要想说说需求评审过程中对隐形需求挖掘的重要性。 这里我想说的是，隐性需求，就是真实的原始需求。 ，其实这么简单的地方，需求评审的时候提一下，就可以把需求明确了，难的是谁能想的到。 这种事在需求评审过程中很常见，有一些貌似「不言自明」的逻辑，每个人都以为自己明白，别人也肯定能明白，并且和自己理解的一致，其实每个人可能理解的都不一样。 其实需求评审就是这么个明确显性需求、挖掘隐性需求，然后相互确认理解一致的过程。 这里我想说的是，隐性需求，就是避免经验主义。
1.2K30发布于 2020-03-04 - 来自专栏ThoughtWorks
怎样做好需求评审？
需求则不同，不适当的需求往往并不是那么明显，而且暴露的很晚。错误的需求往往不会责备需求的提出方，因为互联网时代需要快速 “试错”，而纠正需求所产生的工作却落到了工程师头上。 显然，这似乎不太公平。 错误的需求难以被质疑，这也带来了需求的肆意膨胀，是软件设计不加以克制的原因。 下面是一个检查清单，用于软件工程师在接受需求时来评审需求是否合理。 软件工程师应该建议产品经理提前准备需求，如果是 2-3 天内的需求，就需要警觉起来。 虽然互联网时代变化很快，但不是慌张的理由。 非功能性需求 评审需求时，非功能需求是最容易遗漏的需求，也是需求的冰山。下图是一个添加文章的需求，背后有交互、性能、UI等多方面的非功能性需求。 即使在技术上能完成，但是付出的代价非常大，也应该在评审时对此类需求进行质疑。 ---- 本文版权属Thoughtworks公司所有，如需转载请在后台留言联系。
52820编辑于 2023-04-28 - 来自专栏授客的专栏
测试思想-文档评审 关于需求评审
关于需求评审 by:授客 QQ：1033553122 1、 传统的软件开发模式中，太过依赖文档，有各种各样的文档，需求说明书，比如市场需求说明书，业务需求说明书， 软件概要说明书，软件详细设计文档等等 去掉无用的功能定义文档、需求文档可行方法： 想法快速制作成静态的原型->>根据“市场效果反馈”修改原型设计->>用真实数据建立一个动态原型->去除累赘 这样，以实际的界面或原型来说明你要构建一个真正的产品 从这个点出发，我们可以把重心从“需求文档评审”转移到“原型(Demo)评审”,以原型评审为中心，辅以必要的文档说明，作为原型的补充。 2、 三方协作 也就是说，每项功能需求的讨论都要开发人员，测试人员，产品人员的参与，有参与才有认同，开发前必须达成一致 3、各种评审会上，一定要有个能做决定的人，因为评审的时候各方不可避免地会对需求有不同理解
73140发布于 2019-09-11 - 来自专栏sylan215 的软件测试技术学习
需求评审之实战演练
今天我还拿这个例子来实操下在《测试人员参与需求评审的价值是什么？》中提到的需求评审关注点。 下面是模拟针对这个需求的需求评审。 二 先是需求合理性的讨论。 测试：「命令行的计算器，干嘛用的，为啥不用系统自带的计算器？」 产品：「恩，目前是演示环节，先不用考虑使用者，请忽略这个问题。」 这么简单一个 if 语句就可以搞定的需求，竟然可以提出 12 个有效问题，如果这些是在测试过程中提出，考虑下每个问题从提出到产品确认，然后开发修复，然后测试验证，这过程的损耗有多大，而如果是在需求评审阶段提出的话 五 好了，这次是从一个简单的需求着手，说说关于需求评审的两个关注点，可以想象一下，如果是比较大的需求，测试要提出的问题会很多，那么就需要考虑一些策略的问题了，比如分批次进行评审，每一次评审确定下合理的颗粒度 ，方便大家聚焦，但是不管怎么说，测试参与需求评审的作用是很大的。
66940发布于 2020-03-04 - 来自专栏授客的专栏
测试思想-文档评审 需求分析和评审简述
如果把所有的需求都看作同样的重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度 以上特点也是需求评审的要点，评审前可以根据实际情况指定需求评审检查表来帮助评审。 可以根据以上特点对需求进行评审 3．软件需求评审输出 还是一句话，根据具体情况适当的做好评审记录，形式不限，输出文档名称也不限，随便你取，^^内容才是重点 4．组织需求评审原则 还是一句话 正式评审是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职 责，对需求进行正规的会议评审。 6.需求评审的策略 (1)分层次评审 一般，可以分成如下的层次： *目标性需求指整个系统需要达到的业务目标，是最高层次的、基本的需求，是企业的高层管理人员所关注的。 (2)分阶段评审 应该在需求形成的过程中进行分阶段的多次评审，而不是在需求最终形成后才进行仅有的一次评审分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，这样就降低了需求分析返工的风险
1.2K10发布于 2019-09-10 - 来自专栏资深Tester
测试流程之需求评审
很多公司虽然有需求分析，但是并没有需求评审，今天我先给大家讲一讲测试流程中的重点之一—需求评审，需求评审的好坏直接影响接下来项目的质量，这也是为什么大多公司都会做需求评审的原因。 评审发起人： 产品经理 评审参与人： 相关的开发人员，相关的测试人员，SQA 以上人员都是必须参加的，这里相关人员是指与需要评审的需求相关的人员，除了以上人员其它的研发人员也可以参加。 评审之时： 需求评审之时产品经理作为主讲人，会针对需求文档进行详细的讲解和说明，那这时，开发人员和测试人员做什么呢？ 开发人员：对产品经理给出的需求，考虑如何用程序语言实现功能，主要是考虑可行性。 评审之后： 需求评审后，产品经理将最终确定出来的需求文档，以邮件的形式发送给团队所有成员。如果评审后的需求文档改动过大，需要再次发起会议，再次评审。 以上就是需求评审的全过程，但不是需求评审做好之后，需求分析就没问题了，一般来说需求分析会伴随整个测试过程。
1.5K40发布于 2018-06-08 - 来自专栏Miguel三先生
撕逼大会之需求评审
经历过需求评审的我们都知道一件事，就是当我们各项产出物都完成、流程捋顺的之后，我们会跟需求方确认，确认之后呢，紧接着就会进入到技术方的需求评审，这个评审的过程目的很明确，就是阐述自己的观点并且将设计文档在最可行下的方案得以落实和执行 ~ 但是需求评审中，往往不少产品会把自己搞的伤痕累累，为什么呢？ 我们今天要说的是，如何让需求评审更高效，更具体的可以落实，而不是变成异常各抒己见的撕逼大会！ （只是举个例子） 如果我们在这么一个点上因为每个人的每个不同的想法而一直争论，那么无疑是对需求评审会的亵渎，需求评审会在我看来本身就是一件以讨论技术实现方案以及评估工期时间节点为主的一场会议，如果真的停留在某一个点上一只撕的话 别做让自己后悔并且无法挽回的事~ 以上我们说了需求评审三个需要注意的点 另外，评审会有几个阶段，也想分享一下： 1 一、会前 会前最好把相关部门的现有工作进行一个总体的了解，因为任何一个新需求出来之前，
73930发布于 2018-06-19 - 来自专栏PM吃瓜(公众号)
需求评审，需求说明书的正确性
也有的时候,在需求评审会议中,大家的关注点常常会不知不觉的转向设计,结果需求评审会议成了设计讨论会议,大家想得最多的是需求如何实现,而不是需求文档本身有无问题。 评审开始 评审人员选择 需求评审涉及到各层次人员,在进行评审员选择时,一定要将各层次人员都囊括进来,他们可能有用户、需求分析人员、产品经理、项目经理、架构师、概要设计人员、详细设计人员、编码人员 正式评审与非正式评审结合 正式评审时指通过开评审会的方式,将需求涉及到的人员集合在一起,并定义好参与评审人员的角色和职责,对需求进行正规的会议评审。 (4)注意对需求方案的可行性和成本预算进行评审。 (5)注意对需求的质量属性进行评审。评审需求规格需要说明是否合理地确定了所有的性能目标,是否合理地确定了安全性方面要考虑到的问题。 用例文档作为需求重要的成果性文档也是需求评审主体之所在。 需求评审确认的重点是对关键用户的最常用和最重要的用例进行深入和细致的评审,首先要通过测试用例的主干过程。
1.6K10发布于 2020-07-01 - 来自专栏靠谱PM
需求评审会怎么做？
大概看到这个标题很多PM小伙伴情绪有些小波动，是的需求评审会听上去挺高大上，但对许多小伙伴来说简直就是噩梦，在行业内他还有个“优雅”的叫法“撕逼大会”，每个从会议室坚强走出来的小伙伴都有一部血泪史，废话不多说 为什么要开需求评审会？ 三、让参与者明确工作内容和交付时间 这个就是在我们几次需求评审修订后最终定方案，团队中的每个人员都清楚接下来每个人的工作内容和需要阶段性的产出交付物。 怎么做需求评审会？ 提前预约时间 参与需求评审会的人一般有以下一些人：领导、设计、研发、测试、运营。 对于要不要写这篇文章我也想了很久，大家应该都经历过需求评审会议，这里面没什么技术含量，但是如果需求评审会做的好对于产品经理树立威信很有帮助，需求评审会各种被挑问题，大家就会对你的能力质疑，做的好的话后面的沟通都会很顺利
69020发布于 2018-09-10 从人肉评审到 AI 陪审：需求评审会议的效率革命
前言 每个参与过需求评审会的人，都有过同一种感受：这个会，开得太费人了。 这不是个别团队的问题，这是整个行业需求评审会议的集体困境。 问题的根源，不是人不够认真，而是需求评审这件事本身，对人的认知负载要求极高，而传统会议的形式，几乎是最低效的认知协作方式。 ”到“需求质量资产”——评审价值的长期积累 五、结语：AI 陪审的边界，与人类判断的不可替代 主体 一、从“会上发现”到“会前消化”——评审节奏的前置革命 传统需求评审会议的结构是线性的：产品经理讲，参与者听 需求评审从“一次性消耗”转变为“持续积累”的过程，本质上是在建立组织层面的需求质量飞轮——每次评审的经验让下次评审更高效，更高效的评审让需求质量更高，更高的需求质量让整个研发交付过程的返工率降低，而降低的返工率又为更认真的需求评审释放了时间和精力 将评审数据纳入需求质量追踪：建立一个简单的数据记录机制，追踪每个版本的需求评审中发现的问题数量、类型和来源（AI 发现 vs 人工发现），形成可量化的需求质量指标。
2010编辑于 2026-03-31- 来自专栏测试之道
需求评审期间测试人员需要做什么？
参会人员 项目经理、产品经理、前后端开发、测试、（可能还有需求分析师、业务等，一般不在场） 首先我们来看看每个角色于需求评审会议的内心世界 产品眼中的需求评审 1.开需求评审会，意义不大，因为大家都不重视 2.宣讲过程，开发猿们在需求评审会上一讨论技术问题就没完没了，将需求评审会开成技术大会，留下我在那里目瞪口呆，要开好几个小时都开不完，还吐槽我文档写的不完整，哪有时间啊！ 开发眼中的需求评审 1.开始思考该版本中的需求自己目前的技术是否有难度 2.这些需求具体要怎么实现，前后端开始讨论这些数据的是前端自己去拿还是后端传给前端，接着就开启了技术讨论大会，口吐芬芳！ 不能每次让测试开发吐槽"功能一大把，用户不过十" 那么需求评审时期测试到底要做什么呢？ 1.需求评审前，提前进行需求熟悉阶段，逐一分析需求点，做好准备，相关需求疑问点列好清单，带着问题去参会。 ，项目群推送需求评审会议记录点，周知各位目前的版本的疑问点以及修改点，并提醒产品进行下次需求确认会议时间,这个会议也可以由测试主持，
1.2K20发布于 2021-03-04 - 来自专栏sylan215 的软件测试技术学习
测试人员参与需求评审的价值是什么？
学习过测试理论的同学肯定都知道，测试人员参与项目的第一步，大部分都是需求评审，但是不少测试同学反馈，自己很少参与需求评审，需求会议也很少喊测试人员参与。 我曾经参加过几次需求评审会议，就发现产品在那讲需求，开发偶尔会提一些技术实现上的细节问题，测试就只是在那听了，会议结束后，回去该干嘛干嘛，既然我们测试参与需求评审时不能产生什么价值，那产品怎么能在评审的时候想起来喊我们呢 终于到了今天我们要说的主题了，作为测试，参与需求评审时我们可以贡献什么价值？下面我说下我的观点。 1.需求评审的作用 回答上面的问题前，我们先看看需求评审到底是干嘛的？ 先不管书上怎么说，从我的经验看，需求评审就两个作用： 1.同步产品对于需求的详细设计 2.收集大家对于需求的各种反馈 对于需求设计，肯定是产品发起并负责的了，那么作为测试人员参与需求评审，着重点就在于第二点 2.需求评审的形式 最开始我提到有同学说没有参与过需求评审，有部分是面试的同学说的，但是详细问过之后，才知道他说的是形式的问题。
1.5K30发布于 2020-03-04 - 来自专栏FreeBuf
安全需求评审：业务研发团队该如何提交信息
那如何在安全需求评审中融合数据合规呢？我们今天先来看看需要业务研发团队提交的信息。 0x01安全需求评审的内容 在《信息安全技术 个人信息安全规范》中，规定了在某些场景下，需进行个人信息安全影响评估，包括信息所用于的目的、根据评估应当采取的安全措施等等。 可以看出DPIA的进行其实和安全需求评审的实施阶段类似，都是在项目立项或者需求阶段进行介入；其次，安全需求评审往往也需要了解业务涉及的敏感级别、业务的目的、处理方式、安全措施等情况，在内容上和DPIA需要研发所提供的信息有重合的地方 因此，应当更多的让研发做选择题，并通过选择题，让部分需求评审能够自动化（不要指望完全自动化）。 但是根据整个安全需求评审的逻辑来看，应该是先看当前版本主要开发了什么新的业务模块，为了实现这个业务模块需要哪些数据（是否包含个人信息），这些数据是如何获取的。
2K20发布于 2020-11-06 - 来自专栏HansBug's Lab
2021敏捷软件工程需求评审答辩问题总结与建议
团队软件工程的总体目标： 研发出符合用户需求的软件说明：要通过实际的工作收集、推导、提炼需求，并在软件发布后通过实际数据验证需求的确被满足了。 需求来自于实际，而不是自己想象出来的“需求”或者人云亦云的需求（例如：图书馆管理系统）。 问题与建议： N（需求） 【问题】你们对于市场做过哪些调查呢，是否对用户做过产品使用需求调查？ 问题与建议： N（需求） 【建议】将用户调研的结果也补充到需求分析报告中。 【问题】对于服务的管理者而言，是否需要一个平台来进行网站以及题库相关的管理？如果需要的话，微信小程序可否胜任？ 问题与建议： N（需求） 【答辩】是否对问答领域有限制？
1.1K10发布于 2021-04-19 - 来自专栏简尚
如何发挥需求评审的价值，测试同学应该怎么做？
需求评审没做好，可能会导致，整个研发过程节奏拖拉、提测质量烂、上线质量烂、项目延期 等综合症 ； 需求评审，是一个项目启动的源头；一般会有哪些人参与呢 ？ 产品、研发、测试，以及项目Leader ，甚至是业务方（当然，业务方这块，可以不用一起参与；可产品经理，单独找业务方评审；拆分成两个会议）； 高效的需求评审会议，至少得「产品、研发、测试」参与，且控制 问：“ 如何让需求评审真正发挥作用？ 我们现在有个需求评审会议通知人员到场，然后产品经理blabla讲了一番系统的基本需求比如要做注册、增加、删除等之类的。 很多公司，评审开始可能很好，慢慢的，可能就会变成形式；为了评审而评审，或者应付流程。 那么如何发挥需求评审的价值呢 ？ 4、评审结束后，把会议上大家的疑问点，补充后，发一个新版本出来，大家提前了解，并安排下一次的需求澄清会议（也可由测试主导）。 5、需求存档，确保最新，团队成员同步（建议放在wiki ）。
58840发布于 2020-07-13 - 来自专栏软件测试
需求评审时，如何让开发主动说“这个用例写得好”？
为什么总在提测后才暴露需求漏洞？为什么开发总觉得测试用例脱离实际？——测试左移的瓶颈，往往卡在‘用例协作’环节。本文分享3套经过BAT验证的实战方法，让开发从被动审查变为主动设计用例。” 一、需求反讲工作坊：把模糊需求变成可测用例场景：产品PRD描述“支持用户批量导入数据”❌ 传统做法：测试按文档写用例 → 开发实现时发现歧义✅ 左移方案：会前准备测试人员根据PRD 预先起草核心用例（例 Scenario: 上传含特殊字符的CSV Given 用户选择"工资表.csv" When 文件包含"薪资@2024"等特殊字符 Then 系统应过滤特殊字符并显示"已成功导入980条"效果：需求会耗时增加 0.2=0.3API接口是否定义明确的HTTP状态码输入非法参数应返回400而非500与开发共建知识库使用 Confluence+Jira 关联：[DEV] 提交代码 → 触发核对单检查 → [QA] 评审通过
24710编辑于 2025-08-12 - 来自专栏软件测试
需求评审总是漏？测试工程师的“找茬”清单请收好
本文将为你提供一份详尽的“找茬”清单，帮助你在需求评审中脱颖而出，成为团队中不可或缺的质量守护者。一、为什么需求评审总是漏？理解根本原因在分享具体清单前，我们先来分析为什么需求评审容易遗漏问题：1. 三、高效需求评审的实施技巧有了全面的检查清单，如何在实际评审中有效应用呢？以下是几个实用技巧：1. 评审后跟踪到位明确每个问题的责任人和解决时限验证问题修复效果，确保不引入新问题定期回顾评审效果，持续改进评审过程四、测试工程师在需求评审中的角色定位作为测试工程师，在需求评审中不应仅仅是“找茬者”，更应该是 团队粘合剂促进产品、开发和测试之间的沟通，确保各方对需求的理解一致。五、从需求评审到质量保障体系优秀的需求评审是高质量产品的基石，但它只是质量保障体系的一环。 结语需求评审是测试工程师展现专业价值的绝佳舞台。通过使用本文提供的“找茬”清单，你可以更系统、更全面地参与需求评审，提前发现潜在问题，大幅降低项目风险。
37010编辑于 2025-09-27 需求池管理工具全方位解析：从需求收集、评审到开发落地覆盖全流程场景
需求池管理工具，聚焦于产品需求从提出到落地的整个生命周期管理，覆盖需求的： 收集与录入 分类与筛选 评审与排期 分发与追踪 验证与归档 为什么你需要它？ ，如“新建 - 待评审 - 排期中 - 开发中 - 已上线” 负责人机制：清晰标记每条需求当前责任人，避免“扔完就没人管” 协作能力：支持评论、通知、提醒、审批等基本协同动作 系统集成性：是否能对接到 ✅ 明确“需求生命周期”设定标准的需求流转路径，并全员达成共识，如：新建 → 评审中 → 排期中 → 进行中 → 待验证 → 已完成✅ 责任人制度 + 定期审查每条需求必须绑定“当前处理人”，并通过周会 /需求评审定期更新状态。 ✅ 评审机制要上线不建议“谁提就谁做”，引入评审环节统一判断优先级和可行性。✅ 用户反馈入口整合通过表单、客服工单、社群等渠道接入统一平台，避免信息碎片。
44521编辑于 2025-07-14kanass通关指南(15) - 如何通过评审，有效保障需求和用例的质量
此方法添加的用例会自动关联当前需求。添加用例3、需求评审当某一类需求或某个模块的需求创建成功后，就可以在评审模块对其评审。需求评审目的：确认需求的正确性和可行性，确保项目参与人员统一理解并达成共识。 添加评审页面填写相关信息，并选择评审类型为需求提交需求评审属性说明属性是否必填描述评审名称必填用来标记当前评审，可以是某个人负责的需求、或者某个某个功能模块的需求、或者是某次迭代的需求等评审类型必填选择不同的类型 ，会导致接下来添加评审内容的不同，此时选择需求评审负责人必填选择当前需求的评审人计划日期必填当前评审的计划日期关联需求需求评审单创建完成后，进入评审单，点击右上角的关联需求->选择需要评审的需求。 关联需求4、用例评审当某个功能模块的测试用例创建成功后，就可以在评审模块对其评审。测试用例评审的目的：确保测试用例充分覆盖需求，并尽早发现需求理解与用例设计上的偏差。 关联用例5、再次提交评审点击需求或用例列表中的评审按钮，可以在弹出的评审页面查看需求或用例的详情，并点击通过或不通过。评审页面若评审为不通过，可以修改对应的需求或者用例。
19255编辑于 2025-11-26
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号