1、從概念到產品需求分析過程Something about grammar & literature.2開場的話.3引子：不僅僅純技術人文比科技重要！方法比技藝重要！初做者有閱歷者監視者專家管理者高級專家指點者資深專家.4學習態度？一天，三年甲班的楊過忘了交作業，導師郭靖問他：“為什么沒交作業？ 楊過答曰：“作業為什么要交？交了不一定是本人寫的； 寫了又不一定會；不小心破了珍瓏的虛竹不好意思地看了逍遙子一眼 會了又不一定會考；苦心預備當盟主的左冷禪背后響起悶響 考了又不一定會過；白眉鷹王身邊秋風吹過陣陣凄涼的落葉 過了又不一定能畢業；被古墓派退學的李莫愁神色一變 畢業又不一定會找到任務；樂天的令狐

2、沖正在酒醉中沒聽見 找得到任務又不一定保得住任務；蕭峰奪門而出 ？ 只見現場沉默三秒之后，眾人聯手圍毆楊過.5先從語法課講起用戶是一個或者多個名詞；產品是名詞，普通由很多個名詞組成；產品設計過程功能需求就是找出“動賓短語的集合性能需求就是找出“描畫詞的集合.6訂書機為例僅供參考產品訂書機: n. 一種裝訂文件的文具訂書機包括：杠桿構造：n.進釘構造；n.壓釘構造；n.釘書釘(耗費品):n.用戶用戶：n. 運用訂書機的人，應大于3周歲；且有手或者類似可以發出至少1kg力量的人。最常用(80%以上)為女性(21-40)。需求功能需求裝訂文件；Load釘書釘；Unload釘書釘；性能需求外觀、顏色、

3、省力、材質.7產品設計過程定義好用戶定義好產品先分析功能需求再分析性能需求80/20的誤區：產品日趨同質化，公司之間的差別，市場競爭的成敗，往往是由性能決議.8互聯網本質論計算機為什么叫計算機？互聯網其實是一個大數據庫大部分運用都是數據庫運用Search?B2B、B2C、C2C?Gaming? Avatar？Blog?小部分運用是即時的存儲轉發類IMVoIP復習數據庫的知識!.9課程概述.10課程內容Use Case分析方法找尋用戶定義產品開掘功能需求性能需求的“套路需求文檔的撰寫產品經理常用“技法任務組織方法常用圖表和繪圖方法.11需求分析與人文需求分析是一個工業化的寫作過程80的套路20的

4、創意好的語文程度：有利于抓住關鍵詞匯有利于培育數字敏感有利于加強描畫才干有利于組織文檔構造有利于提高溝通才干讀書吧！寫博客吧！.12Use Case分析法.13USE-CASE的歷史1967年Jacobson在愛立信任務的時候開場運用這種思想這種想法最早運用于大型交換機系統的需求獲取1971年完成了這種方法的最初原型1985年推出了改良版，并發布了面向對象的OOSE方法大部分面向對象技術都采用這種需求方法，UML建模言語也已將它包容進去它還被廣泛的運用于工業領域.14需求獲取的前提用戶必需通知他他想要什么他必需完好地了解用戶的業務他必需知道與系統有關的任何人和任何東西假設用戶不能通知他他們想要

5、什么，他必需破費時間去察看和記錄他們如今是怎樣任務的從專家那里了解用戶業務的原理和規那么他是去了解要做什么而不是怎樣做.15首先，您需求把系統看成黑盒一開場就深化細節的產品經理，忙亂而又沒有績效往往墮入細節的泥坑，甚至是技術細節，甚至UI細節被層出不窮的需求點和例外處置困擾控制不住滿腦袋亂冒的ideas請置信！系統內部無論多么復雜他總是可以被“運用闡明書說清楚.16Actor.17需求分析的第一個問題誰是這個產品的用戶？或者，誰是這個產品系統中的角色？.18什么是角色(Actor)與系統發生交互作用的、系統之外的任何東西都是角色可以是人也可以是機器角色不等同于運用者角色存在于系統外部角色不是活

6、動的準確描畫運用者是行駛某個角色職責的系統的運用人員如小王是個采購員我是角色Actor！.19角色續每個Actor都經過不同的方式運用系統，除非他們是一樣的ActorActor運用系統的每一種方式就是一個Use Case群普通用戶群管理員群股東群創建者群股東.20角色分類自動角色：Use Case的動作序列是由他先發起的，通常系統前往最后結果主叫方，采購人員，票據錄入員等被動角色：系統經過調用角色來完成Use Case的動作序列或其中的某一個動作不是初始動作的發起者當系統需求它們協助的時候最終是為了滿足自動角色的需求通常是機器或其他系統ActorUse Case1Use Case2ActorA

