① 市場營銷學的市場需求預測方法有哪些
轉載以下資料供參考
要搞好預測，必須把握預測的四個基本要素：
信息
信息是客觀事物特性和變化的表徵和反映，存在於各類載體，是預測的主要工作對象、工作基礎和成果反映。
方法
方法是指在預測的過程中進行質和量的分析時所採用的各種手段。預測的方法按照不同的標准可以分成不同的類別。按照預測結果屬性可以分為定性預測和定量預測，按照預測時間長短的不同，可以分為長期預測、中期預測和短期預測。按照方法本身，更可以分成眾多的類別，最基本的是模型預測和非模型預測。
分析
分析是根據有關理論所進行的思維研究活動。根據預測方法得出預測結論之後，還必須進行兩個方面的分析：一是在理論上要分析預測結果是否符合經濟理論和統計分析的條件；二是在實踐上對預測誤差進行精確性分析，並對預測結果的可靠性進行評價。
判斷
對預測結果採用與否，或對預測結果依據相關經濟和市場動態所作的修正需要判斷，同時對信息資料、預測方法的選擇也需要判斷。判斷是預測技術中重要的因素。
預測應該遵循一定的程序和步驟以使工作有序化、統籌規劃和協作。市場預測的過程大致包含以下的步驟：
確定預測目標
明確目的，是開展市場預測工作的第一步，因為預測的目的不同，預測的內容和項目、所需要的資料和所運用的方法都會有所不同。明確預測目標，就是根據經營活動存在的問題，擬定預測的項目，制定預測工作計劃，編制預算，調配力量，組織實施，以保證市場預測工作有計劃、有節奏地進行。
搜集資料
進行市場預測必須佔有充分的資料。有了充分的資料，才能為市場預測提供進行分析、判斷的可靠依據。在市場預測計劃的指導下，調查和搜集預測有關資料是進行市場預測的重要一環，也是預測的基礎性工作。
選擇預測方法
根據預測的目標以及各種預測方法的適用條件和性能，選擇出合適的預測方法。有時可以運用多種預測方法來預測同一目標。預測方法的選用是否恰當，將直接影響到預測的精確性和可靠性。運用預測方法的核心是建立描述、概括研究對象特徵和變化規律的模型，根據模型進行計算或者處理，即可得到預測結果。
預測分析和修正
分析判斷是對調查搜集的資料進行綜合分析，並通過判斷、推理，使感性認識上升為理性認識，從事物的現象深入到事物的本質，從而預計市場未來的發展變化趨勢。在分析評判的基礎上，通常還要根據最新信息對原預測結果進行評估和修正。
編寫預測報告
預測報告應該概括預測研究的主要活動過程，包括預測目標、預測對象及有關因素的分析結論、主要資料和數據，預測方法的選擇和模型的建立，以及對預測結論的評估、分析和修正等等。
② 市場營銷環境分析內容和方法有哪些
市場營銷環境分析常用的方法為SWOT法，它是(優勢)、(劣勢)、(機會)、(威脅)的意思。 具體內容如下：
(一)外部環境分析（機會與威脅）
環境機會的實質是指市場上存在著「未滿足的需求」。它即可能來源於宏觀環境也可能來源於微觀環境。隨著消費者需求不斷變化和產品壽命周期的縮短，引起舊產品的不斷被淘汰、要求開發新產品來滿足消費者的需求，從而市場上出現了許多新的機會。
環境機會對不同企業是不相等的，同一個環境機會對這一些企業可能成為有利的機會，而對另一些企業可能就造成威脅。環境機會能否成為企業的機會，要看此環境機會是否與企業目標、資源及任務相一致，企業利用此環境機會能否比其競爭者帶來更大的利益。
環境威脅是指對企業營銷活動不利或限制企業營銷活動發展的因素。這種環境威脅，主要來自兩方面：一方面，是環境因素直接威脅著企業的營銷活動，如政府頒布某種法律，它對造成環境污染的企業來說，就構成了巨大的威脅；另一方面，企業的目標、任務及資源同環境機會相矛盾。
（二）內部環境分析（優勢/劣勢分析）
識別環境中有吸引力的機會是一回事，擁有在機會中成功所必需的競爭能力是另一回事。每個企業都要定期檢查自己的優勢與劣勢，這可通過「營銷備忘錄優勢／劣勢績效分析檢查表」的方式進行。管理當局或企業外的咨詢機構都可利用這一格式檢查企業的營銷、財務、製造和組織能力。每一要素都要按照特強、稍強、中等、稍弱或特弱劃分等級。
很清楚，公司不應去糾正它的所有劣勢，也不是對其優勢不加利用。主要的問題是公司應研究，它究竟是應只局限在已擁有優勢的機會中，還是去獲取和發展一些優勢以找到更好的機會。 有時，企業發展慢並非因為其各部門缺乏優勢，而是因為它們不能很好地協調配合。因此，評估內部各部門的工作關系作為一項內部審計工作是非常重要的。
③ 需求分析常用方法
行為事件分析
行為事件分析是根據運營關鍵指標對用戶特定事件進行分析。通過追蹤或記錄用戶行為事件，可以快速的了解到事件的趨勢走向和用戶的完成情況。
以用戶投標的行為事件為例，出借人在完成投標過程中，所進行的注冊、認證、開戶、充值、投資等行為，都可以定義為事件，也是完成投標成功的一個完整事件。
確定投標行為事件後，我們可以根據事件屬性細分維度：用戶來源、性別、出生年月、注冊時間、綁卡時間、首次充值時間、首次投資時間、標的ID，標名、期限、利率、還款方式等。然後從中找出符合指標的規律，並制定針對性的措施。
用戶留存分析
用戶留存分析是一種用來分析用戶參與情況與活躍程度的模型。通過留存量和留存率，可以了解用戶的留存和流失狀況。比如用次日留存、周留存、月留存等指標來衡量產品的人氣或粘度。以渠道訪問的用戶留存為例，我們對APP端有過訪問行為的渠道用戶進行留存分析。用戶留存一般符合40-20-10法則，即新用戶的次日留存應該大於40%，周留存大於20%，月留存大於10%才符合業務標准。我們做用戶留存分析主要驗證是否達到既定的運營目標，進而影響下一步的產品決策。
漏斗模型分析
漏斗模型分析是用戶在使用產品過程中，描述各個階段中關鍵環節的用戶轉化和流失率情況。比如在日常活動運營中，通過確定各個環節的流失率，分析用戶怎麼流失、為什麼流失、在哪裡流失。找到需要改進的環節，要重點關注，並採取有效的措施來提升整體轉化率。
邀請人將活動專題頁分享給好友，之後進行的注冊、認證、開戶、充值到投資，用漏斗模型分析一些關鍵節點的轉化率。其中用戶注冊轉化率為68%，實名認證轉化率為45%，綁卡開戶轉化率為29%，線上充值轉化率為17%，投資標的轉化率為8%。
漏斗模型分析可以驗證整個流程的設計是否合理。經過對比發現，訪問到注冊的轉化率為68%，遠低於預期的80%。這次運營策略是用戶必須先注冊才能領取新手福利。之後採取A/B測試的方式，優化為先領取新手福利再誘導用戶注冊。經過數據對比分析，注冊轉化率提升了20%。因此，通過對各環節相關轉化率的比較，可以發現運營活動中哪些環節的轉化率沒有達到預期指標，從而發現問題所在，並找到優化方向。
行為路徑分析
行為路徑分析就是分析用戶在產品使用過程中的訪問路徑。通過對行為路徑的數據分析，可以發現用戶最常用的功能和使用路徑。並從頁面的多維度分析，追蹤用戶轉化路徑，提升產品用戶體驗。
不管是產品冷啟動，還是日常活動營銷，做行為路徑分析首先要梳理用戶行為軌跡。用戶行為軌跡包括認知、熟悉、試用、使用到忠誠等。軌跡背後反映的是用戶特徵，這些特徵對產品運營有重要的參考價值。我們可以記錄用戶從注冊、認證、開戶、充值到投資的行為軌跡。通過分析用戶的這些行為軌跡數據，來驗證訪問路徑是否和預期指標的一致。
④ 需求分析方法主要包括哪些
結構化的分析方法是傳統的分析法，它的好處是在需求階段可以不需要精確地定義系統，只需要根據業務框架確定系統的功能范圍，以及每個功能的處理邏輯和業務規則，功能需求規格書等。因為不需要精確描述，因此描述系統的方式比較靈活多樣，可以採用圖表、示例圖、文字等等方式來描述系統。在系統開發以前，一般還可以採用更為直觀的原型系統方式和最終用戶進行交流和確認，因此對業務需求的要求會低一些，業務需求階段的周期相對容易控制；通過業務全景圖，最終用戶也能了解系統的功能；通過功能活動圖和業務規則的描述，也可以相對精確地描述業務系統；因為沒有嚴格的標記語言，可以採用適當的篇幅描述適當的系統。當然，這種方法的缺點也是明顯的，分析人員和業務人員之間可能缺乏共同語言，機器不能識別業務需求書，在設計階段還需要繼續和用戶確認一部分功能。
面向對象的分析方法的最大好處是在需求階段，就能夠非常精確地描述一個系統，採用程序語言的方式和最終用戶交流（最終用戶必須要熟悉這種語言），能夠在項目一開始就發現很多問題，避免在開發的過程中出現需求的反復，而且在系統設計和開發階段不需要最終用戶參與。在實施上，一般可以採用場景、業務功能等方式來描述，比較適合於業務流程環節多的系統，或者軟體產品的開發。但是，我們也要看到，在現實中，絕大多數的應用系統都很難在需求階段就可以被精確地抽象化定義，所以這種方法的缺點和困難也是顯而易見的：首先，用戶要非常清楚地知道最終的業務系統應該是什麼樣，或者採用一種抽象的方式能夠確定最終的應用系統；其次，因為最終用戶不需要參與設計和開發階段的工作，所以雙方確定業務需求的過程也會比較長；同時，因為是精確描述，因此描述系統的語言是非常邏輯化的，一般通過某種方式可以使機器識別業務需求，採用這種方式寫的業務需求是非常格式化的，一方面描述一個系統需要的信息非常多，可能使需求說明的篇幅非常長，不便於理解和閱讀；另外由於通過抽象的方式來推演最終系統的運行方式，對業務人員的要求非常高。
⑤ 市場營銷需求分析有哪些理論
1、馬斯洛理論把需求分成生理需求、 安全需求、 歸屬與愛的需求、回 尊重需求和自我實答現需求五類， 依次由較低層次到較高層次排列。
2、消費者購買行為模式之黑箱理論。打開「購買者黑箱引出需要的需要, 渴了會產生對水的需要等等, 也有外在的刺激, 如看到某人穿著非常漂亮得體的服裝, 消費者也會對這種服裝產生希望擁有的慾望, 從而產生購買行為。
3、4Cs營銷理論。
4C（Customer、Cost、Convenience、Communication）營銷理論以消費者需求為導向，重新設定了市場營銷組合的四個基本要素：瞄準消費者的需求和期望（Customer）。
⑥ 做營銷，你會分析用戶需求嗎
會的
⑦ 需求分析有哪些方法
三種需求分析的方法：結構化分析方法、面向對象的分析方法、面向問題域的分析方法。
結構化的分析方法是傳統的分析法，它的好處是在需求階段可以不需要精確地定義系統，只需要根據業務框架確定系統的功能范圍，以及每個功能的處理邏輯和業務規則，功能需求規格書等。因為不需要精確描述，因此描述系統的方式比較靈活多樣，可以採用圖表、示例圖、文字等等方式來描述系統。在系統開發以前，一般還可以採用更為直觀的原型系統方式和最終用戶進行交流和確認，因此對業務需求的要求會低一些，業務需求階段的周期相對容易控制；通過業務全景圖，最終用戶也能了解系統的功能；通過功能活動圖和業務規則的描述，也可以相對精確地描述業務系統；因為沒有嚴格的標記語言，可以採用適當的篇幅描述適當的系統。當然，這種方法的缺點也是明顯的，分析人員和業務人員之間可能缺乏共同語言，機器不能識別業務需求書，在設計階段還需要繼續和用戶確認一部分功能。
面向對象的分析方法的最大好處是在需求階段，就能夠非常精確地描述一個系統，採用程序語言的方式和最終用戶交流（最終用戶必須要熟悉這種語言），能夠在項目一開始就發現很多問題，避免在開發的過程中出現需求的反復，而且在系統設計和開發階段不需要最終用戶參與。在實施上，一般可以採用場景、業務功能等方式來描述，比較適合於業務流程環節多的系統，或者軟體產品的開發。但是，我們也要看到，在現實中，絕大多數的應用系統都很難在需求階段就可以被精確地抽象化定義，所以這種方法的缺點和困難也是顯而易見的：首先，用戶要非常清楚地知道最終的業務系統應該是什麼樣，或者採用一種抽象的方式能夠確定最終的應用系統；其次，因為最終用戶不需要參與設計和開發階段的工作，所以雙方確定業務需求的過程也會比較長；同時，因為是精確描述，因此描述系統的語言是非常邏輯化的，一般通過某種方式可以使機器識別業務需求，採用這種方式寫的業務需求是非常格式化的，一方面描述一個系統需要的信息非常多，可能使需求說明的篇幅非常長，不便於理解和閱讀；另外由於通過抽象的方式來推演最終系統的運行方式，對業務人員的要求非常高。
⑧ 需求分析怎麼做
10月22日 10:37 盡量把客戶所持的假設解釋清楚，特別是那些發生沖突的部分。從字里行間去理解以明確客戶沒有表達清楚但又想加入的特性或特徵。Gause 和Weinberg（1989）提出使用「上下文無關問題」—這是一個高層次的問題，它可以獲取業務問題和可能的解決方案的全部信息。客戶對這些問題的回答諸如「產品要求怎樣的精確度」或「你能幫我解釋一下你為什麼不同意某人的回答嗎？」這些回答可以更直接地認識問題，而這是封閉（close-end）問題所不能做到的。
需求獲取利用了所有可用的信息來源，這些信息描述了問題域或在軟體解決方案中合理的特性。一個研究表明：比起不成功的項目，一個成功的項目在開發者和客戶之間採用了更多的交流方式（Kiel and Carmel 1995）。與單個客戶或潛在的用戶組一起座談，對於業務軟體包或信息管理系統（MIS）的應用來說是一種傳統的需求來源。直接聘請用戶進行獲取需求的過程是為項目獲得支持和買入（buy-in）的一種方式。
盡量理解用戶用於表述他們需求的思維過程。充分研究用戶執行任務時作出決策的過程，並提取出潛在的邏輯關系。流程圖和決策樹是描述這些邏輯決策途徑的好方法。
在需求獲取的過程中，你可能會發現對項目范圍的定義存在誤差，不是太大就是太小。如果范圍太大，你將要收集比真正需要更多的需求，以傳遞足夠的業務和客戶的值，此時獲取過程將會拖延。如果項目范圍太小，那麼客戶將會提出很重要的但又在當前產品范圍之外的需求。當前的范圍太小，以致不能提供一個令人滿意的產品。需求的獲取將導致修改項目的范圍和任務，但作出這樣具有深遠影響的改變，一定要小心謹慎。
正如經常所說的，需求主要是關於系統做什麼，而解決方案如何實現是屬於設計的范圍。這樣說雖然很簡潔，但似乎過於簡單化。需求的獲取應該把重點放在「做什麼」上，但在分析和設計之間還是存在一定的距離。你可以使用假設「怎麼做」來分類並改善你對用戶需求的理解。在需求的獲取過程中，分析模型、屏幕圖形和原型可以使概念表達得更加清楚，然後提供一個尋找錯誤和遺漏的辦法。把你在需求開發階段所形成的模型和屏幕效果看成是方便高效交流的概念性建議，而不應該看成是對設計者選擇的一種限制。
需求獲取討論會中如果參與者過多，就會減慢進度。人數大致控制在5到7人是最好的。這些人包括客戶、系統設計者、開發者和可視化設計者等主要工程角色。相反地，從極少的代表那裡收集信息或者只聽到呼聲最高、最有輿論影響的用戶的聲音，也會造成問題。這將導致忽視特定用戶類的重要的需求，或者其需求不能代表絕大多數用戶的需要。最好的權衡在於選擇一些授權為他們的用戶類發言的產品代表者，他們也被同組用戶類的其它代表所支持。
沒有一個簡單、清楚的信號暗示你什麼時候已完成需求獲取。當客戶和開發者與他們的同事聊天、閱讀工業和商業上的文獻及在早上沐浴時思考時，他們都將對潛在產品產生新的構思。你不可能全面收集需求，但是下列的提示將會暗示你在需求獲取的過程中的返回點。
1. 如果用戶不能想出更多的使用實例，也許你就完成了收集需求的工作。用戶總是按其重要性的順序來確定使用實例的。
2. 如果用戶提出新的使用實例，但你可以從其它使用實例的相關功能需求中獲得這些新的使用實例，這時也許你就完成了收集需求的工作。這些新的使用實例可能是你已獲取的其它使用實例的可選過程。
3. 如果用戶開始重復原先討論過的問題，此時，也許你就完成了收集需求的工作。
4. 如果所提出的新需求比你已確定的需求的優先順序都低時，也許你就完成了收集需求的工作。
5. 如果用戶提出對將來產品的要求，而不是現在我們討論的特定產品，也許你就完成了收集需求的工作。
以上知識大致上討論需求分析應該如何做，實際上對於需求分析的方法有很多很多，已經形成了一定的理論，當然這種理論比較偏向與方法學，而方法學的應用主要還是要靠個人。所以，大家在實際應用的時候，不妨結合自己的實際，有選擇性的採用一些方法，那你就是成功的。
用例在需求分析中的使用
多年來，分析者總是利用情節或經歷來描述用戶和軟體系統的交互方式，從而獲取需求（McGraw and Harbison 1997）。Ivar Jacobson（1992）把這種看法系統地闡述成用例（用例）的方法進行需求獲取和建模。雖然用例來源於面向對象的開發環境，但是它也能應用在具有許多開發方法的項目中，因為用戶並不關心你是怎樣開發你的軟體。而最重要的，用例的觀點和思維過程帶給需求開發的改變比起是否畫正式的用例圖顯得更為重要。注意用戶要利用系統做什麼遠遠強於詢問用戶希望系統為他們做什麼這一傳統方法。
用例的重要功能是用畫用例圖的功能來鑒別和劃分系統功能。它把系統分成角色（actor）和用例（用例）。角色(actor)表示系統用戶能扮演的角色（role）。這些用戶可能是人，可能是其他的計算機一些硬體或者甚至是其它軟體系統，唯一的標準是它們必須要在被劃分進用例的系統部分以外。它們必須能刺激系統部分並接收返回。用例描述了當角色給系統特定的刺激時系統的活動。這些活動被文本描述。它描述了觸發用例的刺激的本質，輸入和輸出到其他活動者，和轉換輸入到輸出的活動。用例文本通常也描述每一個活動在特殊的活動線時可能的錯誤和系統應採取的補救措施。
這樣說可能會非常復雜，其實一個用例描述了系統和一個角色（actor）的交互順序。用例被定義成系統執行的一系列動作，動作執行的結果能被指定角色察覺到。用例可以:
· 用例捕獲某些用戶可見的需求，實現一個具體的用戶目標。
· 用例由角色激活，並提供確切的值給角色。
· 用例可大可小，但它必須是對一個具體的用戶目標實現的完整描述。在UML中，用例表示為一個橢圓。
角色是指用戶在系統中所扮演的角色。其圖形化的表示是一個小人。在某些組織中很可能有許多角色實例（例如有很多個銷售員），但就該系統而言，他們均起著同一種作用，扮演著相同的角色，所以用一個角色表示。一個用戶也可以扮演多種角色。例如，一個高級營銷人員既可以是貿易經理，也可以是普通的營銷人員；一個營銷人員也可以是售貨員。在處理角色時，應考慮其作用，而不是人或工作名稱，這一點是很重要的。
我們使用不帶箭頭的線段將角色與用例連接到一起，表示兩者之間交換信息，稱之為通信聯系。角色觸發用例，並與用例進行信息交換。單個角色可與多個用例聯系；反過來，一個用例可與多個角色聯系。對同一個用例而言，不同角色有著不同的作用：他們可以從用例中取值，也可以參與到用例中。需要注意的是角色在用例圖中是用類似人的圖形來表示，盡管執行的，但角色未必是人。例如，角色也可以是一個外界系統，該外界系統可能需要從當前系統中獲取信息，與當前系統有進行交互。
一個用例可能包括完成某項任務的許多邏輯相關任務和交互順序。因此，一個用例是相關的用法說明的集合，並且一個說明（scenario）是用例的實例。這種關系就像是類和對象的關系。在用例中，一個說明被視為事件的普通過程(normal course)，也叫作主過程，基本過程，普通流，或「滿意之路」 (happy path)。在描述普通過程時列出執行者和系統之間相互交互或對話的順序。當這種交互結束時，執行者也達到了預期的目的。
在用例中的其它說明可以描述為可選過程(alternative coruse)。可選過程也可促進成功地完成任務，但它們代表了任務的細節或用於完成任務的途徑的變化部分。在交互序列中，普通過程可以在一些決策點上分解成可選過程，然後再重新匯成一個普通過程。
角色類和角色實例
軟體產品最終是給一些用戶來使用的，而用戶之間的差異是非常大的。造成差異的原因包括了對計算機的認知程度的不同，使用習慣的不同，在軟體目標組織中所處的地位不同，地理位置不同，業務熟練程度不同。
不同的用戶都有自己一系列的功能需求和非功能需求。對電腦熟練程度不同的人可能就會有不同的要求，熟練程度低的用戶可能希望有一個友好的界面，熟練程度高的用戶可能更希望有快捷鍵或宏的操作以提高工作效率。考慮到用戶的差異性，將用戶分類並研究用戶類的行為特徵是非常有必要的。所以在做具體的需求之前，先將用戶分局行為和特點進行分類，對於研究、收集用戶的需求是非常有幫助的。
可以利用一個簡單的表格列出一些原始的分類，然後不斷的完善這個表格。確認你的分類之間沒有交集。並充分描述用戶分類的行為，目的，要求等。在企業分析中，比較常見的分類可能包括，供應商，客戶，部門等。
就像C++中的類和對象一樣，我們把分析出的用戶分類稱為「角色類」，把實際的用戶稱為「角色實例」。在得到用戶分類之後，最重要的就是要選出用戶代表，用戶代表不僅僅是在需求階段中參與項目，還必須對項目的全過程負責。用戶代表能夠代表用戶分類的需求。抓住用戶代表的需求就大致把握住了用戶類的需求。當然，需求分析還是需要在用戶中做大規模的調查的，只是要把重點放在用戶代表上。
確保和用戶直接進行溝通！大家有沒有玩過傳話的游戲，可能看過。一群人排成一列，一句話從排頭挨個向後傳，到最後，那句話已經是面目全非了。所以，一定要保證項目組能夠直接和用戶接觸。
對於和用戶直接溝通這一點，一般的針對特定企業的應用系統當然是不成問題，可是如果是開發行業軟體，和用戶直接溝通就成為一件幾乎是不可能的事情。在這種情況下，一般有幾種解決的辦法：
做大規模的市場調查，針對你的目標市場做市場調查，並根據統計學的理論建立你的數學模型。這部分的工作效果最好，其性質有些象一些游戲公司會發布一些Demo版的游戲。可是對於一般的企業來說，這項工作費時費力，高昂的成本往往使大家知難而退。我的意見是，方法是非常好的，但是可以採用折衷的辦法，例如選取有代表性的企業，為特定企業製作一個較小的版本並收集反饋意見等。這涉及到很多市場營銷的內容，並不是我的專業所長，這里就不多弄斧了。
聘請行業專家，一個行業專家往往可以在項目需求方面發揮極為重要的作用。一個行業專家往往都有大量的行業經驗和行業的人際關系網路。在產品的設計方面，這個行業專家提供很多寶貴的意見。在目前很多的軟體的開發過程中都採用了這種方式。行業專家有兩種：一種是在這個行業中有很深的資歷，但是對軟體技術並不熟悉；第二種是開發過同類軟體的軟體專家，這種人在開發同類軟體過程中已經積累了大量的項目經驗，並且具有軟體開發的知識。這種方式是獲取需求的最好的方式。 分析對比同類軟體，微軟在開發Office、Visual Studio的時候，也是參照了Lotus和Borland的成熟產品。這種方式的特點在於成本很低，比較適合和其他的方式配合使用。但是，要注意自己有沒有觸犯專利法。
需求的沖突
有的時候，雖然已經將用戶分類並選出了用戶代表。但是需求的來源眾多，往往會發生需求之間自相矛盾的事情。需求從四面八方收集來後，人們難以解決沖突，澄清模糊之處以及協調不一致之處。某些人還要對不可避免要發生的范圍問題單獨作出決定。在項目的早期階段，你必須決定誰是需求問題的決策者。如果不清楚誰有權並且有責任來作出決策，或者授權的個人不願意或不能作出決策，那麼決策者的角色將自然而然地落在開發者身上。這是一個非常糟糕的選擇，因為開發者通常沒有足夠多的信息和觀點來作出業務上的決策。
在軟體項目中，誰將對需求作出決策的問題並沒有統一的正確答案。分析員有時聽從呼聲高的或來自最高層人物的最大的需求。即便使用用戶代表這一手段，必須解決來自不同用戶類的相沖突的需求。通常，應盡可能由處於公司底層的人作出決策，因為他們與問題密切相關，並能得到關於這些問題的廣泛信息。
如果不同的用戶類有不一致的需求，那麼必須決策出滿足哪一類用戶的需求更為重要。了解可能使用產品的客戶種類的信息和他們的用法與產品的業務目標的關系如何，將有助於你決定哪一個用戶類所佔份額最大。
當開發者想像中的產品與客戶需求沖突時，通常應該由客戶作出決策。然而，不要陷到「客戶總是對的」的陷阱中去，對他們百依百順。現實中，客戶並不總是對的。客戶總是持有自己的觀點，開發者必須理解並尊重這一觀點。
用例
在具體的需求過程中，有大的用例（業務用例），也有小的用例。主要是由於用例的范圍決定的。用例像是一個黑盒，它沒有包括任何和實現有關或是內部的一些信息。它很容易就被用戶（也包括開發者）所理解（簡單的謂詞短語）。如果用例不足以表達足夠的信息來支持系統的開發，就有必要把用例黑盒打開，審視其內部的結構，找出黑盒內部的Actor和用例。就這樣通過不斷的打開黑盒，分析黑盒，再打開新的黑盒。直到整個系統可以被清晰的了解為止。
為什麼要採用這種分析方法呢？計算機系統除了在與外界系統、人員有一系列的交互，在系統內部也往往存在著復雜的交互。因此，在系統建模時，除了描述系統與外界的交互，同時還要描述系統內部的交互。傳統的MIS系統中，系統與外界的交互較多。典型的，如ATM取款機：存在著大量的用戶與ATM，ATM與其它系統的交互。而電信領域的系統，與外界的交互較少。例如，系統的輸入可能僅僅是從交換機上採集信息，然後由系統進行處理。系統的復雜邏輯包含在系統內部處理的流程上，而非與外部系統的交互。建模主要任務是表達系統內部的交互。
用例圖適於表達交互，之所以上面使用了電信系統，是因為用例最早來自於Ericsson的交換機系統。當時，還是Ericsson雇員的Jacobson初步建立了用例圖的概念，並於1994年提出了OOSE方法，其最大特點是面向用例（Use-Case），並在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器，比較適合支持商業工程和需求分析。隨著用例的發展，用例被大量的用於對功能進行描述。每個用例代表了系統與外部ACTOR的交互。可以採取順序圖來表達用例的具體操作程序。ACTOR用於確定系統的邊界。
ACTOR、用例可以從不同的層次來描述信息。採用該原則的原因有：
1. 需求並不是在項目一開始就很明確，往往是隨著項目的推進，逐漸細化。
2. 人的認知往往具有層次的特性。從粗到細、從一般到特殊。採用不同的層次來描述，適於認知的過程。
使用用例開發系統的一般過程
在開發過程的初始階段，可以根據具體的項目特點，制訂開發各個視圖之間的關聯原則，指導規范。在開發的過程中，視圖的組織原則應不斷進行維護、更新。
識別ACTOR來識別系統與外界交互的實體。ACTOR具有特定領域的特徵，例如：交換機（採集系統）、97信息系統等。在系統層次的ACTOR確定了系統的邊界。
識別用例。同ACTOR一樣，用例具有不同層次。對較為概括的USECASE，需要細化。註：系統開發需要一定的規則來確定，如何來分解用例；可能基於原有系統的經驗，或是參考現有資料。
當用例細化到可以被理解的層次。需要基於用例進行下一步的開發。如前面提到的，用例主要用來描述交互。因此，存在交互的實體和交互的細節。交互的實體採用類圖來描述；而交互的細節，採用順序圖來描述。
當系統復雜到一定層次時，類圖和順序圖可能不能足以描述其復雜程度。在該情況下，需要使用狀態圖來輔助闡述。狀態圖和順序圖之間使用事件聯結在一起。它們之間的一致性問題，目前UML和ROSE沒有提供解決方案。相對折衷的方法是使用事件的命名規范強制一致性。
可以說，之前說的所有的東西都是為了能夠導出用例在需求中的作用。用例是從用戶的角度看待系統，而不是基於程序員的角度。這樣的話，用例驅動的系統能夠真正做到以用戶為中心，用戶的任何需求都能夠在系統開發鏈中完整的體現。用戶和程序員間通過用例溝通，避免了牛頭馬嘴的尷尬局面。 從前，系統開發者總是通過情節來獲取需求，是問用戶希望系統為他做什麼。在Jacobson發明了用例的概念之後，需求獲取就變成問用戶要利用系統做什麼。這是立場不同導致的結果。用戶通常並不關心系統是如何實現的（也有少數可愛的技術狂是例外）。對他們來說，更重要的是要達到他的目的。相反的，大部分的程序員的工作習慣就是考慮計算機應該如何實現用戶的要求。所幸的是，用例方法能夠調和雙方的矛盾，因為雖然用例是來源於用戶，服務於用戶，但是它同樣可以用於開發的流程。當系統的開發過程都是基於用例的，用用例獲取需求，用用例設計，用用例編碼，用用例測試的時候。這個開發過程就是用例驅動的。 用例和用例文檔
《軟體需求》一書中提到了幾種方法來確定用例：
· 首先明確執行者和他們的角色，然後確定業務過程，在這一過程中每一個參與者都在為確定用例而努力。
· 確定系統所能反映的外部事件，然後把這些事件與參與的執行者和特定的用例聯系起來。
· 以特定的說明形式表達業務過程或日常行為，從這些說明中獲得用例，並確定參與到用例中的執行者，有可能從現在的功能需求說明中獲得用例。如果有些需求與用例不一致，就應考慮是否真的需要它們。
用例代表了用戶的需求，在你的系統中，應該直接從不同用戶類的代表或至少應從代理那裡收集需求。用例為表達用戶需求提供了一種方法，而這一方法必須與系統的業務需求相一致。分析者和用戶必須檢查每一個用例，在把它們納入需求之前決定其是否在項目所定義的范圍內。基於「用例」方法進行需求獲取的目的在於：描述用戶需要使用系統完成的所有任務。在理論上，用例的結果集將包括所有合理的系統功能。在現實中，你不可能獲得完全包容，但是比起我所知道的其它獲取方法，基於用例的方法可以為你帶來更好的效果。
當使用用例進行需求獲取時，應避免受不成熟的細節的影響。在對切合的客戶任務取得共識之前，用戶能很容易地在一個報表或對話框中列出每一項的精確設計。如果這些細節都作為需求記錄下來，他們會給隨後的設計過程帶來不必要的限制。你可能要周期性地檢查需求獲取，以確保用戶參與者將注意力集中在與今天所討論的話題適合的抽象層上。向他們保證在開發過程中，將會詳盡闡述他們的需求。在一個逐次詳細描述過程中，重復地詳述需求，以確定用戶目標和任務，並作為用例。然後，把任務描述成功能需求，這些功能需求可以使用戶完成其任務，也可以把它們描述成非功能需求，這些非功能需求描述了系統的限制和用戶對質量的期望。雖然最初的屏幕構思有助於描述你對需求的理解，但是你必須細化用戶界面設計。
建立用例文檔。在每一次的需求獲取之後，都會生成很多未整理的需求，你必須將它們組織成用例文檔。使用諸如模板的技術能夠提高你的速度和需求的復用性。一個用例文檔可以使用表格來組織，主要的要素包括了用例標識號、用例名稱、父用例標志號、創建者、創建時間、審核者、修訂記錄、角色、說明、先決條件、請求結果、優先順序、普通過程、可選過程、例外、非功能需求、假設、注釋和問題。
雖然列舉出了這么多的屬性，但是實際中使用的屬性這要看你的團體而定，看項目的大小而定。把大量的時間花在用例的描述上是沒有意義的。用戶需要的是一個軟體系統，並不是一大堆的用例說明。