最近與學弟聚餐時，我們閒聊共同討論專案文件時是否精簡系統求規格書與需求文件嗎？因為學弟公司是小型開發團隊(4-5人)，每個專案花太多時間整理需求文件，這也是增加公司的工作成本，但是削減太多會造成無法充分了解客戶需求與降低專案品質，尤其在多專案進入開發團隊時就會複雜，所以怎樣適當撰寫系統求規格書與客戶需求文件，但又不想影響整體專案需求管理品質，因此我將討論結果，做梳理後與各位分享。
(PS： 這方式是以開發團隊是4-5人，每個專案需求數為100以內，作為基礎條件去思考)
在討論過程中，我嘗試將之前在導入CMMI ML2【1】認證時與成大洪肇奎老師討論的需求追溯矩陣(RTM)【2】中需求垂直追溯表作個改良，用Execl表將複雜文件做分類，第一頁籤作為客戶需求表(當成是原始客戶需求)，然後接下依序依照垂直追朔表產生不同頁籤來管理，因此順序如下：(共5頁籤)
1.客戶需求表
將會議記錄的客戶需求、內部需求整理成為專案需求數作簡單列表，作為這專案的需求源頭且這需求是來自於客戶需求會議紀錄與內部討論的會議紀錄，日後要追朔客戶需求有沒有達到是可以找到作一個稽核資料，並將每個需求都給他一個需求編號(RM-01)。
2.系統分析(系統需求規格_SRS)【3】
將第一個頁籤當作源頭關聯到第二頁籤的系統分析需求項目，在這頁籤可以思考公司現有的專案或系統是吻合這個需求，舉例以"帳號要密碼管理"，收到這需求就可以對應到公司系統有"帳號管理"的功能，也許有符合這需求或要在修改，新增。這需求最好可以在搭配需求接收準則【4】來審核這樣就會更完善，因為"帳號要密碼管理"這需求並不詳細，因為"管理"這詞可以衍生很多需求如要做"二段式驗證"、"密碼強度要有中英文並有數字最少12碼."..等，若在這階段新增系不需求就可已給他新需求編號RM-01-01來作區隔。
3.專案規格設計(系統設計規格_SDS)【5】
當第二頁籤的需求項目確認後就可以將資料衍生到第三頁籤作進一步程式設計的來源，如上面範例 RM-01-01_"帳號要密碼管理"_加上"二段式驗證" 這資訊給第三頁籤後，我在這頁籤項目就可加入"帳號權限模組"_用Google 的手機驗API的整合程式_FM020001.do"來描述，當然這頁籤也可備註修改或全新程式，日後要維護這就是基本的程式清單。
4.專案估算工時
當第三頁籤將程式模組與程式清單勾勒出來後，就連結到第四頁籤進行估算工時的工作，基本上程式的分工結構就規畫出來，我們可以依據CMMI估算方式【6】或傳統績算法進行估算工時，這估算好處是依照客戶需求條列式並結構化估算，若工程師估算太高或太低都有文件與依據來進行討論。
5.專案報價單
當第四頁籤頁籤的工時整理出來，業務與主管只要依據這些工時表就可以進行價表單規格與價格的修改成為正式報價單。
6.專案討論的會議紀錄與相關文件
在這些頁籤在撰寫時就可以將會議紀錄或相關文件貼到這頁籤就可以當作日後需求或規格的查詢依據。
以上就是將客戶需求表與需求重直接受表作整理，我個人認為這份文件也可以當作基本的系統分析文件，當專案的規模很小時這份文件可以當作基本專案維護文件之一。
這方法經過我的實驗來作驗證，以公司小專案來實作，在2個小專案以56-40個需求數來撰寫，我大約式2-3hr就可以給業務工時與規格來進行報價，當然我是很熟悉這流程，若以資淺的系統分析師來做這份文件應該不會到4hr，當然這是我的個人經驗也許讀者依據貴公司的文化與流程規範撰寫時間會更少或更多。當然這文件你可以善用Google的WorkSpace來做管理【7】可以做到基本的型構管理(建構管理 CM)，因此建議可用Google 雲端文件。
最後想補充是軟體流程改善、企業內部流程改善可以參考不同的國外規範【8】，但不要太執著於哪個方法論，畢竟這些方法是要符合企業需求與文化，若導入制度輕忽企業原本文化這樣就會讓你導入表單與流程面臨很大挑戰，教導我CMMI的老師常跟我說不要因CMMI而CMMI，所有制度都要他缺點，當有人問我他它們公司要用CMMI或Scrum那個比較好，我都會簡單跟他說要用適合你公司文化的方法比較重要，請先了解你公司的需求，先作落差分析來確認你公司的需求，再來規畫要用那種方法或是混合使用2種方法。
(Note：若對軟體專案住清楚，建議事後可以多了解相關軟體工程的觀念【9】)
【1】CMMI (Capability Maturity Model® Integration，能力成熟度模式整合) 起源於美國國防部與卡內基美隆大學 （Carnegie-Mellon University）合作所設立的軟體工程學院（Software Engineering Institute，SEI）
CMMI2.0已經可以跟國際現行各種軟體開發方法做整合，如Scrum、DevOps...等各種敏捷(Agile)是開發方式。
CMMI Ver 2.0成熟度第二級認證的實踐域 (PA)
-Governance (GOV) 治理
【2】需求追溯矩陣(Requireability Matrix，RTM)
【3】系統需求規格 (Software Requirements Specification,SRS)
【4】專案經理怎確認客戶的需求？軟體需求接受準則是個好方法
https://ithelp.ithome.com.tw/articles/10286843
【5】系統設計規格 (Software Design specification ,SDS)
軟體設計規格書(Software Design Description, SDD)
【6】CMMI估算方式
https://ithelp.ithome.com.tw/articles/10286263
【7】Google的WorkSpace來做管理
https://www.web123.com.tw/blog/985
【8】參考不同的國外規範
1.CMMI (Capability Maturity Model® Integration，能力成熟度模式整合)
2.Agile 敏捷式開發，這是軟體工程中軟體開發模式之ㄧ(台灣常看到有Scrum、DevOps)
3.ITIL 資訊技術基礎架構庫（Information Technical Infrastructure Library，ITIL）
【9】軟體在專案開發的特性
https://ithelp.ithome.com.tw/articles/10286722
主管如何善用CMMI ML2觀念來制定簡易的規範
https://ithelp.ithome.com.tw/articles/10286721
怎產生小型軟體開發團隊的量化數據
https://ithelp.ithome.com.tw/articles/10285887
用客戶需求表、需求追溯表來取代系統需求規格
這是製造業標準流程，尤其是做 OEM/ODM 也一定這麼開
以前學校上系統分析，我就覺得哪裡怪怪的
原來就是這裡，多謝指點迷津
這位大大不客氣，我也是透過社群將頭殼東西整理出來跟大家分享，若有指教也歡迎討論^^
iThome鐵人賽
看影片追技術