需求分析建模方法

『壹』 需求建模是什麼階段採用的主要手段

需求建模是設計需求階段採用的主要手段。

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

建模過程

建立DFD圖的目的是描述系統的功能需求。DFD方法利用應用問題域中數據及信息的提供者與使用者、信息的流向、處理、存儲四種元素描述系統需求，建立應用系統的功能模型。

首先要明確目標系統的功能需求，並將用戶對目標系統的功能需求完整、准確、一致地描述出來，然後確定模型要描述的問題域。雖然在建模過程中這些內容是逐步細化的，但必須自始自終保持一致、清晰和准確。

『貳』 需求分析的建模分析方法有哪兩種

資料庫設計需求
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 應用系統的用戶口令進行加密

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

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

『叄』 如何進行軟體需求的建模

軟體需求建模的方法目前比較流行一般有三種：面向對象、結構化、面向問題域。傳統上一般採用結構化的方法，也就是面向過程、面向數據的方法，可以採用數據流圖、與ER圖的建模方法對流程和數據分別建模。而現在大家也在使用面向對象的需求分析方法，也就是採用USE CASE的方式描述需求，採用對象關系圖描述數據。比較新的方法是面向問題域的方法。

『肆』 需求分析的主要方法是

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

『伍』 需求分析時應該建立哪些模型，如何建立

需求分析是指理解用戶需求，就軟體功能與客戶達成一致，估計軟體風險和評估項目代價，最終形成開發計劃的一個復雜過程。（這個和我在微軟體驗到的又不太一樣，微軟的需求分析大多是市場人員和用戶協助小組的人去評估用戶的接受程度，這一點也可以理解，因為公司的性質有根本差別）在這個過程中，用戶的確是處在主導地位，需求分析工程師和項目經理要負責整理用戶需求，為之後的軟體設計打下基礎。需求分析階段結束後，要求得到：1.SRS文檔 (System Requirement Specification); 2.DRM 文檔；3.Acceptance Plan.

從廣義上理解：需求分析包括需求的獲取、分析、規格說明、變更、驗證、管理的一系列需求工程。

狹義上理解：需求分析指需求的分析、定義過程。

一、為什麼要需求分析

需求分析就是分析軟體用戶的需求是什麼.如果投入大量的人力，物力,財力,時間,開發出的軟體卻沒人要,那所有的投入都是徒勞.如果費了很大的精力,開發一個軟體,最後卻不滿足用戶的要求,從而要重新開發過,這種返工是讓人痛心疾首的.(相信大家都有體會)比如,用戶需要一個for linux的軟體,而你在軟體開發前期忽略了軟體的運行環境,忘了向用戶詢問這個問題,而想當然的認為是開發for windows的軟體,當你千辛萬苦地開發完成向用戶提交時才發現出了問題,那時候你是欲哭無淚了,痕不得找塊豆腐一頭撞死.

需求分析之所以重要,就因為他具有決策性,方向性,策略性的作用,他在軟體開發的過程中具有舉足輕重的地位.大家一定要對需求分析具有足夠的重視.在一個大型軟體系統的開發中,他的作用要遠遠大於程序設計.

二、需求分析的任務

簡言之,需求分析的任務就是解決"做什麼"的問題,就是要全面地理解用戶的各項要求,並准確地表達所接受的用戶需求.

三、需求分析的過程

需求分析階段的工作,可以分為四個方面:問題識別,分析與綜合,制訂規格說明,評審.

