• 如何做需求分析

    一：架构师需要做什么，包含但不限于：

    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：对于非功能性需求，需要尽量明确到指标，并准确理解相关的约束条件