需求工程(Requirements Engineering)是一種系統化的需求制定過程，該過程以不斷對問題進行分析、並將所獲結果以各種表達方式記錄成文件，同時查驗所瞭解事項是否正確，以定出相關的需求。

需求工程的重點在於掌握需要設計的事項，而非如何將需求事項設計出來，同時注意到未來的相關問題。在設計階段開始之前，一定有許多與未來狀況有關的知識必須要先掌握，包括未來的系統會長成什麼樣子等等。

換句話說，需求工程的重點是在於資訊的蒐集，以及各種可能方案的研析，以找出能滿足已知未來需求的設計。

----------------
引文:

請問什麼是軟體需求管理 ? 有沒有國際標準指導 ?

系統使用者的需求常常改變，當我們面對這種情況時，應採取怎樣的方式來管理需求 ?

請先進不吝賜教 !

一. 請問什麼是軟體需求管理 ?
RE: 軟體需求管理相關的主要工作有三項：
1. 需求分析與規格製作
2. 需求變更管理
3. 需求追溯管理

二. 有沒有國際標準指導 ?
RE: 國際標準指導與流程改善：
1. IEEE 830-1998 IEEE Recommended Practice for Software Requirements Specifications.
2. CMMI-SE/SW/IPPD/SS, V1.1 Requirements Development & Requirements Management.

三. 系統使用者的需求常常改變，當我們面對這種情況時，應採取怎樣的方式來管理需求 ?
RE: 必須建立軟體需求規格基準 (SRS Baseline)，相關步驟可採用 Best Practices，並參考 IEEE 830-1998 推薦實務與 CMMI RD & REQM 等流程領域。

@ 目前軟體品質協會也有開設相關課程，可作為進修參考。

兩年前我們公司為了突破營運瓶頸，採納了一位副總經理的建議，利用104分包委外網，一年內共篩選了九件小型軟體及軔體的委託設計案，透過我們公司在北京的一位朋友仲介，分別交給大陸的工程師或大學教授進行系統設計，本來認為這是一個很有希望的獲利模式，但結果竟然全部都失敗了，因為當初對每個專案的客戶需求都沒有仔細搞清楚，最後沒有一件設計完成的產品符合客戶的需求規格，只好依照合約退款甚至受罰，造成公司損失慘重，那位負責執行的副總經理也在去年一月就自己落跑了，下落不明。

公司終於恍然大悟：原來印度做國際軟體代工能夠成功，其實最重要的關鍵人物是負責「軟體需求分析與管理」和「驗證與確認」的人，台灣若想要和大陸仿效這種模式進行兩岸分工，也一定需要有這樣的人才，否則最後注定會失敗。

貴會程理事長5/11在中國時報「時論廣場」發表的文章，真是一針見血點出了台灣軟體「慘」業的問題核心，以上則是我們公司的慘痛經驗與教訓，願與大家分享，以做為呼應 !

在需求的分類中，有一種需求被歸類為Emergent Properties的需求，它不像一般的功能需求只靠系統中的單一元件(element)就可以滿足(如：新增一張訂單)。它是要靠系統中所有元件相互合作才能滿足，它極依賴系統的架構。當發現不能滿足那樣的需求時，為了達成目的常常要修改架構，甚至有時候要另起爐灶。

同樣的，『系統使用者的需求常常改變，當我們面對這種情況時，應採取怎樣的方式來管理需求 ?』這個問題要獲得解決，也不能只靠專案中的一個元件來解決。它的意思是我們不能只靠某個人(或一群人)在專案中的某個時點或某段時間，做一件事就能解決的。它必須依賴專案中的所有元件(專案成員與組織、工作流程、標準、合約…)等在需求管理的指導下相互配合，才有可能達成想要的目的。不是，在此三言兩語可以說清楚的。有興趣進一步了解，歡迎來參加協會舉辦的相課程，共同研究。

話說：想要做到由分屬不同的組織、身處不同地點與時間的人，共同成功地開發一套軟體系統，必須先要能夠做到在同一個辦公室一起工作的人員，不用口頭的方式溝通，而能把軟體完整而成功地開發出來。此處所指的“完整”意謂著，完成所有必要的軟體文件(包括：需求、設計、測試、使用手冊…等技術文件)。而“成功”的意涵則可暫時撇開“時間”與“成本”只談“品質”是否合乎需求。那個團隊真能做到這一點，就會知道如何在“時間”與“成本”的限制下去完成軟體專案。在此基礎下，才有可能做到以“異地分工”的方式開發軟體產品。否則，叫做“小孩玩大車危險啦！”。

