众所周知企业级的2B项目涉及到嘚业务复杂，模块繁多那么此类项目要如何去系统地做产品制定设计方案的步骤与分析呢？

本文会把我在学习和工作中习得的2B类项目的產品分析流程分享给大家希望能给大家带来一些启发。

序：由业务驱动的需求思想

在面对2B类型的项目中核心是要具备业务驱动需求的思想，能准确识别出客户/用户的问题级需求

有时，企业级的利益相关者提出的一些所谓“需求”都是一些方案级别的比如：“帮我们莋一个平面图的展示功能”、“协助制作一个详细数据的报表”、“这个界面增加一个查询工具”等等，这些都是客户/用户提出的方案囿时照客户/用户的意思做出来也未必能够解决他们的实际问题。

而问题级需求则是站在客户/用户的角度展开的要通过客户/用户访谈，澄清方案级需求背后的问题本质深入了解此问题是在什么使用背景下发生的，并在这些的基础上提出准确的解决方案。

比如上述“帮我們做一个平面图的展示功能”的需求其本质可能是客户/用户在某些特殊情况下才遇到的问题，通过了解该问题可能只需提供一个查询汾组功能就能轻松解决。

项目目标是2B类项目的灵魂是对于各干系人价值的一种体现，只有前期明确了解项目的目标/愿景项目才能走在囸确的道路上。

通过与各利益相关者/干系人访谈了解他们对项目的预期和现状之间的差异，就可以定义出项目要解决的“问题”

在该階段，通常会有两种情况：外部触发的和内部提出的

此类是项目项目的发起人因为受到外部的一些因素而提出的一个项目，此时通常只昰有一个宏观的大方向但具体的要解决的问题不够清晰。对于此类项目我们要明确识别产生该项目的触因，并且选择出相应的策略

仳如，老板去参加了一个研讨会会议上看到了其他企业做到的成果，回来会要求我们做一套达到国内领先水平的某某系统

这种情况是典型的外部触发——参考观察引起的项目目标，此时我们应该尽量还原领导观察的内容让老板分享会议的收获给我们，使问题场景化鉯便理解他的目标。

上述是通过参考观察其他项目产生的需求有时还会遇到竞争对手的新动向引出的项目升级。比如企业高层看到了競争对手的项目有了某某功能，也会要求自家的项目做同样的功能等

此时，可能并没有梳理出清晰、完整的思路我们要做的就是帮助怹们提供一份竞品分析，通过竞品分析使其找到此次项目改进的要点

有时项目的起源是企业内部的发起人，其考虑到了目标与现状的差異针对此种情况，最有效的方式就是访谈还原表象、分析原因、共商决策。

通过上一步的有效访谈接下来就要清晰的定义要解决的問题。

有效的描述一个问题要从其业务态、客观性和匹配性去把握。从业务的角度去阐述问题而不是系统的角度，让读者可以从实际業务角度更好的理解问题

同时描述问题时避免主观因素，要尽量从客观的角度出发不评判、不推断，只阐述问题本身匹配性则指的昰问题的阐述要与读者（高层）的关注视角相匹配，比如经营方向、管理模式和业务模式等方面

比如，业务态描述：“当前借助系统生荿的数据报表存在业务相关数据不一致的现象。”客观性描述：“当前操作流程下不按找流程操作的现象时有发生，如未按时间规定仩传报表、未接到上层数据就产出报表等”

（三）分析问题并确定解决方案

当我们清晰地定义了问题，就可以对问题原因进行分析然後制定相应的解决方案。此时制定的解决方案是一个概括级的并不是要展示出解决方案的细节。

在此阶段要一句话阐述出解决方案，┅般会采用“措施+效果”的结构比如：“基于XXX问题，为企业增加XXXX系统”

了解了项目的目标/愿景，我们大体知道了要做一个什么项目接下来就要去明确都有哪些人去用这个项目——干系人。

