[學(xué)習(xí)]騰訊：從概念到產(chǎn)品-需求分析過(guò)程

1、從概念到產(chǎn)品－需求分析過(guò)程,Something about grammar & literature,2,開(kāi)始的話,3,引子：不僅僅純技術(shù),人文比科技重要！方法比技能重要！,初做者,有經(jīng)驗(yàn)者,監(jiān)督者,專(zhuān)家,管理者,高級(jí)專(zhuān)家,領(lǐng)導(dǎo)者,資深專(zhuān)家,4,學(xué)習(xí)態(tài)度？,一天，三年甲班的楊過(guò)忘了交作業(yè)，導(dǎo)師郭靖問(wèn)他：“為什么沒(méi)交作業(yè)？” 楊過(guò)答曰：“作業(yè)為什么要交？交了不一定是自己寫(xiě)的； 寫(xiě)了又不一定會(huì)；（不小心破了珍瓏的虛竹不好意思地

2、看了逍遙子一眼） 會(huì)了又不一定會(huì)考；（苦心準(zhǔn)備當(dāng)盟主的左冷禪背后響起悶響） 考了又不一定會(huì)過(guò)；（白眉鷹王身邊秋風(fēng)吹過(guò)陣陣凄涼的落葉） 過(guò)了又不一定能畢業(yè)；（被古墓派退學(xué)的李莫愁臉色一變） 畢業(yè)又不一定會(huì)找到工作；樂(lè)天的令狐沖正在酒醉中沒(méi)聽(tīng)見(jiàn)） 找得到工作又不一定保得住工作；（蕭峰奪門(mén)而出） ……？” 只見(jiàn)現(xiàn)場(chǎng)沉默三秒之后，眾人聯(lián)手圍毆楊過(guò)……,5,先從語(yǔ)法課講起,用戶(hù)是一個(gè)或者多個(gè)名詞；產(chǎn)品是名詞，一般由很多個(gè)名詞組成

3、；產(chǎn)品設(shè)計(jì)過(guò)程功能需求就是找出“動(dòng)賓短語(yǔ)”的集合性能需求就是找出“形容詞”的集合,6,訂書(shū)機(jī)為例（僅供參考）,產(chǎn)品訂書(shū)機(jī): n. 一種裝訂文件的文具訂書(shū)機(jī)包括：杠桿結(jié)構(gòu)：n.進(jìn)釘結(jié)構(gòu)；n.壓釘結(jié)構(gòu)；n.釘書(shū)釘(消耗品):n.,,,,,,,,用戶(hù)用戶(hù)：n. 使用訂書(shū)機(jī)的人，應(yīng)大于3周歲；且有手或者類(lèi)似可以發(fā)出至少1kg力量的人。最常用(80%以上)為女性(21-40)。,需求功能需求裝訂文件；Lo

4、ad釘書(shū)釘；Unload釘書(shū)釘；…性能需求外觀、顏色、省力、材質(zhì)….,7,產(chǎn)品設(shè)計(jì)過(guò)程,定義好用戶(hù)定義好產(chǎn)品先分析功能需求再分析性能需求,80/20的誤區(qū)：產(chǎn)品日趨同質(zhì)化，公司之間的差別，市場(chǎng)競(jìng)爭(zhēng)的成敗，往往是由性能決定,8,互聯(lián)網(wǎng)本質(zhì)論,計(jì)算機(jī)為什么叫計(jì)算機(jī)？互聯(lián)網(wǎng)其實(shí)是一個(gè)大數(shù)據(jù)庫(kù)大部分應(yīng)用都是數(shù)據(jù)庫(kù)應(yīng)用Search?B2B、B2C、C2C?Gaming? Avatar？Blog?小部分應(yīng)

5、用是即時(shí)的存儲(chǔ)轉(zhuǎn)發(fā)類(lèi)IMVoIP,復(fù)習(xí)數(shù)據(jù)庫(kù)的知識(shí)!,9,課程概述,10,課程內(nèi)容,Use Case分析方法找尋用戶(hù)定義產(chǎn)品發(fā)掘功能需求性能需求的“套路”需求文檔的撰寫(xiě)產(chǎn)品經(jīng)理常用“技法”工作組織方法常用圖表和繪圖方法,11,需求分析與人文,需求分析是一個(gè)工業(yè)化的寫(xiě)作過(guò)程80％的套路＋20％的創(chuàng)意好的語(yǔ)文水平：有利于抓住關(guān)鍵詞匯有利于培養(yǎng)數(shù)字敏感有利于增強(qiáng)形容能力有利于組織文檔結(jié)構(gòu)有利于提高溝通能力,讀

6、書(shū)吧！寫(xiě)博客吧！,12,Use Case分析法,13,USE-CASE的歷史,1967年Jacobson在愛(ài)立信工作的時(shí)候開(kāi)始使用這種思想這種想法最早應(yīng)用于大型交換機(jī)系統(tǒng)的需求獲取1971年完成了這種方法的最初原型1985年推出了改進(jìn)版，并發(fā)布了面向?qū)ο蟮腛OSE方法大部分面向?qū)ο蠹夹g(shù)都采用這種需求方法，UML建模語(yǔ)言也已將它包容進(jìn)去它還被廣泛的應(yīng)用于工業(yè)領(lǐng)域,14,需求獲取的前提,用戶(hù)必須告訴你他想要什么你必須完整地了解

