有這麼一道pmp考試模擬題：
下列哪項說法不正確：
a.範圍蔓延是未經評估對時間和成本的影響就增加的功能或服務。
b.失控的變更通常指範圍蔓延。
c.範圍蔓延與功能需求的漸進明細沒有本質區別。
d.範圍蔓延並不一定總能提高客戶滿意度。
正確答案是c。
做軟體專案，特別管理軟體類的專案，客戶軟體需求的把握是一件十分重要且困難的事情。專案的需求很容易變更、蔓延。客戶開始的時候很難明確自己的需求，需求很難確認，確認後的需求也經常會發生變化，需求的變化極易引起專案成本的提高、進度的拖延、質量的風險。
因此而引發的對專案的後果，哪些是客戶的問題，哪些是服務方的問題，有很多說不清道不明。軟體服務方說「你需求不確定，我們不能開始開發。」，客戶說「我現在一開始不可能把需求都說清楚，你先這樣做，以後再完善。」；軟體做出來以後，客戶說做出來的東西和他們的需求不符，要改，軟體服務方說「你的需求變更了」，客戶說「我的需求沒有變，只是比以前細化了」。
這道pmp題所帶來的乙個啟發是，要與客戶建立起「範圍蔓延」與「漸進明細」的概念差異。在專案的「範圍管理」中：「範圍蔓延」與範圍的「漸進明細」是有本質區別的：
「漸進明細」是正常的，也就是說專案的範圍不可能在開始的時候就非常清晰，需要不斷地補充、細化、完善，這是客觀規律。
但「範圍蔓延」是不正常的，是危險的，是「未經評估對時間和成本的影響就增加的功能或服務」 （答案a），是「失控的變更」（答案b），這是專案實施過程中經常遇到的重要問題。
首先，由於需求是需要「漸進明細」的，所以專案中無法保證需求分析報告簽字確認後，一切的需求就鎖定了，客戶從本質上講也無法從實質上承擔此責任。但是要和客戶明確的是：哪些新提出的需求是屬於「漸進明細」的（以前沒說清楚，現在細化了），哪些是屬於「範圍蔓延」的（超出了原先的範圍框架），需要納入「需求變更」程式。
在現實專案中，這確實很難，太多的需求說不清楚。遇到這種問題，專案經理要和客戶充分溝通，只要能擺事實，講道理，是能夠達到雙贏效果的，絕大部分的客戶都是講道理的。關鍵在於事實怎麼擺？道理怎麼講？這就要考驗專案經理的業務能力（不僅能夠準確理解客戶原始需求，而且還要能想在客戶的前面）、技術能力、專案管理能力、以及溝通能力。
另外，專案經理一定要時刻警惕「範圍蔓延」問題，這是專案經理極其重要的職責！即使麻煩一點，也不要輕易答應客戶，切記「範圍蔓延並不一定總能提高客戶滿意度」（答案d）！因為客戶提出的需求或方案很有可能是錯誤的或不合適的，到時候再返工，不僅對於服務商來說成本代價很大，而且會嚴重拖延專案進度，對客戶也很不利。
當客戶提出屬於範圍蔓延的新需求時，一定要評估其對進度、成本與質量的影響（範圍、進度、成本、質量多重約束）；如果是較重大問題，一定要盡量走「正式」的變更流程，要通過包含客戶方和我方重要干係人在內的ccb（變更控制委員會）的審核。（按照「pmp主義」，所有的變更都要是正式的、書面的，雖然現實中很難做到這點，但這是方向）。
軟體選擇的起點 目的與需求
我們用軟體是為了實現某個目的 軟體也是工具，工具順不順手，對工具的要求就是我們的需求 挑選軟體前，應該羅列下需求，比如說想做筆記，那麼需求可能是 支援 markdown 支援實時渲染 能貼上軟體最好小巧些 支援全文搜尋 然後就可以朝著這幾點要求尋找平台能用的軟體了，最後還可以看下額外需求 軟體的選擇...
《軟體需求與分析》需要掌握的內容
今天閱讀了建民老師課件上提供的關於如何做需求分析的博文，下面把這篇博文的 一些重點總結一下。需求分析既是乙份體力活兒，更是乙份技術活兒，它既是人際交往的藝術，又是邏輯分析與嚴密思考的產物。作者給我們提出了幾個例子 第乙個故事講的是發生在東軟的事情，由於對客戶的需求了解不夠透徹最終導致了 整個這個專案...
論軟體工程需求的分類與獲取
摘要 在軟體工程的生命週期中，需求分析是很核心的一環，如果是自頂下上的設計，那麼它就是頂層的核心設計。軟體工程的過程中，不僅僅只有 編寫，明確需求，分析需求，是對產品目標的設計。當需求完整，準確，清晰，具體的時候，軟體的開發才可能事半功倍。那麼如何去獲取軟體需求，軟體需求又有哪些型別，這是我們要去 ...