|
版本号 |
作者 |
内容提要 |
修订日期 |
|
V0.1 |
XX |
系分初版 |
2021.01.06 |
|
V0.2 |
YY |
完善性能部分 |
2021.01.16 |
1. 需求概述
对需求进行描述，保证和产品、测试理解一致即可
如果是技术改造，需要对改造原因进行描述
1.1 术语
|
名词 |
名字解释 |
|
麦座 |
票务Saas解决方案 |
1.2 背景&目标
|
背景 |
|
|
业务目标 |
|
|
系统目标 |
|
2. 整体分析
2.1 系统架构设计
新增场景：体现架构设计，同时联系中台架构接口人更新麦座整体架构
修改场景：体现修改前后的架构设计，同时联系中台架构接口人更新麦座整体架构
2.2 业务用例
列举本次需求改动影响的所有“场景”，这里可以用excel、脑图、用例图都可以
建议使用脑图，一级场景，二级接口，三级分支
这里描述的业务用例更多是用例层面的，代码改动影响其他接口的建议也标注出来
麦座对已有用例图积累的比较少，还是已脑图形式体现影响范围更好一些。
2.3 业务流程
建议必填
相当于需求概述的流程图，能体现出不同模型（或系统）之间的指责
2.4 领域模型图
若没有涉及领域模型的新建或变更，则可以不填写
如果涉及到模型变更和状态机的变化，可以在这里体现
3. 详细分析
3.1 系统依赖关系
若没有涉及到多个系统的交互，则可以不填写
例如
3.2 系统交互时序(时序图)
（1）画图工具统一调整为 visual paradigm 社区最新版：https://www.visual-paradigm.com/download/community.jsp
（2）如果需要反向工程的话可以考虑集团的旧版本：https://www.atatech.org/articles/43781?spm=a1z2e.8101737.webpage.dtitle4.42026a6ck6fcmm
建议从以下几个点考虑异常场景
- 服务依赖：依赖的服务是弱依赖还是强依赖，对依赖服务的响应时间是否有要求，对其超时时间的配置是否合理，当依赖服务出现问题时是否可以降级或者故障隔离。
- 数据一致性：网络或者系统异常时服务提供方和服务使用方的数据一致性，如A调用B，B处理成功，但是由于网络等原因返回A失败，或者A调用完B后的处理异常，怎么保障数据一致性。
- 幂等：为保障数据一致性，上游系统可能会重试，或者网络重发，消息重发等，幂等控制是否有效，幂等返回结果处理是否正常。
- 并发：只要是数据有关系的处理流程都可能涉及并发问题，不同主流程或者主流程和定时任务等，数据表的唯一性约束是否有效。
- 事务：事务内的异常是怎么处理的，是否存在异常但事务无法回滚的情况。
- 消息：消息的发送和回查，消息的发送异常是否需要感知。
- 定时：定时任务捞取条数，范围，频次，失败降级策略。
系分评审就要有接口文档
提供接口文档地址：基础描述和语雀地址
依赖接口文档地址：基础描述和语雀地址
3.3 数据库变更
若没有涉及数据库变更，则可以不填写
标识新增字段、删除字段、还是修改索引(结合数据量并请DBAreview)、数据订正之类、数据库实体关系
交易、生产、会员等影响数据库变更要考虑对报表的影响
ALTER TABLE `enroll_info` ADD COLUMN `order_number` bigint(20) NULL COMMENT '订单号', MODIFY COLUMN `pay_status` tinyint NULL COMMENT '支付状态：1=待支付，2=已支付，5=超时未支付',
备注：数据库脚本要结合线上业务调用量，考虑现有索引的合理性、是否需要增加索引以避免慢SQL。
3.4 其他
如果使用了一些新的关键技术、第三方框架等，可补充在这边。
备注： 使用新的关键技术、第三方框架； 研发人员要考虑运维成本和自己知识储备和驾驭能力
4. 非功能场景分析
每个子项必须要考虑，如没有则填无
4.1 兼容性
- 原有的功能上新增、修改、删除，不管是db、模型、消息、接口服务，兼容性务必考虑
- 新老数据兼容
- 数据库新增字段默认值
- 接口变化对未发布的消费方是否兼容
4.2 资损
- 分析项目中是否存在资损风险点
- 针对资损点需要哪些监控或者核对
- 有什么应急处理方案
- 接口一致性方案，如果有
- 核心字段一致性检测，如果有
4.3 性能
- 业务上是否有性能要求
- 系统变更本身是否会引发性能问题，如是否有批量操作，较长的流程设计，DB操作次数及耗时，复杂对象解析等
- 依赖外部服务变更是否会引发性能问题，如新增依赖服务的性能
4.4 安全
- 需求是否有安全性要求
- 权限、敏感信息、CTU、第三方安全、加密等
- 咨询安全工程师，听取安全建议
4.5 需求报表
- 需求是否需要埋点反馈需求上线效果到业务、产品、开发
- 需求是否开发需求报表体现需求效果给到商户
5. 三板斧
每个子项必须要考虑，如没有则填无
5.1 灰度方案
- 如果存在switch开关，备注灰度的维度，如果是商户或租户灰度，要有灰度计划，否则评审不通过
- 如果是灰度环境SPE，需要说明怎么保证前后端兼容
5.2 监控方案
- xflush地址
- alimonitor地址
- 日志埋点、监控报警方案&报警群
5.3 回滚方案
- 如果Aone回滚，要声明是否有其他应用需要回滚
- 如果是Switch开关回滚，前端是否需要回滚，其他依赖系统是否需要回滚
5. 参与评估人员
开发:XX
测试:XX
CR:XX
需求评估人:XX
评估结论：通过、不通过（本次原因说明）
PM：XXX
架构：XX
主系分人：XXX
前端主系分：XXX
POS主系分：XXX
XXX主系分：XXX
里程碑：
整体联调时间
用例评审时间
代码CR时间
提交测试时间
6. 工作量拆解
初期建议精确到0.5人日，项目更加可控
每个工作项的工作量建议不超过1人日，对于项目管理者可以确定每天都有进度