7、用戶(hù)的業(yè)務(wù)你必須知道與系統(tǒng)有關(guān)的任何人和任何東西如果用戶(hù)不能告訴你他們想要什么，你必須花費(fèi)時(shí)間去觀察和記錄他們現(xiàn)在是怎么工作的從專(zhuān)家那里了解用戶(hù)業(yè)務(wù)的原理和規(guī)則你是去了解要做什么而不是怎么做,15,首先，您需要把系統(tǒng)看成黑盒,一開(kāi)始就深入細(xì)節(jié)的產(chǎn)品經(jīng)理，忙亂而又沒(méi)有績(jī)效往往陷入細(xì)節(jié)的泥坑，甚至是技術(shù)細(xì)節(jié)，甚至UI細(xì)節(jié)被層出不窮的需求點(diǎn)和例外處理困擾控制不住滿(mǎn)腦袋亂冒的ideas請(qǐng)相信?。。。。。。。。。。。。。。。。。。?/p>

8、！系統(tǒng)內(nèi)部無(wú)論多么復(fù)雜他總是可以被“使用說(shuō)明書(shū)”說(shuō)清楚,16,Actor,17,需求分析的第一個(gè)問(wèn)題,誰(shuí)是這個(gè)產(chǎn)品的用戶(hù)？或者，誰(shuí)是這個(gè)產(chǎn)品系統(tǒng)中的角色？,18,什么是角色(Actor),與系統(tǒng)發(fā)生交互作用的、系統(tǒng)之外的任何東西都是角色可以是人也可以是機(jī)器角色不等同于使用者角色存在于系統(tǒng)外部角色不是活動(dòng)的準(zhǔn)確描述使用者是行駛某個(gè)角色職責(zé)的系統(tǒng)的使用人員如小王是個(gè)采購(gòu)員,19,角色（續(xù)）,每個(gè)Actor都通過(guò)不同的

9、方式使用系統(tǒng)，除非他們是相同的ActorActor使用系統(tǒng)的每一種方式就是一個(gè)Use Case,20,角色分類(lèi),主動(dòng)角色：Use Case的動(dòng)作序列是由他先發(fā)起的，通常系統(tǒng)返回最后結(jié)果主叫方，采購(gòu)人員，票據(jù)錄入員等被動(dòng)角色：系統(tǒng)通過(guò)調(diào)用角色來(lái)完成Use Case的動(dòng)作序列（或其中的某一個(gè)動(dòng)作）不是初始動(dòng)作的發(fā)起者當(dāng)系統(tǒng)需要它們幫助的時(shí)候最終是為了滿(mǎn)足主動(dòng)角色的需要通常是機(jī)器或其他系統(tǒng),,Use Case1,,Use Cas

10、e2,,,,,21,Script,22,腳本Script,腳本是一個(gè)角色與系統(tǒng)之間的一組交互作用通常具有詳細(xì)的真實(shí)數(shù)據(jù)及實(shí)際的期望輸出值一個(gè)應(yīng)用系統(tǒng)可能具有成千上萬(wàn)個(gè)腳本即使同一件事，所得到的腳本可能也會(huì)有細(xì)微的區(qū)別腳本是描繪Use Case的重要的背景信息,23,,,,腳本示例,1：小王輸入他的賬號(hào)#4135972：小王輸入他的密碼#1198233：小王查詢(xún)98.7.1至98.12.31日之間的平均余額4：系統(tǒng)顯示余額

11、1：小張輸入他的賬號(hào)#4133432：小張輸入他的密碼#6467883：小張查詢(xún)98.3.1至98.5.31日之間的平均余額4：系統(tǒng)顯示余額1：小李輸入她的賬號(hào)#3467802：小李輸入她的密碼#4356453：小李查詢(xún)98.7.1至98.12.31日之間的平均余額4：系統(tǒng)顯示余額,24,腳本與Use Case,一個(gè)Use Case代表一組潛在的腳本通過(guò)研究一組相似的腳本，可以得到它們內(nèi)在的邏輯相似的腳本通常遵循

12、相似的模式工作，并提供相似類(lèi)型的結(jié)果一個(gè)Use Case通常關(guān)注某一個(gè)目標(biāo)例如：查詢(xún)存折余額,Use Case,25,Use Case,,26,,轉(zhuǎn)讓群,通過(guò)Use Case描述系統(tǒng)功能需求,一個(gè)系統(tǒng)具有無(wú)限個(gè)潛在的腳本但一個(gè)系統(tǒng)可以被有限的Use Case完整說(shuō)明系統(tǒng)的每一個(gè)Use Case都必須列舉，否則系統(tǒng)將會(huì)遺漏功能,,創(chuàng)建群,,解散群,,加入群,,贊助群,,邀請(qǐng)加入群,,群內(nèi)發(fā)言,,授權(quán)群管理,27,Use Case,

