項目管理的范圍通俗的說是項目的實施邊界,邊界以里的歸項目管理,以外的不屬于項目.軟件需求是指軟件實現(xiàn)的功能,操作的方便性能、兼容性和可擴展性

通過需求開發(fā)來獲取信息系統(tǒng)項目的需求，在此基礎上確定項目的范圍、進行項目范圍管理。確定每一期應滿足的需求后，該期的范圍管理就有了基礎。需求管理處理需求的變更，需求的變更會引起項目范圍的變更。

在講述項目管理課程的時候，歸納出一個比喻：
需求是回答為什么要進行這個項目
范圍是回答，項目需要完成什么才能滿足需求。這里僅僅是指產(chǎn)品范圍，也就是最后的可交付物。
如果我們把范圍擴展到工作范圍的話，則是在做什么工作能夠完成產(chǎn)品范圍，滿足需求
質量則是回答：產(chǎn)品應該達到什么要求
成本和時間則是回答完成工作的效率
這里面闡述了需求，范圍，質量，時間和成本之間的關系。國內(nèi)的論述鮮有提及。大多只在時間，成本和質量之間討論。這可能是傳統(tǒng)項目領域的限制，因為那些建筑工程類項目大都是需求明確，范圍清晰的，項目經(jīng)理的精力則主要和實施效率上作斗爭。所以所謂的項目約束條件也僅僅在質量與時間和成本之間尋求平衡?？纯错椖抗芾淼慕炭茣?，翻譯加摘抄的思維定式也就不會有人去關注效果和效率之間的關系了。

但我在實施軟件和IT類項目多年的經(jīng)驗來看，傳統(tǒng)項目管理所關注的效率因素并不能解決軟件項目的真正難點，也就是所謂效果目標。但凡一個項目啟動，其目的不是說客戶點名要什么產(chǎn)品，而是需要利用某個產(chǎn)品來解決自身的問題。而這里所謂要解決的問題就是“客戶需求”。而能夠解決問題的產(chǎn)品就被定義在產(chǎn)品規(guī)格，也就是Product Specification當中。項目的起因顯然來自需求，但是項目工作本身卻起始于產(chǎn)品范圍的界定，也就是規(guī)格。

在需求工程中有一句話：“客戶需求不是客戶所說的”。這句話仔細研究起來，也對，也不對。說對，是因為和客戶的溝通是獲取需求的重要根源，你不聽取客戶的意見如何了解需求信息。說它不對，是因為大多數(shù)客戶和技術人員交流時會陷入到直接定義產(chǎn)品功能和規(guī)格上去。也就是客戶并不是直接表述“我的需求是什么”，而是“我要的是什么”。這就提早了需求到規(guī)格之間的轉化。但問題的關鍵是這個轉化往往是錯誤的，因為溝通的雙方都不是對方領域的專家。這個轉化做的越早越快，越容易出錯。這個錯誤往往會在最后交付階段才會被發(fā)現(xiàn)。因為它不是功能錯誤和缺陷，它是做錯了功能。

既然雙方都不是對方領域的專家，由哪一方完成了。我們只能說這個時候由技術實現(xiàn)方來完成更好。因為畢竟后續(xù)的大量工作是由實現(xiàn)方完成的，讓他們掌握的更全面將會更有利于項目的完成。所以，需求的收集和開發(fā)工作就是這類型項目的第一個重要工作。需求收集的方法很多，這里給出一個判據(jù)，也就是通過需求收集的目的和結果來判斷其工作是否到位。如果工作結果是：客戶想要什么產(chǎn)品，說明結果是錯誤的。如果工作結果是回答：客戶用我們的產(chǎn)品來解決什么問題，則是正確的。從這一點上，用例是一個不錯的需求收集和記錄的工具。

需求收集工作完成之后，才開始定義產(chǎn)品規(guī)格，其目的是滿足客戶需求。我們可以說傳統(tǒng)的需求分析工作目的就是定義項目的產(chǎn)品范圍。而后的工作分解結構就是將產(chǎn)品范圍進行任務分解。