7、ctor.21Script.22腳本Script腳本是一個角色與系統之間的一組交互作用通常具有詳細的真實數據及實踐的期望輸出值一個運用系統能夠具有成千上萬個腳本即使同一件事，所得到的腳本能夠也會有細微的區別腳本是描畫Use Case的重要的背景信息.23腳本例如1：小王輸入他的賬號#4972：小王輸入他的密碼#1198233：小王查詢98.7.1至98.12.31日之間的平均余額4：系統顯示余額1：小張輸入他的賬號#4133432：小張輸入他的密碼#6467883：小張查詢98.3.1至98.5.31日之間的平均余額4：系統顯示余額1：小李輸入她的賬號#3467802：小李輸入她的密碼#435

8、6453：小李查詢98.7.1至98.12.31日之間的平均余額4：系統顯示余額.24腳本與Use Case一個Use Case代表一組潛在的腳本經過研討一組類似的腳本，可以得到它們內在的邏輯類似的腳本通常遵照類似的方式任務，并提供類似類型的結果一個Use Case通常關注某一個目的例如：查詢存折余額Use Case.25Use Case.26轉讓群經過Use Case描畫系統功能需求一個系統具有無限個潛在的腳本但一個系統可以被有限的Use Case完好闡明系統的每一個Use Case都必需列舉，否那么系統將會脫漏功能創建群解散群參與群資助群約請參與群群內發言授權群管理.27Use Case描

9、畫系統提供的交互功能一個Use Case可以被其他的Use Case調用Use Case可以組合完成某一項更大的功能Use Case闡明系統需求提供什么而不是怎樣提供用戶并不關懷他如何給他們提供所需求的功能Use Case普通是用“動賓短語命名創建群解散群參與群資助群約請參與群群內發言授權群管理.28Use CaseUse Case不是分析設計文檔雖然它們支持后續的分析設計任務Use Case不是操作腳本它不是用戶運用系統時實踐操作的詳細步驟的記錄雖然它能夠是經過操作腳本得來的.29Use Case是很好的測試單元Use Case明晰地描畫了系統的功能界面測試人員可以在開發初期制定測試方案每一

10、個Use Case都嚴厲地闡明了系統的某一項功能它的輸入它的輸出期間的交互作用Use Case是黑盒測試的基準.30Use Case的論述應該包含Use Case的一切重要細節應該包括角色與系統交互的關鍵步驟，可以運用順序圖Sequence Diagram要表述有關角色的信息要分清哪些是角色所具有的職能、哪些是系統所應提供的要列清運用這些功能是所應滿足的前提條件假設某些功能具有質量上的要求如性能，也要列出來創建群DdddddddddddDddddxxafsdfadsDdddddddddddDdddfcadsfasdddddccdasdwe.31Use Case：標志方法簡單Actor稱號Use

11、 Case稱號.32Use Case：自動角色經紀人下單投資人報價審查貨幣存取經紀管理系統.33Use Case：被動角色經紀人下單投資人報價審查貨幣存取經紀管理系統銀證轉賬系統.34畫Use Case圖規那么自動角色畫在圖的左邊被動角色畫在圖的右邊每個Use Case必需為用戶提供確切的功能Use Case稱號必需寫在橢圓里面堅持圖面整潔每一張圖里不能有太多的Use Case為每一個Use Case編號便于檢索為Use Case建立目錄編號和稱號便于管理.35Use Case 高級概念.36Use Case高級概念經過分析Use Case圖，分析人員可以找出不同的業務過程之間的共性擴展、包含

12、、派生、運用等關系經過這些關系可以降低系統的復雜度為重用提供了條件將共性提出來，可以協助我們發現反復的過程二次開發應該關注的地方.37Actor 的承繼類似于Use Case的擴展，角色之間可以承繼其他銀行不僅具有儲戶的一切功能，還有其他的功能.38Actor 承繼的益處在不喪失信息的前提下，簡化了Use Case圖承繼闡明了角色間的層次關系派生者承繼了父角色的一切才干父角色不知道派生者.39擴展關系：extend擴展關系通常用來表示某一個Use Case的可選擇部分擴展關系允許分析人員在沒有改動基Use Case的情況下添加或修正基Use Case的功能復雜的可替代途徑應該運用擴展關系把它們

