需求識別常用方法論

⑴ 軟體需求的分析方法

軟體需求分析方法大體分為如下四類：結構化方法、面向對象方法、面向控制方法和面向數據方法。限於篇幅，將主要從結構化方法和面向對象方法以及RUP三個方面進行簡要的探討。 面向對象（Object Oriented, OO）的方法把分析建立在系統對象以及對象間交互的基礎之上，使得我們能以3個最基本的方法框架——對象及其屬性、分類結構和集合結構來定義和溝通需求。面向對象的問題分析模型從3個側面進行描述，即對象模型(對象的靜態結構)、動態模型(對象相互作用的順序)和功能模型(數據變換及功能依存關系)。需求工程的抽象原則、層次原則和分割原則同樣適用於面向對象方法，即對象抽象與功能抽象原則是一樣的，也是從高級到低級、從邏輯到物理，逐級細分．每一級抽象都重復對象建模(對象識別)一動態建模(事件識別)一功能建模(操作識別)的過程，直到每一個對象實例在物理(程序編碼)上全部實現為止。
面向對象需求分析(OORA)利用一些基本概念來建立相應模型，以表達目標系統的不同側面。盡管不同的方法所採用的具體模型不盡相同，但都無外乎用如下五個基本模型來描述軟體需求：
整體—部分模型：該模型描述對象(類)是如何由簡單的對象（類）構成的。將一個復雜對象(類)描述成一個由交互作用的若干對象(類)構成的結構的能力是OO途徑的突出優點。該模型亦稱聚合模型。
分類模型：分類模型描述類之間的繼承關系。與聚合關系不同，它說明的是一個類可以繼承另一個或另一些類的成分，以實現類中成分的復用。
類—對象模型：分析過程必須描述屬於每個類的對象所具有的行為，這種行為描述的詳細程度可以根據具體情況而定。既可以只說明行為的輸入、輸出和功能，也可以採用比較形式的途徑來精確地描述其輸入、輸出及其相應的類型甚至使用偽碼或小說明的形式來詳細刻畫。
對象交互模型：一個面向對象的系統模型必須描述其中對象的交互方法。如前所述，對象交互是通過消息傳遞來實現的。事實人對象交互也可看作是對象行為之間的引用關系。因此，對象交互模型就要刻畫對象之間的消息流。對應於不同的詳細程度，有不同的消息流描述分析，分析人員應根據具體館況而選擇。一般地，一個詳細的對象交互模型能夠說明對象之間的消息及其流向，並且同時說明該消息將激活的對象及行為。一個不太詳細的對象交互模型可以只說明對象之間有消息，並指明其流向即可。還有一種狀況就是介於此兩者之間。
狀態模型：在狀態模型中，把一個對象看作是一個有限狀態機，由一個狀態到另一狀態的轉變稱作狀態轉換。狀態模型將對象的行為描述成其不同狀態之間的通路。它也可以刻畫動態系統中對象的創建和廢除，並稱由對象的創建到對象的廢除狀態之間的退路為對象的生存期。
狀態模型既可以用狀態轉換因的圖形化手段，又可用決策表或稱決策矩陣的形式來表。 RUP（Rational Unified Process）是Rational公司開發和維護的過程產品。RUP是工程化的軟體開發過程，它提供了在開發機構中分派任務和責任的紀律化方法。RUP不僅僅是一個簡單的過程，而是一個通用的過程框架，可用於各種不同類型的軟體系統、各種不同的應用領域、各種不同類型的組織、各種不同的功能級別以及各種不同的項目規模。RUP的突出特點可以由以下三個關鍵詞來體現——用例驅動、以構架為中心、迭代和增量的。這些是RUP所特有的，也是同等重要的。構架提供了一種結構來指導迭代過程中的工作，而用例則確定了目標井驅動每次迭代的工作。
進行需求分析的基礎是要獲得用戶的需要，為了完成這一工作，必須建立業務模型，通過描述業務規則、業務邏輯，明確業務過程並對其進行規范、優化。對於一個系統，在建立業務模型時，應從3個方面來描述其特性：功能、行為、數據，對應於這些特性。 基於上述分析可知，結構化分析方法與面向對象分析方法的區別主要體現在兩個方面：
* 將系統分解成於系統的方式不同。前者將系統描述成一組交互作用的處理，後者則描述成一組交互作用的對象。
* 子系統之間的交互關系的描述方式不一樣。前者加工之間的交互是通過不太精確的數據流來表示的，而後者對象之間通過消息傳遞交互關系。
因此，面向對象軟體需求分析的結果能更好地刻畫現實世界，處理復雜問題，對象比過程更具有穩定性，便於維護與復用。

