1、something about grammar & literature2開始的話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? 小部分應用是即時的存儲轉發類 im voip復習數據庫的知識!9課程概述10 use case分析方法 找尋用戶 定義產品 發掘功能需求 性能需求的“套路” 需求文檔的撰寫 產品經理常用“技法” 工作組織方法 常用圖表和繪圖方法11 需求分析是一個工業化的寫作過程 80的套路2

4、0的創意 好的語文水平： 有利于抓住關鍵詞匯 有利于培養數字敏感 有利于增強形容能力 有利于組織文檔結構 有利于提高溝通能力讀書吧！寫博客吧！12use case分析法13 1967年jacobson在愛立信工作的時候開始使用這種思想 這種想法最早應用于大型交換機系統的需求獲取 1971年完成了這種方法的最初原型 1985年推出了改進版，并發布了面向對象的oose方法 大部分面向對象技術都采用這種需求方法，uml建模語言也已將它包容進去 它還被廣泛的應用于工業領域14 用戶必須告訴你他想要什么 你必須完整地了解用戶的業務 你必須知道與系統有關的任何人和任何東西 如果用戶不能告訴你他們想要什么，

5、你必須花費時間去觀察和記錄他們現在是怎么工作的 從專家那里了解用戶業務的原理和規則 你是去了解要做什么而不是怎么做15 一開始就深入細節的產品經理，忙亂而又沒有績效 往往陷入細節的泥坑，甚至是技術細節，甚至ui細節 被層出不窮的需求點和例外處理困擾 控制不住滿腦袋亂冒的ideas 請相信！ 系統內部無論多么復雜 他總是可以被“使用說明書”說清楚16actor17誰是這個產品的用戶？或者，誰是這個產品系統中的角色？18 與系統發生交互作用的、系統之外的任何東西都是角色 可以是人 也可以是機器 角色不等同于使用者 角色存在于系統外部 角色不是活動的準確描述 使用者是行駛某個角色職責的系統的使用人員

6、 如小王是個采購員我是角色actor！19 每個actor都通過不同的方式使用系統，除非他們是相同的actor actor使用系統的每一種方式就是一個use case群普通用戶群管理員群股東群創建者群股東20 主動角色：use case的動作序列是由他先發起的，通常系統返回最后結果 主叫方，采購人員，票據錄入員等 被動角色：系統通過調用角色來完成use case的動作序列（或其中的某一個動作） 不是初始動作的發起者 當系統需要它們幫助的時候 最終是為了滿足主動角色的需要 通常是機器或其他系統actoruse case1use case2actoractor21script22 腳本是一個角色與

7、系統之間的一組交互作用 通常具有詳細的真實數據及實際的期望輸出值 一個應用系統可能具有成千上萬個腳本 即使同一件事，所得到的腳本可能也會有細微的區別 腳本是描繪use case的重要的背景信息231：小王輸入他的賬號#4135972：小王輸入他的密碼#1198233：小王查詢98.7.1至98.12.31日之間的平均余額4：系統顯示余額1：小張輸入他的賬號#4133432：小張輸入他的密碼#6467883：小張查詢98.3.1至98.5.31日之間的平均余額4：系統顯示余額1：小李輸入她的賬號#3467802：小李輸入她的密碼#4356453：小李查詢98.7.1至98.12.31日之間的平均

8、余額4：系統顯示余額24 一個use case代表一組潛在的腳本 通過研究一組相似的腳本，可以得到它們內在的邏輯 相似的腳本通常遵循相似的模式工作，并提供相似類型的結果 一個use case通常關注某一個目標 例如：查詢存折余額腳本功能夾use case25use case26轉讓群 一個系統具有無限個潛在的腳本 但一個系統可以被有限的use case完整說明 系統的每一個use case都必須列舉，否則系統將會遺漏功能創建群解散群加入群贊助群邀請加入群群內發言授權群管理27 描述系統提供的交互功能 一個use case可以被其他的use case調用 use case可以組合完成某一項更大的

9、功能 use case說明系統需要提供什么而不是怎么提供 用戶并不關心你如何給他們提供所需要的功能 use case一般是用“動賓”短語命名創建群解散群加入群贊助群邀請加入群群內發言授權群管理28 use case不是分析設計文檔 雖然它們支持后續的分析設計工作 use case不是操作腳本 它不是用戶使用系統時實際操作的具體步驟的記錄 雖然它可能是通過操作腳本得來的29 use case清晰地描述了系統的功能界面 測試人員可以在開發初期制定測試計劃 每一個use case都嚴格地說明了系統的某一項功能 它的輸入 它的輸出 期間的交互作用 use case是黑盒測試的基準30 應該包含use

