产品 - 需求实例化
强弱项分析
铁三角
- 说明
- 能力方面：多角色、多视角（SE，BA，DEV，QA）确保需求挖掘的广度和深度；
- 价值传递：各个角色作为各个阶段的价值传递人员，需要准确地将信息传递到各个环节；
- 强项
- 多角色参与：多角色参与需求分析过程，确保多视角保障需求分析质量；
- 分析内容线上化：实际内容线上化管理，便于信息传递和检索；
- 弱项
- 过程可追溯性有待提高：过程记录不完善，无法直接获取参与人员信息；
- 过程内容管理薄弱：关键决策依据、重要讨论纪要等需要进行归档；
- 协同机制形式化：多角色协同需要聚焦需求分析质量统一的目标，共同方式各角色只关注自己职责：
过程质量保障
说明
- 在需求分析的各个活动中的质量表现
弱项
- 需求变更管理能力需提升：对于需求变更没有统一规范和要求，各个产品团队也没有建立自己的变更管理流程，所以导致过程数据客观性需要提高；
- 有效评审记录規范性提升：需要公司层面提供统一的需求评审模板。
需求实例化方法
说明
- 通过系统化的方法确保需求的确定性
强项
- 五步法框架：需求分析模板都以融入需求实例化五步法框架，在分析过程中出对每个步骤的输出都有所体现：
- 演进和创新：多个项目结合自身产品特点，对需求分析进行演进和创新；
弱项
- 系统性加强：需求实例化过程最常出现的问题还是信息（如用户，场景）孤岛，文档中会发现这类信息向上看到“源”，向下看不到“果”。没有系统化出来：
- 模板信息的成度需要加强：目前文档还是有很多内容就是从模板中保留下来的。需求分析过程没有修改和补充，建议可以将模板中的内容用特殊字体，颜色来标记；
结果质量
- 说明
- 需求分析输出物的质量表现
- 弱项
- 规范化：确保引入活动，发现活动等用于改进的指标数据准确；
需求分析的目的
实例化方法如何保证需求的确定性
需求实例化五步法：定系统，找用户，问目的，画场景，列功能。
定系统：去真正理解我们的系统边界，寻找在对外提供的用户系统中，我们和其他子系统的交互界面是什么。
找用户：当系统边界定下来后，用户也就清楚了、对于一个大的系统产品来说。可能存在外部用户和内部用户。这一步。对于一些互联网的创新型产品，通过引入用户画像等用户挖掘的探索，给这个产品创造竞争力。
问目的：是我们通常忽略的，我们往往拿到的外部专业网给出的解决方案，而不是关于用户真正需要的是什么。在这个步骤中，往前走一步理清用户真正需要的是什么，从问题域出发，反而可能会有突破性的收获。
画场景：去理解不同的用户角色在什么样的场景下去使用这个功能。比如，用户是是手工操作还是远程控制；不同的应用场景，需要考虑的侧重点会不一样。同时，也会涉及到一些特殊场景的识别。比如: 产品的安装和升级场景，多时区夏令时，时区跳变等。
列功能：需要提供满足不同用户在不同场景下的需要，基于现有的系统需要进行哪些功能的改造，可能涉及到对已有功能的修改，或提供新的功能。侧重点是这些功能应该如何验收。对于复杂系统来说，尤其需要考虑在改造已有功能的过程中的波及影响。
总结起来说，需求五步法就是一个具体的，可落地实践的需求分析工具，它提供了一个套路，让我们更全面更系统的对一个用户需求进行分析。通过这个分析过程，BA主导，不断与将各个利益相关的角色进行沟通和交流。输出物可作为开发编码和测试设计的入口。往前走一步”基干需求五步法的需求实例化实践还可以很好的和MFQ进行结合，用干解决复杂系统复杂功能的质量保证，两者的结合会达到事半功倍的效果。
场景
scenario：描述了系统与环境（包括用户、其它系统及定时事件）的交互，聚焦于环境如何使用系统来达成其目标。
关键要素
- 应用环境
- 产品被使用的地点、时机。
- 参与者
- 每个场景至少包括一个参与者。
- 目标
- 每个Actor有一个或多个目标。
- 行动和事件
- 参与者采取的步骤用以达成其目标。
use case
Use case为用例，它描述的是一个操作，而不是一个功能。传统的软件模型设计喜欢在需求分析把业务分解成功能模块，这样的弊端就是混淆了需求和设计的界限，因为功能模块的划分牵涉到系统的概要设计。在RUP里面提倡用 use case 来代替功能模块的划分。
与功能模块不同的是，用例不是站在开发者的角度，而是站在用户的角度来分解系统，因为用户并不想了解系统的内部结构和设计，他们关心的是系统的服务，即系统是如何去操作的，这就是用例的基本思想。用例模型主要由以下元素组成：
- 参与者(Actor)
- 指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。
- 用例(Use Case)
- 用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
- 通讯关联(Communication Association)
- 通讯关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些参与者所使用的。
需求实例化的工程化