13、描述系統(tǒng)提供的交互功能一個(gè)Use Case可以被其他的Use Case調(diào)用Use Case可以組合完成某一項(xiàng)更大的功能Use Case說(shuō)明系統(tǒng)需要提供什么而不是怎么提供用戶(hù)并不關(guān)心你如何給他們提供所需要的功能Use Case一般是用“動(dòng)賓”短語(yǔ)命名,,創(chuàng)建群,,解散群,,加入群,,贊助群,,邀請(qǐng)加入群,,群內(nèi)發(fā)言,,授權(quán)群管理,28,Use Case,Use Case不是分析設(shè)計(jì)文檔雖然它們支持后續(xù)的分析設(shè)計(jì)工作Use C

14、ase不是操作腳本它不是用戶(hù)使用系統(tǒng)時(shí)實(shí)際操作的具體步驟的記錄雖然它可能是通過(guò)操作腳本得來(lái)的,29,Use Case是很好的測(cè)試單元,Use Case清晰地描述了系統(tǒng)的功能界面測(cè)試人員可以在開(kāi)發(fā)初期制定測(cè)試計(jì)劃每一個(gè)Use Case都嚴(yán)格地說(shuō)明了系統(tǒng)的某一項(xiàng)功能它的輸入它的輸出期間的交互作用Use Case是黑盒測(cè)試的基準(zhǔn),30,Use Case的闡述,應(yīng)該包含Use Case的所有重要細(xì)節(jié)應(yīng)該包括角色與系統(tǒng)交互的關(guān)鍵

15、步驟，可以使用順序圖（Sequence Diagram）要表述有關(guān)角色的信息要分清哪些是角色所具有的職能、哪些是系統(tǒng)所應(yīng)提供的要列清使用這些功能是所應(yīng)滿(mǎn)足的前提條件如果某些功能具有質(zhì)量上的要求（如性能），也要列出來(lái),,創(chuàng)建群,DdddddddddddDddddxxafsdfadsDdddddddddddDdddfcadsfasdddddccdasdwe,31,Use Case：標(biāo)記方法簡(jiǎn)單,,Use Case名稱(chēng),,32

16、,Use Case：主動(dòng)角色,,,,,,經(jīng)紀(jì)管理系統(tǒng),33,Use Case：被動(dòng)角色,,,,,,經(jīng)紀(jì)管理系統(tǒng),,34,畫(huà)Use Case圖規(guī)則,主動(dòng)角色畫(huà)在圖的左邊被動(dòng)角色畫(huà)在圖的右邊每個(gè)Use Case必須為用戶(hù)提供確切的功能Use Case名稱(chēng)必須寫(xiě)在橢圓里面保持圖面整潔每一張圖里不能有太多的Use Case為每一個(gè)Use Case編號(hào)便于檢索為Use Case建立目錄（編號(hào)和名稱(chēng)）便于管理,35,Use Case

17、 高級(jí)概念,36,Use Case高級(jí)概念,通過(guò)分析Use Case圖，分析人員可以找出不同的業(yè)務(wù)過(guò)程之間的共性擴(kuò)展、包含、派生、使用等關(guān)系通過(guò)這些關(guān)系可以降低系統(tǒng)的復(fù)雜度為重用提供了條件將共性提出來(lái)，可以幫助我們發(fā)現(xiàn)重復(fù)的過(guò)程二次開(kāi)發(fā)應(yīng)該關(guān)注的地方,37,,Actor 的繼承,類(lèi)似于Use Case的擴(kuò)展，角色之間可以繼承其他銀行不僅具有儲(chǔ)戶(hù)的所有功能，還有其他的功能,38,Actor 繼承的好處,在不丟失信息

18、的前提下，簡(jiǎn)化了Use Case圖繼承說(shuō)明了角色間的層次關(guān)系派生者繼承了父角色的所有能力父角色不知道派生者,39,,擴(kuò)展關(guān)系：extend,擴(kuò)展關(guān)系通常用來(lái)表示某一個(gè)Use Case的可選擇部分?jǐn)U展關(guān)系允許分析人員在沒(méi)有改變基Use Case的情況下增加或修改基Use Case的功能復(fù)雜的可替代途徑應(yīng)該使用擴(kuò)展關(guān)系把它們分成多個(gè)Use Case也可以這樣看擴(kuò)展關(guān)系：在基Use Case上插入功能，而基Use Case本身不

19、知道這個(gè)擴(kuò)展,40,,擴(kuò)展關(guān)系(extend )示圖,41,,使用關(guān)系,如果Use Case A包含Use Case B，表示在執(zhí)行Use Case的動(dòng)作序列過(guò)程中，在某一點(diǎn)上將開(kāi)始執(zhí)行Use Case B的動(dòng)作序列，完成后將回到同一點(diǎn)上繼續(xù)執(zhí)行完Use Case A的動(dòng)作序列它與擴(kuò)展關(guān)系的區(qū)別是：擴(kuò)展是可選的包含是必做的（更象一個(gè)子過(guò)程）和擴(kuò)展關(guān)系一樣，一個(gè)Use Case可以包含很多個(gè)子Use Case，也可以被很多個(gè)父Us