10、case的所有重要細節 應該包括角色與系統交互的關鍵步驟，可以使用順序圖（sequence diagram） 要表述有關角色的信息 要分清哪些是角色所具有的職能、哪些是系統所應提供的 要列清使用這些功能是所應滿足的前提條件 如果某些功能具有質量上的要求（如性能），也要列出來創建群dddddddddddddddddxxafsdfadsddddddddddddddddfcadsfasdddddccdasdwe31actor名稱use case名稱32經紀人下單投資人報價審查貨幣存取經紀管理系統33經紀人下單投資人報價審查貨幣存取經紀管理系統銀證轉賬系統34 主動角色畫在圖的左邊 被動角色畫在圖的右

11、邊 每個use case必須為用戶提供確切的功能 use case名稱必須寫在橢圓里面 保持圖面整潔 每一張圖里不能有太多的use case 為每一個use case編號便于檢索 為use case建立目錄（編號和名稱）便于管理35use case 高級概念36 通過分析use case圖，分析人員可以找出不同的業務過程之間的共性 擴展、包含、派生、使用等關系 通過這些關系可以降低系統的復雜度 為重用提供了條件 將共性提出來，可以幫助我們發現重復的過程 二次開發應該關注的地方37 類似于use case的擴展，角色之間可以繼承 其他銀行不僅具有儲戶的所有功能，還有其他的功能查詢余額存錢儲戶銀行

12、取錢費用結算其他銀行38 在不丟失信息的前提下，簡化了use case圖 繼承說明了角色間的層次關系 派生者繼承了父角色的所有能力 父角色不知道派生者39 擴展關系通常用來表示某一個use case的可選擇部分 擴展關系允許分析人員在沒有改變基use case的情況下增加或修改基use case的功能 復雜的可替代途徑應該使用擴展關系把它們分成多個use case 也可以這樣看擴展關系： 在基use case上插入功能，而基use case本身不知道這個擴展使用柜員機查詢余額擴展用戶選擇查詢余額40查詢余額存錢柜員機用戶柜員機取錢使用柜員機擴展用戶選擇查詢余額擴展用戶選擇存錢擴展用戶選擇取錢4

13、1 如果use case a包含use case b，表示在執行use case的動作序列過程中，在某一點上將開始執行use case b的動作序列，完成后將回到同一點上繼續執行完use case a的動作序列 它與擴展關系的區別是： 擴展是可選的 包含是必做的（更象一個子過程） 和擴展關系一樣，一個use case可以包含很多個子use case，也可以被很多個父use case所包含存錢打印單據包含421.輸入員工信息2.輸入工資額3.輸入職位4.保存5.系統進行合法化檢查6.如果正常，系統建立新的員工記錄1. 攝像2. 插入空白卡3. 新建工卡包含的插入點父功能夾“ 增加新員工”子功能夾

14、“ 新建工卡”43查詢余額存錢柜員機用戶柜員機取錢使用柜員機擴展用戶選擇查詢余額擴展用戶選擇存錢擴展用戶選擇取錢打印單據包含包含4445use case發掘實操46 定義actor 發掘actor使用系統的腳本script 總結use case組合 研究actor之間的繼承關系 研究use case之間的include、extend關系 貫穿始終：維護一套詞匯表ce47 詞匯表有多重要? 可以建巴別塔 代碼中的變量 需求文檔的重要組成部分和線索 維護詞匯表應該是產品團隊最重要的工作之一buddy？面板聯系人？通訊錄聯系人？電話好友？手機好友？qq聯系人？郵件好友？im聯系人？過濾聯系人？48本

15、節所述之被叫號碼，其格式要求為：符合e.164電話號碼編號計劃規范。對于pbx分機號碼，應為18位數字；對于普通電話號碼，合法格式為：以“+”、“-”分隔的1-21位數字字符串；可選包含以“+”引導的國家代碼；如+86代表中國，+1代表美國；必須包含地區代碼和電話號碼，其間用“-”分隔；010-38454233；如果包含國家代碼，則地區代碼的長途前綴（如“0”）應省略；如+86-755-26441099；+86-10-38454233如果某外線號碼包含分機號碼，其間用“-”分隔；384；+86-755-26551099-384對于中國

