需求分析兩種方法

⑴ 需求分析有哪三種方法2，什麼是面向數據結構方法

它首先用結構化分析（SA）對軟體進行需求分析，然後用結構化設計（SD）方法進行總體設計，最後是結構化編程（SP）。它給出了兩類典型的軟體結構（變換型和事務型）使軟體開發的成功率大大提高。

三種基本的結構形式就是順序、選擇和重復。三種數據結構可以進行組合，形成復雜的結構體系。這一方法從目標系統的輸入、輸出數據結構入手，導出程序框架結構，再補充其它細節，就可得到完整的程序結構圖。這一方法對輸入、輸出數據結構明確的中小型系統特別有效，如商業應用中的文件表格處理。該方法也可與其它方法結合，用於模塊的詳細設計。

⑵ 如何正確的理解和分析用戶需求

3、兩種需求分析方法
1.HMW：how might we=我們可以如何=怎麼辦（Designhackthon）
流程
問題：明確用戶場景問題（問題需要聚焦及開放）
例1:公司想要沖刺業績/清理庫存，如何促銷？
例2:用戶購後評價率低於8%應該怎麼辦？
手段：HMW方法分解問題
拆解問題
積極：如何讓用戶自發資源的解決問題？
轉移：怎樣讓其他人幫助解決這個問題？
腦洞：怎樣想些腦洞大開，平常不敢想的方案？
分解：把大的問題分解成幾個小的步驟？
否定：想什麼辦法能讓用戶放棄這個想法？
方案：腦暴
全部都要想要解決的方案，全部窮舉
優先順序：分類排序
MVP：流程與原型設計
分析需求
步驟
澄清問題
原始需求是什麼層次？（方案級還是問題級？）
想要解決誰的、什麼問題？
用戶遇到現在的問題會採取什麼樣的解決方案？
這個問題中有需要進一步細化和明確的概念嗎？
了解背景
場景（功能）
該需求誰使用？什麼時候使用？具體怎麼做？
術語（數據）
有需要澄清的業務術語嗎？它們的格式是什麼？
環境（質量）
不做誰生氣？多久生氣一次？為什麼？多久用一次？
建議並確定解決方案
要解決這個問題有哪些可行的解決方案
這些方案的實現成本分別有多少？
你覺得哪種最合適？（解決問題/成本合適）
該解決方案對用戶而言有什麼優缺點？
有其他需要挖掘的需求嗎？

⑶ 需求分析的主要方法是

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

⑷ 需求分析方法有哪些

問題一：需求分析有哪些方法 三種需求分析的方法：結構化分析方法、面向對象的分析方法、面向問題域的分析方法。
結構化的分析方法是傳統的分析法，它的好處是在需求階段可以不需要精確地定義系統，只需要根據業務框架確定系統的功能范圍，以及每個功能的處理邏輯和業務規則，功能需求規格書等。因為不需要精確描述，因此描述系統的方式比較靈活多樣，可以採用圖表、示例圖、文字等等方式來描述系統。在系統開發以前，一般還可以採用更為直觀的原型系統方式和最終用戶進行交流和確認，因此對業務需求的要求會低一些，業或沖務需求階段的周期相對容易控制；通過業務全景圖，最終用戶也能了解系統的功能；通過功能活動圖和業務規則的描述，也可以相對精確地描述業務系統；因為沒有嚴格的標記語言，可以採用適當的篇幅描述適當的系統。當然，這種方法的缺點也是明顯的，分析人員和業務人員之間可能缺乏共同語言，機器不能識別業務需求書，在設計階段還需要繼續和用戶確認一部分功能。
面向對象的分析方法陪團如的最大好處是在需求階段，就能夠非常精確地描述一個系統，採用程序語言的方式和最終用戶交流（最終用戶必須要熟悉這種語言），能夠在項目一開始就發現很多問題，避免在開發的過程中出現需求的反復，而且在系統設計和開發階段不需要最終用戶參與。在實施上，一般可以採用場景、業務功能等方式來描述，比較適合於業務流程環節多的系統，或者軟體產品的開發。但是，我們也要看到，在現實中，絕大多數的應用系統都很難在需求階段就可以被精確地抽象化定義，所以這種方法的缺蘆啟點和困難也是顯而易見的：首先，用戶要非常清楚地知道最終的業務系統應該是什麼樣，或者採用一種抽象的方式能夠確定最終的應用系統；其次，因為最終用戶不需要參與設計和開發階段的工作，所以雙方確定業務需求的過程也會比較長；同時，因為是精確描述，因此描述系統的語言是非常邏輯化的，一般通過某種方式可以使機器識別業務需求，採用這種方式寫的業務需求是非常格式化的，一方面描述一個系統需要的信息非常多，可能使需求說明的篇幅非常長，不便於理解和閱讀；另外由於通過抽象的方式來推演最終系統的運行方式，對業務人骸的要求非常高。

