【SE赋能培训系列】【纪要】001期 场景分析

【基本概念】

RR：Raw Requirement，原始需求
IR：Initial Requirement，初始需求
SR：System Requirement，系统需求
AR：Allocated Requirement，分配需求
SF：System Feature，系统特性
参考文献（建议阅读其中有详细的解释）：https://blog.csdn.net/zsqianqiu/article/details/125058243

1、背景

1.1 方法：把系统作为黑盒，主要分析外部环境对系统的要求。作为开发人员转身做SE上来容易先考虑实现，场景分析阶段，需要先不考虑实现，从外部视角看产品应该如何实现。外部包括了使用产品的人，也包括了和产品交互的设备。
1.2 说明：背景介绍解决为什么做这个版本或特性的问题（Why）目标客户是谁，解决客户的什么痛点问题。目前版本是什么样，本版本完成后，达到什么目标。
1.3 展开：TR1阶段解决做什么的的问题（What），TR2阶段解决怎么做的问题（方案选择，How）

2、假设和约束

2.1 假设和约束的区别和联系：假设和约束都是对版本需求范围的限定，没有限定需求范围就不可控；假设是不完全确定的限定，约束是已经确定的限定。
2.2 关于假设的说明：假设即使是不完全确定的，也不是拍脑袋想出来的，要有一定的现场数据、竞品分析或是行业规范作为支撑

3、系统概述

3.1 系统的上下文：识别与系统有交互的所有外部对象、系统与外部对象之间的交互内容。了解了系统的上下文，需求功能才不会有遗漏。
3.2 需求的依赖和联系：指一个需求的实现，需要接收另一个需求的输出作为输入。需求间的相互依赖需要提前识别，这对于版本中人力投入顺序和分迭代交付有重要指导意义。

4、功能需求分析

功能需求是产品作为黑盒和外部的交互接口
4.1 主场景：一般不容易有遗漏和偏差
4.2 分支场景：设计时容易遗漏分支场景，需要SE逐项推敲主体场景的每一个流程环节，对于可能出现的各类状态和异常逐一总结从而形成各个分支场景；对于具体的产品和业务比较好的实践是总结产品特性的故障模式库，对应特性有新需求设计时，对照特性故障模式库过一遍，基本不容易遗漏分支场景。
4.3 性能需求：产品的资源（CPU，内存，磁盘，网络带宽等）总是有限的，系统与外部对象的每一步交互，涉及资源使用的需要量化形成性能需求
4.4 DFX（Design For X）：可靠性，可维护性，可测试性，可扩展性，安全性。目前团队是开发兼顾产品生命周期运维，设计阶段就需要考虑可靠性和可维护性，避免在产品上线阶段出现可靠性问题，或者出现问题无法定位恢复。可测试性主要考虑需求实现后测试人员是否可以验证，如果无法验证，需要增加一条需求来解决这个问题，常见的如故障注入，测试异常场景故障注入的时候如果测试领域没有故障注入的手段，需要开发提供一些接口构造故障场景，也包括一些压测工具的开发。可扩展性包括需要为未来扩展功能、扩展性能提供哪些能力；安全性是产品系统的自身安全性要求（通信安全、存储安全、安全漏洞要求等）

5、非功能需求

5.1 升级需求：如何从历史的某一个版本升级到本版本。需要考虑升级路径，尤其在做架构调整和资源调整的时候，需要考虑已发货的产品如何进行异构升级，如果涉及升级需要补充硬件资源，需要和产品及售后团队就补充发货达成一致。
5.2 License需求：哪些特性需要有独立的License控制，一般和产品领域讨论License规划。
5.3 认证需求：版本发布后需要取得哪些第三方认证，需要提前解读认证规则
5.4 兼容性需求：需要兼容哪些外部软硬件。
5.5 生产需求：为了支持供应链生产人员做产品生产，需要系统提供哪些能力？
5.6 资料需求：除了常规的资料输出，本版本有没有特殊的资料需要输出？

【FAQ】

1、SE和产品领域澄清需求的三板斧：善于倾听，多引导需求方讲，避免自顾自的表述对需求的看法；多问几个为什么，挖掘需求背后的场景和价值，一般有三问基本场景和价值都会比较清楚；SE要有自己的判断，及时沟通裁剪伪需求和低价值需求。
2、客户交流时应该避免的坑：要及时识别客户提出的是需求还是解决方案，有些客户针对某些特定的问题，喜欢自己给出解决方案甚至是实现方案，这个时候SE要特别警惕，因为客户出方案是不专业的，他考虑问题常常没有这么全面，如果照着客户提的解决方案/实现方案来开发，很大概率会掉到坑里。

【往期链接】

【SE赋能培训系列】【纪要】000期 角色认知_pkyy_xp的博客-CSDN博客