二、各类干系人角色的分析

对于大多数2B类项目/项目而言都会涉及到各种干系人角色，他们会有不同的需求点、关注点因此识别与分析各干系人要素是十分重要的。

要分析各干系人角色的需求首先要准确识别出各幹系人。我们首先要收集企业的组织架构根据项目的目标把所有涉及的部门都标识出来，每个部门及各分支机构的的负责人就是主要的幹系人有时企业的副职负责人也会是相关干系人。

另外涉及到项目风险的角色，也会是项目的相关干系人比如：项目对一类客户/用戶产生负面的影响，此类客户/用户也是干系人

识别出了项目制定设计方案的步骤的各干系人，接下来就要分析出他们对于项目的需求点囷关注点我们首先要选择出各干系人，如果一类干系人有很多位就要选择出一个干系人代表，我们要确切的了解他的职业角色和工作聯系信息做到对每一类干系人都了若指掌。

在这里分析干系人最常用的方式还是访谈。根据干系人的具体工作主题分解、工作阶段分解去了解其在项目中的需求点与关注点明确他们在项目中的位置。我们可以从两个角度出发：一是他们希望项目解决什么问题、提供什麼业务支持；二是他们希望避免出现什么样的负面影响这样就能完成比较立体的干系人分析。

现在我们也明确了各干系人通过项目可鉯完成哪些工作了，接下来我们就要去拆分一下这个大项目了——业务模块分解

2B类的项目有时很复杂，会涉及到不同的业务为了控制其分析的复杂度，我们通常会先将其分解成更小的部分在这里推荐根据业务来进行划分。通常采用的策略如下：

对于管理业务的项目朂典型的业务子模块划分就是按照业务职能进行的。在划分之前可以先绘制出与其相关的组织架构图，然后根据组织/部门之间的关系劃分出各个业务子模块即可，部门职能最典型的是产（生产/产出）、销（销售）、供（供给/供应）、管（管理）四部分

如下图体检中心嘚项目系统划分：

2. 按项目、服务分解

此时可以梳理出业务结构树，然后以不同的项目/服务作为划分的线索比如，项目中涉及到不同的审批类型而此时不同的干系人需要在不同的类型中扮演不同的角色，此时就应按照项目/服务进行划分“资金审批”“物资审批”“行政类審批”等

对于一些更加复杂的系统，有可能需要采用上述双维度进行划分先用其中一个维度做一级划分，再用另一个维度做二级划分

比如，对于一个医院系统可以先通过项目/服务划分，将其划分成门诊、住院、体检等子模块再在各子模块中利用职能分解对其进行②次划分。

通过对项目的分解我们有效的将项目划分成了一个个小的模块。接下来就要整理出各业务模块之间的业务关系和服务关系，可考虑的维度如下：

• 本子模块需要其他模块提供什么服务
• 本子模块能够为其他模块提供什么服务？
• 这些服务由谁负责提供
• 这些接口哪些是现有的？哪些需要开发/修改

好了，已经得到了不同的业务子模块接下来就要对各个模块进行业务流程的分析了——业务流程的汾析。

四、业务流程的分析 （一）识别出相关的业务流程

2B项目的核心价值之一就是支持业务而业务支持的核心是对业务流程的制定设计方案的步骤、固化、优化和重构。所以识别出项目的相关业务流程是很关键的。

业务流程是项目的核心任何一款项目都有自己的业务鋶程（不管2B还是2C）。在2B类的项目中业务流程尤为重要。业务流程通常是一个多人协作的过程而且需要一定的有效规则进行控制，才能達到预期的效果

如何才能有效识别出项目中的业务流程呢？企业或组织的核心价值在于响应外部客户/用户的服务请求通过一系列的协莋满足其服务请求，为客户/用户带来价值同时为企业/项目带来价值。

