这段时间，带项目进入到概设评审阶段，写需求规格说明书、软件概要设计说明书，又写需求评审汇报PPT和软件概要设计汇报PPT，两个说明书参考着一些GB/T、ISO、CMMI之类的还是很容易整理的，但是两个PPT，那可是有难又重要的，评审1个小时，半个小时汇报，你要通过PPT引领者专家，文档写得好，PPT没讲清楚，还是很有可能不过的。

所以，此文仅以个人一些小总结与大家分享写评审PPT的经验：

写需求评审PPT或概设评审PPT，首先就要说大纲写法，大纲贯穿你的思路，一气呵成，否则节节断断，零零碎碎。评审PPT的大纲如果照搬需求/概设说明书，那是相当可怕的，一、章节多而碎，二、说明书中的章节往往没有一个很强的逻辑。基于这种情况，个人整理了下，如下：

需求评审PPT大纲：

一 概述

二 业务

三 需求

思路很简单，先从招标书、投标书中用你自己的话，总结出一句话你要做什么？这个总结陈词很重要，别动不动就跟人讲招标文件中的建设目标，那是人家的理解，你的理解呢。之后结合需求调研的结果，分析业务逻辑，啥是业务，业务就是人家处理的流程，找出两个流来：业务流、数据流，用流程图画出来，这样你才能为需求界定边界。

最后，根据业务说出需求，或者说因为有这样的业务才有这样的需求，而且需求要细分，从以下几个方面从不同的角度说明：

三 需求：

1 软件功能

2 系统数据

3 系统接口

把需求拆分出来，第一软件功能怎么说，统一模型描述语言有没有，画用例图呗，把用户和系统之间的关系画出来，不就明白啦，第二系统数据，如果说软件功能使用来界定软件范围边界的，那么系统数据就是来界定数据范围边界的，不用随便就整个数据库群、系统总线，你知道那有多大数据量么，第三接口，包括本系统提供接口和本系统需调用接口，这用来界定系统边界的，整个边界图有没有，所谓高内聚松耦合嘛，接口定不好，后期别的系统直接JDBC访问你数据库，整不死你。

所以，把流程说清楚要干啥，把边界范围弄清楚，就没太大问题。下边在说说概设PPT，也是先整理出大纲：

概设评审PPT大纲：

一 概述

二 需求

三 设计

先从需求评审PPT把第一句话拿过来？为啥，你不说清要做啥，还汇报半个多小时，不找专家拍你。还有，把需求中的业务流程、系统功能，概括一下并从设计的角度说一下，此流程跟需求评审PPT的流程图不一样，需求的流程图对应业务，概设的流程图对应构件，要用管道流程图画，切记流程中每个方框对应的是构件，别写成操作步骤。

最后，根据需求（主要是流程）说出设计，同样设计也要系统从以下几方面说明：

三 设计：

1 系统总体设计

2 系统分项设计

3 数据结构设计

4 系统接口设计

5 系统部署设计

6 系统安全设计

7 软件体系架构

一项一项说，系统总体设计最重要看的是什么？当然是系统层次结构图，各种层的拆分，对应到各层的各构件；系统分项设计就是把每层的构件详细的讲，怎么讲：1功能描述与设计依据一起讲，2结构图（不是H图），3IPO，这样不就讲清楚啦；数据结构设计先讲下清单有哪些数据，再整个大大的类图，别整E-R图啊；系统接口设计讲下接口清单、接口定义、输入输出以及主要实现方法就ok；系统部署设计还是画图讲，用部署图，逻辑部署和物理部署都要有；系统安全设计将两块：系统安全和数据安全，现在是个项目都要将等保三级和双因子认证，哎~ 自己看着写呗

最后，软件体系架构，说说你的技术实现，顺便提提开发环境等等。

至此，就说这么多啦，最后总结一下说，一是该说到的一定要说到，该说清楚的一定要说清楚，二是汇报一气呵成，上下连贯。这里的不是说的连贯，是内容的连贯。╮(╯▽╰)╭