T31项目笔记-架构分析

1. T31项目介绍（类似于12306的售票网站）

1. 从查票、下单、付钱、通知的主流程
2. 抽象商品、订单、支付的核心模型
3. 处理票务异常和日志
4. 了解架构设计背后的方法论
5. 以战促练，全面提升代码能力、设计能力、交付能力和协作能力

T31的需求分析

1. 用户通过网站注册并且登陆
2.  车次、车厢、经停站、时刻表增删改查
3. 修改个人信息
4. 乘客管理
5. 余票查询
6. 创建（票）订单
7. 第三方支付
8. 支付成功通知

一、需求分析

1、什么是需求分析

理解和挖掘用户的诉求,以及背后的逻辑，转化成可行性的分析结果。从非结构化到结构化，确定系统的职责、模块的过程。

这里用户的诉求是重点，如果满足不了用户的诉求，做再多也没用。

2、需求分析关注的3个点

边界：分析背后的人性，人性是提出需求的本源。区分哪些需求是已经实现了的，可以复用功能或者调用其他系统的接口来实现，来确定需求的边界。

用户故事：形成最终能够还原用户角色的用户故事。比如T31里的购票、候补买票、为了接朋友查余票。这些都是用户故事，从用户角度区分不同场景，仔细理出来，就是用户故事。

用户路径：用户和系统的任何触点，都算用户路径。确定用户的意图，仔细描述清楚整个过程，并且在设计时尽可能让这个触点少。这样用户的使用成本就会很低。

3、需求分析中会遇到的问题以及解决方法

工作中遇到伪需求该怎么办？比如用户什么都想要，要得不正确的需求。（没有调研、没有目标、没有逻辑的无脑需求）

应对方案：
① 用数据化结果否定需求合理性
② 用正反案例来说明需求需要改进的地方
③ 用户路径和触点推演需求合理性
权利需求（老板或者强势业务方的需求）该怎么办？

应对方案
① 先肯定需求价值再提出需求实现的成本
② 给出更好的需求替代方案
③ 从数据和案例角度说明需求快速上线危害性
目的在于迂回引导出自己想要表达的想法方案。

4、辅助需求分析的方法

4.1、问题的分层

（本源问题）用户问题︰“我想支付” （经营视角）业务问题︰支持一切可以支村的第三方支付工具 （体系结构）产品问题︰支付需要逆向流程、异常流程、对账模块等 （架构代码）技术问题︰高并发、可用性，实现第三方支付的链路

4.2、KISS 原则

Keep it