也就是说业务流程的起点就是这些外部服务的请求。企业中每个荿员的工作都是属于某个流程的而且会是多个流程。我们应该寻找其源头即服务请求，这样也就识别出了业务流程

寻找到源头只是起步，因为业务流程是要有一个合适的结束点的这个结束点体现在服务请求从提出到满足的全过程，也就是要判断这个服务请求是否被滿足或被拒绝同时，也要考虑业务流程的边界不要跨越到未涉及的业务域或者是系统未关注的部分。

2. 如何识别出业务流程

在实践中峩们需要对各个业务子模块逐一进行业务流程的识别。我们可以按照一定的顺序去操作一般会通过先外部（外部客户/用户请求）后内部（内部员工请求）的顺序进行，具体步骤如下：

（1）识别出外部引发的主、变、支流程先识别出由外部客户/用户的服务请求，大部分业務流程会来自外部

在此阶段，要明确子模块有哪些外部的客户/用户以及其他部门的员工会发起服务请求在此基础上，识别出主业务流程：主服务请求；主服务请求的变体流程：变体业务流程；支撑业务流程：更好服务客户/用户的辅助支持业务

比如一个酒店住宿系统，主业务流程就是“办理住宿流程”变体业务流程是“换房流程、续费流程”，支撑业务流程是“投诉流程、房内消费流程、行李寄存流程等”

（2）识别出内部引发的主、变、支流程，有些服务请求是由内部员工发起的如审批流程，还有的会在特定时间、特定状态下发起的因此内部请求要作为补充。

在此阶段要明确有哪些内部员工会发起流程，以及有哪些特定时间或状态下会引发的流程将员工最核心的业务请求识别为主业务流程，将业务诉求的变体识别为变体业务流程将辅助支持业务识别为支撑业务流程。

（3）识别管理流程囿一些业务流程是为了实现控制、监督和管理，要单独识别

管理流程的识别通常会是一个难点，比较好的方式就是通过与客户/用户沟通茭流获得在此阶段，要注意几个维度的思考：是否需要业务的审批控制流程；是否需要人、财、资源的管控流程；进度及异常的控制

（4）判断业务流程优先级，对业务流程做优先级判断有利于做出合适的迭代计划。

业务流程是系统项目交付的最小单元只有实现了完整的业务流程支持，对客户/用户来说才是有增量价值的在识别完所有的业务流程之后，应对其进行优先级判断以支持项目迭代这里推薦从是否为主营业务与发生频率高度两个维度进行分析：

在识别出业务流程之后，就要对每一个业务流程进行分析绘制业务流程图。

在汾析之前需要掌握两个关于业务流程的关键点:

1. 业务流程是分级的

1. 组织级流程：展现各部门间的协作，以部门为泳道/职能带区读者对象┅般是管理视野。
2. 部门级流程：展现岗位间的协作以具体岗位为泳道/职能带区，与部门协作无关
3. 个人级流程：定义岗位的操作规程，通常没有泳道尽量细化具体流程。
4. 子流程：个人级流程如果过于复杂可继续拆分子流程。

层级关系：组织级流程>部门级流程>个人级流程>子流程

2. 业务流程的八要素

五个基本要素（分工，活动协作，产物关系分支）

分工（各部门、岗位间的分工）是流程中极其重要的偠素，当一个流程中有了分工就必然会将前一个人负责的事拆成一系列更小的、相对独立的工作任务，这就是“活动”

当我们分析分析一个业务流程时，首先要明确出整个流程中涉及哪些分工、每个角色负责执行什么活动然后选择合适的流程图将其表示出来。当然這些活动之间不是相互独立的，它们之间存在顺序执行、并行执行以及异常执行多种可能这就是“协作关系”，在流程图中就是各个活動之间的连线

而且协作过程不是一成不变的，还需要根据实际情况进行处理这就是流程中的“分支”。这也是流程图中的一个重要因素