16、移動電話號碼，合法格式為：國家代碼和移動電話號碼移動電話號碼在被叫號碼中無需根據對外地手機加入0前綴。不包含omni pcx交換機的外線撥號前綴。如某omni pcx交換機的外線撥號前綴為“9”，但在rtx系統中的電話號碼資料中不需要具備這個外線撥號前綴。rtx omni pcx插件軟件需求規格說明書.doc49 大部分互聯網服務本質上是db： 增刪改查 導入導出 批量操作 計算機應用的基礎支撐功能： 安裝卸載 啟動停止重啟動 oam（運營、管理、監視）50用戶server組管理員pmm第三方頭像cp設置自定義頭像從本機設置從網絡硬盤

17、設置從第三方系統設置 第三方頭像系統網絡硬盤系統extendextendextend添加第三方cp查看頭像運營數據51use case闡述52 use case圖并不是需求文檔的必備部分 use case分析是過程，不是結果 use case闡述，等于：53 進入條件 描述use case在何種情況下進入 如用戶必須具備什么條件？之前發生了什么？ 基本流程 不考慮任何異常例外，沒有if then else 從用戶角度闡述use case如何運作 結束條件 use case成功結束后，發生了什么變化 用戶發生什么變化？系統發生什么變化？ 例外流程 逐個闡述在基本流程中某個環節出現異常時的處理54

18、 禁止假設系統由哪些技術實現模塊組成 “系統從服務器基礎db中刪除好友關系” 禁止假設用戶可以使用哪些ui界面 “系統彈出錯誤提示窗口” 禁止使用沒有主謂賓的語句 “給出提示” 禁止使用沒有任何意義、意義不全的語句 “系統給出狀態提示信息” “系統立即顯示”、“等”、“或者”、“其他”、“通常” 禁止給出沒有值域的定義 “系統顯示天氣溫度信息”55a)當郵件用戶要求管理郵件信息時功能夾啟動，系統顯示信息。b)郵件用戶可以按照以下的一個或多個步驟執行：c)按照發送這或主題整理郵件信息；d)閱讀郵件信息的內容；e)把郵件信息保存為文件；f)把郵件信息的附件保存為文件；g)當郵件用戶要求退出管理新來

19、郵件信息時，功能夾終止。56a)當郵件用戶要求管理郵件信息時功能夾啟動，系統顯示信息。用戶必須能夠區分新的、已讀過的、未讀過的消息。用戶還必須能夠看見每個消息的發送者、主題和優先級。b)郵件用戶可以按照以下的一個或多個步驟執行：c)按照發送這或主題整理郵件信息；d)閱讀郵件信息的內容；e)把郵件信息保存為文件；f)把郵件信息的附件保存為文件； 用戶必須能夠看見附件的文件類型 g)當郵件用戶要求退出管理新來郵件信息時，功能夾終止。57a)當郵件用戶要求管理郵件信息時功能夾啟動，系統顯示信息。用戶必須能夠區分新的、已讀過的、未讀過的消息。用戶還必須能夠看見每個消息的發送者、主題和優先級。 平均每1

20、00個同時顯示的未讀郵件消息中，其中90%的消息主題行少于40個字符。b)郵件用戶可以按照以下的一個或多個步驟執行：c)按照發送這或主題整理郵件信息；d)閱讀郵件信息的內容； 平均消息內容包括100字符。 e)把郵件信息保存為文件；f)把郵件信息的附件保存為文件； 用戶必須能夠看見附件的文件類型 這種情況下，95%的郵件都少于2個附件。 g)當郵件用戶要求退出管理新來郵件信息時，功能夾終止。58a)當郵件用戶要求管理郵件信息時功能夾啟動，系統顯示信息。用戶必須能夠區分新的、已讀過的、未讀過的消息。用戶還必須能夠看見每個消息的發送者、主題和優先級。 平均每100個同時顯示的未讀郵件消息中，其中9

21、0%的消息主題行少于40個字符。b)郵件用戶可以按照以下的一個或多個步驟執行：c)按照發送這或主題整理郵件信息；(在這種情況下，有超過60%做了此項操作。) d)閱讀郵件信息的內容； 平均消息內容包括100字符。 e)把郵件信息保存為文件；(在這種情況下，少于5%做了此項操作。) f)把郵件信息的附件保存為文件； 用戶必須能夠看見附件的文件類型 這種情況下，95%的郵件都少于2個附件。 (在這種情況下，有少于30%做了此項操作。) g)當郵件用戶要求退出管理新來郵件信息時，功能夾終止。59 發現詞匯，并給以定義 詳細的解釋，值域的描述 形成需求文檔中的“定義” 發現功能需求和性能需求 整理文字