⑵ 需求分析常用方法都有哪些，請舉例說明

問卷調查法，是指設計方就用戶需求中的一些個性化的、需要進一步明確的需求或問題，通過採用向用戶問卷調查表的方式，達到徹底弄清項目需求的一種需求獲取方法。 這種方法適合於設計方和建設方、使用方都清楚項目需求的情況。因為建設方和使用方都清楚項目的需求，需要雙方進一步溝通的需求或問題就比較少，通過採用這種簡單的問卷調查方法就能使問題得到較好的解決。顯然對於樂百氏集團這樣規模龐大的公司，簡單的問卷調查是不能夠滿足准確獲得需求的需要的。會議討論法，是指設計方和用戶相關人員召開若干次需求討論會議，達到徹底弄清項目需求的一種需求獲取方法。這種方法適合於設計方不清楚用戶的詳細業務需求，但使用方清楚項目需求的情況。因為使用方清楚項目的需求，他們能准確地表達出他們的需求，而設計方有專業的需求，而我們有專業的軟體開發經驗，經過回憶討論交流之後，能夠對用戶的需求進行准確描述和把握。這個方法對於准確的獲得樂百氏公司的需求是一種不錯的選擇。在本案例中系統的設計人員也是這么做的，他們通過和樂百氏項目組經理的討論，很快了解了樂百氏的運作過程的數據。界面原型法，是指設計方根據自己所了解的用戶需求，描畫出應用系統的功能界面後與用戶進行交流和溝通，通過「界面原型」這一載體，達到雙方逐步明確項目需求的一種需求獲取的方法。這種方法比較適合於設計方和用戶都不是非常清楚項目需求、只是大概了解用戶需求的情況。因為設計方和用戶方都不能非常准確的描述出客戶的需求，因此此時就更需要藉助於一定的「載體」來加快對需求的挖掘和雙方對需求理解

⑶ 傳統需求分析方法包括哪些主要特點是什麼

傳統需求分析方法：結構化分析方法。

主要特點：結構化的分析方法是傳統的分析法，它的好處是在需求階段可以不需要精確地定義系統，只需要根據業務框架確定系統的功能范圍，以及每個功能的處理邏輯和業務規則，功能需求規格書等。

因為不需要精確描述，因此描述系統的方式比較靈活多樣，可以採用圖表、示例圖、文字等等方式來描述系統。在系統開發以前，一般還可以採用更為直觀的原型系統方式和最終用戶進行交流和確認，因此對業務需求的要求會低一些，業務需求階段的周期相對容易控制。

通過業務全景圖，最終用戶也能了解系統的功能；通過功能活動圖和業務規則的描述，也可以相對精確地描述業務系統；因為沒有嚴格的標記語言，可以採用適當的篇幅描述適當的系統。

當然，這種方法的缺點也是明顯的，分析人員和業務人員之間可能缺乏共同語言，機器不能識別業務需求書，在設計階段還需要繼續和用戶確認一部分功能。

需求分析原則

為了促進軟體研發工作的規范化、科學化，軟體領域提出了許多軟體開發與說明的方法，如結構化方法、原型化法、面向對象方法等。這些方法有的很相似。在實際需求分析工作中．每一種需求分析方法都有獨特的思路和表示法，基本都適用下面的需求分析的基本原則。

1、側重表達理解問題的數據域和功能域。對新系統程序處理的數據，其數據域包括數據流、數據內容和數據結構。而功能域則反映它們關系的控制處理信息。

2、需求問題應分解細化，建立問題層次結構。可將復雜問題按具體功能、性能等分解並逐層細化、逐一分析。

