【HappyCoding 之前，如何做好需求分析？】

“代码没写完，哪有脸睡觉”？代码爱好者们如是说。在工作当中，开发者往往也要担任需求分析的角色，承担一些需求分析设计文档编写等工作，这对于一些刚入行的新手或是一些自我封闭的“代码高手”来说是比较头疼的，毕竟 “Talk is cheap, Show me the code!”，当然，大多数人并没有达到 Linus Torvalds 那样的高度，还是要一步一步脚踏实地，完成日常任务的同时提升各方面能力不断打怪升级。

那么，在遨游于代码的世界之前，如何分析好接到的需求呢？又该如何清晰有结构有层次地表达出来？保证项目组任何一个开发者拿到你的需求分析设计文档是否可以很明确的知道要做什么？做多少才算完成这个需求中涉及到的内容？分享记录一下自己做需求分析编写设计文档的一些做法。

这里以数据仓库、数据集市系统中的数据开发类需求举例。

无论是数据仓库，还是数据集市系统，粗略地讲都是一个数据中转站，有需要消费数据，对数据进行展示等操作的下游系统，也有需要提供业务数据或日志数据的上游系统，一般都是业务部门需要数据展示或统计进行分析从而提出的数据需求，然后根据数据调研确认数据链路后进行需求变更，数仓或者数据集市针对需求变更说明书进行需求分析设计，然后供数下游系统应用。

在业务部门提出需求变更时，往往都已经做好了数据调研，我们可以根据需求变更说明书的内容进行需求分析，不考虑不可实现的一些功能，一般的设计思路大体可以按数据仓库或数据集市的数据流向进行拆解需求内容，这里简要分为：输入接口、模型层、分析层、应用层、输出接口。

1、输出接口

这里定义的是输出数据文件接口，即数仓或数据集市通过数据文件形式将数据供给下游应用系统。

先和下游应用系统确认数据文件输出接口表变更或新增，假设与下游系统交互是按数据文件，存储方式按表，那么，还需要：

与下游沟通表结构变更或新增，表的业务数据范围等，然后需要确认所在的数仓或数据集市是否存在满足下游系统所需数据，按文件进行传输还需要确定分隔符，定界符，字符编码，数据文件、标志位文件后缀名等等。

2、输入接口

定义也是输入数据文件接口，即接收的是上游系统的数据文件形式。

需求数据调研分析过程中，如果当前数仓或数据集市中数据不满足下游系统消费需求，则需要新增输入数据文件接口，然后就涉及到数仓或数据集市的数据存储流程，比如要根据新接入数据进行数据建模，是否可以与现有数据进行整合等。

3、模型层

模型层涉及到数据存储的问题，可以通过数据仓库建模理论，项目数据架构进行了解。可以按业务或者主题进行归入模型层，并对表名、字段名、数据类型等进行规范化，明确一张表的业务主键，确认业务数据范围等。

比如，一张企业客户信息表，里面存储的是企业客户的基本信息，包括客户编号、客户名称、客户的统一社会信用证代码、注册地址、经营地址等信息，这张表的业务主键就是 “客户编号”，可以唯一标识该表的一行记录。

4、分析层

分析层一般是通过模型层的数据对一些统计指标或客户属性标签的分析处理，或者提供如指标明细数据。

比如一个客户在某一年总的账户余额为 1000 万元，提供的明细数据包含这个客户每个账户当年的余额情况。

5、应用层

应用层一般是针对不同的下游系统提供定制化数据接口。可以根据下游系统提供的表结构及数据范围以及业务提供的数据处理逻辑（业务口径），转化为技术实现逻辑并形成书面文档。

描述需求
在需求分析过程中，要编写设计方案，通过文档展现并留存分析结果，也是梳理分析人的思路的过程，是否对真正理解了需求，并且能否把思路梳理清晰并描述出来，这个描述包括书面描述形成文档，还包括沟通表达的方式，因为在设计文档编写完成之后，还需要对需求进行评审并且与开发人员进行需求内容和技术交底，所以还需要考验你的表达能力。

书面和口头表达可以按“从前往后，从后往前”的方法进行描述。

在与开发同事进行技术交底的时候，可以按从“输出接口”开始，即下游需要什么样的数据，需要构建一个什么样的表，为什么需要？展示在什么地方？可以实现什么样的价值？【这些都可以多了解，不只是明白数据的生命周期，对于自己的系统思维和全局观念的形成会有很大帮助，也能明白自己工作的意义】然后再具体讲在这次需求中需要完成哪些工作，涉及哪些表和数据的变动，是否需要新增输入接口，从哪个上游系统接入，如何实现等等。

在编写设计文档时，又可以从“输入接口”开始，需要接入某个系统的哪些数据文件，数据的内容，数据模型的构建，然后到分析层和应用层的指标、标签、接口表的业务口径、技术口径（实现逻辑），最后要输出哪些数据文件接口到哪个下游系统等。

这里提供一个参考的变动项表达方式：

可以使用伪代码表达技术口径，以便代码开发者开发的代码与需求分析人所设想的结果尽可能相差不远，沟通也更加高效。

举个简单的例子：

如业务口径为要统计当年客户的账户余额。

则在设计方案文档里面编写关键业务设计时技术实现口径可以这样表述：

INSERT INTO appcrm.cust_indx_statis(
data_dt
,cust_id
,...
,sum_ind_val
)
SELECT
批量日期
,cust_id
,...(其他字段)
,SUM(ind_val)   AS sum_ind_val  -- 总余额
FROM cust_info -- 客户信息表
WHERE SUBSTR( data_dt, 1, 4 ) = SUBSTR( 批量日期(YYYY-MM-DD), 1, 4 )
AND ...
GROUP BY cust_id, ...
/**/;

小结

以上只是需求分析工作过程当中的一部分，更复杂的分析工作还涉及数据调研，部门之间沟通协调，与业务或者说产品经理不断沟通理解真实需求目的或痛点，中间还可能要经历多次的会议进行上下游沟通和需求确认等。

分析过程中也要多思考，多总结，了解数据的生命周期，数据是如何产生的，接入数据后每一个细节的处理过程，到最后下游系统消费，实现功能后可以解决什么问题，比如对公司决策或营销策略有什么帮助等，不断刻意练习系统思维和工程思维，不要一开始接到需求就直接进行代码开发，先从大格局观察再深入细节，最后还能回归到顶层中看待问题，避免陷入惯性思维，细节思维；

做需求分析还可以思考如何进一步提高文档书写能力，以及沟通表达的能力，比如作为一个技术开发人员人，如何能更好的将技术实现思维清晰地表达给产品经理或其他非专业技术人员，如何更好的与同事、领导、客户进行沟通等，还涉及到任务拆解和任务分发的能力，可以作为锻炼组织管理能力的一部分，为之后更多的职业发展规划可能性做准备，不断增进自己的通用软实力。

---

欢迎微信搜索并关注我的公众号： 键道码屋
这里分享工作、生活、见闻、思考，我们一起阅读、思考、写作、行动，共同进步。

原文地址：https://blog.csdn.net/m0_47163275/article/details/142744671

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！