20、e Case所包含,42,,包含關(guān)系(include)示例,43,,包含關(guān)系(include)示圖,44,關(guān)于擴(kuò)展和包含關(guān)系,45,Use Case發(fā)掘?qū)嵅?46,Use Case發(fā)掘過(guò)程,定義Actor發(fā)掘Actor使用系統(tǒng)的腳本Script總結(jié)Use Case組合研究Actor之間的繼承關(guān)系研究Use Case之間的include、extend關(guān)系貫穿始終：維護(hù)一套詞匯表,}CE,47,詞匯表！詞匯表！,詞匯表有多重要?

21、可以建巴別塔代碼中的變量需求文檔的重要組成部分和線索維護(hù)詞匯表應(yīng)該是產(chǎn)品團(tuán)隊(duì)最重要的工作之一,,Buddy？面板聯(lián)系人？通訊錄聯(lián)系人？電話好友？手機(jī)好友？QQ聯(lián)系人？郵件好友？IM聯(lián)系人？過(guò)濾聯(lián)系人？,48,詞匯表示例：被叫號(hào)碼,本節(jié)所述之被叫號(hào)碼，其格式要求為：符合E.164電話號(hào)碼編號(hào)計(jì)劃規(guī)范。對(duì)于PBX分機(jī)號(hào)碼，應(yīng)為1－8位數(shù)字；對(duì)于普通電話號(hào)碼，合法格式為：以“+”、“-”分隔的1-21位數(shù)字字符串；可選包

22、含以“+”引導(dǎo)的國(guó)家代碼；如+86代表中國(guó)，+1代表美國(guó)；必須包含地區(qū)代碼和電話號(hào)碼，其間用“-”分隔；如0755-26441099；010-38454233；如果包含國(guó)家代碼，則地區(qū)代碼的長(zhǎng)途前綴（如“0”）應(yīng)省略；如+86-755-26441099；+86-10-38454233如果某外線號(hào)碼包含分機(jī)號(hào)碼，其間用“-”分隔；如0755-26551099-384；+86-755-26551099-384對(duì)于中國(guó)移動(dòng)電話

23、號(hào)碼，合法格式為：國(guó)家代碼和移動(dòng)電話號(hào)碼如+86-13509345659或移動(dòng)電話號(hào)碼如13509345659，在被叫號(hào)碼中無(wú)需根據(jù)對(duì)外地手機(jī)加入0前綴。不包含Omni PCX交換機(jī)的外線撥號(hào)前綴。如某Omni PCX交換機(jī)的外線撥號(hào)前綴為“9”，但在RTX系統(tǒng)中的電話號(hào)碼資料中不需要具備這個(gè)外線撥號(hào)前綴。,－《RTX Omni PCX插件軟件需求規(guī)格說(shuō)明書(shū).doc》,49,Use Case的Pattern,大部分互聯(lián)網(wǎng)服務(wù)

24、本質(zhì)上是DB：增刪改查導(dǎo)入導(dǎo)出批量操作計(jì)算機(jī)應(yīng)用的基礎(chǔ)支撐功能：安裝卸載啟動(dòng)停止重啟動(dòng)OAM（運(yùn)營(yíng)、管理、監(jiān)視）,50,,自定義頭像的Use Case,用戶(hù),Server組管理員,PMM,第三方頭像CP,設(shè)置自定義頭像,從本機(jī)設(shè)置,從網(wǎng)絡(luò)硬盤(pán)設(shè)置,從第三方系統(tǒng)設(shè)置,第三方頭像系統(tǒng),網(wǎng)絡(luò)硬盤(pán)系統(tǒng),《extend》,《extend》,《extend》,添加第三方CP,查看頭像運(yùn)營(yíng)數(shù)據(jù),51,Use Case闡述,52,Us

25、e Case：開(kāi)始走向需求規(guī)格說(shuō)明書(shū),Use Case圖并不是需求文檔的必備部分Use Case分析是過(guò)程，不是結(jié)果Use Case闡述，等于：,53,Use Case闡述的基本四要素,進(jìn)入條件描述Use Case在何種情況下進(jìn)入如用戶(hù)必須具備什么條件？之前發(fā)生了什么？基本流程不考慮任何異常例外，沒(méi)有if then else從用戶(hù)角度闡述Use Case如何運(yùn)作結(jié)束條件Use Case成功結(jié)束后，發(fā)生了什么變化用戶(hù)發(fā)