3、建立分析模型。模型包括各種圖表，是對研究對象特徵的一種重要表達形式。通過邏輯視圖可給出目標功能和信息處理間關系，而非實現細節。由系統運行及處理環境確定物理視圖，通過它確定處理功能和數據結構的實際表現形式。

⑷ 如何識別出用戶真正的需求

識別客戶真正需求的五個方法：
一、產品及其服務的價格
即是客戶為購買而支付的實際貨幣數量，它是買賣雙方形成交易的唯一平衡點。這個點有分歧，交易不能實現，這個點一致，就實現交易。當客戶不清楚自己的真正需求或供應商不理解客戶需求時，價格就是交易唯一的依據。在許多交易中，許多客戶以為知道自己真正的需求，供應商也主觀認為理解了客戶的全部需求，雙方都直奔主題---價格談判，結果客戶買到的未必符合需求，供應商也沒有利潤，如果供應商利用「客戶需求經濟學」來分析客戶需求，價格永遠放在最後，因為在客戶需求里，價格不是全部，只是其中的一部分。
從1998年開始中國施樂公司就開始在保險行業推銷其大型高速列印機，價格在100萬—300萬元之間，到了2000初已有初步成效，部分客戶採用了施樂公司的產品，但是這時候，HP、IBM、STAR等公司也發現高速列印機在保險業的機會，紛紛進入市場競爭，他們針對施樂產品價格高的狀況，均採用了低價格(相對應產品都便宜10—50萬元之間)的競爭策略，但經過兩年的較量，結果在2001底前施樂公司還是贏得競爭，幾乎佔有所有省級單位的采購訂單。施樂公司並沒有採用降價而予以應付競爭，而是以「客戶需求經濟學」為核心指導，利用自身早先進入保險業而非常了解客戶需求的優勢，制定出一攬子包含如何降低客戶使用成本、降低采購風險、解決核心問題、提供延伸利益、提前交貨時間等等全方面解決方案，其中包含了售後全程保修服務、融資、全外包服務、提供樣機周轉等等，結果擋住了競爭對手的瘋狂的進逼，並迫使他們迫使轉移競爭領域。
我們在銷售過程中，一旦客戶提出低價格要求或價格比較，多數業務員就驚慌失措，要不失去定單，要不利潤非常低。作者在工作中就這個狀況經常提醒業務員，遇到價格競爭或客戶低價格要求，不要在價格上糾纏不清，引導客戶關注於需求的其他領域而不是僅僅是價格，往往問題就迎刃而解。

⑸ 需求分析的主要方法是

目前，軟體需求的分析與設計方法較多，一些大同小異，而有的則基本思路相差很大。從開發過程及特點出發，軟體開發一般採用軟體生存周期的開發方法，有時採用開發原型以幫助了解用戶需求。在軟體分析與設計時，自上而下由全局出發全面規劃分析，然後逐步設計實現。
從系統分析出發，可將需求分析方法大致分為功能分解方法、結構化分析方法、信息建模法和面向對象的分析方法。
(1)功能分解方法。
將新系統作為多功能模塊的組合。各功能義可分解為若乾子功能及介面，子功能再繼續分解。便可得到系統的雛形，即功能分解——功能、子功能、功能介面。
(2)結構化分析方法。
結構化分析方法是一種從問題空間到某種表示的映射方法，是結構化方法中重要且被普遍接受的表示系統，由數據流圖和數據詞典構成並表示。此分析法又稱為數據流法。其基本策略是跟蹤數據流，即研究問題域中數據流動方式及在各個環節上所進行的處理，從而發現數據流和加工。結構化分析可定義為數據流、數據處理或加工、數據存儲、端點、處理說明和數據字典。
(3)信息建模方法。
它從數據角度對現實世界建立模型。大型軟體較復雜；很難直接對其分析和設計，常藉助模型。模型是開發中常用工具，系統包括數據處理、事務管理和決策支持。實質上，也可看成由一系列有序模型構成，其有序模型通常為功能模型、信息模型、數據模型、控制模型和決策模型。有序是指這些模型是分別在系統的不同開發階段及開發層次一同建立的。建立系統常用的基本工具是E—R圖。經過改進後稱為信息建模法，後來又發展為語義數據建模方法，並引入了許多面向對象的特點。
信息建模可定義為實體或對象、屬性、關系、父類型/子類型和關聯對象。此方法的核心概念是實體和關系，基本工具是E-R圖，其基本要素由實體、屬性和聯系構成。該方法的基本策略是從現實中找出實體，然後再用屬性進行描述。
(4)面向對象的分析方法。
面向對象的分析方法的關鍵是識別問題域內的對象，分析它們之間的關系，並建立三類模型，即對象模型、動態模型和功能模型。面向對象主要考慮類或對象、結構與連接、繼承和封裝、消息通信，只表示面向對象的分析中幾項最重要特徵。類的對象是對問題域中事物的完整映射，包括事物的數據特徵(即屬性)和行為特徵(即服務)

