❶ 需求分析和系统设计应该采用什么样的方法更能体现系统本质
1 需求分析的任务与过程
需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节，定义软件的其他有效性需求，细化软件要处理的数据域。用一句话概括就是：需求分析主要是确定待开发软件的功能、性能、数据、界面等要求。需求分析的实现步骤通常包括：获取当前系统的物理模型，抽象出当前系统的逻辑模型，建立目标系统的逻辑模型三个部分。具体来说，需求分析阶段的工作可以分成 4 个方面：
（1）问题识别：用于发现需求、描述需求，主要包括功能需求、性能需求、环境需求、可靠性需求、安全保密需求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求，以此来预先估计以后系统可能达到的目标。
（2）分析与综合：也就是对问题进行分析，然后在此基础上整合出解决方案。这个步骤经常是反复进行的，常用的方法有面向数据流的结构化分析方法（Structured Analysis， SA），面向数据结构的 Jackson 方法，面向对象的分析方法（Object Oriented Analysis，OOA），以及用于建立动态模型的状态迁移图和 Petri 网。
（3）编制需求分析的文档：也就是对已经确定的需求进行文档化描述，该文档通常称为“需求规格说明书”。
（4）需求分析与评审：它是需求分析工作的最后一步，主要是对功能的正确性、完整性和清晰性，以及其他需求给予评价。
❷ 需求分析有哪两种主要分析方法
从系统分析出发，可将需求分析方法大致分为功能分解方法、结构化分析方法、信息建模法和面向对象的分析方法。
(1)功能分解方法。
将新系统作为多功能模块的组合。各功能义可分解为若干子功能及接口，子功能再继续分解。便可得到系统的雏形，即功能分解——功能、子功能、功能接口。
(2)结构化分析方法。
结构化分析方法是一种从问题空间到某种表示的映射方法，是结构化方法中重要且被普遍接受的表示系统，由数据流图和数据词典构成并表示。此分析法又称为数据流法。其基本策略是跟踪数据流，即研究问题域中数据流动方式及在各个环节上所进行的处理，从而发现数据流和加工。结构化分析可定义为数据流、数据处理或加工、数据存储、端点、处理说明和数据字典。
(3)信息建模方法。
它从数据角度对现实世界建立模型。大型软件较复杂；很难直接对其分析和设计，常借助模型。模型是开发中常用工具，系统包括数据处理、事务管理和决策支持。实质上，也可看成由一系列有序模型构成，其有序模型通常为功能模型、信息模型、数据模型、控制模型和决策模型。有序是指这些模型是分别在系统的不同开发阶段及开发层次一同建立的。建立系统常用的基本工具是E—R图。经过改进后称为信息建模法，后来又发展为语义数据建模方法，并引入了许多面向对象的特点。
信息建模可定义为实体或对象、属性、关系、父类型/子类型和关联对象。此方法的核心概念是实体和关系，基本工具是E-R图，其基本要素由实体、属性和联系构成。该方法的基本策略是从现实中找出实体，然后再用属性进行描述。
❸ 系统分析方法有哪几种
系统分析方法（System Analysis Method）
什么是系统分析方法
系统分析方法是指把要解决的问题作为一个系统，对系统要素进行综合分析，找出解决问题的可行方案的咨询方法。兰德公司认为，系统分析是一种研究方略，它能在不确定的情况下，确定问题的本质和起因，明确咨询目标，找出各种可行方案，并通过一定标准对这些方案进行比较，帮助决策者在复杂的问题和环境中作出科学抉择。
系统分析方法来源于系统科学。系统科学是20世纪40年代以后迅速发展起来的一个横跨各个学科的新的科学部门，它从系统的着眼点或角度去考察和研究整个客观世界，为人类认识和改造世界提供了科学的理论和方法。它的产生和发展标标志着人类的科学思维由主要以“实物为中心”逐渐过渡到以“系统为中心”，是科学思维的一个划时代突破。
系统分析是咨询研究的最基本的方法，我们可以把一个复杂的咨询项目看成为系统工程，通过系统目标分析、系统要素分析、系统环境分析、系统资源分析和系统管理分析，可以准确地诊断问题，深刻地揭示问题起因，有效地提出解决方案和满足客户的需求。
咨询工具
安索夫矩阵
案例面试分
析工具/框架
ADL矩阵
安迪·格鲁夫的
六力分析模型
波士顿矩阵
标杆分析法
波特五力分析
模型
波特价值链
分析模型
波士顿经验曲线
波特钻石理论模型
贝恩利润池
分析工具
波特竞争战略
轮盘模型
波特行业竞争结构
分析模型
波特的行业组织
模型
变革五因素
BCG三四规则矩阵
产品/市场演变
矩阵
差距分析
策略资讯系统
策略方格模型
CSP模型
创新动力模型
定量战略计划矩阵
大战略矩阵
多点竞争战略
杜邦分析法
定向政策矩阵
德鲁克七种
革新来源
二元核心模式
服务金三角
福克纳和鲍曼的
顾客矩阵
福克纳和鲍曼的
生产者矩阵
FRICT筹资分析法
GE矩阵
盖洛普路径
公司层战略框架
高级SWOT分析法
股东价值分析
供应和需求模型
关键成功因素
分析法
岗位价值评估
规划企业愿景的
方法论框架
核心竞争力分析
模型
华信惠悦人力
资本指数
核心竞争力识别
工具
环境不确定性分析
行业内的战略群体
分析矩阵
横向价值链分析
行业内战略集团
分析
IT附加价值矩阵
竞争态势矩阵
基本竞争战略
竞争战略三角模型
竞争对手分析论纲
价值网模型
绩效棱柱模型
价格敏感性测试法
竞争对手的成本分析
竞争优势因果关系
模式
竞争对手分析工具
价值链分析方法
脚本法
竞争资源四层次模型
价值链信息化管理
KJ法
卡片式智力激励法
KT决策法
扩张方法矩阵
利益相关者分析
雷达图分析法
卢因的力场分析法
六顶思考帽
利润库分析法
流程分析模型
麦肯锡7S模型
麦肯锡七步分析法
麦肯锡三层面理论
麦肯锡逻辑树分析法
麦肯锡七步成诗法
麦肯锡客户盈利性
矩阵
麦肯锡5Cs模型
内部外部矩阵
内部因素评价矩阵
诺兰的阶段模型
牛皮纸法
内部价值链分析
NMN矩阵分析模型
PEST分析模型
PAEI管理角色模型
PIMS分析
佩罗的技术分类
PESTEL分析模型
企业素质与活力分析
QFD法
企业价值关联分析
模型
企业竞争力九力分析
模型
企业战略五要素分析法
人力资源成熟度模型
人力资源经济分析
RATER指数
RFM模型
瑞定的学习模型
GREP模型
人才模型
ROS/RMS矩阵
3C战略三角模型
SWOT分析模型
四链模型
SERVQUAL模型
SIPOC模型
SCOR模型
三维商业定义
虚拟价值链
SFO模型
SCP分析模型
汤姆森和斯特克兰
方法
V矩阵
陀螺模型
外部因素评价矩阵
威胁分析矩阵
新7S原则
行为锚定等级评价法
新波士顿矩阵
系统分析方法
系统逻辑分析方法
实体价值链
信息价值链模型
战略实施模型
战略钟模型
战略地位与行动
评价矩阵
战略地图
组织成长阶段模型
战略选择矩阵
专利分析法
管理要素分析模型
战略群模型
综合战略理论
纵向价值链分析
重要性-迫切性模型
知识链模型
知识价值链模型
知识供应链模型
组织结构模型
[编辑]
系统分析方法的分类
1）系统特征分析方法；
2）系统逻辑分析方法；
3）系统工程技术。
系统分析方法的步骤
系统分析方法的具体步骤包括：限定问题、确定目标、调查研究收集数据、提出备选方案和评价标准、备选方案评估和提出最可行方案。
1、 限定问题
所谓问题，是现实情况与计划目标或理想状态之间的差距。系统分析的核心内容有两个：其一是进行“诊断”，即找出问题是及其原因；其二是“开处方”，即提出解决问题的最可行方案。所谓限定问题，就是要明确问题的本质或特性、问题存在范围和影响程度、问题产生的时间和环境、问题的症状和原因等。限定问题是系统分析中关键的一步，因为如果“诊断”出错，以后开的“处方”就不可能对症下药。在限定问题时，要注意区别症状和问题，探讨问题原因不能先入为主，同时要判别哪些是局部问题，哪些是整体问题，问题的最后确定应该在调查研究之后。
2、确定目标
系统分析目标应该根据客户的要求和对需要解决问题的理解加以确定，如有可能应尽量通过指标表示，以便进行定量分析。对不能定量描述的目标也应该尽量用文字说明清楚，以便进行定性分析和评价系统分析的成效。
3、调查研究，收集数据
调查研究和收集数据应该围绕问题起因进行，一方面要验证有限定问题阶段形成的假设，另一方面要探讨产生问题的根本原因，为下一步提出解决问题的备选方案做准备。
调查研究常用的有四种方式，即阅读文件资料、访谈、观察和调查。
收集的数据和信息包括事实（facts）、见解(opinions)和态度(attitudes)。要对数据和信息去伪存真，交叉核实，保证真实性和准确性。
4、提出备选方案和评价标准
通过深入调查研究，使真正有待解决的问题得以最终确定，使产生问题的主要原因得到明确，在此基础上就可以有针对性地提出解决问题的备选方案。备选方案是解决问题和达到咨询目标可供选择的建议或设计，应提出两种以上的备选方案，以便提供进一步评估和筛选。为了对备选方案进行评估，要根据问题的性质和客户具备的条件。提出约束条件或评价标准，供下一步应用。
5、备选方案评估
根据上述约束条件或评价标准，对解决问题备选方案进行评估，评估应该是综合性的，不仅要考虑技术因素，也要考虑社会经济等因素，评估小组应该有一定代表性，除咨询项目组成员外，也要吸收客户组织的代表参加。根据评估结果确定最可行方案。
6、提交最可行方案
最可行方案并不一定是最佳方案，它是在约束条件之内，根据评价标准筛选出的最现实可行的方案。如果客户满意，则系统分析达到目标。如果客户不满意，则要与客户协商调整约束条件或评价标准，甚至重新限定的问题，开始新一轮系统分析，直到客户满意为止。
系统分析方法的案例分析
案例一:某锻造厂系统分析方法分析
某锻造厂是以生产解放、东风140和东风130等汽车后半轴为主的小型企业，现在年生产能力为1.8万根，年产值为130元。半轴生产工艺包括锻造、热处理、机加工、喷漆等23道工序，由于设备陈旧，前几年对某些设备进行了更换和改造，但效果不明显，生产能力仍然不能提高。厂领导急于要打开局面，便委托M咨询公司进行咨询。M咨询公司采用系统分析进行诊断，把半轴生产过程作为一个系统进行解剖分析。通过限定问题，咨询人员发现，在半轴生产23道工序中，生产能力严重失调，其中班产能力为120-190根的有9道工序，主要是机加工设备。班产能力为70-90根的有6道工序，主要是淬火和矫直设备。其余工序班产能力在30-45根之内，都是锻造设备。由于机加工和热处理工序生产能力大大超过锻造工序，造成前道工序成为“瓶颈”，严重限制后道工序的局面，使整体生产能力难于提高。所以，需要解决的真正问题是如何提高锻造设备能力？
在限定问题的基础上，咨询人员与厂方一起确定出发展目标，即通过对锻造设备的改造，使该厂汽车半轴生产能力和年产值都提高1倍。
围绕如何改造锻造设备这一问题，咨询人员进行深入调查研究，初步提出了四个备选方案，即：新装一台平锻机；用轧同代替原有夹板锤；用轧制机和碾压机代替原有夹板锤和空气锤；增加一台空气锤。
咨询人员根据对厂家人力物力和资源情况的调查分析，提出对备选方案的评价标准或约束条件，即：投资不能超过20万元；能与该厂技术水平相适应，便于维护；耗电量低；建设周期短，回收期快。咨询小组吸收厂方代表参加，根据上述标准对各备选方案进行评估。第1个方案（新装一台平锻机），技术先进，但投资高，超过约束条件，应予以淘汰。对其余三个方案，采取打分方式评比，结果第4方案（增加一台空气锤）被确定为最可行方案，该方案具有成本低，投产周期短，耗电量低等优点，技术上虽然不够先进，但符合小企业目前的要求，客户对此满意，系统分析进展顺利，为该项咨询提供了有力的工具。
本条目对我有帮助
70
分享到：
❹ 需求分析的步骤有哪些
一、需求识别
需求人员在此步骤应该分析需求类别、需求复杂度和需求价值用来确定需求实施的优先级。
1.需求类别确认：
需求类别包含流程类需求、统计分析类需求、接口类需求，一个需求可能为某一类型需求，也可能包含多类需求。
确认需求类别后应对每类需求的数量进行初步分析（比如流程类需求包含几个流程、统计分析类需求包含几个报表、接口类需求包含几个接口）。
2.需求复杂度分析：
一般需求受理工作量在1-5人天的需求复杂度低，工作量在5-15人天的需求复杂度中，工作量在15人天以上需求复杂度高。（工作量表示需求受理全过程需求人员需要付出的工作量）。
3.价值分析：
需求人员收到需求后应根据收集需求内容初步分析需求痛点/目标、需求复杂度、业务重要程度确定需求价值，需求价值分析
二、业务流程/统计查询/接口分析
针对流程类需求必须进行业务流程分析，统计查询和接口类需求可不进行详细的流程分析。
1.业务流程分为部门级、组织级和岗位级
部门级流程关注脉络需要分析涉及哪些具体岗位、执行活动、每个活动之间的关联关系，它是需求分析的主线条，也是流程分析的主要产物。
组织级流程关注宏观一般不会直接绘制，是对部门级流程的概括和抽象。
岗位级流程关注每个业务活动的执行步骤属需求细节范畴，在流程分析阶段不要过度进入细节。
2.需求识别阶段确认的流程均为部门级流程
需求人员在进行流程分析应遵循如下方法：
（1）业务流程确认：
一个流程为一个业务事件，一般是外部角色发起或系统内部主动发起（比如时间事件或状态事件），发起后会触发一系列业务活动。
（2）角色及业务活动确认：
流程图中的每个泳道都必须对应到角色，每个角色对应多个业务活动。需求人员在确认业务活动时一定要保证活动的粒度，一个业务活动一定是由一个角色完成且每个业务活动都是有价值的活动。
比如项目输入项目名称是一个执行步骤，这个动作没有价值，项目经理查询项目信息就是一个业务活动。
在需求描述时针对线下活动或新增活动应该应标识区分。
（3）业务活动间关系及数据确认：
确定所有业务活动的前后置关系，并明确流程间的传递的数据实体。
（4）流程整体瓶颈分析：
一般若某个角色业务活动工作量较大，或流程涉及高级领导，一般都会造成瓶颈，这种情况需求人员应想办法分散工作量提出流程优化建议。
3.针对统计查询类需求及接口类需求，按照上述业务活动确定原则分析、确定角色，并明确每个角色所执行的业务活动即可。
三、数据实体分析
针对流程类需求需要分析各业务活动传递的数据实体，统计分析类需求需要分析统计查询条件和查询展现两类数据实体、接口类需求需要分析接口传递数据实体，具体分析包含如下内容：
1.明确数据实体：
确认需要分析的所有数据实体，明确哪些为系统原有实体、哪些为新增实体、哪些为改造实体。
2.明确所有数据实体间关系：
实体间关系包含（1对1、1对多、多对多），另外需要分析数据实体变更是否需要保留版本，实体删除（逻辑删除、物理删除）是否影响其它数据实体。
3.明确数据实体字段：
针对新增数据或改造数据实体需要明确新增字段的名称、字段类型、是否必填、字段取值方式（人工输入、系统自动继承自其它数据实体、系统自动计算需要明确计算公式）。
4.数据权限分析：
需要分析不同角色在数据权限方面的差异，若涉及纵向多级用户，要说明对于集团/省/地市用户的数据隔离。
四、角色及使用场景分析
一般来说每个业务活动是对用户使用场景的抽象，每个业务活动可能包含多个场景，分析使用场景时应按照业务活动为主线逐个进行分析，每个业务活动分析时应包含如下内容：
1.明确活动执行角色。
2.明确活动执行的前置条件和后置条件。
3.明确不同场景：
一个业务活动可能包含正常的使用场景、备选使用场景和异常使用场景；
4.明确每个场景的执行步骤：
描述执行步骤时应使用简单的语法，主语明确语义易于理解，每个步骤不应该在任何一方（执行角色、系统）停留两部以上，重点描述如何交互。
5.业务规则和约束：
明确在每个业务活动下应遵循的业务规则和约束，这里一般是与业务流程相关的行为规则（比如项目周期时长超过90天必须提交二级领导审批），或与数据实体相关的数据规则（需求交接单拒收时候必须填写拒收原因，且拒收原因不能超过500字）。
五、系统功能分析
❺ 需求分析有哪三种方法2，什么是面向数据结构方法
它首先用结构化分析（SA）对软件进行需求分析，然后用结构化设计（SD）方法进行总体设计，最后是结构化编程（SP）。它给出了两类典型的软件结构（变换型和事务型）使软件开发的成功率大大提高。
三种基本的结构形式就是顺序、选择和重复。三种数据结构可以进行组合，形成复杂的结构体系。这一方法从目标系统的输入、输出数据结构入手，导出程序框架结构，再补充其它细节，就可得到完整的程序结构图。这一方法对输入、输出数据结构明确的中小型系统特别有效，如商业应用中的文件表格处理。该方法也可与其它方法结合，用于模块的详细设计。
❻ 需求分析有哪些方法
三种需求分析的方法：结构化分析方法、面向对象的分析方法、面向问题域的分析方法。
结构化的分析方法是传统的分析法，它的好处是在需求阶段可以不需要精确地定义系统，只需要根据业务框架确定系统的功能范围，以及每个功能的处理逻辑和业务规则，功能需求规格书等。因为不需要精确描述，因此描述系统的方式比较灵活多样，可以采用图表、示例图、文字等等方式来描述系统。在系统开发以前，一般还可以采用更为直观的原型系统方式和最终用户进行交流和确认，因此对业务需求的要求会低一些，业务需求阶段的周期相对容易控制；通过业务全景图，最终用户也能了解系统的功能；通过功能活动图和业务规则的描述，也可以相对精确地描述业务系统；因为没有严格的标记语言，可以采用适当的篇幅描述适当的系统。当然，这种方法的缺点也是明显的，分析人员和业务人员之间可能缺乏共同语言，机器不能识别业务需求书，在设计阶段还需要继续和用户确认一部分功能。
面向对象的分析方法的最大好处是在需求阶段，就能够非常精确地描述一个系统，采用程序语言的方式和最终用户交流（最终用户必须要熟悉这种语言），能够在项目一开始就发现很多问题，避免在开发的过程中出现需求的反复，而且在系统设计和开发阶段不需要最终用户参与。在实施上，一般可以采用场景、业务功能等方式来描述，比较适合于业务流程环节多的系统，或者软件产品的开发。但是，我们也要看到，在现实中，绝大多数的应用系统都很难在需求阶段就可以被精确地抽象化定义，所以这种方法的缺点和困难也是显而易见的：首先，用户要非常清楚地知道最终的业务系统应该是什么样，或者采用一种抽象的方式能够确定最终的应用系统；其次，因为最终用户不需要参与设计和开发阶段的工作，所以双方确定业务需求的过程也会比较长；同时，因为是精确描述，因此描述系统的语言是非常逻辑化的，一般通过某种方式可以使机器识别业务需求，采用这种方式写的业务需求是非常格式化的，一方面描述一个系统需要的信息非常多，可能使需求说明的篇幅非常长，不便于理解和阅读；另外由于通过抽象的方式来推演最终系统的运行方式，对业务人员的要求非常高。
❼ 软件工程中常用的需求分析的方法有哪些
一、过滤需求的方法
做后端系统，要学会的第一个技能就是砍需求。也就是过滤需求。
这不是一个贬义词，反而是体现后端产品价值判断的基础。
过滤需求的方法，就是通过一定的手段判断需求是否是伪需求，应该被过滤掉。
1. 用户场景模拟法
后端产品的出发点就是帮助业务用户，因此在调研需求的时候要模拟业务的场景，分析业务用户提到的需求是否能解决他的问题。
如果不能帮助用户，那么这个需求就可能是伪需求。
以下面的案例说明：
背景：“货到付款”类型的订单会因为缺货而无法发出，如果超过一定的时间，客服就会跟顾客沟通，帮顾客取消订单。
需求：由于这种订单的数量还是蛮多的，逐个取消太费时间，因此业务用户要求在“缺货订单”列表页增加“批量取消订单”按钮。
分析：调研到业务操作场景,是先找到该类缺货订单，然后和顾客沟通，顾客同意删除，才进行删除。也就是逐个沟通确认，再逐个取消订单的，所以“批量取消订单”无法被有效使用。
因此，该需求是个伪需求，应该被过滤掉。
2. 功能归属分析
专门的系统做专职功能，有助于合理的产品体系建设。
因此需求调研的时候，可以通过系统的定位，判断需求是否应该在该系统完成。
如果不属于该系统范畴，那么直接说服需求方更换方案。以
下面的案例说明：
背景：CRM系统（顾客关系管理系统）有一个顾客标签生成功能，就是根据顾客的消费行为数据，自动对应关联上标签，如优质顾客、高潜力顾客、欺诈顾客等。
需求：业务用户提出需求，除了做上述的基础标签之外，还要做出英语版本的标签（就是把标签文案翻译成英文），这样欧美员工可以在英语版本的系统下使用。
分析：调研到翻译之后的标签不是在CRM系统使用的，而是给到SMS（客服系统）使用的。
所以应该由SMS根据CMS提供的基础标签数据，自己做二次的衍生。
之所以这样，首先是为了避免未来更多语言版本的扩展需求或更多系统提出类似的需求；
其次，CRM系统已经完成了“接力赛”的第一棒，创造了基础数据，那么其他系统要特殊化使用，完全可以自行进行特殊化处理，无需耦合回CRM系统。
结论：案例的需求本身是真需求，并且实现上也没难度，但是该功能的定位超出了本系统范畴，专门系统做专职功能，化衍生需求应该在下游执行。
否则，耦合性过高只会增加系统的复杂程度，难以维护和扩展。
二、拆分和聚合的方法
1. 拆分需求法
业务用户提出一个需求，很可能只是短短的一段话。
但是不要高兴太早，可能这一句话暗含了很多线索，因此要善于拆分：
先找他要解决的核心问题，再围绕核心点，理清前、后、左、右、上、下的旁系需求点。
每个需求点再当做一个子需求进行调研，最后再聚合在一起。
以下面的案例说明：
背景：订单业务的类型很多，订单退货之后需要创建售后单据，但是因为数量大，所以花费很多人力，且手动创建有出错的风险。
需求：业务提出的需求是“增加退货订单自动创建售后单的功能”，这是个一句话需求。
该一句话需求，其实包含了多种具体的订单类型和场景，那么我们就要拆分调研，拆分的维度比如：
自营订单、第三方订单、货到付款订单、先款后货订单、部分退货订单、完全退货订单、服装事业部订单、电子事业部订单等，其中每一个维度就相当于一个小需求。
这里不一一展开。
2. 聚合需求法
拆分法是对单个需求分解成若干小需求进行调研，聚合法相反，是找到许多个相互关联的小需求的共性，然后统筹成一个大需求去完成。例如：
由于业务用户分散在不同的部门，各自为政，于是张三、李四可能都对一个业务流程有相同的需求，或者对同一个功能有相同的优化期望，结果俩人分别提了需求过来。那么产品经理就要找到二者背后的相关性和交叉区。
然后统筹规划，聚合在一起当作一个需求来调研，最终输出一个整体的需求调研结果。
三、利用辅助功能调研需求
调研产品现有功能，可以用来确认原有功能的逻辑，或者确定新需求方案是否可行。
比如业务用户需要更新一个功能，为了避免更新出错或遗漏，产品经理需要知道修改前和修改后是否会能正常运行。
最基础的办法就是自己设计一个测试用例，记录操作方式、状态变化、数据流向等。看看下面的例子：
背景：从销售网站获取到OMS系统（订单管理系统）的订单信息中带着顾客的邮箱。顾客下完单，可能会在销售网站修改邮箱，而此时已经获取到OMS的历史订单中的邮箱是不变的。
需求：顾客若在销售网站修改邮箱，要求已获取到OMS的该顾客的订单中的邮箱也要同步修改。
分析：需求是很明白的，也有它的意义，但有风险。
因为我们知道订单信息贯穿于整个订单流转过程中，牵扯到订单编辑、审核、取消、配货、发货等，而这些环节跳转的触发条件可能就是某个信息更新（这里面就可能包括有邮箱更新）。
因此，更新邮箱是否会影响流程中的某些环节，一时间很难准确知道。
于是，我们可以采用预测试的方式，设计测试用例，在测试机运行一些订单，观察各个环节邮箱变更的影响，然后收集起来分析对策。
测试法就像是探雷一样，主要用来解决未知风险点。这个方式的重点是记录和分析操作前状态、操作位点、操作后状态、操作后触发的连锁反应、数据流向等。
四、“拔萝卜带出泥”的方式调研需求
调研需求时，产品经理要拔萝卜带出泥,挖掘用户没看到的需求点和价值。
举例说明：
背景：公司入驻到销售平台后，销售平台会对入驻的店铺的违规行为进行罚款。
需求：业务用户提出需求，将销售平台的罚款数据抓取到订单系统，关联订单数据，以便进行人工分析。
分析：
第一步，先拆分需求，确定什么是罚款数据，总共有哪些罚款种类，需要对接哪些罚款种类，罚款数据与订单系统关联方式是什么，是否都能关联到，关联不到怎么办，销售平台是否已经提供了公用的罚款接口，Token（请求权限）如何获取，抓取频率怎么样，数据增长幅度多大，获取之后做哪些展示和搜索，用户权限怎么设置，需要和订单系统做哪些交互，该需求的价值是什么……
第二步，挖掘需求：是否需要作分析功能，分析功能的规则是什么；是否需要做监控和预警，是否需要指派负责人；其他业务人员是否也有类似需求，其他平台是否也有类似需求……
通过“拔萝卜带出泥”的方式，连带出更多需求点。将上述调研结果重新组装起来，得到一个系统化的完整需求。
罗列出需求要点和对应的验收目标，这样使得需求具象化，同时又不会遗漏细节，内部充实，外部闭环，并且进行了价值挖掘，做成控制阈值、预警、责任人分派、趋势分析、损失分析等高价值的功能，超出业务的预期。