需求分析的过程

需求分析是软件开发的第一关，评什么，审什么这个中心问题，下面我们详细梳理下。
一个需求的完整链路流程如下：
需求梳理---->分工到人---->定排期---->跟进度

需求梳理是什么

梳理些什么;搞清楚需求是什么；需求涉及的角色，范围，谁来用；需求的流程是什么；需求的构成是什么；

如何梳理需求

第一步

搞清楚需求是什么,需求的构成，根据用户角色，不同角色的视角来看待使用系统，梳理出各个角色的用例图，确定出系统要干些什么，具备哪些功能能力。通过穷举，列个用户角色清单。

用例图可以根据模块维度来划分，也可以根据操作维度来划分。

第二步

根据每个角色的用例图，梳理出各个角色的用例图的流程图。用例图尽量完整，闭环。

第三步

将各个角色的流程图整合为泳道图。或者说全链路图，保证业务的闭环。
好处：可以以全局的视角来看待系统。

第四步

划分模块，划分团队，划分系统边界，分阶段，岗位分工(职能分工，流程分工)，分步骤，定排期，跟进度。

第五步

用例图-->识别出系统功能-->系统构成图:划分出系统边界，以及识别出系统构成-->系统交互图:系统之间的交互关系-->系统泳道图/时序图/活动图:系统之间的调用时序.
系统构成图：描述了系统的构成，组成元素，内部构成。用例图反映的是用户角色，谁用及系统提供了哪些功能，能力。根据用例图，及活动图/泳道图/时序图来分辨出系统构成。
系统交互图：描述了系统之间的交互关系。

系统静态描述: 描述静态结构的。构成图，结构图，交互关系图，架构图，功能模块矩阵图。
系统动态描述：描述动态交互关系。时序图，泳道图，活动图，流程图。
功能模型：从用户的角度展示系统的功能，包括用例图。或者从系统功能角度展示功能模块矩阵图。以及系统交互图。
动态模型：展现系统的内部行为。包括序列图，活动图，状态图。

用户角度及系统角度来画图，如下：
用户角度：用例图（静态），时序图/活动图/泳道图，交互图（动态）
系统角度：系统构成图/功能模块矩阵图（静态），系统交互图，泳道图（动态）。
系统构成，系统交互图：适合系统设计，总体设计，架构设计时使用。
泳道图/时序图/活动图：横轴-系统构成，纵轴-活动，用例，流程图构成，适合详细设计时使用。

如何划分模块

模块划分，分解细化出详细的清单明细，目的是为了更容易的完成整个大任务。

如何分工执行

 模块分解完之后，下一步就是具体的执行，如何更有效的执行，效率更高，涉及到分工。
 
一个需求过大，过于复杂，在一个开发周期内完成的可能性比较小，我们需要对需求进行拆分，分步完成这个大的需求。

分期完成实现，每一期作为分割为一个独立的需求。在每一个独立的需求完成周期内，包含一个完整的流程（分析-设计-开发-测试-上线-运维）。需求经过分析分解后，下一步就是执行，干就完了，分工，定排期，进度推进跟踪。

分工维度：根据流程维度来分工，根据职责职能来分工。即时间维度和空间维度，横向分工(职责/职能)和纵向分工(分流程)。

分阶段的方法：先分阶段，分步骤，比如分为3期，第1期包含完整的流程(开发-测试-上线-监控)。

需求构成分析：

• 用例构成
• 角色构成
• 数据构成
• 操作构成

用例分解/角色分解 从页面的角度划分模块或者说用户or不通的使用角色的角度来划分；

页面功能模块	页面元素	页面元素-数据	页面元素-数据加载逻辑	页面元素-操作/交互逻辑
单元 1	单元 2	单元 3	单元 4	单元 4
单元 3	单元 4	单元 3	单元 4	单元 4

step0角色分解：用户角色分解
step1（用户端分解）页面分解or客户端分解or用例分解：着重页面的构成、元素构成；着重各个端的构成交互，而不是服务端的功能；中心是客户端自己；比如一个泳道：标题是客户端自己，下面是客户端的模块分解；有几个用户端就有几个分解表格；
step2（服务端分解）系统交互分解：着重服务端系统提供的功能模块；中心是服务端，所有的客户端；比如一个泳道，多个外部客户端；只有一个分解表格，汇总所有的端，包括系统自身的job；

