需求背景
现在的系统有什么样的问题需要解决，业务上要达到的目标是什么。
技术需求的话主要是目前技术上哪些痛点：是无法灵活支持业务需求变化，还是性能有问题，还是流程上有缺陷等等。
也可以画图表示一下系统现状，现在的服务架构、底层商品模型、流程等。
改动点
本次项目需要改动哪些地方，是全新做一个交易流程（体验项目预约）；还是需要要改到商品模型，导致全流程重做（洗浴改版）；还是只需要改 C 端展示，不涉及底层商品模型及交易流程（足疗改版），还是新增加一些功能，对现有流程不影响（洗浴出票机）等。
如果大项目涉及到的改动点比较多，要做一个思维导图将所有相关的点列出来。
重要方案
本次项目比较重要的一些方案，这里可能会有讨论过多个方案，尽量写上每个方案的优缺点，选择哪个方案以及原因。
重要考虑点
- 商品模型，SPU 与 SKU 划分，现在的划分能否更好的支持价格库存与优惠等？良好的底层商品模型抽象能更好的适配适应当前业务并服务未来需求，不好的抽象会导致各种补救方法，导致系统补丁太多。
- 库存模型是什么，库存如何与 SKU 挂钩？
- 价格模型是什么，价格要不要与商品系统解耦开？底层数据结构是什么？现有的模型能更好的支持各种展示需求吗？比如列表页起价，详情页价格范围等。
- 上单要不要接审核，不接审核有什么风险，后续有问题了能不能快速接入，接入审核了线上线下数据一致性如何保证，B 端商户体验如何保证等。
- 对接第三方时，第三方超时、返回错误怎么处理？边界问题如何处理？任何接口任何流程第三方不可用怎么处理？有什么样的降级措施？
方案展现形式
- 涉及多个可选方案的，表格形式的方案对比。详细列出每个方案的描述及优缺点，目前选择了哪个方案以及原因。
- 用例图，主要用于大项目。
- 改动点的思维导图。主要用于涉及业务团队比较多，对流程改动比较大的。一方面可以对所有改动点有一个全局视图，另一方面也可以避免遗漏某些场景。
- 服务架构图。整体设置系统架构是怎么样子的，包括接入层、聚合层、领域层、数据层，每层都有哪些服务，服务之间的调用关系。
- 序列图。主要用于项目流程性比较强的，如与第三方有订单交互的，详细标注系统间的交互。
- 状态机。主要用于订单状态扭转。
- 数据库实体关系图。主要的用于展示商品、价格、库存模型。如果有新建表，要附上建表语句。
涉及服务
列出涉及到的所有服务，涉及包括但不限于以下
1. 新增服务或接口
2. 修改服务
3. Lion 配置需要修改
4. 下游需要扩容的服务
5. 上下游只需要升级 API
6. 外部需要提供的接口，或者工具类等
接口定义
需要对外部团队提供的接口，主要指向外部团队提供的接口，以及为前端提供的接口。
历史兼容
数据模型有没有变，有变的话如何兼容历史数据；是不是要刷数据，如果要的话刷数据的方案是什么；要不要双写，双写的方案是什么，如何保证数据一致性。
老订单如何兼容，不兼容展示会不会有问题，未消费完的订单要不要特殊处理等。
灰度上线及回滚策略
服务是否需要灰度上线，如果不灰度会有什么样的风险；灰度是按机器、用户、商户哪种策略，何时灰度多少量，何时全量。
回滚策略是什么，如果涉及到多个服务，不同服务回滚流程是什么。
涉及外部团队
列出所有需要感知到的外部系统，如果外部团队也有开发工作量的，则附上外部团队方案文档链接以及负责人，排期等。
也有可能涉及到外部资源申请，如申请消息主题、短信触达模板、商品类型、订单类型、结算类型等，可以附上申请负责人，进度，以及申请到的资源。
如果是交易流程相关的服务，可能涉及到的团队有：商家后台、旺铺宝、商家后台上单、阿波罗主方案、泛商品系统、前端、支付、订单、券、退款、结算、优惠、第三方、客服、BI、 UGC、POI、团购、搜索推荐等。
需要考虑到对本系统模块的影响：库存、订单、价格、商品、触达。
工作量评估及排期
涉及到共有哪些改动，每个改动点需要的大概工作量，以及排期。
测试点
需求改动较大的，或逻辑较为复杂的地方，边界条件，需要测试同学重点关注的点。