這段時間，帶專案進入到概設評審階段，寫需求規格說明書、軟體概要設計說明書，又寫需求評審彙報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；系統部署設計還是畫圖講，用部署圖，邏輯部署和物理部署都要有；系統安全設計將兩塊：系統安全和資料安全，現在是個專案都要將等保三級和雙因子認證，哎~ 自己看著寫唄

最後，軟體體系架構，說說你的技術實現，順便提提開發環境等等。

至此，就說這麼多啦，最後總結一下說，一是該說到的一定要說到，該說清楚的一定要說清楚，二是彙報一氣呵成，上下連貫。這裡的不是說的連貫，是內容的連貫。╮(╯▽╰)╭