需求實踐中的種種不足會給專案的成功帶來很多風險。
如使用者參與不足：客戶常常不能理解為什麼必須下這麼大力氣去收集需求和保證需求質量。開發人員往往也不重視使用者的參與，原因是自己以為已經知道了使用者想要什麼，這就是使用者心中所想與開發人員心中所想產生偏差，從而影響專案的成功。
使用者需求拓展：由於開發過程中需求的不斷發展與增加，專案往往會落後於計畫的進度並超出預算。出現這種情況是因為沒有依據對需求的規模和複雜度的實際評估來制定計畫，而不斷修改需求來是情況變得更糟。問題的責任部分在於使用者不斷提出修改需求的要求，部分在於開發人員處理這種要求的方式。
有歧義的需求：歧義是需求規約的大忌。歧義表現為同一讀者對同一項需求宣告作出多種解釋，或者不同的讀者對同一需求產生不同的理解。
過於抽象的需求：營銷人員或者經理經常喜歡只給出乙個粗略的說明，他們希望開發人員在開發過程中充實他，這種方式對研究性專案或需求特別靈活的專案也許管用，但是需要緊密合作的團隊，而且緊限於開發小型系統。大多數情況下，這種做法的結果是使開發人員受挫，讓客戶失望。
忽略某類使用者：使用者所使用的產品特性，產品的使用頻率以及使用者自身的經驗水平不盡相同。因此，多數產品都擁有不同的使用者群。如果一開始沒能找出產品的所有重要使用者群，就會有某些使用者需求得不到滿足。確定所有使用者群後，還要保證獲得各類使用者的需求。
《軟體需求》讀後感05
自從上一次發表讀書筆記已經有一段時間了。第10章畫圖工具目前我使用的是visio，與之前用wps畫圖感到比較明顯的就是，以前用wps畫還得考慮邊界大小和改變填充等，通過visio可以畫各種各樣的圖並且不會出現邏輯的錯誤，修改起來也比較麻煩。關於建立類圖 1確定類 概念類，我們需要區分不同的類哪些是無...
《軟體需求》讀後感04
今天閱讀了第二部分的第8章後部分，第9章和第10章 聆聽客戶的意見，編寫需求文件，需求的圖形化分析。需求分析的定位是做什麼而不是怎麼做，例項圖是具有功能性質的，不宜太多或者太細。在第9章學習中，需求文件應該是由形式化，結構化，陳訴一致的樣式，確定的態度，定量化，言簡意賅的自然語言 使用者術語 編寫，...
《軟體需求》讀後感01
今天閱讀了第一部分的前三章 是什麼為什麼，客戶需求觀，需求工程的推薦方法 感悟深刻的是 參與度 要做乙個專案，就得明白給誰做做什麼，也就是這個專案的需求。需求是不同類的使用者所不同的，所以我們需要針對不同類的使用者獲取需求，這就需要不同類的使用者參與。當我們在獲取需求時，要判斷哪些是我們能做的拿些不...