個人淺見，僅供參考。

軟體品質協會專案管理師 周茂松 敬上

提供個人經驗如下：

1.系統上線之後將隨着硬體衰退以及軟體市場需求的遞變，經常會在Operation與Maintenance階段發生使用者(1)產生操作不方便(non-friendly)、(2)感覺準確度不足(insufficient accuracy)、(3)運算無法及時處理(non-real time)、(4)使用技能不足(skill level gap)、或維護者發現(5)零件消失造成修護不易(parts obsoleting)、(6)維修檢測不易(stupid test equipment)、(7)可靠度不佳(insufficient reliability)、(8)人力不足(insufficient human resource)、…等問題。管理單位一般處理方式可包括(a)加強訓練以改善操作熟練度、(b)更改操作程序、(c)調整系統任務配賦角色、(d)採購並更換系統。當發生(d)之情形，即進入買方的Acquisition Process，這也是一般對於系統發展或軟體發展最有興趣之部分。
2.但在進入Acquisition Process之前，事實上尚包括多項有關需求 (requirements)的釐清與分析程序，通常使用單位/操作單位需要以Mission Need Statement (SON)、Operational Requirement (ORD)、..等文件表述現有問題以及需要什麼性能與功能的需求（包含操作環境以及外部介面），也是所謂的requirements engineering中所謂的requirements elicitation程序；user表述之後，acquirer對於此等敘述或需求應進行分析，此包括成本、效益、可行方式、籌獲方式、技術分析、…等，即所謂的requirements analysis。可行requirements確定之後即進行functional analysis，應將此等requirements 配賦(allocated)到不同的function執行，如何再將function配賦(allocated)到不同的component或subsystem，即是承約商必需於PDR階段完成之事項。在RFP package中的specification，最基本的表達方式就是將functional requirement轉換為functional specification文件，即所謂的documentation程序，較佳的是寫成performance specification，但要避免採用撰寫“how to manufacture”的design specification格式。
3.Acquisition Process可以Contract Award點區分為Pre-acquisition與Post-acquisition。要執行Contract，就要有RFP之程序，RFP Package包含有三份基本文件(1)Specification、(2)Statement of Works (SOW)或Statement of Objects (SOO)、(3)Contract Data Requirements List (CDRL)、以及以下幾項補充資訊(4)Contract Schedule、(5)保密切結書（視需要）、(6)Program WBS （Down to Level-3），前三份資料（僅敘述“what”，其中specification用以表示涵蓋硬體與軟體的“goods”，SOW用以表示“service”，將要買的實體物件與服務分開敘述），將組合出合約應完成的Products與Procedures；賣方競標(bids)的Cost Proposal或CWBS即依據此三份文件逐項報價。其中的Specification即是籌獲者（acquirer）依據SON與ORD轉換為Technical Requirements，此部份可稱之為requirements generating system。
4.RFP內容即涵蓋全部requirements，在前述 “1”-(1)至(8)舉例的情形即所謂的User Needs，通常可以由SON與ORD文件敘述，所敘述的內容可包括Functions to be performed (what)、Performance required (how well)、Essential physical characteristics (environmental/interfaces)；Acquirer或PM在收到有關Requirements的Statements of Needs即可進行Requirements Analysis動作，可大致包括What does the yet to be identified item have to do? 、How well does it have to do it? 、Where will it be used? 、Under what conditions will it be used? 、How often? How long? 、Who will use it? 、When is it needed? 、How many are needed? ，即所謂的requirements validation；此等問題澄清之後即可以撰寫Specification。以Performance Specification而言，其用意應將“Operational Requirements”轉換為承約商可以執行的“Technical language”且以定量方式敘述而非定性方式敘述，文件中應包括未來所交付產品相關性能的條件（results）、可承受之環境條件（operational environment condition）、以及買方決定允收（verify compliance）之方法。
5.簽約之後可舉行System Requirement Review (SRR)，SRR係用以確認承約商確實了解買方之Specification、SOW、SOO、Contract Schedule、… 等需求，以避免日後賣方交出不是買方所需要的系統。
6.RFP package能否涵蓋SON與ORD事項，acquirer即應採用traceability方式表達、若有需求變更即應依循configuration management程序提出change request，即所謂的requirements management。
7.需求訂定不完整、不正確、或不可行，將會有5-50倍的cost-to-fix之penalty。