现状分析

一旦对项目进行了授权并起草了项目启动文档（PID），业务分析师就可以开始进行需求收集工作。以我的经验，解决此任务的最佳方法是从当前状态分析开始。它有助于了解业务需求，主要痛点，受影响的业务流程以及这些流程中涉及的利益相关者，等等。

当前状态分析的区域如下图所示：

分析的主要目的是提出“现状”状态：现有的业务环境，背景，业务功能和现有的业务流程，最后是涉及这些业务流程的利益相关者。根据项目的性质，基础架构的某些组件也可以包含在文档中。

当前状态分析文档列出了已识别的业务流程和其中的任务的关键痛点，并突出显示了预计会发生变化的领域。

该文件的最后一部分是关于提出建议的。它概述了主要发现并列出了预期的主要变化。任何警告也应在此处提出。

当前状态分析文档的内容结构如下：

本文档是业务分析师产生的其他工件的基础或参考点。其他文章将在以下文章中讨论。

项目愿景

项目愿景是由项目经理和业务分析师共享的文档。他们一起工作以概述问题陈述，确定所需状态，描述可交付成果的业务接受标准以及如何衡量项目的成功。该文档包含具有利益相关者分析的部分，其中显示了所有参与方及其职责和需求：

业务分析师会添加项目范围内的高级需求，并将每个需求标记为强制性或可选的。为了清楚定义项目范围并避免歧义，本节末尾还列出了所有超出范围的要求。

根据当前状态分析的结果，业务分析师将描述当前业务环境，用于支持它们的关键业务流程和服务。之后，所需的更改将映射到当前业务环境。最好将此映射显示为图表，以便将建议的更改轻松传达给业务利益相关者。

解决方案愿景

一旦批准了Project Vision文档，就开始准备Solution Vision文档。

首先，业务分析师从Project Vision工件中总结问题陈述。解决方案声明描述了解决方案的目标受众，解决方案将满足的条件以及关键的益处。添加解决方案与可能的替代方案的区别的说明，作为解决方案定位的结论点。

该文档使用RACI矩阵描述了目标受众中的利益相关者及其角色。

解决方案愿景的主要部分是一个详细的部分，专门介绍由功能和非功能特性组成的解决方案功能，并由业务利益相关者给出优先级。

下一节将介绍其未来的“即将成为”状态的业务环境。最好包括一个图表，说明主要的更改和对现有状态的添加，并提供简短的叙述以阐明建议的更改。

与Project Vision文档类似，在上一节中清楚列出了超出范围的功能，以确保每个人对于要实现的内容都在同一页上。

业务需求

本文档着重于提供有关当前流程的详细信息，并提供足够的信息来描述业务问题及其如何适合项目范围。本节重申“当前状态分析”文档的发现，但是在此与项目目标保持一致。

解决方案将要满足的业务需求在“范围内”部分中列出。在单独的部分中介绍了适用于所描述要求的业务规则。这种方法简化了与业务利益相关者对规则的确认。 
与业务需求相关的任何假设和依赖关系都将在适当的部分列出。
最后一部分介绍了对利益相关者角色，新的或修改的业务流程以及支持他们的业务服务的建议更改。

业务流程设计

本文档重点介绍业务流程的更改范围，提供有关当前业务环境，现有业务流程以及这些业务流程中涉及的利益相关者的详细信息。

它还描述了未来的状态：拟议的业务流程和“将要”的信息环境。新流程随附说明，以方便将建议的更改传达给利益相关者和业务最终用户。此“原样”部分重申了“当前状态分析”文档的发现，但是在此它们与对支持业务服务的更改保持一致。
在适当的部分中列出了与业务流程的更改相关的所有假设和依赖性。

用例模型

用例模型列出了使用业务涉众所需的解决方案的所有方案。将解决方案描述为一组功能区域并按功能区域对方案进行分组很有用。这样的方法可以更有效地在与业务涉众进行沟通时使用此文档，因为他们可以轻松地参考他们感兴趣的部分。

该模型列出了范围内的所有可能场景，其简要摘要，每个场景中涉及的参与者，使用频率，触发事件以及两个可能的结果-成功和失败。
方案的关键属性之一是对允许建立可追溯性的高级需求和必需功能的引用。
注意：在更改用例规范时，请不要忘记相应地更新用例模型文档。

用例规范

用例规范文档在用例模型文档中提供了有关用例的更多详细信息。

每个规范包括：

• 简要用例概述
• 参考功能区
• 前提条件
• 参与的演员
• 主流
• 替代流程
• 异常处理流程
• 解决方案的功能要求
• 可追溯到业务需求
• 适用于方案的市场或业务规则
• 用户界面，控件和数据

系统范围的要求

当业务需求，用例模型和用例规范完成时，将准备本文档。该文档的主要目的是提出解决方案的“质性”方面。

“负载模式”部分最为有趣，因为它说明了预期在工作日内如何使用该解决方案。这些信息可以从“非功能性”的角度很好地了解业务需求，并有助于在需要时阐明业务需求。由于解决方案通常基于信息技术，因此应注意解决方案的弹性。减轻灾难的方法和解决方案的恢复要求在这里起着主要作用。如今，很少有解决方案是全新的。通常的做法是将解决方案集成到现有的业务环境中。系统范围的需求文档描述了与内部和外部系统及解决方案的接口，在它们之间流动的数据，其格式和数据元素。如果解决方案应与外部系统连接，则必须在附录中提供数据样本。除了业务报告功能外，该解决方案还必须提供报告功能以监视解决方案的运行方式。这些报告在文档的最后部分列出。

解决方案词汇表

业务涉众通常在交流中使用术语和术语。为了跟上该术语的使用（您可能还很陌生），使用了解决方案词汇表文档。它有助于为项目团队和主要利益相关者建立通用术语，并在解决方案中使用。该文档的结构很简单：

将解决方案划分为功能区域是一个好习惯。对于参与项目的利益相关者，这些功能领域是小的知识领域。本文档用作所有先前讨论的文档的参考点。

不要忘记在下面添加您的评论。