26、生什么變化？系統(tǒng)發(fā)生什么變化？例外流程逐個(gè)闡述在基本流程中某個(gè)環(huán)節(jié)出現(xiàn)異常時(shí)的處理,54,Use Case闡述的幾個(gè)禁止,禁止假設(shè)系統(tǒng)由哪些技術(shù)實(shí)現(xiàn)模塊組成“系統(tǒng)從服務(wù)器基礎(chǔ)DB中刪除好友關(guān)系”禁止假設(shè)用戶(hù)可以使用哪些UI界面“系統(tǒng)彈出錯(cuò)誤提示窗口”禁止使用沒(méi)有主謂賓的語(yǔ)句“給出提示”禁止使用沒(méi)有任何意義、意義不全的語(yǔ)句“系統(tǒng)給出狀態(tài)提示信息”“系統(tǒng)立即顯示”、“等”、“或者”、“其他”、“通?！薄菇o出沒(méi)有值域

27、的定義“系統(tǒng)顯示天氣溫度信息”,55,Use Case 闡述的逐步細(xì)化 － 1 基本流程,a)當(dāng)郵件用戶(hù)要求管理郵件信息時(shí)功能夾啟動(dòng)，系統(tǒng)顯示信息。b)郵件用戶(hù)可以按照以下的一個(gè)或多個(gè)步驟執(zhí)行：c)按照發(fā)送這或主題整理郵件信息；d)閱讀郵件信息的內(nèi)容；e)把郵件信息保存為文件；f)把郵件信息的附件保存為文件；g)當(dāng)郵件用戶(hù)要求退出管理新來(lái)郵件信息時(shí)，功能夾終止。,56,Use Case 闡述的逐步細(xì)化 － 2 期望擴(kuò)展,a

28、)當(dāng)郵件用戶(hù)要求管理郵件信息時(shí)功能夾啟動(dòng)，系統(tǒng)顯示信息。[用戶(hù)必須能夠區(qū)分新的、已讀過(guò)的、未讀過(guò)的消息。用戶(hù)還必須能夠看見(jiàn)每個(gè)消息的發(fā)送者、主題和優(yōu)先級(jí)。]b)郵件用戶(hù)可以按照以下的一個(gè)或多個(gè)步驟執(zhí)行：c)按照發(fā)送這或主題整理郵件信息；d)閱讀郵件信息的內(nèi)容；e)把郵件信息保存為文件；f)把郵件信息的附件保存為文件； [用戶(hù)必須能夠看見(jiàn)附件的文件類(lèi)型] g)當(dāng)郵件用戶(hù)要求退出管理新來(lái)郵件信息時(shí)，功能夾終止。,57,Use C

29、ase 闡述的逐步細(xì)化 － 3 補(bǔ)充值域,a)當(dāng)郵件用戶(hù)要求管理郵件信息時(shí)功能夾啟動(dòng)，系統(tǒng)顯示信息。[用戶(hù)必須能夠區(qū)分新的、已讀過(guò)的、未讀過(guò)的消息。用戶(hù)還必須能夠看見(jiàn)每個(gè)消息的發(fā)送者、主題和優(yōu)先級(jí)。] {平均每100個(gè)同時(shí)顯示的未讀郵件消息中，其中90%的消息主題行少于40個(gè)字符。}b)郵件用戶(hù)可以按照以下的一個(gè)或多個(gè)步驟執(zhí)行：c)按照發(fā)送這或主題整理郵件信息；d)閱讀郵件信息的內(nèi)容； {平均消息內(nèi)容包括100字符。} e)把郵

30、件信息保存為文件；f)把郵件信息的附件保存為文件； [用戶(hù)必須能夠看見(jiàn)附件的文件類(lèi)型] {這種情況下，95%的郵件都少于2個(gè)附件。} g)當(dāng)郵件用戶(hù)要求退出管理新來(lái)郵件信息時(shí)，功能夾終止。,58,Use Case 闡述的逐步細(xì)化 － 4 補(bǔ)充發(fā)生概率,a)當(dāng)郵件用戶(hù)要求管理郵件信息時(shí)功能夾啟動(dòng)，系統(tǒng)顯示信息。[用戶(hù)必須能夠區(qū)分新的、已讀過(guò)的、未讀過(guò)的消息。用戶(hù)還必須能夠看見(jiàn)每個(gè)消息的發(fā)送者、主題和優(yōu)先級(jí)。] {平均每100個(gè)同時(shí)顯示

31、的未讀郵件消息中，其中90%的消息主題行少于40個(gè)字符。}b)郵件用戶(hù)可以按照以下的一個(gè)或多個(gè)步驟執(zhí)行：c)按照發(fā)送這或主題整理郵件信息；(在這種情況下，有超過(guò)60%做了此項(xiàng)操作。) d)閱讀郵件信息的內(nèi)容； {平均消息內(nèi)容包括100字符。} e)把郵件信息保存為文件；(在這種情況下，少于5%做了此項(xiàng)操作。) f)把郵件信息的附件保存為文件； [用戶(hù)必須能夠看見(jiàn)附件的文件類(lèi)型] {這種情況下，95%的郵件都少于2個(gè)附件。} (

32、在這種情況下，有少于30%做了此項(xiàng)操作。) g)當(dāng)郵件用戶(hù)要求退出管理新來(lái)郵件信息時(shí)，功能夾終止。,59,Use Case闡述后,發(fā)現(xiàn)詞匯，并給以定義詳細(xì)的解釋?zhuān)涤虻拿枋鲂纬尚枨笪臋n中的“定義”發(fā)現(xiàn)功能需求和性能需求整理文字，形成功能需求規(guī)格說(shuō)明和性能需求說(shuō)明,60,性能需求,61,性能需求的Pattern,性能指標(biāo)易用性安全性兼容性可擴(kuò)展性可維護(hù)性可延展性可移植性可編程性可靠性可測(cè)試性,,產(chǎn)品關(guān)注,技術(shù)

