需求開發沒有做好會出現什麼後果？需求問題的代價？需求分析如何做？為什麼要做？
首先來看下需求問題產生的代價模型：
一、需求問題的代價
通過圖形可以看出，在需求階段消除問題的代價最小，而如果需求問題等到產品發布出去後才發現的話，那修復的成本就會
n倍的增加。
不合格的需求分析：
1、 沒有足夠的使用者參與；
2、 忽略了使用者分類；
3、 模稜兩可的需求；
4、 不必要的特性；
5、 自我猜測的需求；
6、 過於簡單的規格說明；
7、 使用者需求的不斷增加；
不合格的需求很多很多，很難說出所有，但需求分析沒有做肯定會有影響。
需求沒有做好的後果一般會有下列現象：
1、 浪費時間和資源來滿足使用者並不需要的需求（過度實現一些功能）；
2、 開發出來的產品技術上先進，但不滿足使用者需求；
3、 總是需要比較長的時間來達成對產品設計的共識；
4、 在產品設計，開發和測試工作中對於使用者需求的解釋不一致；
5、 員工會厭倦因需求不斷被重新解釋而導致的返工；
6、 未說明的或不正確的需求會導致員工與使用者間的不滿；
7、 不穩定的產品，使用者的不滿意對我們未來的市場造成損失；
8、 浪費時間，增加成本，使得在一些投標的專案中不能低價；
從上面2方面可以看出，需求沒有做好，對後續產品來說是巨大的災害，也可以說需求是源頭，也是站在統領的位置上，那麼如何來做好需求分析這塊呢？首先了解下，為什麼要做需求分析，什麼是需求分析，需求分析有哪些方面。
為什麼要做需求分析，從上面
2個方面就可以看出做好需求分析的必要性，再具體一點：
1、 「決策性」——要不要做這個產品，通過對市場需求的分析來決策專案是否需要立項；
2、 「方向性」——良好的需求分析可以對專案人員明確方向，讓專案成員知道下面應該如何實施；
3、 「策略性」——
既然知道了為什麼要做需求分析，就需要了解什麼是需求分析，及如何做。需求分析並不是簡單的對與錯，比如說做乙個產品，「做技術最先進的軟體，還是做最好賣的軟體」，這個需求有錯嗎，沒有，只能說需要從不同的地方去考慮，去定位。
「 需求分析」不代表「使用者要求什麼就是什麼」也不代表「我們能做什麼就做什麼」，做為需求人員，在進行需求分析的時候，首先應該明白使用者的需求，然後再加上 自己的分析處理過程，知道哪些我們現在能做，哪些我們做不了，哪些我們咬咬牙齒能做，需求人員在做需求分析的時候不能一味的成為客戶的傳話筒，要有自己的 分析。
在「需求分析」中一般可以從三個方面去考慮：
1、 功能需求——產品應該完成哪些功能，即向使用者提供的功能，一般來說這個都是比較硬性的標準；
2、 非 功能性需求——使用者可能不能明確告訴你的一些需求，比如說效能達到什麼要求，可靠性方面，響應時間，擴充套件性，效能方面等，這塊的內容並不是說使用者需要，而 是說不知道需要做成什麼樣的，我們不能不做，做了只會對自己受益。要不然等到後期使用者使用感覺這慢，那不爽，那倒霉的還是是自己。
3、 一些約束——在需求分析中需要考慮一些條件約束，規則等，比如客戶的約束，行業的約束，法律的約束以及自己的約束等，這些都需要在需求分析考慮清楚，要不然做出一款白人狂毆黑人的遊戲給黑人玩，那就慘了，，，
需求——就是抓住使用者「真正」的需求，抓住使用者群真正的「需求」。
分析——就是分析一大幫人的行為習慣，然後由需求人員來總結歸納。
《需求管理》系列之二需求定義 表達與組織
描述使用者的某個需求看似一件簡單易做的事情，感覺上只需要指出使用者想要幹什麼，系統能夠提供什麼就可以了，實則不然。比如，使用者在商品建檔時有如下需求 使用者可以臨時調整商品的 其規則是 使用者申請對某個商品臨時調價，並設定臨時 啟用期的起止日期，臨時調價審批通過後，在該臨 啟用期內系統按臨時 開單銷...
02軟體需求之二
今天是第二次讀軟體需求這本書，經過上次的閱讀，我知道了軟體需求的三個層次，分別是 業務，使用者和功能。在專案中它們在不同的時間來自不同的 也有著不同的目標和物件，並需以不同的方式編寫成文件。業務需求不應包括使用者需求，而所有的功能需求都應該源於使用者需求。同時你也需要獲取非功能需求，如質量屬性。那麼...
《軟體需求》閱讀筆記之二
這次閱讀的這本書的第二部分。第二部分講述了軟體需求的步驟，以及文件的內容。首先是專案檢視與範圍文件，這就需要通過業務需求來確立，確立了範圍之後就不要 超出這個範圍，如果超出了就會可能變成使用者不喜歡的累贅，進而可能導致了這款軟體 的失敗。其次是尋找客戶的需求，針對這一點我們需要尋找使用者代表，確立典...