{需求.1004.07}需求報告書
在 前篇中 提到當我們需求訪談完，會出第一份需求報告書，一般小專案我們常會用會議記錄來取代，雖然省了一份文件製作的工，但有一些負面的缺點會出現：
(1) 會議開多了，不易追蹤結論。
(2) 會議中的一些遺漏，不易在多份會議記錄中被發現。
(3) 一下進入介面或使用者案例往往會加入太多的系統分析師的想法，而失去了客戶的原始想法。
而在這份報告書有3個重點要謹記
(1) Customer View 用客戶的話
(2) 識別的ID
(3) 簡單的彙總分類
在寫作報告書時最重要的是文字描述，亦可加入流程圖或簡易的使用者介面參考，但不要太執著於一張圖勝過千言萬或是太過深入描述需求，過度的細節會讓大方向及重點失焦，而細節應是在需求設計書中才需要撰寫，提供給系統設計人員來做架構的設計及Coding，也不要怕在進行需求設計書時又會回來改這份文件，因為這是必然的且一定會發生。
此外，有一個很重要的利害關係人常被忽視，就是未來維護或管理系統的IT人員，他們的需求也是很重要，亦需在這份文件中納入，忽視他們的需求往往會讓你在系統上線前吃足苦頭，甚至大改系統，僅管有些超強的專案經理可以用高超的政治手段讓他們屈服，但我覺得人如果業障做多了對自己也不好（一陣子就該問自己，如此混蛋般的活著，到底有什麼好處？）
如果你是第一次寫出這樣的內容，會發現這份文件的往返(Iteration)會超出你想像，並且發現其實你一點都不懂他（客戶）的心，也會常出現文字上的誤會，大部份情形是好事，會增加雙方溝通上相同認知，最怕發生像無底洞般放下一顆石頭但沒有回音，客戶沒有意見也沒有產生想法卻在案子的最後找麻煩。此外我喜歡用Word來製作這份文件，因為Word的追蹤功能, 可以讓我快速地看出修改的內容及歷程。
範例：
需求報告書
2010/04/25
文件制/修訂履歷
| 制/修訂版次 | 制/修訂日期 | 制/修訂說明 |
| 1.0 | 2010/04/25 | 第一次發行 |
一. 需求項目
1. 使用者介面
1.1 套用a系統之畫面風格.
1.2 套用a系統之操作方式.
1.3 Web base 並可支援IE 5.5以上版本, firefox瀏覽器.
2. 系統
2.1 為公司內部系統(intranet)單一授權平台, 第一階段應整合 a系統, b系統, c系統。
2.2 系統可容許8小時的服務中止.
3. 功能
3.1 功能管理
3.1.1 可建立/修改/刪除應用系統
3.1.2 可建立/修改/刪除應用系統內之功能
3.2 群組管理
3.2.1 可建立/修改/刪除群組
3.2.2 可加入/減少群組內之功能
3.3 授權人員管理
3.3.1 可將人員加入/減少群組
3.3.2 人員不可直接授予功能
3.3.3 代理人機制
3.3.4 可跨部門兼職
3.4 報表
3.4.1 可查詢單一人員的權限
3.4.2 可查詢單一群組的內含應用系統及功能
3.4.3 可查詢歷史記錄
3.4.4 除線上查詢外, 另需可輸出為Excel.
4. 安控
4.1 所有連線皆需SSL加密
4.2 所有的編輯及維護皆需有流程控管
下期預告:
需求設計書all in one版，需求設計書+介面規格書，需求追蹤矩陣