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

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

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

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

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

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

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