33、關(guān)注,62,性能需求的專(zhuān)業(yè)化撰寫(xiě)態(tài)度,產(chǎn)品經(jīng)理應(yīng)忘記自己懂技術(shù)、交互從用戶(hù)、市場(chǎng)角度把要求提出來(lái)弄清楚自己的專(zhuān)業(yè)發(fā)展方向User-Oriented，Market-Oriented其他的，不妨“扮豬吃老虎”,63,Good News：天下文章一大抄,在一個(gè)產(chǎn)品系統(tǒng)中，性能需求是可以Copy的第一份性能需求是重點(diǎn)，大家一起作之后的需求文檔往往只需改變：性能指標(biāo)可擴(kuò)展性易用性可延展性安全性兼容性可維護(hù)性可移植性

34、可編程性可靠性可測(cè)試性,這里簡(jiǎn)簡(jiǎn)單單幾句話要求，讓開(kāi)發(fā)同事、設(shè)計(jì)師作半年……,64,需求規(guī)格說(shuō)明書(shū),65,,沒(méi)有高質(zhì)量的需求軟件就象一個(gè)巧克力的盒子你不會(huì)知道你將要得到什么,66,高質(zhì)量需求敘述的特性,正確 可行性 必要性 優(yōu)先權(quán) 明確 可證實(shí),67,高質(zhì)量需求敘述的特性 1/6,正確：每個(gè)需求必須精確描述要交付的功能。正確性依據(jù)于需求的來(lái)源，如真實(shí)的客戶(hù)或高級(jí)別的系統(tǒng)需求說(shuō)明書(shū)。只有用戶(hù)的代表能夠決定用戶(hù)需求

35、的正確性，這就是為什么在檢查需求時(shí)，要包括他們或他們的代理的關(guān)鍵所在。不包括用戶(hù)的需求檢查就會(huì)導(dǎo)致開(kāi)發(fā)人員的：“這是沒(méi)意義的”，“這可能是他們的意思”等眾所周知的猜測(cè)。,68,高質(zhì)量需求敘述的特性 2/6,可行性：在已知的能力、有限的系統(tǒng)及其環(huán)境中每個(gè)需求必須是可實(shí)現(xiàn)的。為了避免需求的不可行性，在需求分析階段應(yīng)該有一個(gè)開(kāi)發(fā)人員參與，這個(gè)開(kāi)發(fā)人員應(yīng)能檢查在技術(shù)上什么能做什么不能做哪些需要需要額外的付出或者和其他的權(quán)衡。 在抽象階

36、段應(yīng)該有市場(chǎng)人員參與。,69,高質(zhì)量需求敘述的特性 3/6,必要性：每個(gè)需求應(yīng)載明什么是客戶(hù)確實(shí)需要的，什么要順應(yīng)于外部的需求，接口或標(biāo)準(zhǔn)。每個(gè)需求源于你認(rèn)可或者具有授權(quán)的原始資料跟蹤每個(gè)需求回溯到出處，如用例，系統(tǒng)需求，規(guī)章，或來(lái)自其他用戶(hù)（特別是Boss）的意見(jiàn)。如果你不能標(biāo)識(shí)出處，可能需求只是個(gè)鍍金的例子，沒(méi)有真正的必須。,70,高質(zhì)量需求敘述的特性 4/6,優(yōu)先權(quán)：為了表明在一個(gè)詳細(xì)的產(chǎn)品版本中應(yīng)包含哪些要點(diǎn)，需要為每

37、個(gè)需求，特征，或用例分配實(shí)現(xiàn)的優(yōu)先權(quán)?？蛻?hù)或其代理都應(yīng)有強(qiáng)烈的責(zé)任建立優(yōu)先權(quán)。如果所有的需求都被視為同等重要，那么由于在開(kāi)發(fā)中，預(yù)算削減，計(jì)劃超時(shí)或組員的離開(kāi)導(dǎo)致新的需求時(shí)， 項(xiàng)目經(jīng)理將不能起到作用。優(yōu)先權(quán)的作用是提供給客戶(hù)的價(jià)值，實(shí)現(xiàn)的相關(guān)費(fèi)用，實(shí)現(xiàn)相關(guān)聯(lián)的有關(guān)技術(shù)風(fēng)險(xiǎn)。Must Have, Nice To Have, Can Delay,71,高質(zhì)量需求敘述的特性 5/6,明確：需求敘述的讀者應(yīng)只能從其得到唯一的解釋說(shuō)明，