⑹ 論述題識別消費者需求的方法有幾種

有許多方法可以對市場特徵和客戶需求進行分析，大致可以分為兩類：定性分析方法和定量分析方法。定性分析方法一般從對一小群客戶的深入了解中發現問題，其目標是在一個開放的環境中識別顧客的優先權。調查人員使用定性分析方法進行新的假定，在新的領域加深了解。定量分析方法經常用於檢驗假定，關注不同條件下不同產品需求量的大小。
一、定性分析方法
對動態市場的分析一般始於定性分析。當我們的目標是了解基本市場情況和客戶需求，預測趨勢和發現問題，了解能夠產生價值主張的優先權時，可以使用定性分析方法。定性分析方法根據市場情況、分析精度和投資水平的不同分成三類。
1、行業類比
在許多市場環境下，對代表性的行業進行研究是了解客戶需求和新產品概念的一個不錯的開始。在某行業中出現的客戶需求可能在其他類似的行業中曾經出現過且已有了有效的解決方案。在這些案例當中，我們必須要增強客戶的忠誠度並固化客戶的購買行為。在早期的這些案例中，解決
方案是對客戶進行跟蹤和獎勵以鞏固向本公司繼續購買產品和服務的行為。這里的定性分析方法包括分析類似行業的共同特徵、研究這些行業成功的解決方案。
2、核心組
核心組是充分了解客戶需求和進行新產品概念開發的常見方法之一。在很多案例中，核心組涉及到對潛在顧客和目標市場購買者的小組討論。這樣的討論可以通過主題會議議程來實現。會議的主持者應該鼓勵對顧客需求進行自由開放的討論，詳細記錄這些討論以保證我們可以從中得到有用的信息。核心組通常作為系統地探索市場需求和特徵的第一步。
3、人種學
人種學通常是研究系統的市場需求的第二步。這種研究包含和監控和觀察現實生活中人們是如何使用產品的。其目標是研究人們使用當前產品的行為，並找出他們在使用產品時遇到的困難以及他們如何解決這些困難。為了發現客戶的需求，還必須對觀察結果進行仔細、深入的分析以發現那些不能一眼看出的需求。

⑺ 需求分析有哪些方法

三種需求分析的方法：結構化分析方法、面向對象的分析方法、面向問題域的分析方法。
結構化的分析方法是傳統的分析法，它的好處是在需求階段可以不需要精確地定義系統，只需要根據業務框架確定系統的功能范圍，以及每個功能的處理邏輯和業務規則，功能需求規格書等。因為不需要精確描述，因此描述系統的方式比較靈活多樣，可以採用圖表、示例圖、文字等等方式來描述系統。在系統開發以前，一般還可以採用更為直觀的原型系統方式和最終用戶進行交流和確認，因此對業務需求的要求會低一些，業務需求階段的周期相對容易控制；通過業務全景圖，最終用戶也能了解系統的功能；通過功能活動圖和業務規則的描述，也可以相對精確地描述業務系統；因為沒有嚴格的標記語言，可以採用適當的篇幅描述適當的系統。當然，這種方法的缺點也是明顯的，分析人員和業務人員之間可能缺乏共同語言，機器不能識別業務需求書，在設計階段還需要繼續和用戶確認一部分功能。

