如何管理軟體專案的需求？嘗試將客戶需求表與需求垂直接受表作整合

BY Jos │ 2022-12-01 13:50:37

最近與學弟聚餐時，我們閒聊共同討論專案需求可以再精簡嗎？因為學弟公司是小型開發團隊(4-5人)花太多時間整理需求文件也是增加公司的工作成本，但是削減太多會造成無法充分了解客戶需求，尤其在多專案進入開發團隊時就會複雜，所以怎樣適當撰寫客戶需求文件但又不想影響整體專案品質，我將討論結果整理後與各位分享。( 這方式是以開發團隊是4-5人，每個專案需求數為100以內，作為基礎條件去思考整理)

我嘗試將之前在導入CMMI ML2【1】認證時與成大洪肇奎老師討論的需求追溯矩陣(RTM)【2】表作改良，用Execl表將第一頁籤作為客戶需求表(當成是原始客戶需求)，然後接下依序依照垂直追朔表產生不同頁籤來管理，因此順序如下：(共5頁籤)共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那個比較好，我都會簡單跟他說要用適合你公司文化的方法，請先了解你公司的需求先作落差分析來確認你公司的需求。=============================

補充資料與文獻說明

=============================

【1】CMMI (Capability Maturity Model® Integration，能力成熟度模式整合) 起源於美國國防部與卡內基美隆大學（Carnegie-Mellon University）合作所設立的軟體工程學院（Software Engineering Institute，SEI）

CMMI Ver 2.0成熟度第二級認證的實踐域 (PA)

-Governance (GOV) 治理

- Implementation Infrastructure (II)實施基礎條件

- Configuration Management (CM)建構管理(配置)

- Planning (PLAN)計畫(策畫)

- Process Quality Assurance (PQA)流程品質保證

- Requirements Development and Management (RDM)需求發展與管理

- Supplier Agreement Management (SAM)供應商管理

- Estimating (EST)估算

- Monitor and Control (MC)監控與控制

- Managing Performance and Measurement (MPM) 管理效能與度量

【2】需求追溯矩陣(Requireability Matrix，RTM)