38、同樣，一個(gè)需求的多個(gè)讀者也應(yīng)達(dá)成共識(shí)。自然語(yǔ)言極易導(dǎo)致含糊。要避免使用一些對(duì)于SRS作者很清楚但對(duì)于讀者不清楚的主觀詞匯，如：用戶(hù)友好性，容易，簡(jiǎn)單，快速，有效，幾個(gè)，藝術(shù)級(jí)，改善的，最大，最小等等。每寫(xiě)一個(gè)需要都應(yīng)簡(jiǎn)潔，簡(jiǎn)單，直觀的采用用戶(hù)熟知的語(yǔ)言，不要采用計(jì)算機(jī)術(shù)語(yǔ)。檢查需求模糊的有效方式包括需求說(shuō)明書(shū)的正規(guī)檢查，根據(jù)需求寫(xiě)測(cè)試，建立用戶(hù)的假想來(lái)說(shuō)明產(chǎn)品某個(gè)特定部分預(yù)期的特性。,72,高質(zhì)量需求敘述的特性 6/6,可證實(shí)：

39、看你是否能夠做出測(cè)試計(jì)劃或其他驗(yàn)證方式，如檢查和實(shí)證，來(lái)決定在產(chǎn)品中每個(gè)需求是否正確的實(shí)現(xiàn)。如果需求是不可驗(yàn)證的，決定需求是不是正確的實(shí)現(xiàn)就成了判斷的事。需求之間不一致，不可行，不明確也能導(dǎo)致不可證實(shí)。任何需求如果說(shuō)產(chǎn)品將要支持什么也是不可證實(shí)的。,73,高質(zhì)量需求說(shuō)明書(shū)的特征,完整 一致性 可修改性 可追蹤,74,高質(zhì)量需求說(shuō)明書(shū)的特征 1/4,完整：不應(yīng)該遺漏要求和必需的信息。完整性也是一個(gè)需求應(yīng)具備的。發(fā)現(xiàn)缺少

40、的信息很難，因?yàn)楦静淮嬖?。在SRS中將需求以分層目錄方式組織，將幫助評(píng)審人員理解功能性描述的結(jié)構(gòu)，使他們很容易指出遺失的東西。在需求抽象上，應(yīng)用Use Case方法會(huì)發(fā)揮很好的作用。能夠從不同角度察看需求的圖形分析模型也可以檢查出不完整性。使用TBD（to be determined）標(biāo)準(zhǔn)標(biāo)志已知的缺失當(dāng)你在構(gòu)建產(chǎn)品的相關(guān)部分時(shí)，就可以從一個(gè)給定的需求集中解決所有的缺陷。如“Vista表現(xiàn)”,75,高質(zhì)量需求說(shuō)明書(shū)的特征

41、2/4,一致性：一致性需求就是不要于其他的軟件需求或高級(jí)別的系統(tǒng)（商業(yè)）需求發(fā)生沖突。需求中的不一致必須在開(kāi)發(fā)開(kāi)始前得到解決。只有經(jīng)過(guò)調(diào)研才能確定哪些是正確的。修改需求時(shí)一定要謹(jǐn)慎如果只審定修改的部分，沒(méi)有審定于修改相關(guān)的部分，就可能導(dǎo)致不一致性。,76,高質(zhì)量需求說(shuō)明書(shū)的特征 3/4,可修改性：當(dāng)每個(gè)需求的要求修改了或維護(hù)其歷史更改時(shí)，你必須能夠?qū)彾⊿RS。每個(gè)需求必須相對(duì)于其他需求有其單獨(dú)的標(biāo)示和分開(kāi)的說(shuō)明，便于清晰的

42、查閱。通過(guò)良好的組織可以使需求易于修改，如：將相關(guān)的需求分組，建立目錄表，索引，以及前后參考Feature List.xls 是很好的工具,77,高質(zhì)量需求說(shuō)明書(shū)的特征 4/4,可追蹤：應(yīng)能將一個(gè)軟件與其原始材料相對(duì)應(yīng)如高級(jí)系統(tǒng)需求，用例，用戶(hù)的提議等。能夠?qū)④浖枨笈c設(shè)計(jì)元素，源代碼，用于構(gòu)造實(shí)現(xiàn)和驗(yàn)證需求的測(cè)試相對(duì)應(yīng)?？勺粉櫟男枨髴?yīng)該具有獨(dú)立標(biāo)示，細(xì)密和結(jié)構(gòu)化的編寫(xiě)，不應(yīng)過(guò)大，不應(yīng)是敘述性的文字和公告式的列表。,78,