面向對象的分析方法的最大好處是在需求階段，就能夠非常精確地描述一個系統，採用程序語言的方式和最終用戶交流（最終用戶必須要熟悉這種語言），能夠在項目一開始就發現很多問題，避免在開發的過程中出現需求的反復，而且在系統設計和開發階段不需要最終用戶參與。在實施上，一般可以採用場景、業務功能等方式來描述，比較適合於業務流程環節多的系統，或者軟體產品的開發。但是，我們也要看到，在現實中，絕大多數的應用系統都很難在需求階段就可以被精確地抽象化定義，所以這種方法的缺點和困難也是顯而易見的：首先，用戶要非常清楚地知道最終的業務系統應該是什麼樣，或者採用一種抽象的方式能夠確定最終的應用系統；其次，因為最終用戶不需要參與設計和開發階段的工作，所以雙方確定業務需求的過程也會比較長；同時，因為是精確描述，因此描述系統的語言是非常邏輯化的，一般通過某種方式可以使機器識別業務需求，採用這種方式寫的業務需求是非常格式化的，一方面描述一個系統需要的信息非常多，可能使需求說明的篇幅非常長，不便於理解和閱讀；另外由於通過抽象的方式來推演最終系統的運行方式，對業務人員的要求非常高。

⑻ 項目的需求是如何產生的如何識別這些需求

1、 需求的產生：公共需求與公共項目；個體需求與個體項目。
2、需求識別：起始於需求、問題或機會的產生，結束於需求建議書的發布。清晰的需求是承約商規劃與實施項目的基礎。
3、所謂項目識別就是面對客戶已識別的需求，承約商從備選的項目方案中選出一種可能的項目方案來滿足這種需求。
4、項目識別與需求識別的不同：需求識別是客戶的一種行為；項目識別是承約商的行為。
參考資料：http://wenku..com/view/12934123af45b307e87197f8.html。

⑼ 需求分析的建模分析方法有哪兩種

資料庫設計需求
1. 需求概述
建立完善的資料庫結構管理設備的基本參數、運行狀態和各種工作計劃。

資料庫的框架和結構必須根據設備和運行狀態而設計，方便提供強大的錄入、查詢、統計、分析和報表等各種功能操作，較好的反映平台業務的基本情況和運行狀況，滿足平台的基本要求。

2. 外部設計需求
2.1 標識符和狀態

資料庫表前綴：根據模塊名定義（如用戶模塊：sys_）

用戶名：root

密碼：待定

許可權：全部

有效時間：開發階段

說明：系統正式發布後，可能更改資料庫用戶/密碼。

2.2 使用它的程序

本系統主要利用java作為後端的應用開發工具，使用MySQL作為後台的資料庫， Linux或Windows均可作為系統平台。

2.3 約定

所有命名一定要具有描述性，杜絕一切拼音、或拼音英文混雜的命名方式。
字元集採用 UTF-8，請注意字元的轉換。
所有數據表第一個欄位都是系統內部使用主鍵列，自增欄位，不可空，名稱為：id，確保不把此欄位暴露給最終用戶。
除特別說明外，所有日期格式都採用date格式。
除特別說明外，所有欄位默認都設置不充許為空， 需要設置默認值。
所有普通縮影的命名都是表名加設置縮影的欄位名組合，例如用戶表User中name欄位設置普通所以，則縮影名稱命名方式為user_name_index。
2.4 專門指導

對本系統的開發者、使用這、測試員和維護人員，提出以下參考意見：

在使用資料庫時，首先要參考上面的約定內容，做好軟體的安裝以及表格的建立。
資料庫的輸入統一採用鍵盤。對於資料庫的使用許可權，請參考本系統其他相關文檔。
資料庫的後台管理員沒用等級差異，可根據實際情況添加刪除管理員。
2.5 支持軟體

操作系統： Linux / Windows

資料庫系統：MySQL

查詢瀏覽工具：Navicat Premium

命令行工具：mysql

注意：mysql 命令行環境下對中文支持不好，可能無法書寫帶有中文的 SQL 語句。

3. 結構設計需求
3.1 概念結構設計需求

概念資料庫的設計是進行具體資料庫設計的第一步，概念資料庫設計的好壞直接影響到邏輯資料庫的設計，影響到整個資料庫的好壞。

我們已經得到了系統的數據流程圖和數據字典，現在就是要結合數據規范化的理論，用一種模型將用戶的數據要求明確地表示出來。

