架构师成长第一步:如何做需求分析(方法经验总结,纯干货系列)

2021年9月7日 2点热度 0条评论 来源: 云飞龙行2021

前面两篇文章:

第一篇:《突破内卷,聊聊软件架构师成长之路,说人话接地气!系列文章》

  从架构师日常工作的角度,概要讲述了架构师要做什么,以及需要匹配什么能力

第二篇:《架构师成长之路纯干货:什么是架构和架构分类》

  讲述了架构的基本概念和架构分类

  接下来我们就来具体聊聊 每个阶段该如何去做,从实战的角度,讲讲做的方法,都是多年经验总结,或许看上去没有那么高大上,但绝对实用。

  从几十万的小项目到数千万的大项目,都可以用得上。

  先来聊聊 架构师该如何做需求分析

一:架构师需要做什么,包含但不限于:

1:理解业务,要准确、全面、深入

  这是需求分析阶段最最重要的工作。

  准确的意思就是:对每个功能点的理解,要没有歧义,不可再分。

  如果一个功能点,不同的人有不同的理解,这就是有歧义;另外这个功能点,里面还有很多小功能点,是可以再分的,这也是不行的。

  可惜咱们在需求文档里,看过太多这样的坑,往往一两句话,就一笔带过好大一个功能块,最后为了填坑,多耗费出上月的人力和时间。

  因此,架构师在做需求分析的时候,对每一个功能点,一定要准确,要求理解到没有歧义,不可再分,基本要到最细粒度的操作,比如:新增、修改这样的功能。

2:识别重难点业务

  这个算是架构师的一个基本功,拿到需求后,架构师要能识别出里面的重难点业务,对它们的分析和设计,可能会影响到后面的技术选型和具体的架构设计。

  毕竟,软件只是工具,是用来帮助实现业务活动的工具;而架构设计是为软件服务的,是为了更好的开发和制作软件这个工具。

  因此,对于重难点业务的把握,可能直接决定了架构设计的成败,一定要非常重视。

3:识别非功能需求和质量约束

  非功能需求:就是除去业务功能需求之外的需求,通常也是软件质量约束的一部分,比如对系统:性能的要求、可靠性的要求、可扩展性要求、可维护性要求、安全要求、备份恢复的要求等等。

  这些要求对于架构设计的影响是非常大的,很多都是架构设计要重点考虑的问题,比如:性能、可靠性、可扩展等等。

4:业务架构

  这个通常是以产品人员设计的业务架构为主,但技术架构师需要在准确、深入理解的基础之上,按照技术人员能理解的方式,对业务架构进行微调,输出一个技术落地实现的业务架构。

二:对架构师而言,需求分析非常重要

  需求分析是做架构设计的基石或者是起点,架构师在对需求进行全面、准确、深入理解过后,在这个基础之上才能去做架构设计。

  需求分析告诉我们到底要做什么,连这个问题都没有解决,谈何架构设计。如果要做什么都不清楚,请问这个架构设计为谁做,做来干什么呢?

  现在有一些所谓的架构师,轻业务而重技术,成天高谈阔论各种技术,名词满天飞,为了技术而技术,却忘了架构设计的初心,这是很不可取的。

  可以毫不客气地说,这些人根本算不上是真正的架构师,称之为“伪架构师”或者“PPT架构师”。

三:如何做需求分析

这里并不是教科书式的方法,只是多年架构设计实战经验的总结,供大家参考,不足之处也请海涵,可以多交流。

一)基本思维方式

  只是考虑:具体要实现什么、明确具体的展现形式

  不去考虑:究竟如何实现

  通常,架构师都是从开发人员升上来的,有些刚开始做架构的架构师,他的思维方式,还带着浓厚的开发人员的思维,一看到功能需求,脑袋里就全是代码,自觉不自觉的就在思考该怎么实现,就差把代码写出来了。

  特别提醒,这个阶段是只考虑要做什么,而不考虑具体如何做。至于如何做的事情,是接下来的架构设计、详细设计等阶段要考虑的。

(二)做需求分析的基本方法

1:明确系统边界

2:视角进入系统,按照大业务功能(子系统、业务模块)的方式,来理解这些系统的业务边界、业务功能和业务流程

如果把系统想象成是一栋大楼的话,视角就像是镜头,由远及近地推进。

3:采用模拟业务运转的方式加深对业务的理解

4:采用不断问问题的方式,进行业务挖掘和深入理解

5:不断进行功能分解,把复杂的、较大的功能,分解为颗粒度较小的功能,直至不可再分

6:对业务功能点:

(1)逐字逐句地去读需求说明书,读出显示的或者是隐含的功能点

(2)对这些功能点,进行从前台页面到后台功能,逐步进行明确,要到实现需要明确下来的地步

(3)换位思考

7:对业务流程

(1)把流程中的每个节点当做一个具体的功能来思考

(2)每个节点的角色是什么

(3)每个节点相应的页面是什么(页面流)

(4)节点要操作的数据的来源和去向(数据流)

(5)节点的启动条件和向后流转的条件(逻辑流)

8:进一步应用 模拟业务运转的方式 进行业务走查

9:对于不明确的、模糊的功能

(1)跟需求调研人员或者是产品人员讨论、或者再次跟用户讨论

(2)暂时搁置,明确后再做这部分

10:对于非功能性需求,需要尽量明确到指标,并准确理解相关的约束条件

 

以上的方法步骤,是多年实战经验的总结,有不明之处,可以多交流。

另外提示一点:对于这些方法,在不同的项目实操中,还会有调整和变化,最好是结合实际工作中的项目,多实践、多思考、多运用,才能真正理解和掌握。

熟能生巧,最后内化成为你自己的能力,形成你自己的一套方法,你也就成了真正的架构师了!

也欢迎各路架构师朋友一起探讨,碰撞和完善这些方法,谢谢大家!

更多架构师之路干货文章,已在路上,稍后就到!

 

    原文作者:云飞龙行2021
    原文地址: https://www.cnblogs.com/yflx/p/15235061.html
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系管理员进行删除。