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

用友U8关键特性解决方案分析说明书 第 PAGE 1 页 共 NUMPAGES 10 页 SUBJECT 项目名称 关键特性解决方案说明书 版本 1.0修订历史记录 日期 版本 说明 作者 日/月/年 x.x 详细信息 姓名 目录 TOC \o 1-4 \h \z 前言 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分解提供直接支持；但是，这个阶段不是详细需求和详细设计阶段，参与分析的人员有限，不能事无巨细，面面俱到，否则，产品概念阶段会太长，因此，解决方案的质量关键在于识别出问题的关键点和难点，解决方案只针对关键点和难点分析解决方案，如果主设计没有把握识别出正确的关键点和难点，有必要和产品经理和相关主设计讨论确定后再动手分析。 概述 [解决方案的简介应提供整个文档的概述。它应包括解决方案的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。] 目的 [阐明此解决方案的目的。] 范围 [简要说明此解决方案适用的软件应用程序、特性或其他子系统分组以及受到此文档影响的任何其他事物。] 定义、首字母缩写词和缩略语 [本小节应提供正确解释此解决方案所需的全部术语的定义、首字母缩写词和缩略语。] 参考资料 [本小节应完整地列出此解决方案中其他部分所引用的所有文档。每个文档应标有标题、报告号（如果适用）、日期和出版单位或出版人。这些信息可以通过引用附录或其他文档来提供。] 问题定义与领域分析 [此小节应说明解决方案其他部分所包含的内容，并解释文档的组织方式。] 问题与目标定义 [对问题域的问题和期望目标清晰简要列出，在解决方案列示的问题只是领域中的核心问题，如果没有明确方案就会影响产品决策的问题，不包括一般性常规问题] 关键业务场景 [用Actor清单和Use Case 清单和UseCase图描述领域的核心业务活动范围和职责] 核心概念模型 核心概念定义 [对核心概念的解释说明] 核心概念图 [描述问题领域涉及到核心概念及其关系，概念一般是一个业务实体或者抽象概念，概念之间的关系主要表现为是、包括、属于等结构关系，主动者和被操作对象间也可能包含业务业务操作（动词）] 业务流程图 [业务流程主要为了表达问题领域内的参与角色、业务活动序列之间的依赖关系和执行过程，如果有多个核心流程，可以用多张流程图表达] 解决方案 现有系统原理模型可选 [此节需要让相关人员了解当前系统有关该问题域的处理机制，并标识出当前的机制的缺陷。如果解决方案所针对的问题域是以前未处理过的，则该章节无需编写] 使用结构图 [组件职能、组件协作与通信、数据流向（数据内容概要，批量/单条）] [描述系统的核心逻辑组建的职责、关系、核心输入输出以及核心用例的运行时实现原理，如果有多个核心用例，可以考虑用多张使用结构图] 现有系统局限性 [结合需求和当前系统模型，阐述当前系统的缺陷，重点描述与目标问题有关的缺陷，只有与目标问题相关的缺陷我们才出解决方案] 蓝图解决方案系统原理模型 [描绘蓝图规划的模型，如果该问