13、分成多個Use Case也可以這樣看擴展關系：在基Use Case上插入功能，而基Use Case本身不知道這個擴展.40擴展關系(extend )示圖.41運用關系假設Use Case A包含Use Case B，表示在執行Use Case的動作序列過程中，在某一點上將開場執行Use Case B的動作序列，完成后將回到同一點上繼續執行完Use Case A的動作序列它與擴展關系的區別是：擴展是可選的包含是必做的更象一個子過程和擴展關系一樣，一個Use Case可以包含很多個子Use Case，也可以被很多個父Use Case所包含.42包含關系(include)例如.43包含關系(incl

14、ude)示圖.44關于擴展和包含關系.45Use Case開掘實操.46Use Case開掘過程定義Actor開掘Actor運用系統的腳本Script總結Use Case組合研討Actor之間的承繼關系研討Use Case之間的include、extend關系貫穿一直：維護一套詞匯表CE.47詞匯表！詞匯表！詞匯表有多重要?可以建巴別塔代碼中的變量需求文檔的重要組成部分和線索維護詞匯表應該是產品團隊最重要的任務之一Buddy？面板聯絡人？通訊錄聯絡人？好友？手機好友？QQ聯絡人？郵件好友？IM聯絡人？過濾聯絡人？.48詞匯表例如：被叫號碼本節所述之被叫號碼，其格式要求為：符合E.164號碼編號

15、方案規范。對于PBX分機號碼，應為18位數字；對于普通號碼，合法格式為：以“+、“-分隔的1-21位數字字符串；可選包含以“+引導的國家代碼；如+86代表中國，+1代表美國；必需包含地域代碼和號碼，其間用“-分隔；如26441099假設包含國家代碼，那么地域代碼的長途前綴如“0應省略；如+86-755-26441099；+86-10-38454233假設某外線號碼包含分機號碼，其間用“-分隔；如26551099-384；+86-755-26551099-384對于中國挪動號碼，合法格式為：國家代碼和挪動號碼如+86-09345659或挪動號碼如09345659，在被

16、叫號碼中無需根據對外地手機參與0前綴。不包含Omni PCX交換機的外線撥號前綴。如某Omni PCX交換機的外線撥號前綴為“9，但在RTX系統中的號碼資料中不需求具備這個外線撥號前綴。.49Use Case的Pattern大部分互聯網效力本質上是DB：增刪改查導入導出批量操作計算機運用的根底支撐功能：安裝卸載啟動停頓重啟動OAM運營、管理、監視.50自定義頭像的Use Case用戶Server組管理員PMM第三方頭像CP設置自定義頭像從本機設置從網絡硬盤設置從第三方系統設置 第三方頭像系統網絡硬盤系統添加第三方CP查看頭像運營數據.51Use Case論述.52Use Case：開場走向需求

17、規格闡明書Use Case圖并不是需求文檔的必備部分Use Case分析是過程，不是結果Use Case論述，等于：.53Use Case論述的根本四要素進入條件描畫Use Case在何種情況下進入如用戶必需具備什么條件？之前發生了什么？根本流程不思索任何異常例外，沒有if then else從用戶角度論述Use Case如何運作終了條件Use Case勝利終了后，發生了什么變化用戶發生什么變化？系統發生什么變化？例外流程逐個論述在根本流程中某個環節出現異常時的處置.54Use Case論述的幾個制止制止假設系統由哪些技術實現模塊組成“系統從效力器根底DB中刪除好友關系制止假設用戶可以運用哪些

18、UI界面“系統彈出錯誤提示窗口制止運用沒有主謂賓的語句“給出提示制止運用沒有任何意義、意義不全的語句“系統給出形狀提示信息“系統立刻顯示、“等、“或者、“其他、“通常制止給出沒有值域的定義“系統顯示天氣溫度信息.55Use Case 論述的逐漸細化 1 根本流程a)當郵件用戶要求管理郵件信息時功能夾啟動，系統顯示信息。b)郵件用戶可以按照以下的一個或多個步驟執行：c)按照發送這或主題整理郵件信息；d)閱讀郵件信息的內容；e)把郵件信息保管為文件；f)把郵件信息的附件保管為文件；g)當郵件用戶要求退出管理新來郵件信息時，功能夾終止。.56Use Case 論述的逐漸細化 2 期望擴展a)當郵件用