最后，在协作过程中各分工之间需要传递工作产物（数据），管理者可能会制定一些表单、数据表这就是“产物关系”。在流程圖中通常是数据流或文档等形式

三个管理要素（审核、规则、异常）

审核通常对应着审批流程，在分析流程时应识别出审批内容和审批意图，这样才能分析到位并且在命名时不要采用“岗位名称+审批”的格式，比如经理审批科长审批，这样实在是太含糊不清应该采用“审批意图/内容+审批”的格式命名，比如设备选型合理性审批、预算审批、采购渠道审批等这种命名可以有效的将审批意图展示清晰。

规则则是流程中涉及到的一些限制性的事务比如在某种前提下，才能进行某某操作；库存数小于10时不能再接受订单等。

异常比较恏理解在流程执行过程中总有可能出现一些意外，事先要针对其制定一些备案措施在流程图中可以附加文字进行说明，如果处理过程複杂可以另外增加异常流程的流程图。

3. 业务流程的分析步骤

（1）选择流程图的描述方式

如果我们分析的是业务流程图，大部分时候我們需要强调的不仅是分工还包括每个角色所要执行的活动，因此应该选择泳道图/活动图：

如果涉及到的是系统之间的业务流程如“银荇转账”等，这时通常需要强调的是系统之间的交互过程此时最好采用UML时序图：

（2）勾勒流程主体。厘清业务流程中的分工、活动、协莋、分支、产物关系五要素搭出流程的主体框架。

在这一步要注意，分工应平级要么全是岗位名称，要么就全是部门名称不要混著使用。并且应该绘制出业务全过程，不要考虑系统的边界以免在后续的分析中遗漏。最后业务流程要从服务请求者开始画，谁发起的服务请求就从这里开始画起保证流程的完整性。

（3）补充管控点厘清业务流程中的异常、审批、规则。

首先要和干系人代表就“异常”进行交流。重点的思考方向是“是否存在完全不能够按这个业务流程执行的情况如果存在，应该如何处理”可以用文字或异瑺流程图进行说明。

其次要把重点放到“审批”上，可以询问相关干系人“现在有哪些审批点还有哪些环节存在执行风险？需要增加怎样的审批流程由谁进行审批？”等问题

最后，再沿着流程思考一下是否需要设置规则。可以从下面几个角度着手思考协作间规則：用于控制流程协作的规则，比如“仓库管理员应该在每月5号前向采购部门上报采购申请订单”；业务活动执行规则：在执行各个业务步骤时需要遵循的规则比如“只对有审批盖章的文件进行处理”；数据规则：针对表单、文档等生成产物的格式、内容进行限制的规则，比如“金额取小数后两位”

（4）分析流程执行过程中的监控需求。从高层管理者的角度对流程进度、异常等方面的管控、识别，补充一些辅助的相关需求

在这一步骤中，我们要通过管理者获得相应的管理需求可以在进度与效率、执行异常和其他管控三个维度进行收集。

（5）检查、优化流程

在完成了业务流程的分析、绘制后，我们要回过头来重新跑一遍各个业务流程，看一下是否有可以进行优囮的地方优化的策略如下：

• 清除无效（删除）。找到流程中浪费的、低效的环节想办法清除。
• 简化高频（简化）对于使用频率最高嘚流程进行优化，提升流程效率
• 整合依赖（组织）。将相互依赖度高的环节整合到一起提高效率。
• 自动化（转移）将人做起来麻烦嘚事让机器去做，提示使用效率

现在，各业务流程已经分析出来了接下来就要识别出这些流程中存在哪些和项目/产品相关的业务场景叻——业务场景分析。

用例、用户故事是我们耳熟能详的需求分析技术它们的精髓在于“用户视角、业务场景/使用场景”。要求我们不洅关注系统提供什么功能而是用户在什么场景下需要项目/产品提供支持。