22、，形成功能需求規格說明和性能需求說明60性能需求61 性能指標性能指標 易用性易用性 安全性安全性 兼容性兼容性 可擴展性可擴展性 可維護性可維護性 可延展性可延展性 可移植性可移植性 可編程性可編程性 可靠性可靠性 可測試性可測試性產品關注技術關注62 產品經理應忘記自己懂技術、交互 從用戶、市場角度把要求提出來 弄清楚自己的專業發展方向 user-oriented，market-oriented 其他的，不妨“扮豬吃老虎”63 在一個產品系統中，性能需求是可以copy的 第一份性能需求是重點，大家一起作 之后的需求文檔往往只需改變： 性能指標性能指標 可擴展性可擴展性 易用性易用性 可延展

23、性可延展性 安全性安全性 兼容性兼容性 可維護性可維護性 可移植性可移植性 可編程性可編程性 可靠性可靠性 可測試性可測試性這里簡簡單單幾句話要求，讓開發同事、設計師作半年64需求規格說明書65沒有高質量的需求沒有高質量的需求軟件就象一個巧克力的盒子軟件就象一個巧克力的盒子你不會知道你將要得到什么你不會知道你將要得到什么66 正確正確 可行性可行性 必要性必要性 優先權優先權 明確明確 可證實可證實 67 正確：正確： 每個需求必須精確描述要交付的功能。每個需求必須精確描述要交付的功能。 正確性依據于需求的來源，如真實的客戶或高級正確性依據于需求的來源，如真實的客戶或高級別的系統需求說明書。別

24、的系統需求說明書。 只有用戶的代表能夠決定用戶需求的正確性，這只有用戶的代表能夠決定用戶需求的正確性，這就是為什么在檢查需求時，要包括他們或他們的就是為什么在檢查需求時，要包括他們或他們的代理的關鍵所在。不包括用戶的需求檢查就會導代理的關鍵所在。不包括用戶的需求檢查就會導致開發人員的：致開發人員的：“這是沒意義的這是沒意義的”，“這可能是這可能是他們的意思他們的意思”等眾所周知的猜測。等眾所周知的猜測。68 可行性：可行性： 在已知的能力、有限的系統及其環境中每個需求在已知的能力、有限的系統及其環境中每個需求必須是可實現的。必須是可實現的。 為了避免需求的不可行性，在需求分析階段應該為了避免需

25、求的不可行性，在需求分析階段應該有一個開發人員參與，這個開發人員應能檢查有一個開發人員參與，這個開發人員應能檢查 在技術上什么能做什么不能做在技術上什么能做什么不能做 哪些需要需要額外的付出或者和其他的權衡。哪些需要需要額外的付出或者和其他的權衡。 在抽象階段應該有市場人員參與。在抽象階段應該有市場人員參與。69 必要性：必要性： 每個需求應載明什么是客戶確實需要的，什么要每個需求應載明什么是客戶確實需要的，什么要順應于外部的需求，接口或標準。順應于外部的需求，接口或標準。 每個需求源于你認可或者具有授權的原始資料每個需求源于你認可或者具有授權的原始資料 跟蹤每個需求回溯到出處，如用例，系統需

26、求，跟蹤每個需求回溯到出處，如用例，系統需求，規章，或來自其他用戶（特別是規章，或來自其他用戶（特別是boss）的意見。）的意見。 如果你不能標識出處，可能需求只是個鍍金的例如果你不能標識出處，可能需求只是個鍍金的例子，沒有真正的必須。子，沒有真正的必須。70 優先權：優先權： 為了表明在一個詳細的產品版本中應包含哪些要點，需為了表明在一個詳細的產品版本中應包含哪些要點，需要為每個需求，特征，或用例分配實現的優先權。要為每個需求，特征，或用例分配實現的優先權。 客戶或其代理都應有強烈的責任建立優先權。客戶或其代理都應有強烈的責任建立優先權。 如果所有的需求都被視為同等重要，那么由于在開發中，預

27、算削如果所有的需求都被視為同等重要，那么由于在開發中，預算削減，計劃超時或組員的離開導致新的需求時，減，計劃超時或組員的離開導致新的需求時， 項目經理將不能項目經理將不能起到作用。起到作用。 優先權的作用是提供給客戶的價值，實現的相關費用，優先權的作用是提供給客戶的價值，實現的相關費用，實現相關聯的有關技術風險。實現相關聯的有關技術風險。 must have, nice to have, can delay71 明確：明確： 需求敘述的讀者應只能從其得到唯一的解釋說明，同樣，需求敘述的讀者應只能從其得到唯一的解釋說明，同樣，一個需求的多個讀者也應達成共識。一個需求的多個讀者也應達成共識。 自然