19、戶要求管理郵件信息時功能夾啟動，系統顯示信息。用戶必需可以區分新的、已讀過的、未讀過的音訊。用戶還必需可以看見每個音訊的發送者、主題和優先級。b)郵件用戶可以按照以下的一個或多個步驟執行：c)按照發送這或主題整理郵件信息；d)閱讀郵件信息的內容；e)把郵件信息保管為文件；f)把郵件信息的附件保管為文件； 用戶必需可以看見附件的文件類型 g)當郵件用戶要求退出管理新來郵件信息時，功能夾終止。.57Use Case 論述的逐漸細化 3 補充值域a)當郵件用戶要求管理郵件信息時功能夾啟動，系統顯示信息。用戶必需可以區分新的、已讀過的、未讀過的音訊。用戶還必需可以看見每個音訊的發送者、主題和優先級。

20、平均每100個同時顯示的未讀郵件音訊中，其中90%的音訊主題行少于40個字符。b)郵件用戶可以按照以下的一個或多個步驟執行：c)按照發送這或主題整理郵件信息；d)閱讀郵件信息的內容； 平均音訊內容包括100字符。 e)把郵件信息保管為文件；f)把郵件信息的附件保管為文件； 用戶必需可以看見附件的文件類型 這種情況下，95%的郵件都少于2個附件。 g)當郵件用戶要求退出管理新來郵件信息時，功能夾終止。.58Use Case 論述的逐漸細化 4 補充發生概率a)當郵件用戶要求管理郵件信息時功能夾啟動，系統顯示信息。用戶必需可以區分新的、已讀過的、未讀過的音訊。用戶還必需可以看見每個音訊的發送者、主

21、題和優先級。 平均每100個同時顯示的未讀郵件音訊中，其中90%的音訊主題行少于40個字符。b)郵件用戶可以按照以下的一個或多個步驟執行：c)按照發送這或主題整理郵件信息；(在這種情況下，有超越60%做了此項操作。) d)閱讀郵件信息的內容； 平均音訊內容包括100字符。 e)把郵件信息保管為文件；(在這種情況下，少于5%做了此項操作。) f)把郵件信息的附件保管為文件； 用戶必需可以看見附件的文件類型 這種情況下，95%的郵件都少于2個附件。 (在這種情況下，有少于30%做了此項操作。) g)當郵件用戶要求退出管理新來郵件信息時，功能夾終止。.59Use Case論述后發現詞匯，并給以定義詳

22、細的解釋，值域的描畫構成需求文檔中的“定義發現功能需求和性能需求整理文字，形勝利能需求規格闡明和性能需求闡明.60性能需求.61性能需求的Pattern性能目的易用性平安性兼容性可擴展性可維護性可延展性可移植性可編程性可靠性可測試性產品關注技術關注.62性能需求的專業化撰寫態度產品經理應忘記本人懂技術、交互從用戶、市場角度把要求提出來弄清楚本人的專業開展方向User-Oriented，Market-Oriented其他的，無妨“扮豬吃老虎.63Good News：天下文章一大抄在一個產品系統中，性能需求是可以Copy的第一份性能需求是重點，大家一同作之后的需求文檔往往只需改動：性能目的可擴展性

23、易用性可延展性平安性兼容性可維護性可移植性可編程性可靠性可測試性這里簡簡單單幾句話要求，讓開發同事、設計師作半年.64需求規格闡明書.65沒有高質量的需求軟件就象一個巧克力的盒子他不會知道他將要得到什么.66高質量需求表達的特性正確 可行性 必要性 優先權 明確 可證明 .67高質量需求表達的特性 1/6正確：每個需求必需準確描畫要交付的功能。正確性根據于需求的來源，如真實的客戶或高級別的系統需求闡明書。只需用戶的代表可以決議用戶需求的正確性，這就是為什么在檢查需求時，要包括他們或他們的代理的關鍵所在。不包括用戶的需求檢查就會導致開發人員的：“這是沒意義的，“這能夠是他們的意思等眾所周知的猜測

24、。.68高質量需求表達的特性 2/6可行性：在知的才干、有限的系統及其環境中每個需求必需是可實現的。為了防止需求的不可行性，在需求分析階段應該有一個開發人員參與，這個開發人員應能檢查在技術上什么能做什么不能做哪些需求需求額外的付出或者和其他的權衡。 在籠統階段應該有市場人員參與。.69高質量需求表達的特性 3/6必要性：每個需求應載明什么是客戶確實需求的，什么要順應于外部的需求，接口或規范。每個需求源于他認可或者具有授權的原始資料跟蹤每個需求回溯到出處，如用例，系統需求，規章，或來自其他用戶特別是Boss的意見。假設他不能標識出處，能夠需求只是個鍍金的例子，沒有真正的必需。.70高質量需求表達

