关于技术方案与需求拆解最佳实践

   我们知道面对复杂的业务场景，如何去做好需求分解这个是非常考验一个技术架构师能力的。看到一篇不错的文章在讲《需求拆解》，简单记录一下学习心得与感悟。

《需求拆解》读书笔记 

1. 敏捷性的核心

以更快的速度更低的成本来验证假设响应变化交付价值

一、按工作流程步骤切分

产品经理在讲一个一故事，这个故事是不是在描述一个工作流程？

是否可以先完成工作流程的头尾部分，再添加中间步骤去完善该故事呢？

二、按业务规则切分

故事是否包含不同的业务规则呢？是否可以先完成业务规则的一个子集，后续再添加其他规则？

比如一个非常形象的例子：

作为贷款者，我可以选择不同的还款方式

作为贷款者，我可以一次还本付息。【这是一个业务规则】

作为贷款者，我可以分期等额本金还款。【可以扩展新的业务规则】

三、按主要工作切分

最直观的方法切分，无论先做哪个事，都是最难做的吗？是否可以先做成一个，再把后续类似的事情分成一组。

四、按简单/复杂切分

可以先完成简单核心，再通过后续故事来扩充它。

五、不同类型的数据切分

对于不同类型的数据，故事是否完成相同的事情呢？

是否可以先处理一种类型的数据，后续再处理其他类型的数据呢？

六、按不同的界面切分

是否会有复杂的界面，是否有一个简单版本可以先完成。再慢慢完善这个复杂的界面

七、按操作切分

故事包含了多种操作，是否可以把不同操作切分成独立的故事呢？

八、延迟性能优化

故事的大量复杂性是否来自于非功能性需求？

是否可以先实现功能，后续再考虑满足非功能性需求？

九、最后一招：探针试验

尝试了之前所有招数后，是否仍然很困惑，不知如何拆分呢？

可以找出最令人困扰的1-3个问题，为每个问题写一个探针故事，以最小成本找到问题的答案。

《技术方案模板》

在我们设计系统的时候出技术方案的时候需要考虑如何编写一个成型的技术方案。

一、领域设计（即领域模型按领域来划分）

1.1 涉及到哪些领域这个是设计的基础第一步。一定要做好

1.2 领域之间的关联关系

二、类图设计

2.1 如果用到了设计模式，必须要写；

三、表结构设计

3.1 表结构设计即各个字段的含义体现在设计思考中

3.2 枚举字段定义说明（字段如果是枚举类型就必须要在文档里面说明）

四、功能点设计

4.1 功能1的设计

4.2 功能2的设计

五、时序图（泳道图）

5.1 能够描述清楚主流程（比如一个自动扩的流程是怎么样的）

系统业务流程它关注的是从系统全局来看，而用例则是自己某个流程内部的流程。

5.2 描述清楚各类的职责

六、异常处理说明 

即非功能性说明

七、细节节点设计

考虑比较细的地方。比如大对象如何处理防止FGC

八、对外系统依赖

需要将外部系统所涉及到的接口对应的文档、联系人说明清楚；便于在将来可以快速找到联系人

九、API说明

后端对应的API定义。涉及到跟前端的交互

也可以参考这份模板《系分设计说明书》

这个模板会写的更详细，属于细分文档

1. 概述

1.1 术语解释

1.2 需求背景

1.3 目标

     1.3.1 系统目标 

2. 系统业务流程分析

    2.1 业务主流程

它是从系统全局来看，而用例关注的是自己内部的流程（比如某个系统用例的流程）。

系统的业务流程是用户要完成他的业务目的，在系统层面发生什么样的流程、事件来支撑用户业务；此处的流程节点同时是粗粒度的，它关注数据流、事件流来支撑用户的业务；

3. 系统架构和领域模型

    3.1 关键技术及第三方框架依赖

本系统采用了哪些关键技术，如业务算法、分布式session、分布式事务、分布式cache等；本系统引用 了哪些外部的Jar

    3.2 应用系统依赖关系

这个项目涉及到的应用系统调用关系及各应用系统之间的依赖关系。比如A这个项目依赖了B这个服务。

    3.3 系统1领域模型

 3.3.1 定义系统的领域模型

可以用UML图，表述领域模型。

 3.3.2 确定核心的业务逻辑

确定领域模型中核心规则、约束、平衡检查等;比如：

账户余额=可用余额 + 冻结金额   类似这样的平衡等式。这个里面就涉及到规则的检查。

4. 业务边界分析

    4.1 业务用例边界

在具体的业务分析的时候需要通过用例依赖树的形式表现出来。

    4.2 系统用例边界

          4.2.1 系统1用例边界

可以通过画业务用例图，明确业务用例边界，一个系统用例可以在多个业务用例中被使用。

通过图形、文字描述本系统用例，一个系统用例可能是一个服务，一个外部接口，可能是系统的一个公共基础功能，对最终用户使用的系统可能是一个页面的操作。

   4.2.2 系统2用例边界

5. 现有系统影响分析

    5.1.1 系统1影响分析

分析这个项目对本系统的影响，例如：添加了新功能，对原有的plan扩容会有什么影响？如果有影响到原有的功能，那就得提前做下约定，这非常重要。如果不明确影响就需要主动找其他产品方、业务方沟通，，把影响说清楚。

    5.1.2 系统2影响分析

跟上面的操作类似

6. 数据分析影响

    6.1 本项目数据分析需求分析

本项目中产生的数据（包含数据库数据、日志、URL访问日志）有没有考虑以后的可分析性。

7. 运维分析

    7.1 数据库影响分析

如果涉及到非标的DB变更，是否需要提前通知DBA；新增表或库的数据量及IO评估，会有多少事务量。

是否存在历史数据的迁移，如果有则需要做历史数据迁移计划；

有没有导数据的计划；

有没有初始化数据的计划；

有没有上线前数据订正的计划；

有没有停机维护的计划；

    7.2 网络硬件等影响分析

项目发布是否需要申请硬件资源

是否需要配置新域名、申请云资源等

    7.3 发布期间影响分析

    7.4 系统监控/业务监控/系统日志/灾备要求

系统发布和运行期间是否要对什么特殊系统日志做监控

系统发布和运行是否要对原有业务做监控，以便知道影响

有没有新的监控指标

系统有没有考虑以后方便的扩充监控

监控发现严重问题是否有方法来得及挽回损失

业务监控：系统发布和运行期，是否需要对业务数据做监控；有没有制定一些新的监控指标；

系统日志：严控按照日志打印规范来打日志，

8. 非功能性分析

    8.1 性能分析

         8.1.1 响应的要求

从业务角度分析对性能的需求：

a) 对事务的响应时间（平均、最大）

b) 吞吐量（每秒处理的事务数）

c) 容量

         8.1.2 业务吞吐量

    8.2 并发访问控制分析

   有没有什么资源需要并发访问控制的。在并发控制情况下会不会造成损失。 

   8.3 可测性分析/强壮性分析/可用性分析/ 

   强壮性分析：

      

9. 系统间关系与影响