用户端	系统功能	系统功能
用户端1	模块	功能点
用户端2	模块	功能点

用例图：更关注用户与提供的交互；
用户端分解：更关注端的元素的分解；
服务端分解：更关注服务端提供的功能分解；(与客户端的交互，需要提供什么数据给客户端，与客户端怎么交互）
系统各端交互：更关注各端之间的交互；

服务端重在 与客户端的交互；结论：有哪些交互；
客户端重在 页面元素分解，及与服务端的交互；结论：有哪些元素数据？

---

客户端：要哪些数据？取哪些数据？页面or页面元素要哪些数据？request
服务端：给哪些数据？记录哪些数据？response
交互流程怎么设计？业务流程怎么设计？

需求评审完了-->页面分解，确定页面要什么？-->服务端分级，服务端给什么？
确定需求明细；

step1：搞清楚页面要什么；（页面分解明细）（以页面为中心）
step2：搞清楚服务端给什么；（服务端分解明细）（服务端用例汇总图，以服务端为中心）

功能分工、功能边界、系统边界划分、服务分工划分，系统交互、模块功能划分
确定分工后再来系统交互，画系统交互图；------这些是初步设计的工作；

---

需求评审、分析、分解阶段：

• 页面分解：页面要什么
• 服务端功能明细、分解列表：服务端给什么，提供什么功能

初步设计阶段：

• 功能边界划分：功能边界划分/系统划分or分工/涉及的系统
• 系统交互：涉及系统的系统交互；系统之间如何交互，以及每个系统的分工，当前需求涉及的功能的分工，在哪个系统当中；
• （系统交互与系统分工的描述方法是不一样的）：比如
  系统交互：观众端----------->关注系统---------------奖励系统----------风控
  系统分工：观众端----------->关注关系（关注系统）-------规则匹配/奖励规则/通知规则（奖励系统）
• 区别：系统交互重在交互 & 系统分工重在功能的分工

分模块详细设计阶段：（系统交互固定下来之后，就是各个功能的交互明细）

• 时序图/泳道图
• 系统内部的模块交互图 & 模块内部的详细设计
• 接口设计文档

---

为什么要系统分工？

• 初步设计的第一步就是系统分工与系统交互；
• 这个是概要设计、初步设计、整体设计、总体设计的一步,在写具体落地的接口前的总体方案；
• 接下来是功能设计，模块的设计；
• 服务端有可能涉及到流程、环节、复用；
• 页面与服务端的交互只是前期的第一步；确定了页面要什么，服务端给什么的列表之后，就要划分服务端的分工，服务端是有服务划分的，解耦，服务化，流程，环节的；
• 系统分工：确定功能做在哪个系统里，属于哪个业务系统；
• 系统交互图：C4模型，分层次，聚焦于不同的层次来画；

C4

C1：有点类似于用例图，以服务端为中心，将服务端当作一个整体；强调的是页面/客户端与服务端的交互；用户要做些什么；客户端要什么；服务端要做些什么；
C2：有点类似于对服务端进行细分；系统划分；系统分工；涉及哪些系统；强调系统之间的交互；系统交互图，即系统级别的交互；
C3：有点类似于模块的详细设计，某个系统的内部模块之间如何交互的；系统内部模块之间的交互图,即模块级别；
C4：代码级别的交互，时序图；

说明

• 系统内部的详细模块，系统内部的模块交互图也是概要设计的一部分；为啥这么说呢？因为涉及多个系统时，才需要系统交互及系统分工；如果只涉及到一个系统时，那么就只需要系统内部模块交互图；所以系统内部模块也只是概要设计的一部分；
• 系统交互、系统分工、内部模块交互：都要落地到模块级别，层次；否则就有点空虚和空洞；
• 接口只是详细设计的产物；模块是详细设计的出发点；
• 系统交互及模块的详细设计只是模块的不同维度、位置、层次、视角的描述；即 模块的系统交互及模块的详细设计；
• 模块的系统交互：所有的系统模块只有一个系统交互 or 系统分工图；
• 模块的详细设计：即每个模块都有一个详细设计；
• 系统只是模块划分、拆分、边界划分的产物；没有落地意义；不能够指导代码实现、功能实现；只是说决定了模块放在哪个系统中来做而已；系统是模块的容器，集合，没有实体；
• 真正的详细设计是模块的详细实现、具体实现；

概要设计/初步设计阶段：C1、C2；系统交互图（系统之间的详细交互）+系统分工图（系统之间的详细分工）；系统交互图不是必须的，涉及到多个系统时才需要考虑；分系统设计（系统内部模块的详细交互或者详细设计） + 没有涉及到多个系统时，不需要分系统画内部详细模块图；（系统内部模块的详细交互设计）模块之间的交互图；
详细设计阶段：C3、C4：模块内部详细设计图；分模块设计（模块的详细设计或者模块内部的详细设计）；

其实就是层层分解的过程，即1，1分2，2分4；当作一个东西，然后再拆分、分解、细分、细化；

总结

1）页面分解
2）服务端分解
3）系统级别：多个系统则系统交互图+系统分工图；多个系统则分系统画系统内部详细模块交互图/划分图；
4）模块级别：模块详细设计图

5）代码级别：时序图

什么是详细设计？
分解到模块，分解到接口，分解到接口实现，功能实现。
step1 页面分解、角色划分
step2 页面-服务端交互分析、分解、交互梳理、汇总；（接口就是功能的组合、分组）；
理清楚前后端交互过程，交互步骤，交互流程，交互环节，所有步骤，所有环节，全部过程；
step3 服务端功能分解为模块/拆分、拆细、细化模块（分解、拆分、切分、切块、分切、分割、切割、分拆、拆细分的越细越好）（切分、分切）；页面是交互发起方，汇总页面与服务端的交互，有几次交互，几处交互；不可分割的交互-->每次交互，必然得提供一个接口，为接口设计指明方向；
step3 功能系统/模块 模块重组、组合、组团、拼团、抱团、模块聚合分组、模块分组、模块分块/模块分工与交互、系统/模块交互；（模块分工交互图适合总图，总体交互图体现了分工）
分工是因，交互是果，有分工才有交互。分工在前，交互在后。

重点关注模块之间的交互，系统只是多个关联模块的组合，或者说是个更大一点的模块，多个模块的分组而已；

---

接口定义/实现？
接口要做哪些事情？做了哪些事情？
一个功能可能需要多个接口；
一个接口可能实现多个功能；
接口只是一个发起方，触发点，发起点，入口；
接口是能力的暴露方式；能力的一个体现方式，能力的获取点；

---

方案设计时考虑线性的过程，流程，步骤，流水线或者说垂直的一条线的过程，从上到下，或者从左到右的过程，环节。
还要考虑分离出环节中涉及的业务方，变为泳道图。
写接口，写代码是单线的思维。
接口的一条线很难把整个过程串起来，比如A调用B，那么这个从接口的角度就是一条线。
那么一个完整的流程，可能B又调用C，B又调用A。那么对于发起方来说，每个单线的流程都是很简单的，如果只是从流程图角度来看，看不出来他们在整体中的作用。
那么泳道图，可以把多个单线流程串起来，形成一个整体的闭环。

对于接口逻辑来说，是单线的，从先后顺序来看，先理清楚泳道图，再来切分每个独立的线，这些独立的线就是一个接口干的事情。

流程图以分工维度来看，可以理解为交互图。以步骤维度来看，可以理解为过程图，步骤图，流程图，环节图。
单线的流程图就是描述步骤，过程，环节。
多线的流程图，就是分工交互图。

---

所有的功能实现细节，都是通过交互入口来实现的。首先要定义好交互。交互入口。
有几个交互入口，接口。几次交互。所有的客户端和服务端的交互。

---

参考链接

https://www.jianshu.com/p/88a...
https://blog.csdn.net/akk4706...
http://www.woshipm.com/pd/568...
http://www.woshipm.com/pd/442...
http://www.woshipm.com/pd/441...
http://www.woshipm.com/pd/438...
http://www.woshipm.com/pd/439...
https://www.dazhuanlan.com/20...
http://c4model.com/
https://www.cnblogs.com/bmake...
https://www.jianshu.com/p/a52...
https://blog.csdn.net/carolzh...
http://www.woshipm.com/pd/634...
https://baijiahao.baidu.com/s...
http://www.blogjava.net/amigo...
https://baijiahao.baidu.com/s...
https://blog.csdn.net/weixin_...
https://blog.csdn.net/zhengfe...
http://www.woshipm.com/pd/634...

主要用来描述“用户、需求、系统功能单元”之间的关系
https://segmentfault.com/a/11...