問題二：項目需求分析的分析方法 需求分析的方法有很多.這里只強調原型化方法,其它的方法如:結構化方法,動態分析法等(個人認為,對初學者不必深究這些方法,實際上我也從來沒用過這些方法)在此不討論.原型化方法是十分重要的(是軟考等常考的知識點).原型就是軟體的一個早期可運行的版本,它實現了目標系統的某些或全部功能.原型化方法就是盡可能快地建造一個粗糙的系統,這系統實現了目標系統的某些或全部功能,但是這個系統可能在可靠性,界面的友好性或其他方面上存在缺陷.建造這樣一個系統的目的是為了考察某一方面的可行性,如演算法的可行性,技術的可行性,或考察是否滿足用戶的需求等.如,為了考察是否滿足用戶的要求,可以用某些軟體工具快速的建造一個原型系統,這個系統只是一個界面,然後聽取用戶的意見,改進這個原型.以後的目標系統就在原型系統的基礎上開發.原型主要有三種類型(軟考考過):探索型,實驗型,進化型.探索型:目的是要弄清楚對目標系統的要求,確定所希望的特性,並探討多種方案的可行性.實驗型:用於大規模開發和實現前,考核方案是否合適,規格說明是否可靠.進化型:目的不在於改進規格說明,而是將系統建造得易於變化,在改進原型的過程中,逐步將原型進化成最終系統。在使用原型化方法是有兩種不同的策略:廢棄策略,追加策略.廢棄策略:先建造一個功能簡單而且質量要求不高的模型系統，針對這個系統反復進行修改,形成比較好的思想,據此設計出較完整,准確,一致,可靠的最終系統.系統構造完成後,原來的模型系統就被廢棄不用.探索型和實驗型屬於這種策略。追加策略:先構造一個功能簡單而且質量要求不高的模型系統，作為最終系統的核心,然後通過不斷地擴充修改,逐步追加新要求，發展成為最終系統。進化型屬於這種策略.

