作者：台灣應用軟件股份有限公司 譚泉清 顧問
接續上篇，在本文中我們將探討什麼是ReqM？軟體工程的需求與程序要如何界定與執行？
ReqM是什麼？
在談ReqM之前我想首先我們應該要談談下列一些主題：
什麼是需求？一般有三種說法，如后：
- 所謂需求可以是當客戶要求我們建立一個系統時，客戶對該系統應該或可能要完成哪些事情已經有一些想法！(這就是需求)。
- 凡是系統均應有一個目的！(這就是需求)。
- 所謂需求(Requirement)就是對目標系統之容貌的一種描述或是為了達成系統目的而應具備之功能的敘述。
多年來軟體工程中需求均是以自然語言來表達，但是以自然語言來表達需求，似乎在不同當事人解讀時會產生不同之感受或定義，如「可用性」之定義就有許多不同之見解，再說需求不見得能夠根據它所涉及之系統元素來抽離與描述，所以軟體工程中就研究並提供一些方法來協助我們將需求用較嚴謹與易掌握之形式來定義需求。
若一個系統應該能由一組完整的需求定義所組成，故需求應該要描述到系統的所有部份包括實體、長相、關聯與進入、經過、離開系統會發生什麼事，所以需求定義是用來指出系統之目的，而不必考慮到如何來製作系統，也就是說不應該有：用哪種語言來開發、要多少錢、用哪種DBMS等字眼出現於需求定義(除非客戶指定)。
為配合ReqM之特定執行方法之要求，筆者建議需求管理流程可以考慮十個步驟如表三所列：
NO |
步驟
|
內容
|
| |
接受需求
|
|
| |
登錄需求
|
|
| |
瞭解需求
|
|
| |
審查與承諾
|
- 技術評估需求之可達成性
- 評估需求處理之時程與成本
- 需求排程
|
| |
確認需求
|
|
| |
管制需求變更
|
|
| |
登錄及追蹤需求
|
- 正式登錄已確認之需求
- 記錄需求變更資料
- 追蹤需求處理情形
|
| |
建立追溯性
|
|
| |
變更計畫
|
- 鑑定計畫與產品之變更範圍及變更方式
- 變更計畫(包含上線計畫)
|
| |
開發或修改軟體
|
- 依需求內容修改產品，並變更相關文件。
- 建立產品需求與產品設計之追溯性
|
表三 建議之需求管理流程
為配合ReqM之特定執行方法之要求，筆者建議找出客戶需求之流程亦可以考慮十個步驟如圖三所列：
圖三 建議找出客戶需求之流程
我們知道專案計畫是為滿足客戶需求 (技術性需求與非技術性需求)而存在，需求管理之目的就應是管理所有專案內之各個階段所發生之需求，故應於專案內，妥善對需求管理、需求發展、技術性解決方案作一整合，所以組織對於專案發展中之需求管理，應訂定一適當之管理原則，以確保客戶之需求能獲得滿足。
有關需求管理在國際標準上亦可以找到許多資料，筆者僅將一些常用之國際標準彙整於表四，供讀者參考：
IEEE Std 830
(1998) |
IEEE Recommended Practice for software requirements specification (SRS)
|
|
IEEE Std 1062
(1998)
|
IEEE Recommended Practice for S/W Acquisition.
|
|
IEEE Std 1233
(1998)
|
Guide for Developments System Requirements Specification.
|
|
ISO/IEC 12207
(1995)
|
S/W life cycle process Chapter 5.1 Acquisition OP.
|
表四 有關需求管理一些常用之國際標準
根據IEEE Std 830(1998)SRS國際標準之一個好的需求通常具備以下條件：
| |
清晰而適當地表達
|
| |
完整
|
| |
相互一致
|
| |
能被個別界定
|
| |
能被適當地實行
|
| |
能被驗證(例如能被測試)
|
| |
具備追溯性
|
根據IEEE Std 830(1998)國際標準建議有關軟體需求規格書之SRS架構：
表五 國際標準建議有關軟體需求規格書之SRS架構
- Std 1062建議獲取優良軟體(quality software)的九個步驟
|
步驟
|
步驟內容
|
|
步驟1：規劃組織策略。
|
審查獲取者的目標，以及訂定軟體獲取策略。
|
|
步驟2：實作組織過程。
|
建立符合組織取得優良軟體產品之需要的軟體獲取過程。此步驟包括適切的合約作業常規。
|
|
步驟3：決定軟體需求。
|
定義將獲取的軟體，以及準備驗收供應者所提供之軟體 的品質與維護規畫。
|
|
步驟4：鑑別可能的供應者。
|
選擇可以提供其軟體的文件、展示其軟體、以及提供正式建議書的可能候選供應商。無法執行這些動作中的任何一項，是將之排除在可能候選供應者之外的基礎。自先前的合約中，審查供應者的績效資料。
|
|
步驟5：準備合約需求。
|
從可接受之績效及驗收準則的角度，去描述應執行之工作的品質，以及研擬交付項目與支付款項關係的合約條款。與法務人員共同審查合約。
|
|
步驟6：評估建議書，以及挑選供應者。
|
評估供應者的建議書，挑選符合資格的供應者，以及磋商合約。必要時與可替代的供應者磋商。
|
|
步驟7：管理供應者的績效。
|
監視供應者的進度，以確保所有的里程碑均被達成，並且核准工作片斷。必要時，提供所有的交付項目給供應者。
|
|
步驟8：驗收軟體。
|
執行充分的測試，並建立所有差異已經矯正，以及所有驗收準則均已被滿足的認證過程。
|
|
步驟9：使用軟體。
|
舉行軟體獲取合約的後續分析，以評估合約作業的常規、記錄經驗教訓、以及評估使用者對產品的滿意度。保留供應者的績效資料。
|
表六 有關Std 1062建議獲取優良軟體(quality software)的九個步驟
ISO/IEC 12207中將需求區分為5.1獲得(即需求方)與5.2供給(即供應方)兩種，如圖四。
圖四 ISO/IEC 12207中將需求區分為5.1獲得與5.2供給兩種