一、      你设计什么

1       系统总体设计

1.1      系统结构设计

1.2      系统流程设计

1.3      系统运行设计

1.4      系统部署设计

1.5      技术架构设计

1.6      系统安全设计

2       系统分项设计

3       数据结构设计

4       系统接口设计

 

二、      你评审什么

1，从工作任务角度，明确概设与需求追踪关系

2，从软件开发角度，阐述系统如何实现哪些功能

3，从业务应用角度，说明反映哪些业务流程

 

第一，概设评审专家不完全都是需求评审时的专家，他们对可能并不了解你要做什么（需求），虽然概设的主要目的是怎么做，但还是需要简述需求的主要任务，避免某些专家因为不了解你要做什么而质疑你为什么这么做。

第二，重点阐述处理流程和功能分解，而且要做到力度适中。第一点说清楚了，你就可以很好引领专家去理解处理流程，根据流程就能标识出关键的处理模块，这样你的功能拆分也有依有据。在对功能模块拆分时，切勿过大或过小，过大会说笼统，模块就会变成黑盒子。过小会偏技术或具体的实现。

如设计一个“智能处理”模块，先看最开始时设计：①开始 → ②提交数据  → ③智能分析 → ④生成索引集 → ⑤存储数据 → ⑥结束，这种设计会发现③→④完全是一个黑匣子，智能分析发生了什么，怎么就生成索引集了？什么数据都能分析，太“智能”了。改进设计之后：①开始 → ②提交数据→ ③关键字抽取 → ④预设条件抽取 → ⑤特定地点抽取 → ⑥索引入库 → ⑦结束，这种设计会发现③④⑤过于处理细节，偏技术具体实现，不仅没有把关键处理环节说清楚，也造成整个流程粒度不一致。那么在进行改进，最终结果：①开始 → ②提交数据 → ③内容分类（判断结构化数据和非结构化数据）→ ④内容抽取（word、excel、视频、音频等内容及属性信息提取方式）→ ⑤索引及数据入库 → ⑥结束。处理流程明确之后，也很清楚的看到“智能处理”模块分为“内容分类、内容抽取、内容入库三个单元。

第三、切忌，对于专家，他们不是技术专家，而是业务专家。如果通篇评审汇报你只谈软件是如何开发的，那你就等死吧。一定要强调你的软件可以为业务提供什么样的服务或支撑。

总而言之，你的概要设计要说明：

1、依据是什么进行设计？（合同任务书的工作任务要求）

2、设计什么功能？（绝不是纯技术式的说明）

3、设计的产品支撑什么业务？（软件的价值所在）