关键特性解决方案(U8).doc

<项目名称>
关键特性解决方案说明书
版本 <1.0>修订历史记录
日期
版本
说明
作者
<日/月/年>

<详细信息>
<姓名>

目录
前言 4
1. 概述 4
1.1 目的 4
1.2 范围 4
1.3 定义、首字母缩写词和缩略语 4
1.4 参考资料 4
2. 问题定义与领域分析 4
2.1 问题与目标定义 4
2.2 关键业务场景 5
2.3 核心概念模型 5
2.3.1 核心概念定义 5
2.3.2 核心概念图 5
2.4 业务流程图 5
3. 解决方案 5
3.1 现有系统原理模型<可选> 5
3.1.1 使用结构图 6
3.1.2 现有系统局限性 6
3.2 蓝图解决方案系统原理模型 6
3.2.1 方案描述 7
3.2.2 总体架构<可选> 7
3.2.3 使用结构图 7
3.2.4 角色及其用例 8
3.2.5 部署模型<可选> 8
3.2.6 方案风险 8
3.2.7 决策与检查 8
3.2.8 典型支持场景 9
3.2.9 任务分解与工作量估算 9
3.3 ╳╳解决方案系统原理模型 9
3.3.1 使用结构图 9
3.3.2 与蓝图差异及原因 9
3.3.3 方案风险 9
3.3.4 决策与检查 9
3.3.5 任务分解与工作量估算 10
4. 发展路标规划 10

前言
[动手编写解决方案前，请认真阅读前言]
解决方案是在产品概念阶段（产品定义规划阶段）对产品经理提出的重大功能目标的中关键问题部分进行分析评估，对产品经理提供工作量成本、风险、工作难度等信息，为产品决策提供相应的支持；对产品开发部指明开发思路和方向，提前识别开发风险和关键路径，为开发计划的WBS分解提供直接支持；但是，这个阶段不是详细需求和详细设计阶段，参与分析的人员有限，不能事无巨细，面面俱到，否则，产品概念阶段会太长，因此，解决方案的质量关键在于识别出问题的关键点和难点，解决方案只针对关键点和难点分析解决方案，如果主设计没有把握识别出正确的关键点和难点，有必要和产品经理和相关主设计讨论确定后再动手分析。

1. 概述
[解决方案的简介应提供整个文档的概述。它应包括解决方案的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。]
1.1 目的
[阐明此解决方案的目的。]
1.2 范围
[简要说明此解决方案适用的软件应用程序、特性或其他子系统分组以及受到此文档影响的任何其他事物。]
1.3 定义、首字母缩写词和缩略语
[本小节应提供正确解释此解决方案所需的全部术语的定义、首字母缩写词和缩略语。]
1.4 参考资料
[本小节应完整地列出此解决方案中其他部分所引用的所有文档。每个文档应标有标题、报告号（如果适用）、日期和出版单位或出版人。这些信息可以通过引用附录或其他文档来提供。]
2. 问题定义与领域分析
[此小节应说明解决方案其他部分所包含的内容，并解释文档的组织方式。]
2.1 问题与目标定义
[对问题域的问题和期望目标清晰简要列出，在解决方案列示的问题只是领域中的核心问题，如果没有明确方案就会影响产品决策的问题，不包括一般性常规问题]
2.2 关键业务场景
[用Actor清单和Use Case 清单和UseCase图描述领域的核心业务活动范围和职责]
2.3 核心概念模型
2.3.1 核心概念定义
[对核心概念的解释说明]
2.3.2 核心概念图
[描述问题领域涉及到核心概念及其关系，概念一般是一个业务实体或者抽象概念，概念之间的关系主要表现为是、包括、属于等结构关系，主动者和被操作对象间也可能包含业务业务操作（动词）]

2.4 业务流程图
[业务流程主要为了表达问题领域内的参与角色、业务活动序列之间的依赖关系和执行过程，如果有多个核心流程，可以用多张流程图表达]

3. 解决方案
3.1 现有系统原理模型<可选>
[此节需要让相关人员了解当前系统有关该问题域的处理机制，并标识出当前的机制的缺陷。如果解决方案所针对的问题域是以前未处理过的，则该章节无需编写]
3.1.1 使用结构图