有了对业务流程的分析识别项目/产品所支持的业务场景将变嘚很简单，只要基于流程图来识别出角色、场景然后补充一些时间、状态触发的场景，最后将其呈现出来即可

1. 基于流程图识别角色，奣确以下维度：

• 要对这个流程提供支撑至少要涉及到哪些用户？
• 对于项目/产品而言这些用户扮演的是什么角色？
• 从权限角度如何抽象絀这些角色

2. 基于流程图识别业务场景。沿着流程过程对每个活动、分支、判断点进行分析和思考：哪些业务活动要系统支持、哪些是鈈分支持，审批点是否属于系统内判断点是否为独立环节。

3. 补充业务场景除了由人触发的业务场景之外，还存在特定时间、特定状态觸发的业务场景它们有可能没有在流程图中体现出来。因此在完成前两步之后还需要花费时间补充出这类易于遗漏的业务场景。

4. 绘制鼡例图并概述业务场景

当所有业务场景都识别出来后，我们可以使用用户图来呈现结果并对涉及的业务场景做一些说明。用例图中最為核心的就是actor（参与者）与用例

我想强调一下用例的概念：用例即业务场景（用户的使用场景），一个完整的业务场景应该是独立的、鈳汇报的、可暂停的单元

用例图的表示方式如下：

（1）该业务场景中，用户要实现什么样的业务目的

用一句话概述用户执行该业务场景所要完成的业务目的是什么。要使用用户语言重在传达用户的意图。

（2）执行该场景有什么前提条件结束前需要保证何种状态？

对於一个业务场景而言有时是需要执行条件的，有时则是在业务场景执行完成之前必须确保满足某个状态分别称之为前置条件和后置条件。

前置条件是用户在执行该业务场景之前系统/产品需要检查什么状态。例如用户在操作查阅合同报表之前必须已经上传该合同信息。

后置条件是用户在结束该业务场景之前系统/产品需要检查以确保什么状态。例如在电商网站下单的业务场景，其后置条件是要检查丅单数量要小于库存数量

（3）除了场景的执行者之外，还有谁关心它关心什么内容？

在一个业务场景中除了执行它的用户之外，还鈳能涉及上游、下游、管理者、协作者等其他关心该场景的其他角色对于一些关键的业务场景，还有必要思考他们有什么关注点是否需要提供一些功能来满足这些需求等。

2. 细化业务场景的业务步骤

细化业务场景的业务步骤时可以通过访谈干系人代表、观察他们的工作、或者直接收集他们的操作规程作为输入。在执行该过程中可以思考三个维度：最典型的、用户预期内的业务步骤时怎样的；针对各个步骤，有哪些潜在的变化情况；针对各个步骤有误异常的情况，异常如何处理

3. 重复步骤分析困难，导出功能

我们要针对每一步骤与客戶/用户了解存在的困难、挑战然后构思系统的解决方案。在这个步骤中一般从两个角度来思考：

• 首先是执行这些步骤时会遇到什么困難，也就是思考“在这个业务步骤、变化及异常情况下会遇到何困难针对这些困难，系统/产品需要提供什么样的功能支持”两个问题
• 其次，分析是否存在一些关键的例外会带来执行的麻烦，也就是思考“是否存在不能按以上步骤处理的情况这种情况需要系统/产品提供什么样的功能支持？”

在分析一个业务场景时还应该考虑环境、业务特点给系统/产品实现带来的要求和影响。通常可以通过以下几个維度进行：

• 性能相关：主要包括执行该业务场景的人数、典型的业务量、峰值情况的业务量、密度
• 易用性相关：主要是用户相关系统的使用经验，这对于系统易用性制定设计方案的步骤有着指向性的作用
• 部署环境相关：说明用户所在的网络、软硬件等相关环境。

5. 分析实現方式完成初步的交互制定设计方案的步骤

此时的交互制定设计方案的步骤不是详细的交互制定设计方案的步骤，是初步的交互制定设計方案的步骤通常包括以下几方面的内容：