25、的特性 4/6優先權：為了闡明在一個詳細的產品版本中應包含哪些要點，需求為每個需求，特征，或用例分配實現的優先權?？蛻艋蚱浯矶紤袆×业呢熑谓炏葯唷＜僭O一切的需求都被視為同等重要，那么由于在開發中，預算削減，方案超時或組員的分開導致新的需求時， 工程經理將不能起到作用。優先權的作用是提供應客戶的價值，實現的相關費用，實現相關聯的有關技術風險。Must Have, Nice To Have, Can Delay.71高質量需求表達的特性 5/6明確：需求表達的讀者應只能從其得到獨一的解釋闡明，同樣，一個需求的多個讀者也應達成共識。自然言語極易導致模糊。要防止運用一些對于SRS作者很清楚但對

26、于讀者不清楚的客觀詞匯，如：用戶友好性，容易，簡單，快速，有效，幾個，藝術級，改善的，最大，最小等等。每寫一個需求都應簡約，簡單，直觀的采用用戶熟知的言語，不要采用計算機術語。檢查需求模糊的有效方式包括需求闡明書的正規檢查，根據需求寫測試，建立用戶的假想來闡明產品某個特定部分預期的特性。.72高質量需求表達的特性 6/6可證明：看他能否可以做出測試方案或其他驗證方式，如檢查和實證，來決議在產品中每個需求能否正確的實現。假設需求是不可驗證的，決議需求是不是正確的實現就成了判別的事。需求之間不一致，不可行，不明確也能導致不可證明。任何需求假設說產品將要支持什么也是不可證明的。.73高質量需求闡明書

27、的特征完好 一致性 可修正性 可追蹤 .74高質量需求闡明書的特征 1/4 完好：不應該脫漏要求和必需的信息。完好性也是一個需求應具備的。發現短少的信息很難，由于根本不存在。在SRS中將需求以分層目錄方式組織，將協助評審人員了解功能性描畫的構造，使他們很容易指出遺失的東西。在需求籠統上，運用Use Case方法會發揚很好的作用?？梢詮牟煌嵌炔炜葱枨蟮膱D形分析模型也可以檢查出不完好性。運用TBDto be determined規范標志知的缺失當他在構建產品的相關部分時，就可以從一個給定的需求集中處理一切的缺陷。如“Vista表現.75高質量需求闡明書的特征 2/4 一致性：一致性需求就是不要于

28、其他的軟件需求或高級別的系統商業需求發生沖突。需求中的不一致必需在開發開場前得到處理。只需經過調研才干確定哪些是正確的。修正需求時一定要謹慎假設只審定修正的部分，沒有審定于修正相關的部分，就能夠導致不一致性。.76高質量需求闡明書的特征 3/4 可修正性：當每個需求的要求修正了或維護其歷史更改時，他必需可以審定SRS。每個需求必需相對于其他需求有其單獨的標示和分開的闡明，便于明晰的查閱。經過良好的組織可以使需求易于修正，如：將相關的需求分組，建立目錄表，索引，以及前后參考Feature List.xls 是很好的工具.77高質量需求闡明書的特征 4/4 可追蹤：應能將一個軟件與其原始資料相對應

29、如高級系統需求，用例，用戶的提議等?？梢詫④浖枨笈c設計元素，源代碼，用于構造實現和驗證需求的測試相對應?？勺粉櫟男枨髴摼哂歇毩耸?，細密和構造化的編寫，不應過大，不應是表達性的文字和公告式的列表。.78幾個不好的需求“產品應在不少于每60秒？的正常周期？內提供形狀信息“產品應瞬間在顯示和隱藏不可打印字符間切換 “HTML分析器可以產生HTML標志錯誤報告，協助HTML入門者快速處理錯誤?！凹僭O能夠，主管號碼應經過聯機校驗，而不是經過主全體主管號碼列表校驗。 .79編寫高質量需求的方針句子和段落要短采用自動語氣運用正確的語法，拼寫，標點運用術語堅持一致性，并在術語表或數據字典中定義它們以開發人員的觀念看需求能否被有效的定義需求編寫者還要努力正確地把握細化程度要防止包含多個需求的長的表達段落把正常流程和異常流程分開親密關注多個需求合成了單個需求 通篇文檔細節上要堅持一致防止在SRS中過多的反復需求在多處包含一樣的需求可以使文檔更易于閱讀，但也會給文檔的維護添加困難。文檔的多份文本要在同一時間內全部更新，防止不一致性。運用Word的“超鏈接功能！換位思索，不要太自信Review再Revi