43、幾個(gè)不好的需求,“產(chǎn)品應(yīng)在不少于每60秒（？）的正常周期（？）內(nèi)提供狀態(tài)信息”“產(chǎn)品應(yīng)瞬間在顯示和隱藏不可打印字符間切換” “HTML分析器可以產(chǎn)生HTML標(biāo)記錯(cuò)誤報(bào)告，幫助HTML入門(mén)者快速解決錯(cuò)誤”?！叭绻赡埽鞴芴?hào)碼應(yīng)通過(guò)聯(lián)機(jī)校驗(yàn)，而不是通過(guò)主全體主管號(hào)碼列表校驗(yàn)”。,79,編寫(xiě)高質(zhì)量需求的方針,句子和段落要短采用主動(dòng)語(yǔ)氣使用正確的語(yǔ)法，拼寫(xiě)，標(biāo)點(diǎn)使用術(shù)語(yǔ)保持一致性，并在術(shù)語(yǔ)表或數(shù)據(jù)字典中定義它們以開(kāi)發(fā)人員的觀點(diǎn)看

44、需求是否被有效的定義需求編寫(xiě)者還要努力正確地把握細(xì)化程度要避免包含多個(gè)需求的長(zhǎng)的敘述段落把正常流程和異常流程分開(kāi)密切關(guān)注多個(gè)需求合成了單個(gè)需求 通篇文檔細(xì)節(jié)上要保持一致避免在SRS中過(guò)多的重復(fù)需求在多處包含相同的需求可以使文檔更易于閱讀，但也會(huì)給文檔的維護(hù)增加困難。文檔的多份文本要在同一時(shí)間內(nèi)全部更新，避免不一致性。使用Word的“超鏈接”功能！,換位思考，不要太自信Review再Review，朗讀自己的作品！當(dāng)成高

45、考作文來(lái)認(rèn)真對(duì)待！,80,一份需求規(guī)格說(shuō)明書(shū)的內(nèi)容 1/6,文檔標(biāo)題：準(zhǔn)確、言簡(jiǎn)意賅、遵守SCM規(guī)定給產(chǎn)品取個(gè)好的英文簡(jiǎn)稱(chēng)《RTX Omni PCX插件軟件需求規(guī)格說(shuō)明書(shū)》修訂記錄 認(rèn)真對(duì)待，仔細(xì)填寫(xiě),81,一份需求規(guī)格說(shuō)明書(shū)的內(nèi)容 2/6,關(guān) 鍵 詞 、摘 要 ：就像寫(xiě)您的學(xué)位論文一樣去寫(xiě)摘要可以最后補(bǔ)充，先標(biāo)紅免得忘記,82,一份需求規(guī)格說(shuō)明書(shū)的內(nèi)容 3/6,縮略語(yǔ)清單：對(duì)本文所用縮略語(yǔ)進(jìn)行說(shuō)明，要求提供每

46、個(gè)縮略語(yǔ)的英文全名和中文解釋。參考資料清單： 請(qǐng)?jiān)诒砀裰辛_列本文檔所引用的有關(guān)參考文獻(xiàn)名稱(chēng)、作者、標(biāo)題、編號(hào)、發(fā)布日期和出版單位等基本信息。,83,一份需求規(guī)格說(shuō)明書(shū)的內(nèi)容 4/6,引言背景A. 用一個(gè)名字標(biāo)識(shí)要生產(chǎn)的軟件產(chǎn)品。 B. 說(shuō)明軟件產(chǎn)品將干什么, 如果需要的話, 還要說(shuō)明這個(gè)軟件產(chǎn)品不干什么。產(chǎn)品定義本節(jié)必須給出易發(fā)生混淆的術(shù)語(yǔ)的定義把詞匯表都放這里,84,一份需求規(guī)格說(shuō)明書(shū)的內(nèi)容 5/6,概述 1。系統(tǒng)

47、描述一般整個(gè)系統(tǒng)作一份，所有需求文檔都Copy2。 系統(tǒng)功能推薦用表格來(lái)說(shuō)明本文檔所列的功能需求3。 開(kāi)發(fā)環(huán)境一般整個(gè)系統(tǒng)作一份，所有需求文檔都Copy4。 開(kāi)發(fā)環(huán)境一般整個(gè)系統(tǒng)作一份，所有需求文檔都Copy,85,一份需求規(guī)格說(shuō)明書(shū)的內(nèi)容 6/6,產(chǎn)品需求功能需求到肉了，把功能需求一個(gè)個(gè)的寫(xiě)UI需求找設(shè)計(jì)師性能需求天下文章一大抄把握產(chǎn)品重點(diǎn)的性能要求,86,常用方法和工具,87,思維導(dǎo)圖,,88,魚(yú)

48、骨圖,,89,Pareto 圖,,90,一張圖勝過(guò)百句話,UML中的幾種圖表：動(dòng)態(tài)的觀察系統(tǒng)：Usecase圖序列圖(Sequence Diagram)協(xié)作圖(Collaboration Diagram)狀態(tài)圖(Statechart Diagram)活動(dòng)圖(Activity Diagram)靜態(tài)的觀察系統(tǒng)：部署圖(Deployment Diagram)組件圖(Compoment Diagram)對(duì)象圖(Object