概念資料庫的設計應該極易於轉換為邏輯資料庫模式，又容易被用戶所理解。概念資料庫設計中最主要的就是採用「實體-關系數據」模型來確定資料庫的結構。

數據是表達信息的一種重要的量化符號，是信息存在的一種重要形式。數據模型則是數據特徵的一種抽象。它描述的是數據的共性，而不是描述個別的數據。一般來說，數據模型包含兩方面內容：

數據的靜態特性：主要包括數據的基本結構、數據間的關系和數據之間的相互約束等特性。
數據的動態特性：主要包括對數據進行操作的方法。
在資料庫系統設計中，建立反映客觀信息的數據模型，是設計中最為重要的，也最基本的步驟之一。

數據模型是連接客觀信息世界和資料庫系統數據邏輯組織的橋梁，也是資料庫設計人員與用戶之間進行交流的共同基礎。概念資料庫中採用的實體-關系模型，與傳統的數據模型有所不同。「實體-關系」模型是面向現實世界，而不是面向實現方法的，它主要是用使用方便，因而在資料庫系統應用的設計中，得到了廣泛應用。「實體-關系」模型可以用來說明資料庫中實體的等級和屬性。

以下是實體-關系模型中的重要標識：

在資料庫中存在的實體；
實體的屬性；
實體之間的關系；
3.2 邏輯結構設計需求
物理結構設計需求

1）定義資料庫、表及欄位的命名規范：

資料庫、表及欄位的命名要遵守可讀性原則。
資料庫、表及欄位的命名要遵守表意性原則。
資料庫、表及欄位的命名要遵守長名原則。
2）選擇合適的存儲引擎：
3）為表中的欄位選擇合適的數據類型。

4）建立資料庫結構

4. 運用設計需求
4.1 表名的命名規范

表名以英文單詞、單詞縮寫、簡寫、下劃線構成，總長度要求小於30位。

4.2 表欄位的命名規范

欄位名以英文單詞、單詞縮寫、簡寫、下劃線構成，總長度要求不超過30位。
欄位名以名詞或名詞短語，欄位採用單數形式。若表名由多個單片語成，則取各個單詞的縮寫組成，單詞縮寫間使用下劃線作為分隔。
若某個欄位是引用某個表的外鍵，則欄位名應盡量與源表的欄位名保持一致，一面混淆。
5. 安全保密設計需求
5.1 防止用戶直接操作資料庫的方法

通過把關鍵應用伺服器和資料庫伺服器進行分離，防止用戶對資料庫伺服器的直接操作，保證資料庫安全。

5.2 應用系統的用戶口令進行加密

在軟體系統中，對於數據的保護、業務操作的許可是通過識別用戶身份和許可權來完成的。用戶口令相比較，相同的話系統將該用戶的操作許可權分配給用戶，用戶再根據所分配的許可權對系統進行操作。

由以上過程可知，用戶口令在傳輸過程中容易被竊取泄漏，另外如果資料庫被非法進入則其中保存的口令能夠被非法查看。因此，在傳輸過程中和資料庫中的口令記錄欄位不應使用明文傳遞和保存，應該在口令被傳遞前對其明文口令使用有效的主流技術，對傳輸數據進行加密部分描述的加密演算法進行加密，在加密後傳輸到系統。系統將用戶提交的經過加密的口令數據保存的加密口令進行比較，相一致則進行後續操作。

⑽ 物業管理服務中,識別客戶需求有哪些方法A對撞分析法,B標桿對比法,C行為訪談

摘要 12、先禮後兵。物業管理面對千家萬戶，形形色色的人都有，講禮的與不講禮的同在，思想品德高尚的和低下的並存，這是我們不能選擇的。其中，收費是物業管理最敏感的一個話題，而服務收費又是物管企業的生存根本，對於一些業主以各種理由拒絕物業收費，我們首先要主動檢討自己工作中的不足，堅持耐心說服解釋。但是，當我們依約提供了質價相符的服務後，對於仍不交物業服務費的業主，我們就不能一味退讓，而應該先禮後兵，該出手時就出手。即：首先是採取主動協商的策略來解決；其次是通過發律師函，再次是對於無理取鬧、惡意拒交管理費的，該打管司的就打官司，直至達到追回物業服務費之目的。