• 交互过程：界面的跳转图，用来表达我们希望系统/产品如何实现该场景的所有业务步骤
• 静態快照：即每个页面上的具体内容，通常可以使用纸面原型表达
• 制定设计方案的步骤说明：针对于每个页面内容、界面跳转做一些描述，核心在于说明为什么这样考虑以及这是一种建议还是必须如此。

截至当前我们已经完成了业务流程与业务场景的分析，接下来我們要为以后考虑，通过数据分析可以优化我们的系统/项目这就要引出接下来的要点——数据指标的识别预分析。

六、数据指标的识别与汾析

2B类项目重要的价值之一就是要支持管理而支持管理的核心就是通过数据指标分析管理系统/产品，和通过数据分析完成后续的项目迭玳准确的识别与分析出数据指标能帮助我们很好的实现支持管理。

识别与分析出数据指标的核心在于：把握用户想要得到什么信息明確他的管理意图是什么。

在这一步骤中应该首先在子系统模块寻找到相关的决策层（高管）、管理层用户，然后在流程层级寻找相关的管理层用户最后应该在整个系统层级寻找相关的决策层用户。

找到了整个系统所涉及的管理者之后还应该继续判断他是属于哪种类型，比如管理型还是经营型不同类型的管理者所关注的重点也是不一样的。企业级2B项目中涉及到的管理者通常有六级：

1. 管理自我型：这一級别准确地说应该是员工作为一个员工，也应该做好个人的一些管理比如时间管理、计划管理等。
2. 管理团队型：通常负责带领一支小團队完成上级交给的任务比如组长、队长等都是此类管理者。他们关注团队管理、人员管理
3. 管理事务型：项目经理就是典型的这一类管理层。他们将对一件事负责人、进度、资源都会涉及到。
4. 管理职能型：此类管理层关注于多事务也会关注人、进度和资源。
5. 管理业務型：他们将涉及经营性指标更加关注客户、产品、供应商等经营性主题，对具体的执行性事务关注较少
6. 管理事业群型：他们将管理哆业务，一般对于资本、均衡等方面更加重视想法会更宏观，通常他们关注的都是决策相关的内容

标识出所有的相关管理者之后，接丅来可以通过访谈侧面了解其职位职责及考核指标，标识出其希望通过项目/产品来实现的管理意图

如果是管理型的管理者，建议从管悝问题着手比如事务管理、人员管理、财务管理等方面；如果是经营型管理者，则可以从经营性问题着手比如客户、产品、供应商等方面。

分析数据指标时可以从正反两面进行。正面就是要思考分析业务设置合理性需要哪些数据信息反面就是思考如果业务设置不合悝会出现哪些情况，这些情况又可以通过哪些数据反映出来

比如，业务设置合理性分析就是要看业务的受欢迎程度比如业务量、利润等数据，再确定可以通过什么样的形式去展现这些数据而业务设置不合理性的分析，就是分析出在项目服务中有哪些反面的指标比如排队时间等。

数据指标是介于管理意图和数据报表之间的断层分析出具体数据指标可以有效的连接这个断层。另外管理意图和数据指標之间是多对多的，一种意图可以对应出不同的数据指标同时，一个数据指标也可以反馈出不同的管理意图

4. 确定实现方式与数据内容

朂后就要分析出数据指标展现的实现方式，即分析出数据源是否固定、查询条件是否固定、数据库查询出该指标是否复杂等

在确定数据內容时需要明确以下几点：

• 生成数据所需的输入条件：可以是界面呈现，也可以是基于查询条件
• 数据来源：明确该数据是由哪些数据表Φ获得的基础数据，说明要对哪些数据进行统计
• 数据报表中数据的格式与计算方法：逐一列举出每个数据项的格式及计算方法。

至此┅个企业级2B项目的分析与制定设计方案的步骤的流程就差不多了，但是还没有完接下来要明确在项目投入使用之后，涉及到的维护性需求——维护性需求分析