問題識別
就是從系統角度來理解軟體,確定對所開發系統的綜合要求,並提出這些需求的實現條件,以及需求應該達到的標准.這些需求包括：功能需求(做什麼),性能需求(要達到什麼指標),環境需求(如機型,操作系統等),可靠性需求(不發生故障的概率）,安全保密需求,用戶界面需求,資源使用需求(軟體運行是所需的內存,CPU等),軟體成本消耗與開發進度需求,預先估計以後系統可能達到的目標.

分析與綜合
逐步細化所有的軟體功能,找出系統各元素間的聯系,介面特性和設計上的限制,分析他們是否滿足需求,剔除不合理部分,增加需要部分.最後,綜合成系統的解決方案,給出要開發的系統的詳細邏輯模型(做什麼的模型).

制訂規格說明書
即編制文檔,描述需求的文檔稱為軟體需求規格說明書.請注意,需求分析階段的成果是需求規格說明書(好象軟考曾經考過這個問題),向下一階段提交.

評審
對功能的正確性,完整性和清晰性,以及其它需求給予評價.評審通過才可進行下一階段的工作,否則重新進行需求分析。

四、需求分析的方法

需求分析的方法有很多.這里只強調原型化方法,其它的方法如:結構化方法,動態分析法等(個人認為,對初學者不必深究這些方法,實際上我也從來沒用過這些方法)在此不討論.

原型化方法是十分重要的(是軟考等常考的知識點).原型就是軟體的一個早期可運行的版本,它實現了目標系統的某些或全部功能.

原型化方法就是盡可能快地建造一個粗糙的系統,這系統實現了目標系統的某些或全部功能,但是這個系統可能在可靠性,界面的友好性或其他方面上存在缺陷.建造這樣一個系統的目的是為了考察某一方面的可行性,如演算法的可行性,技術的可行性,或考察是否滿足用戶的需求等.如,為了考察是否滿足用戶的要求,可以用某些軟體工具快速的建造一個原型系統,這個系統只是一個界面,然後聽取用戶的意見,改進這個原型.以後的目標系統就在原型系統的基礎上開發.

原型主要有三種類型(軟考考過):探索型,實驗型,進化型.探索型:目的是要弄清楚對目標系統的要求,確定所希望的特性,並探討多種方案的可行性.實驗型:用於大規模開發和實現前,考核方案是否合適,規格說明是否可靠.進化型:目的不在於改進規格說明,而是將系統建造得易於變化,在改進原型的過程中,逐步將原型進化成最終系統。

在使用原型化方法是有兩種不同的策略:廢棄策略,追加策略.廢棄策略:先建造一個功能簡單而且質量要求不高的模型系統，針對這個系統反復進行修改,形成比較好的思想,據此設計出較完整,准確,一致,可靠的最終系統.系統構造完成後,原來的模型系統就被廢棄不用.探索型和實驗型屬於這種策略。

追加策略:先構造一個功能簡單而且質量要求不高的模型系統，作為最終系統的核心,然後通過不斷地擴充修改,逐步追加新要求，發展成為最終系統。進化型屬於這種策略.

五、需求分析的20條法則

客戶與開發人員交流需要好的方法。下面建議20條法則，客戶和開發人員可以通過評審以下內容並達成共識。如果遇到分歧，將通過協商達成對各自義務的相互理解，以便減少以後的磨擦（如一方要求而另一方不願意或不能夠滿足要求）。

1、 分析人員要使用符合客戶語言習慣的表達
需求討論集中於業務需求和任務，因此要使用術語。客戶應將有關術語（例如：采價、印花商品等采購術語）教給分析人員，而客戶不一定要懂得計算機行業的術語。

2、分析人員要了解客戶的業務及目標
只有分析人員更好地了解客戶的業務，才能使產品更好地滿足需要。這將有助於開發人員設計出真正滿足客戶需要並達到期望的優秀軟體。為幫助開發和分析人員，客戶可以考慮邀請他們觀察自己的工作流程。如果是切換新系統，那麼開發和分析人員應使用一下目前的舊系統，有利於他們明白目前系統是怎樣工作的，其流程情況以及可供改進之處。

3、 分析人員必須編寫軟體需求報告
分析人員應將從客戶那裡獲得的所有信息進行整理，以區分業務需求及規范、功能需求、質量目標、解決方法和其他信息。通過這些分析，客戶就能得到一份「需求分析報告」，此份報告使開發人員和客戶之間針對要開發的產品內容達成協議。報告應以一種客戶認為易於翻閱和理解的方式組織編寫。客戶要評審此報告，以確保報告內容准確完整地表達其需求。一份高質量的「需求分析報告」有助於開發人員開發出真正需要的產品。

4、 要求得到需求工作結果的解釋說明
分析人員可能採用了多種圖表作為文字性「需求分析報告」的補充說明，因為工作圖表能很清晰地描述出系統行為的某些方面，所以報告中各種圖表有著極高的價值；雖然它們不太難於理解，但是客戶可能對此並不熟悉，因此客戶可以要求分析人員解釋說明每個圖表的作用、符號的意義和需求開發工作的結果，以及怎樣檢查圖表有無錯誤及不一致等。

5、 開發人員要尊重客戶的意見
如果用戶與開發人員之間不能相互理解，那關於需求的討論將會有障礙。共同合作能使大家「兼聽則明」。參與需求開發過程的客戶有權要求開發人員尊重他們並珍惜他們為項目成功所付出的時間，同樣，客戶也應對開發人員為項目成功這一共同目標所做出的努力表示尊重。

6、 開發人員要對需求及產品實施提出建議和解決方案
通常客戶所說的「需求」已經是一種實際可行的實施方案，分析人員應盡力從這些解決方法中了解真正的業務需求，同時還應找出已有系統與當前業務不符之處，以確保產品不會無效或低效；在徹底弄清業務領域內的事情後，分析人員就能提出相當好的改進方法，有經驗且有創造力的分析人員還能提出增加一些用戶沒有發現的很有價值的系統特性。

7、 描述產品使用特性
客戶可以要求分析人員在實現功能需求的同時還注意軟體的易用性，因為這些易用特性或質量屬性能使客戶更准確、高效地完成任務。例如：客戶有時要求產品要 「界面友好」或「健壯」或「高效率」，但對於開發人員來講，太主觀了並無實用價值。正確的做法是，分析人員通過詢問和調查了解客戶所要的「友好、健壯、高效所包含的具體特性，具體分析哪些特性對哪些特性有負面影響，在性能代價和所提出解決方案的預期利益之間做出權衡，以確保做出合理的取捨。

8、 允許重用已有的軟體組件
需求通常有一定靈活性，分析人員可能發現已有的某個軟體組件與客戶描述的需求很相符，在這種情況下，分析人員應提供一些修改需求的選擇以便開發人員能夠降低新系統的開發成本和節省時間，而不必嚴格按原有的需求說明開發。所以說，如果想在產品中使用一些已有的商業常用組件，而它們並不完全適合您所需的特性，這時一定程度上的需求靈活性就顯得極為重要了。

9、 要求對變更的代價提供真實可靠的評估
有時，人們面臨更好、也更昂貴的方案時，會做出不同的選擇。而這時，對需求變更的影響進行評估從而對業務決策提供幫助，是十分必要的。所以，客戶有權利要求開發人員通過分析給出一個真實可信的評估，包括影響、成本和得失等。開發人員不能由於不想實施變更而隨意誇大評估成本。

10、 獲得滿足客戶功能和質量要求的系統
每個人都希望項目成功，但這不僅要求客戶要清晰地告知開發人員關於系統「做什麼」所需的所有信息，而且還要求開發人員能通過交流了解清楚取捨與限制，一定要明確說明您的假設和潛在的期望，否則，開發人員開發出的產品很可能無法讓您滿意。

11、 給分析人員講解您的業務
分析人員要依靠客戶講解業務概念及術語，但客戶不能指望分析人員會成為該領域的專家，而只能讓他們明白您的問題和目標；不要期望分析人員能把握客戶業務的細微潛在之處，他們可能不知道那些對於客戶來說理所當然的「常識」。

12、 抽出時間清楚地說明並完善需求
客戶很忙，但無論如何客戶有必要抽出時間參與「頭腦高峰會議」的討論，接受采訪或其他獲取需求的活動。有些分析人員可能先明白了您的觀點，而過後發現還需要您的講解，這時請耐心對待一些需求和需求的精化工作過程中的反復，因為它是人們交流中很自然的現象，何況這對軟體產品的成功極為重要。

13、 准確而詳細地說明需求
編寫一份清晰、准確的需求文檔是很困難的。由於處理細節問題不但煩人而且耗時，因此很容易留下模糊不清的需求。但是在開發過程中，必須解決這種模糊性和不準確性，而客戶恰恰是為解決這些問題作出決定的最佳人選，否則，就只好靠開發人員去正確猜測了。

在需求分析中暫時加上「待定」標志是個方法。用該標志可指明哪些是需要進一步討論、分析或增加信息的地方，有時也可能因為某個特殊需求難以解決或沒有人願意處理它而標註上「待定」。客戶要盡量將每項需求的內容都闡述清楚，以便分析人員能准確地將它們寫進「軟體需求報告」中去。如果客戶一時不能准確表達，通常就要求用原型技術，通過原型開發，客戶可以同開發人員一起反復修改，不斷完善需求定義。

14、 及時作出決定
分析人員會要求客戶作出一些選擇和決定，這些決定包括來自多個用戶提出的處理方法或在質量特性沖突和信息准確度中選擇折衷方案等。有權作出決定的客戶必須積極地對待這一切，盡快做處理，做決定，因為開發人員通常只有等客戶做出決定才能行動，而這種等待會延誤項目的進展。

15、 尊重開發人員的需求可行性及成本評估
所有的軟體功能都有其成本。客戶所希望的某些產品特性可能在技術上行不通，或者實現它要付出極高的代價，而某些需求試圖達到在操作環境中不可能達到的性能，或試圖得到一些根本得不到的數據。開發人員會對此作出負面的評價，客戶應該尊重他們的意見。

16、 劃分需求的優先順序
絕大多數項目沒有足夠的時間或資源實現功能性的每個細節。決定哪些特性是必要的，哪些是重要的，是需求開發的主要部分，這只能由客戶負責設定需求優先順序，因為開發者不可能按照客戶的觀點決定需求優先順序；開發人員將為您確定優先順序提供有關每個需求的花費和風險的信息。 在時間和資源限制下，關於所需特性能否完成或完成多少應尊重開發人員的意見。盡管沒有人願意看到自己所希望的需求在項目中未被實現，但畢竟是要面對現實，業務決策有時不得不依據優先順序來縮小項目范圍或延長工期，或增加資源，或在質量上尋找折衷。

17、 評審需求文檔和原型
客戶評審需求文檔，是給分析人員帶來反饋信息的一個機會。如果客戶認為編寫的「需求分析報告」不夠准確，就有必要盡早告知分析人員並為改進提供建議。更好的辦法是先為產品開發一個原型。這樣客戶就能提供更有價值的反饋信息給開發人員，使他們更好地理解您的需求；原型並非是一個實際應用產品，但開發人員能將其轉化、擴充成功能齊全的系統。

18、 需求變更要立即聯系
不斷的需求變更，會給在預定計劃內完成的質量產品帶來嚴重的不利影響。變更是不可避免的，但在開發周期中，變更越在晚期出現，其影響越大；變更不僅會導致代價極高的返工，而且工期將被延誤，特別是在大體結構已完成後又需要增加新特性時。所以，一旦客戶發現需要變更需求時，請立即通知分析人員。

19、 遵照開發小組處理需求變更的過程
為將變更帶來的負面影響減少到最低限度，所有參與者必須遵照項目變更控制過程。這要求不放棄所有提出的變更，對每項要求的變更進行分析、綜合考慮，最後做出合適的決策，以確定應將哪些變更引入項目中。

20、 尊重開發人員採用的需求分析過程
軟體開發中最具挑戰性的莫過於收集需求並確定其正確性，分析人員採用的方法有其合理性。也許客戶認為收集需求的過程不太劃算，但請相信花在需求開發上的時間是非常有價值的；如果您理解並支持分析人員為收集、編寫需求文檔和確保其質量所採用的技術，那麼整個過程將會更為順利。

「需求確認」意味著什麼

在「需求分析報告」上簽字確認，通常被認為是客戶同意需求分析的標志行為，然而實際操作中，客戶往往把「簽字」看作是毫無意義的事情。「他們要我在需求文檔的最後一行下面簽名，於是我就簽了，否則這些開發人員不開始編碼。」

這種態度將帶來麻煩，譬如客戶想更改需求或對產品不滿時就會說：「不錯，我是在需求分析報告上簽了字，但我並沒有時間去讀完所有的內容，我是相信你們的，是你們非讓我簽字的。」

同樣問題也會發生在僅把「簽字確認」看作是完成任務的分析人員身上，一旦有需求變更出現，他便指著「需求分析報告」說：「您已經在需求上簽字了，所以這些就是我們所開發的，如果您想要別的什麼，您應早些告訴我們。」

這兩種態度都是不對的。因為不可能在項目的早期就了解所有的需求，而且毫無疑問地需求將會出現變更，在「需求分析報告」上簽字確認是終止需求分析過程的正確方法，所以我們必須明白簽字意味著什麼。

對「需求分析報告」的簽名是建立在一個需求協議的基線上，因此我們對簽名應該這樣理解：「我同意這份需求文檔表述了我們對項目軟體需求的了解，進一步的變更可在此基線上通過項目定義的變更過程來進行。我知道變更可能會使我們重新協商成本、資源和項目階段任務等事宜。」對需求分析達成一定的共識會使雙方易於忍受將來的摩擦，這些摩擦來源於項目的改進和需求的誤差或市場和業務的新要求等。 需求確認將迷霧撥散，顯現需求的真面目，給初步的需求開發工作畫上了雙方都明確的句號，並有助於形成一個持續良好的客戶與開發人員的關系，為項目的成功奠定了堅實的基礎。

六、點評需求分析誤區

要想說什麼是好的需求分析，不如說什麼是不好的需求分析，知道什麼是不好的，自然也就知道了什麼是好的。以下就是一些不好的情況：

（1）創意和求實
毋庸質疑的，每個人都會為自己的一個新的Idea而激動萬分，特別是當這個Idea受到一些根本不知道你原本要幹嘛的人的驚贊時。但是請注意，當你激動得意的時候，你可能已經忘了你原本是在描述一個需求，而不是在策劃一個創意、創造一個概念。很多剛開始做需求分析的人員都或多或少的會犯這樣的錯誤，陶醉在自己的新想法和新思路中，卻違背了需求的原始客觀性和真實性原則。

永遠別忘了：需求不是空中樓閣，是實實在在的一磚一瓦。

（2）解剖的快感
幾乎所有搞軟體的人，做需求分析的時候，一上來就會把用戶告訴你的要求，完完整整的作個解剖，切開分成幾個塊，再細分成幾個子塊，然後再條分縷析。可是當用戶迷惑的看著你辛辛苦苦做出來的分析結果問你：我想作一個數據備份的任務，怎麼做？這時，你會發現，需要先後打開三個窗口才能完成這個任務。

永遠別忘了：分解是必需的，但最終的目的是為了更好的組合，而不是為了分解。

（3）角度和思維
經常聽到這樣的抱怨：「用戶怎麼可以提出這樣苛刻的要求呢？」。細細一了解，你會發現，用戶只不過是要求把一個需要兩次點擊的功能，改成只有一次點擊。這樣會導致需要改變需求、改變編碼、甚至重新測試，增加工作量。可是，如果換個角度來想想，這個功能，開發的時候只用了幾次、幾十次，可是用戶每天都要用幾百次甚 至幾千次幾萬次，改動一下就減少了一半的工作量，對他來說，這樣的需求難道會苛刻嗎？

永遠別忘了：沒有任何需求是不對的，不對的只是你的需求分析。試著站在用戶的思維角度想想，你的需求分析就會更加的貼近用戶，更加的合理。軟體應該是以人為本的。

（4）程序員邏輯
從程序員成長為系統分析員是一個普遍的軌跡，但並不是一個好的程序員就必然能成為一個好的系統分析員。一些程序員的固化邏輯，使得他們在做需求分析的時候往往鑽進了一些牛角裡面。比如說1／0邏輯（或者是說黑白邏輯），認為不是這樣就是那樣，沒有第三種情況。可實際情況往往是，在一定的時候是這樣，其它時候是那樣。又比如窮舉邏輯，喜歡上來就把所有一二三可能的情況列舉出來，然後一個一個分別處理，每個佔用三分之一的時間；可是實際的情況往往是，三分之一的情況佔了99％的比例，其它兩種情況一年都不會遇到一次。實際中還有很多這樣的例子，不一一列舉了。

永遠別忘了：需求分析和程序設計不盡相同，合理、可行是才是重要的。跳出程序設計的圈子，站在系統的角度上來看問題，你的結論會截然不同。

『陸』 需求分析怎麼做

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發明了用例的概念之後，需求獲取就變成問用戶要利用系統做什麼。這是立場不同導致的結果。用戶通常並不關心系統是如何實現的（也有少數可愛的技術狂是例外）。對他們來說，更重要的是要達到他的目的。相反的，大部分的程序員的工作習慣就是考慮計算機應該如何實現用戶的要求。所幸的是，用例方法能夠調和雙方的矛盾，因為雖然用例是來源於用戶，服務於用戶，但是它同樣可以用於開發的流程。當系統的開發過程都是基於用例的，用用例獲取需求，用用例設計，用用例編碼，用用例測試的時候。這個開發過程就是用例驅動的。 用例和用例文檔

《軟體需求》一書中提到了幾種方法來確定用例：

· 首先明確執行者和他們的角色，然後確定業務過程，在這一過程中每一個參與者都在為確定用例而努力。

· 確定系統所能反映的外部事件，然後把這些事件與參與的執行者和特定的用例聯系起來。

· 以特定的說明形式表達業務過程或日常行為，從這些說明中獲得用例，並確定參與到用例中的執行者，有可能從現在的功能需求說明中獲得用例。如果有些需求與用例不一致，就應考慮是否真的需要它們。

用例代表了用戶的需求，在你的系統中，應該直接從不同用戶類的代表或至少應從代理那裡收集需求。用例為表達用戶需求提供了一種方法，而這一方法必須與系統的業務需求相一致。分析者和用戶必須檢查每一個用例，在把它們納入需求之前決定其是否在項目所定義的范圍內。基於「用例」方法進行需求獲取的目的在於：描述用戶需要使用系統完成的所有任務。在理論上，用例的結果集將包括所有合理的系統功能。在現實中，你不可能獲得完全包容，但是比起我所知道的其它獲取方法，基於用例的方法可以為你帶來更好的效果。

當使用用例進行需求獲取時，應避免受不成熟的細節的影響。在對切合的客戶任務取得共識之前，用戶能很容易地在一個報表或對話框中列出每一項的精確設計。如果這些細節都作為需求記錄下來，他們會給隨後的設計過程帶來不必要的限制。你可能要周期性地檢查需求獲取，以確保用戶參與者將注意力集中在與今天所討論的話題適合的抽象層上。向他們保證在開發過程中，將會詳盡闡述他們的需求。在一個逐次詳細描述過程中，重復地詳述需求，以確定用戶目標和任務，並作為用例。然後，把任務描述成功能需求，這些功能需求可以使用戶完成其任務，也可以把它們描述成非功能需求，這些非功能需求描述了系統的限制和用戶對質量的期望。雖然最初的屏幕構思有助於描述你對需求的理解，但是你必須細化用戶界面設計。

建立用例文檔。在每一次的需求獲取之後，都會生成很多未整理的需求，你必須將它們組織成用例文檔。使用諸如模板的技術能夠提高你的速度和需求的復用性。一個用例文檔可以使用表格來組織，主要的要素包括了用例標識號、用例名稱、父用例標志號、創建者、創建時間、審核者、修訂記錄、角色、說明、先決條件、請求結果、優先順序、普通過程、可選過程、例外、非功能需求、假設、注釋和問題。

雖然列舉出了這么多的屬性，但是實際中使用的屬性這要看你的團體而定，看項目的大小而定。把大量的時間花在用例的描述上是沒有意義的。用戶需要的是一個軟體系統，並不是一大堆的用例說明。

『柒』 如何進行結構化需求分析,其建模方法都有哪些

1. 基本型需求，這類需求是應該得到滿足，有是應該的，沒有是會引起用戶不滿；所以這類需求是比較重要也是需求挖掘和需求分析應當用心做好的，這是一個產品的基礎。舉例說明，聊天表情，幾乎任何具備聊天場景的IM，都有發送表情的功能，輸入法也開發了自己的默認表情，如果你設計一款新的APP，缺少了表情，可能會讓用戶不滿。

2. 期望型需求，在做用戶調研或則訪談的時候，用戶反饋如果有某個功能，該多好，當你想深入了解的時候，用戶或客戶自己也說不明白為什麼需要這個功能，就是覺得如果你有，就很好，如果沒有其實也影響不大；還有種可能，用戶使用了競品友商的產品，進行相互對比的時候，告訴你某某產品有這個功能，我覺得你們也應該有，這類需求屬於期望型需求同時也屬於基本型需求，所以這類需求不滿足，會引起用戶的不滿，得到滿足，會給產品加分但是不會太多。對於期望型需求，我曾經也糾結過苦惱過，也設計過原型，一直遲遲沒有提交開發，這類需求收集到了可以提前准備，等時機成熟（有很多用戶或則客戶都提到這個需求）或則有開發資源的時候，再做。舉個例子，我現在在做的是ToB的產品，是專業的銷售人員、外勤人員的行為管理軟體，提需求的大部分是後勤人員，他們的工作就是使用後台進行監督、管理、匯總等，尤其是剛剛使用我們產品，對考勤管理特別用心，每天都會盯著考勤查看誰請假、出差、遲到早退、各種異常，然後每月工資也會按照考勤來制定，問題來了，用戶提到如果考勤能這樣排版、這樣匯總、如果能夠在一個頁面看到所有信息等等。其實這些需求都是某些用戶頻繁使用產品，遇到的麻煩和想偷懶所提出的，他們期望軟體幫他們完成所有的工作，然後自己每天就是坐在電腦前靜靜的等待結果。這類需求，需要慎重容易導致產品變得越來越臃腫，為了滿足了任何人的需求，反而滿足不了任何人的需求。所以很多文章都提到，產品經理面對需求，需要做減法。期望型需求，就是考驗產品經理做加法還是做減法的判斷力。

3. 興奮型需求，讓人出乎意料的產品屬性，這類需求滿足了會給產品增加不少魅力和好評。

1. 生理上的需要：食物 / 水 / 睡眠 / 生理平衡 / 分泌 / 性 / 呼吸；對應的移動互聯網產品有美團外賣、陌陌等。

2. 安全上的需要：人身安全 / 健康保障 / 資源所有 / 財產安全 / 道德保障 / 工作保障 / 家庭安全；對應的移動互聯網產品有支付寶、咕咚、樂運動、超級減肥王、動動記步、KEEP等。

3. 情感和歸屬的需要：愛情 / 友情 / 性親密；對應的移動互聯網產品有珍愛網、世紀佳緣、生日管家、她趣等等。

4. 尊重的需要：自我尊重 / 信心 / 成就 / 對他人尊重 / 被他人尊重；對應的移動互聯網產品有新浪微博等。

5. 自我實現的需要：道德 / 創造力 / 自覺性 / 問題解決能力 / 公正度 / 接受現實能力；對應的移動互聯網產品有在行。

『捌』 面向對象的需求分析中要建立什麼模型

一、總述
面向對象分析的輸入是用戶的功能需求，輸出是簡單的、理性化的分析模型，此階段的工作更多側重於如何理解軟體的功能需求；
面向對象設計的輸入是面向對象分析的結果，蔬菜水果最終的、細化後的設計模型，此階段的工作更多側重於如何得到一個合適的、完整的解決方案。
二、主要區別
(1)
在側重點上，面向對象分析側重於理解問題，描述軟體要做什麼，而面向對象設計側重於理解解決方案，描述軟體要如何做。
(2)
面向對象分析一般只考慮理想餓設計，不關心技術和實現層面的細節，而面向對象設計需要得到更具體、更詳盡，更接近於真實的代碼的設計方案。
(3)
在設計結果的描方式上，面向對象分析階段側重於描述對象的行為，而面向對象設計階段側重於描述對象的屬性和方法。
(4)
面向對象分析只關注功能性需求，而面向對象設計既關注功能性需求，也關注非功能性需求。
(5)
面向對象分析產生的系統模型通常規模較小，而面向對象設計產生的系統模型規模較大，內容也比較詳盡、完整。
三、分析設計工具(rationalrose
+
uml)
1、需求分析階段
常藉助於「用例圖」、「順序圖」對功能模型進行建模；
用例描述，一般包括：用例名稱，系統范圍，用戶目標，前置條件，執行過程，擴展情況，後置條件。
順序圖著眼於整個系統。
2、面向對象分析階段（包含需求分析階段的用例建模）
常藉助於「類圖、對象圖」，「順序圖、協作圖」，「狀態圖」進行靜態模型建模和動態模型建模。
這里的類圖主要指通過用例分析得到的實體類、控制類和邊界類。
順序圖也著眼於各個分析類對象間的協作。
3、面向對象設計階段
常藉助於「類圖」，「順序圖、協作圖」，「狀態圖」來細化各個類以及對象間的協作、關系的可見性；
這里的類圖，要具體到屬性、方法，類之間的關系依賴（繼承、組合、聚合）
這里的順序圖要具體到各個類的實例之間的消息傳遞、函數調用。
面向對象設計階段常藉助一些設計模式達到軟體的可擴展行，應對軟體的可預測到的變化。

『玖』 軟體需求的分析方法

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