[组件职能、组件协作与通信、数据流向（数据内容概要，批量/单条）]
[描述系统的核心逻辑组建的职责、关系、核心输入输出以及核心用例的运行时实现原理，如果有多个核心用例，可以考虑用多张使用结构图]

3.1.2 现有系统局限性
[结合需求和当前系统模型，阐述当前系统的缺陷，重点描述与目标问题有关的缺陷，只有与目标问题相关的缺陷我们才出解决方案]
3.2 蓝图解决方案系统原理模型
[描绘蓝图规划的模型，如果该问题域的解决模型并无发展路标规划，在本版就能完全解决的，该节应命名为╳╳解决方案系统原理模型。]
3.2.1 方案描述
[描述方案模型结构、运行机制已及模型如何解决问题的]
3.2.2 总体架构<可选>
[对于一个新的业务领域或者技术领域，总体的架构思路非常重要，此时，需要通过总体架构的构思，来描述系统的实现原理，通过总体架构来指导组件的职责划分和交互关系]

3.2.3 使用结构图
[描述系统的核心逻辑组建的职责、关系、核心输入输出以及核心用例的运行时实现原理，如果有多个核心用例，可以考虑用多张使用结构图]

3.2.4 角色及其用例
[描述蓝图方案针对的角色及角色可进行的主要操作]
3.2.5 部署模型<可选>
[部署模型直接影响用户的使用模式，对于一个新的领域，部署模型的选择是一个非常关键的决策，这将决定产品的交付形态和技术选择，对新的领域，该部分是非常关键的部分]
3.2.6 方案风险
[需要列出可以预见的或者已知的项目风险、技术风险、商业风险。并评估各风险发生概率及其危害度，并作出风险避免、风险管理等风险处理方式决策。]
3.2.7 决策与检查
[检查需求问题满足度、时间（成本）满足度、兼容与括在能力、权衡选择利弊等问题，该项是为了在完成解决方案后，再次书面阐述对各项指标的满足，特别是如果有些问题解决方式有多项选择时，必须陈述选择的原因，并简单陈述其他备选方案的功能和缺陷]
3.2.8 典型支持场景
[描述问题域典型场景（如权限体系中的角色继承场景、功能权限控制场景、子段权限控制场景等），并简要说明蓝图模型是如何处理该场景的]
3.2.9 任务分解与工作量估算
[WBS表达任务的分配与时间的约束，该任务分解粒度无需太细，分解到部门、组即可；时间上分解到月即可]
序号
任务
任务描述
承接部门
工作量
BAS

3.3 ╳╳解决方案系统原理模型
[如果该问题域的解决模型并无发展路标规划，在本版就能完全解决的，则不需要编写本节；XX指版本号]
3.3.1 使用结构图
[描述系统的核心逻辑组建的职责、关系、核心输入输出以及核心用例的运行时实现原理，如果有多个核心用例，可以考虑用多张使用结构图]

3.3.2 与蓝图差异及原因
[描述出本版本解决方案不同于蓝图之处，并需要说明其决策原因。]
3.3.3 方案风险
[需要列出可以预见的或者已知的项目风险、技术风险、商业风险。并评估各风险发生概率及其危害度，并作出风险避免、风险管理等风险处理方式决策。]
3.3.4 决策与检查
[检查需求问题满足度、时间（成本）满足度、兼容与括在能力、权衡选择利弊等问题，该项是为了在完成解决方案后，再次书面阐述对各项指标的满足，特别是如果有些问题解决方式有多项选择时，必须陈述选择的原因，并简单陈述其他备选方案的功能和缺陷]
3.3.5 任务分解与工作量估算
[WBS表达任务的分配与时间的约束，该任务分解粒度无需太细，分解到部门、组即可；时间上分解到月即可]
序号
任务
任务描述
承接部门
工作量
BAS

4. 发展路标规划
[一般基本的功能必须在第一版本实现
第一版必须考虑未来实现更满意的或者更具吸引力的功能的扩展基础]
更满意的
Satisfier
更有吸引力的
Attractor
基本的
Basic
Ver1
Ver2
Vern