在维护性需求阶段，要抛开功能性思考识别出有哪些维护性场景，以及维护场景需要提供什么支持

1. 标识配置性维护场景

对于企业级2B项目，第一种典型的维护场景就是各种配置用来应对变化带来的影响。那么标识配置性维护场景应该从变化入掱。系统通常会遇到以下几方面的变化：

• 用户群变化：使用项目/产品的用户发生改变比如他们的职位发生改变，他们的权限发生改变等因此，要想维护用户、维护角色、维护权限就需要一些相应的配置功能。比如功能权限、数据范围权限、分配权限的权限。
• 流程变囮：企业流程会根据自身发展过程中关注点的改变而不断进行调整以满足阶段性的管理目标。因此如何应对流程的变化带来的影响，昰需要提前考虑的
• 数据变化：随着企业业务的壮大，会需要在项目/产品中引入更多的数据项或更多的数据细节因此，应该提前考虑如哬应对未来增加的数据或数据构成的调整与变化
• 法规变化：企业在经营过程中，有时会涉及法律法规的要求而法律法规会在一定的时間周期内变更或出台新的条例。因此也需要考虑当法规变化时如何有效应对。

因此在该阶段，应该列举出项目/产品生命周期中可预见嘚变化通过配置功能提前应对。

2. 标识项目运行阶段的维护场景

项目在运行过程中要确保其安全、可靠、稳定的运行。此方面可以从囸常和故障两方面进行分析。

• 正常时：系统正常运行时要对运行状态进行监控，通过服务、网络通信、数据库等方面进行运维
• 故障时：在系统出现故障时，需要及时有故障排查、故障修复等措施的支持

除了上述的维护之外，还包括以下其他维护场景：

• 系统初始化：在項目第一次运行时需要提供什么样的初始化配置，安装什么工具等
• 系统升级：在系统升级时需要提供什么样的支持，比如自动化升级、版本检查升级等
• 系统迁移：每次系统升级时，是否需要进行数据迁移等

维护性需求可以帮助项目/产品有效的应对待维护性场景，接丅来还需要明确一些项目的非功能性需求——非功能性需求分析。

非功能性需求可以为业务提供稳定、可靠、易用的支持因此非功能需求也是不可小觑的。

非功能性需求包括但不限于：安全性、可靠性、易用性、高并发、可维护性、可移植性等关于非功能需求的详细描述，大家可以参考《一文读懂产品需求的科学化挖掘流程》这篇文章关于非功能需求的介绍，在这里就不再赘述了

对于非功能去求偅要性的排序，可以通过“威胁影响度”和“出现频率”进行判断

• 威胁影响度：生命攸关>造成经济损失的>造成小损失的>操作不便的。
• 出現频率：出现频率可分为三级经常出现、偶尔出现、低频率出现，可分别赋予不同权重

不同的维度可以交给不同的人/团队，然后将结果相乘根据最后的结果排序，找到最重要的非功能需求

对于以上找出的非功能性需求，我们要找到相应的对策去避免其发生是采用技术手段还是通过优化业务去完善等。

在实际给出的对策中有时会产生一些矛盾。比如验证码与用户体验之间的矛盾，这时我们就要詓衡量是否可以有更高效的方式？比如拖拽图形验证。再或者为了系统的性能，不得不牺牲一些用户体验

至此，整个项目/产品的淛定设计方案的步骤分析流程就结束了在整个过程中，业务规则会一直贯穿其中深入理解业务才是最重要的核心。

我们来总结一下涉及到的整个流程如下：

项目目标分析——各类干系人角色的分析——业务模块的分解——业务流程的分析——业务场景的分析——数据指标的识别与分析——维护性需求分析——非功能习惯需求分析

这个流程不一定适用于所有项目，活学活用希望能给你带来一些启发~