問題三：如何做好需求分析，需求調研 轉載以下資料供參考
從廣義上理解：需求分析包括需求的獲取、分析、規格說明、變更、驗證、管理的一系列需求工程。
狹義上理解需求分析指需求的分析、定義過程。
原因
需求分析就是分析軟體用戶的需求是什麼。如果投入大量的人力，物力、財力、時間，開發出的軟體卻沒人要，那所有的投入都是徒勞。如果費了很大的精力，開發一個軟體，最後卻不滿足用戶的要求，從而要重新開發過，這種返工是讓人痛心疾首的(相信大家都有體會)。比如：用戶需要一個for linux的軟體，而你在軟體開發前期忽略了軟體的運行環境，忘了向用戶詢問這個問題，而想當然的認為是開發for windows的軟體。當你千辛萬苦地開發完成向用戶提交時才發現出了問題，那時候你是欲哭無淚了，恨不得找塊豆腐一頭撞死。
需求分析之所以重要，就因為他具有決策性、方向性、策略性的作用，他在軟體開發的過程中具有舉足輕重的地位，大家一定要對需求分析具有足夠的重視。在一個大型軟體系統的開發中，他的作用要遠遠大於程序設計。
任務
簡言之，需求分析的任務就是解決「做什麼的問題，就是要全面地理解用戶的各項要求，並准確地表達所接受的用戶需求。
過程
需求分析階段的工作,可以分為四個方面：問題識別、分析與綜合、制訂規格說明、評審。
問題識別：就是從系統角度來理解軟體，確定對所開發系統的綜合要求，並提出這些需求的實現條件，以及需求應該達到的標准。這些需求包括：功能需求(做什麼)、性能需求(要達到什麼指標)、環境需求(如機型、操作系統等)、可靠性需求(不發生故障的概率）、安全保密需求、用戶界面需求、資源使用需求(軟體運行是所需的內存、CPU等)、軟體成本消耗與開發進度需求、預先估計以後系統可能達到的目標。
分析與綜合： 逐步細化所有的軟體功能，找出系統各元素間的聯系，介面特性和設計上的限制，分析他們是否滿足需求，剔除不合理部分，增加需要部分。最後綜合成系統的解決方案，給出要開發的系統的詳細邏輯模型(做什麼的模型)。
制訂規格說明書： 即編制文檔，描述需求的文檔稱為軟體需求規格說明書。請注意，需求分析階段的成果是需求規格說明書，向下一階段提交。
評審： 對功能的正確性，完整性和清晰性，以及其它需求給予評價。評審通過才可進行下一階段的工作,否則重新進行需求分析。
方法
需求分析的方法有很多，這里只強調原型化方法，其它的方法如：結構化方法、動態分析法等，從來沒用過這些方法在此不討論。
原型化方法是十分重要的，原型就是軟體的一個早期可運行的版本，它實現了目標系統的某些或全部功能。
原型化方法就是盡可能快地建造一個粗糙的系統，這系統實現了目標系統的某些或全部功能。但是這個系統可能在可靠性、界面的友好性或其他方面上存在缺陷。建造這樣一個系統的目的是為了考察某一方面的可行性，如演算法的可行性、技術的可行性或考察是否滿足用戶的需求等。如：為了考察是否滿足用戶的要求，可以用某些軟體工具快速的建造一個原型系統，這個系統只是一個界面，然後聽取用戶的意見，改進這個原型。以後的目標系統就在原型系統的基礎上開發。
原型主要有三種類型：探索型、實驗型、進化型。
探索型：目的是要弄清楚對目標系統的要求，確定所希望的特性，並探討多種方案的可行性。
實驗型：用於大規模開發和實現前，考核方案是否合適，規格說明是否可靠。
進化型：目的不在於改進規格說明，而是將系統建造得易於變化，在改進原型的過程中，逐步將原型進化成最終系統。
在使用原型化方法時有兩種不同的策略：廢棄策略、追加策略。
廢棄策略：先建造一個功能簡單而且質量要求不高的模型系統，針對這個系統反復進行修改,形成......>>

問題四：請問常用的需求分析方法有哪些？ 結構分析方法和面向對象分析法

問題五：培訓需求分析的方法有哪幾種 組織資源分析
如果沒有確定可被利用的人力、物力和財力資源，就難以確立培訓目標。組織資源分析包括對組織的金錢、時間、人力等資源的描述。一般情況下，通過對下面問題的分析，就可了解一個組織資源的大致情況。
組織特質與環境分析
組織特質與環境對培訓的成功與否也起重要的影響作用。因為，當培訓規劃和組織的價值不一致時，培訓的效果則很難保證。組織特質與環境分析主要是對組織的系統結構、文化、資訊傳播情況的了解。主要包括如下內容：
系統特質指組織的輸入、運作、輸出、次級系統互動以及與外界環境間的交流特質，使管理者能夠系統地面對組織，避免組織分析中以偏概全的缺失。
文化特質。指組織的軟硬體設施、規章、制度、組織經營運作的方式、組織成員待人處事的特殊風格，使管理者能夠深入了解組織，而非僅僅停留在表面。
資訊傳播特質。指組織部門和成員收集、分析和傳遞信息的分工與運作，促使管理者了解組織信息傳遞和溝通的特性。

問題六：在需求分析階段常用的圖形工具有哪三種 1. 需求分析是准確的理解用的需求將其轉換成需求定義，然後由需求定義轉換成形式化的功能規約。需求分析的困難表現在問題的復雜性、交流的障礙、不完備和不一致性、需求易變性。 2. 結構化分析方法是採用自頂向下逐層分解的分析策略把一個復雜的系統分解成若干小問題然後分別解決 3. 數據流即數據通過一個系統時的變化方式。輸入數據首先轉換成中間數據，然後轉換成輸出結果數據。在此期間可以從已有的數據存儲（如磁碟文件或內存緩沖區）中引入附加數據。對數據進行轉換是程序中應有的功能或子功能。兩個轉換功能之間的數據傳遞就確定了功能間的介面。 4. 把一個功能分解成幾個子功能，並確定這些子功能與父功能的介面，就屬於橫向分解。 5. 把一個功能分解成幾個子功能，並確定這些子功能與父功能的介面，就屬於橫向分解。但如果繼續分解，把某些子功能又分解為小的子功能，某個小的子功能又分解為更小的子功能，這就屬於縱向分解了。 6. 數據流圖是用來表示系統的功能的工具它表示系統的邏輯模型描述了數據流在系統中流動的情況它是一種功能模型。

問題七：如何做需求分析 隨著技術的不斷發展和用戶對網站功能性的需求不斷提高，如今網站項目的設計已經不能再僅僅簡單地利用靜態Html文件來實現，與前幾年網站設計由一兩名網頁設計師自由的創作相比，網站項目的設計和開發越來越像一個軟體工程，也越來越復雜，網站項目的設計和開發進入了需要強調流程和分工的時代，建立規范的、有效的、健壯的開發機制，才能適應用戶不斷變化的需要，達到預期的計劃目標。
網站項目管理（WPM）的含義為Web-based Project Management，即以Web 應用程序為主要表現方式的架構來進行的項目設計及管理，這樣的架構中包含了瀏覽器、網路和Web
伺服器等關鍵主體，主要體現在網站設計、以瀏覽器為客戶端的Web應用程序開發（例如信息類網站、網上商店、虛擬郵局、客戶關系管理。）等項目管理中。
按照筆者的經驗，網站項目管理可以分為以下l六個階段進行控制：
1. 需求分析及變更管理
2. 項目模型及業務流程分析
3. 系統分析及軟體建模
4. 界面設計、交互設計及程序開發
5. 系統測試和文檔編寫
6. 客戶培訓、技術支持和售後服務
需要說明的是，這些階段雖然具有一定的延續性，但是並非完全隔斷的，例如需求變更管理和測試工作、文檔編寫都是貫穿整個項目過程的，許多工作時交叉進行或同時進行的。
（一）如何做好需求分析及變更管理？
業務員與客戶進行的溝通，撰寫需求分析報告是項目展開的基礎。項目是以客戶的需求為中心，而不是為技術而遷就需求。
一：讓客戶暢所欲言，羅列出所有的需求
讓用戶將所有的想法盡可能的闡述清楚，並把所有的要求羅列出來，不要遺漏。這時候不應該害怕「勾引」起客戶的潛在需求而增加設計開發的工作量，從而被今後客戶無止境的變更拖入泥潭，直接明白地跟客戶把問題和要求一條條地列出來，把條理、歸納、分析先都扔到一邊去，將用戶最原始、最完整的要求准確地記錄下來就完成了第一步的工作。
很明顯，假如客戶的需求做的都不完整，隨時可能會產生意想之外的變更，甚至這個變更會破壞已經做的模型及結構，那麼這個項目從開始就註定了會失敗；比如站點所有的功能都實現了，本地測試起來也沒有什麼問題了，但是你卻不知道客戶的系統是要承受每天100萬獨立IP的訪問，而你原來想當然的以為了不起就是1萬獨立IP訪問的訪問流量，稍微有經驗的開發人員都會明白這樣的設計是個災難，無論是應用伺服器、資料庫還是程序全部要重新開發！
二：透過現象分析潛在的需求
很多情況下客戶並非專業人士，在他們滔滔不絕的描述中不能指望他們幫助我們整理出重點和技術難關，這需要我們去為客戶進行分析、歸納和整理，尤其是客戶談的不多卻又是技術上實現難度和強度很高的地方特別值得注意。
客戶往往對需求的概念是非常模糊的，大多時候給出的需求都是籠統而且尺度難以控制的，這就要求業務人員在傾聽了客戶的詳細說明以後，幫助客戶進行整理和分析，同時預測客戶在開發過程中變更及今後應用中可能進行修改升級的潛在需求。
比如在為客戶設計辦公自動化系統的時候，也許就要為客戶預留將來與他們的業務單位進行交互的通道；在設計郵件系統的時候要考慮可能會需要廣告管理伺服器；設計網路電子商店時今後增加庫存產品進銷存統計分析等等；限於時間財力的考慮，客戶通常能夠接受分階段實施的開發過程，在需求分析時，提早為客戶設想到今後的需求變更除了使項目開發更加順利以外，也為今後業務的進一步深入打下......>>

問題八：軟體需求分析的方法和工具有哪些內容 1. 問卷調查法， 開發方就用戶需求中的一些個性化的、需要進一步明確的需求，通過採用向用戶發問卷調查表的方式，達到徹底弄清項目需求的一種需求獲取方法。這種方法適合於開發方和用戶方都清楚項目需求的情況。因為開發方和建設方都清楚項目的需求，則需要雙方進一步溝通的需求就比較少，通過採用這種簡單的問卷調查方法就能使問題得到較好的解決
2. 會議討論法 ，開發方和用戶方召開若干次需求討論會議，達到徹底弄清項目需求的一種需求獲取方法，這種方法適合於開發方不清楚項目需求（一般開發方是剛開始做這種業務類型的工程項目）但用戶方清楚項目需求的情況。因為用戶清楚項目的需求，則用戶能准確地表達出他們的需求，而開發方有專業的軟體開發經驗，對用戶提供的需求一般都能准確地描述和把握
3. 界面原型法 ，開發方根據自己所了解的用戶需求，描畫出應用系統的功能界面後與用戶進行交流和溝通，通過「界面原型」這一載體，達到雙方逐步明確項目需求的一種需求獲取的方法。這種方法比較適合於開發方和用戶方都不清楚項目需求的情況。因為開發方和用戶方都不清楚項目需求，因此此時就更需要藉助於一定的「載體」來加快對需求的挖掘和雙方對需求理解。這種情況下，採用「可視化」的界面原型法比較可取

⑸ 如何做需求分析

你這個問題問的有點太大了，不知道怎麼回答，需求的工作存在很多靈活性，很難整理出一個流程性的東西，我也是正在學習，最近在學習徐峰老師的《軟體需求實踐》，把我知道的拿出來分享，錯了的話請大家糾正，但是不要噴我啊！妹子心裡素質不行，嘿嘿
1、需求是有層次的，分為業務需求、用戶需求以及系統需求，所以在進行需求分析時肯定是要根據不同層次階段進行不同方式、內容以及側重點的需求調研。
1）業務需求，一般是公司的高層提出的，就是我們這個系統的指導需求，這個需求比較空，但是卻是整個系統需求的指導思想，在做需求時經常想想這個知道思想，可以防止需求跑偏。

2）用戶需求，一般是公司的中層和操作層提出的需求。中層突出流程，就是整個框架，而操作層提出具體的細節性需求。就是往中層的框架裡面添加需求細節。

3）系統需求，就是針對前兩種需求調研之後得結果進行需求分析和業務建模之後，得到了系統開發的需求。

2、需求的步驟分為：需求定義（對應上面的業務需求）、需求捕獲（對應上面的用戶需求）、需求分析與需求建模（對應上面的系統需求）、需求驗證、需求跟蹤、需求管理。

3、做需求工程中可以使用的工具：AXURE（用來製作原型，讓用戶更直觀的了解即將做成什麼狀態的系統，便於需求確認）、EA（是建模工具，用來繪制UML圖，「一圖抵千言」為了更好的表達需求和溝通需求）、word、Excel、Visio等工具。

⑹ 項目需求分析的分析方法

需求分析的方法有很多.這里只強調原型化方法,其它的方法如:結構化方法,動態分析法等(個人認為,對初學者不必深究這些方法,實際上我也從來沒用過這些方法)在此不討論.
原型化方法是十分重要的(是軟考等常考的知識點).原型就是軟體的一個早期可運行的版本,它實現了目標系統的某些或全部功能.
原型化方法就是盡可能快地建造一個粗糙的系統,這系統實現了目標系統的某些或全部功能,但是這個系統可能在可靠性,界面的友好性或其他方面上存在缺陷.建造這樣一個系統的目的是為了考察某一方面的可行性,如演算法的可行性,技術的可行性,或考察是否滿足用戶的需求等.如,為了考察是否滿足用戶的要求,可以用某些軟體工具快速的建造一個原型系統,這個系統只是一個界面,然後聽取用戶的意見,改進這個原型.以後的目標系統就在原型系統的基礎上開發.
原型主要有三種類型(軟考考過):探索型,實驗型,進化型.探索型:目的是要弄清楚對目標系統的要求,確定所希望的特性,並探討多種方案的可行性.實驗型:用於大規模開發和實現前,考核方案是否合適,規格說明是否可靠.進化型:目的不在於改進規格說明,而是將系統建造得易於變化,在改進原型的過程中,逐步將原型進化成最終系統。
在使用原型化方法是有兩種不同的策略:廢棄策略,追加策略.廢棄策略:先建造一個功能簡單而且質量要求不高的模型系統，針對這個系統反復進行修改,形成比較好的思想,據此設計出較完整,准確,一致,可靠的最終系統.系統構造完成後,原來的模型系統就被廢棄不用.探索型和實驗型屬於這種策略。
追加策略:先構造一個功能簡單而且質量要求不高的模型系統，作為最終系統的核心,然後通過不斷地擴充修改,逐步追加新要求，發展成為最終系統。進化型屬於這種策略.

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

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

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

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

⑻ 產品需求和需求分析

1.需要 VS 需求
需要：用戶要解決的問題或者要滿足的慾望，我們定義為需要。
需求：為解決用戶的問題或者滿足用戶慾望而產生的產品或功能，我們稱之為需求
上面這個故事中，客戶孫拍想要更短的時間到達目的地，這是需要；想要一匹更快的馬，這是需求。再比如，想聽歌是人們的需要，想要一個隨身聽設備是需求。所以往往人們所表達出來的需求，不一定能更好的滿足人們的需要。好的產品經理一定深諳其道，所以福特去造車，喬布斯做ipod。
2.用戶的解決方案 VS 產品解決方案
在沒有汽車之前，用戶能想到的更快到達遠方的工具是日行千里夜行八百的千里馬。想要一匹千里馬，這是用戶提出的解決方案。福特製造汽車來更好的滿足用戶需求，這是產品解決方案，這里注意用詞「更好的滿足」。解決方案沒有唯一性，先有汽車，後有飛機高鐵，沒有最好只有更好。用戶提出的解決方案不一定不可取，也不一定不能滿足用戶的需要。在沒有汽車飛機高鐵之前，或許馬匹就是最合適的解決方案。
用戶的解決方案：用戶自己思考要滿足自己需要或慾望而想出來的辦法，不同的用戶對於相同的問題往往提供的解決方法不一樣，和用戶的知識、經驗、緊迫程度有關。

產品的解決方案：通過一系列的功能、內容或者服務的組合，滿足用戶需要的手段。產品是功能、內容或者服務的聚合。

3.需求分類
在產品戰略層（《用戶體驗要素》），要回答兩個問題：a.我們要通過這個產品得到什麼？b.用戶能通過這個產品得到什麼？
前者是公司的業務目標，是商業屬性；後者是用戶體驗目標。因此，我們將需求分為業務需求和用戶需求兩類。
a.業務需求=業務目的+業務目標
業務目的是我們為什麼要做這塊業務，社會或市場存在的問題是什麼。業務目標時做了這個產品後，希望得到什麼成果。
比如小米做最好性價比的智能手機，因為智能手機要麼很貴如蘋果三星，要麼質量或者用戶體驗不太好，所以小米的定位要做一款性價比高的手機產品。
那小米想通過這個產品得到什麼呢？小米公布的2018年財報，硬體稅後凈利率小於1%，手機和其他硬體產品都是小米的現金流抓手。商業嘛，最終都是要掙錢的，可能這款產品不直接掙錢或者持續燒錢，但它在戰略中承擔某一環節的作用，為整體生態提供養分。正如小米這種生態型公司，每款產品的商業目的（定位）都不一樣，結合起來就是一張完整版圖。
所以，我們去分析一個產品的業務需求時，不要只看到產品的點，要向上看一看，看到公司布局看到戰略，這樣可以更好的幫產品經理理解業務需求。
b.用戶需求=目標用戶+場景+行為+用戶體驗目標
不要脫離使用主題（目標用戶）談產品解決方案則模羨，也不能脫離用戶的使用場景（場景有很自然的存在，如開車聽歌；也可以營造，比如雙11），用戶行為和場景是關聯的，這些連貫起來就是什麼人在什麼場景下做出什麼行為，想要達成什麼目標。產品的解決方案是要把這些做到自然連貫，把用戶需求和業務需求更好碼殲地融合起來。
這里的重點是，任何產品都是人在用，產品的目標是解決人的問題。脫離人這個主體談需求、談方案，那就是空談。我們常常戰術上很勤奮，為什麼會改了一版又一版？決策者把大把時間花在競爭對手的產品功能研究上，想借鑒別人的解決方案來解決自己的問題，就是不願意花時間調研自己的用戶，基於冥想，而不是基於真實。
幾乎所有的成功產品都做到了「用戶體驗第一」，他們的產品有超高的粘性，源於對用戶的尊重，為用戶打造極致的滿足感，而不是去堆砌功能。
什麼是場景？
梁寧的解釋是：要把場景拆開，場和景。
「場」是時間和空間的概念，一個場就是時間加空間。用戶願意在某個時間段在這個空間里停留和消費，如果一個人不能在某個空間去停留、消費，這個場就是不存在的。
「景」是情景和互動。當用戶停留在這個空間的時間里，要有情景和互動讓用戶的情緒觸發，並且裹挾用戶的意見，這就是場景。
按照這個定義，在電商或者零售中常說的人貨場，這個場絕不僅僅是指賣東西的地方，更多的可以理解為場景。除了空間，它還有時間、有用戶的心情、有當下的交互體驗。如果服務沒法與人緊密連接，那它一定是冰冷的，沒有粘性的服務，最終只會有損於商業目標。

需求採集的方法
被動獲取：
a.用戶反饋,含產品內反饋、服務評價、app評分、網路留言（如微博）、投訴等
b.同事或朋友的反饋
c.競爭對手，含產品功能、市場動態等
d.市場和監管，含政策性要求，如滴滴車內錄像錄音
e.領導輸出

主動發現
主動發現分為定量和定性兩種方法。
定性：判斷是什麼叫定性，定性分析一般用於趨勢判斷
定量：判斷有什麼叫定量，定量分析一般用於量化定性結論
舉例：下雨天外賣訂單會增長，這個是定性，表明下雨這個外因和外賣單量的增長存在關系；下雨天外賣訂單會增長40%，這個是定量，有具體的數據可以量化下雨和外賣單量增長的關系。

1.需求分析的方法
需求分析是一個針對採集到的需求，通過合理性評估，篩選過濾偽需求、提煉歸納合並真需求，並評估優先順序的過程。總結就是去偽求真，把留下的真需求排定一個實現的優先順序的過程。需求採集後，面對一堆雜亂無章的，各式各樣的，不同目的的需求，先明確需求合理性評估原則
1）合規（法律、政策、行業規范等），企業不能違法，不能做不符合法律法規、道德要求的產品。明令禁止的不可打擦邊球。
2）戰略協同（符合公司願景或階段性戰略目標）戰略類需求基本上是自上而下的指令
，產品經理需要與高層溝通清楚，不要出現理解偏差、執行偏差，要A給B，要A給a，執行不到位。
比如，某電商目前是純自營B2C,管理層決定做個開放平台，讓其他商家也接入平台，共享數據、渠道等資源，從單一商家的B2C發展成多商戶平台型電商，這個轉型就是戰略需求。再比如，去年創業公司的營收是1個億，凈虧損2000萬，今年的目標是扭虧為盈，這是公司發展戰略。公司的一些戰略常常會反應在比較細的產品需求之中。如DAU提升a%，轉化率提升b%deng，這類屬於自上而下產生的KPI分解到產品路徑上產生的需求。
3）需求真偽的評估首先不要站在自己角度理解用戶需求。如果不是基於用戶的真實需要，真實的使用場景來判斷需求，不靠譜的概率會很大。
4）價值成本評估主要是2個方面的評估：
a.給企業帶來什麼價值，給用戶帶來什麼價值。很多電商都做會員做積分，企業的需要是用戶粘性，是留存。對於用戶來說，積分可以兌換禮品，或當錢花，做得好就是一個雙贏的需求決策。
b.實現要付出多少成本。這里的成本不僅是研發的人力投入、時間周期的費用。達成目標的方法可能很多，為什麼是A而不是B，AB方案的差異、優劣、價值和成本需要對比，只要能達成目標，方案越簡單越好。
5）技術可行性評估。理論上技術可行性更多是時間周期的問題。需要設計人員了解一些技術，否則容易導致返工。
在完成需求合理評估後，剩下的需求應都是合理的、真實的、有目標的、可實現的需求了。我們對這些需求再進一步分組歸類，用於更好的幫我們理解需求。

需求分析方法1：卡諾模型

*注意：
1）五種需要像階梯一樣從低到高，按層級逐級遞升，但這樣的次序不是完全固定的，可以變化。
2）需求層次理論有兩個基本出發點，一是人人都有需要，某層需求獲得滿足後，另一層需要才出現；二是在多種需求未獲滿足前，首先滿足迫切需要；該需要滿足後，後面的需要才顯示出其激勵作用。
3）一般來說，某一層次的需要相對滿足了，就會向高一層次發展，追求更好一層次的需要就稱為驅使行為的動力。相應的，獲得基本滿足的需要就不再是一股激勵力量。
4）五中需要可以分為兩級，其中生理上的需要、安全上的需要和感情上的需要都屬於低一級的需要，這些需要通過外部條件可以滿足；而尊重的需要和自我實現的需要是高級需要，他們是通過內部因素才能滿足的，而且一個人對尊重和自我實現的需要是無止境的。
面對雜亂無序的各類需求，設計者首先要做的是重建需求秩序，就像手裡抓了一把雜糧，先把小米、大米、麥子分開歸類、這樣我們才能更好的觀察、研究這些需求的本質意義。

2.優先順序評估方法
優先順序評估方法1：需求分級法
卡諾模型、馬斯諾模型等已經對需求做了大概分組，可按層級逐步滿足用戶。對於卡諾模型，先滿足基本型需求，在滿足期望型需求，最後是興奮型需求；對於馬斯諾模型，先滿足低層次的需求。

2）用戶基本需求沒有滿足，緊急重要
3）產品的核心指標不滿足，影響公司營收和成本，目標導向型需求，緊急重要。如為提高注冊激活率而優化注冊流程，為提高DAU而做的每日簽到抽獎。
4）戰略型需求，可能是緊急重要，也可能是重要但不緊急。看需求目標是什麼，狙擊競爭對手的一般都是緊急；公司已處於行業領先地位，且需進一步加深護城河的，一般都重要，但沒那麼著急。
5）業務痛點問題，不解決難以做事，效率低下。一般2B類產品居中，需求偏管理、流程。企業內部的運作效率都很重要，是否緊急要看具體需求。

優先順序評估方法3：威格斯公式。在《軟體需求》一書中，作者介紹了一種需求優先順序量化的辦法，這里簡單介紹一下。
優先順序=價值%/（成本%+風險%）
收益：實現需求帶來的收益
損失：不實現需求有什麼損失
成本：實現需求要花費的成本
風險：實現需求要承擔的風險
舉例：對R1-R4四個需求要排定優先順序
計算步驟：
1、設置相對收益的權重為2，相對損失的權重為1，相對成本的權重為1，相對風險的權重為0.5。這個權重可以根據公司的實際情況來設定，如剛起步的創業項目，沒有太多業績包袱，成本和風險相對較小，無非就是時間、幾個人員投入、一點點錢，但是做成功的話收益就會很好，所以相對收益就設置大一些。對於成熟的項目，業務體量可能很大了，做任何需求可能獲得的相對收益都小，而風險可能會大一些。
2、錄入R1-R4的相對收益、相對損失、相對風險，並在表中對R1-R4的各項指標求和。這里的值都是相對的，可以以R1為基準，或找一個已經實現的需求R0當參考，用R1-R4與R0對比。表中是以一個已經實現的需求R0為參照。
3.計算總價值和相對價值佔比（價值%）。R1總價值=R1相對收益 相對收益權重+R1的相對損失 相對損失權重=2 2+4 1=8。R2-R4同理。然後求總價值∑R=R1的總價值+R2總價值+...Rn總價值。Rn價值%=Rn總價值/∑R
4.計算各需求的相對成本佔比（成本%）、相對風險佔比（風險%）
5.計算優先順序系數a=價值%/（成本%+風險%），最終得出優先順序結論R2>R1>R4>R3

威格斯公式法的好處是量化了需求優先順序，從價值、損失、成本、風險四個維度綜合評估需求，相對來說比四象限法更理性一些。但從實際工作中情況看，決定需求優先順序的因素很多，以上辦法能幫設計者更好的理解需求價值，弱化噪音干擾，更聚焦需求本身。

完全照搬方法亦不可取，市場瞬息萬變，善用數據，把握時機更重要