28、語言極易導致含糊。要避免使用一些對于自然語言極易導致含糊。要避免使用一些對于srs作者作者很清楚但對于讀者不清楚的主觀詞匯，如：很清楚但對于讀者不清楚的主觀詞匯，如： 用戶友好性，容易，簡單，快速，有效，幾個，藝術級，改善的，用戶友好性，容易，簡單，快速，有效，幾個，藝術級，改善的，最大，最小等等。最大，最小等等。 每寫一個需要都應簡潔，簡單，直觀的采用用戶熟知的每寫一個需要都應簡潔，簡單，直觀的采用用戶熟知的語言，不要采用計算機術語。語言，不要采用計算機術語。 檢查需求模糊的有效方式包括需求說明書的正規檢查，檢查需求模糊的有效方式包括需求說明書的正規檢查，根據需求寫測試，建立用戶的假想來說明

29、產品某個特定根據需求寫測試，建立用戶的假想來說明產品某個特定部分預期的特性。部分預期的特性。72 可證實：可證實： 看你是否能夠做出測試計劃或其他驗證方式，如檢查和看你是否能夠做出測試計劃或其他驗證方式，如檢查和實證，來決定在產品中每個需求是否正確的實現。實證，來決定在產品中每個需求是否正確的實現。 如果需求是不可驗證的，決定需求是不是正確的實現就如果需求是不可驗證的，決定需求是不是正確的實現就成了判斷的事。成了判斷的事。 需求之間不一致，不可行，不明確也能導致不可證實。需求之間不一致，不可行，不明確也能導致不可證實。 任何需求如果說任何需求如果說產品將要支持什么產品將要支持什么也是不可證實的

30、。也是不可證實的。73 完整完整 一致性一致性 可修改性可修改性 可追蹤可追蹤 74 完整： 不應該遺漏要求和必需的信息。 完整性也是一個需求應具備的。 發現缺少的信息很難，因為根本不存在。 在srs中將需求以分層目錄方式組織，將幫助評審人員理解功能性描述的結構，使他們很容易指出遺失的東西。 在需求抽象上，應用use case方法會發揮很好的作用。 能夠從不同角度察看需求的圖形分析模型也可以檢查出不完整性。 使用tbd（to be determined）標準標志已知的缺失 當你在構建產品的相關部分時，就可以從一個給定的需求集中解決所有的缺陷。 如“vista表現”75 一致性：一致性： 一致性

31、需求就是不要于其他的軟件需求或高級別的系統（商業）需求發生沖突。 需求中的不一致必須在開發開始前得到解決。 只有經過調研才能確定哪些是正確的。 修改需求時一定要謹慎 如果只審定修改的部分，沒有審定于修改相關的部分，就可能導致不一致性。76 可修改性：可修改性： 當每個需求的要求修改了或維護其歷史更改時，你必須能夠審定srs。 每個需求必須相對于其他需求有其單獨的標示和分開的說明，便于清晰的查閱。 通過良好的組織可以使需求易于修改，如： 將相關的需求分組，建立目錄表，索引，以及前后參考 feature list.xls 是很好的工具77 可追蹤：可追蹤： 應能將一個軟件與其原始材料相對應 如高級

32、系統需求，用例，用戶的提議等。 能夠將軟件需求與設計元素，源代碼，用于構造實現和驗證需求的測試相對應。 可追蹤的需求應該具有獨立標示，細密和結構化的編寫，不應過大，不應是敘述性的文字和公告式的列表。78 “產品應在不少于每60秒（？）的正常周期（？）內提供狀態信息” “產品應瞬間在顯示和隱藏不可打印字符間切換” “html分析器可以產生html標記錯誤報告，幫助html入門者快速解決錯誤”。 “如果可能，主管號碼應通過聯機校驗，而不是通過主全體主管號碼列表校驗”。 79 句子和段落要短 采用主動語氣 使用正確的語法，拼寫，標點 使用術語保持一致性，并在術語表或數據字典中定義它們 以開發人員的觀點看需求是否被有效的定義 需求編寫者還要努力正確地把握細化程度 要避免包含多個需求的長的敘述段落 把正常流程和異常流程分開 密切關注多個需求合成了單個需求 通篇文檔細節上要保持一致 避免在srs中過多的重復需求 在多處包含相同的需求可以使文檔更易于閱讀，但也會給文檔的維護增加困難。文檔的多份文本要在同一時間內全部更新，避免不一致性。 使用word的“超鏈接”功能！換位思考，不要太自信