1、從概念到產(chǎn)品需求分析過程,Something about grammar & literature,2,開始的話,3,引子：不僅僅純技術(shù),人文比科技重要！ 方法比技能重要！,初做者,有經(jīng)驗(yàn)者,監(jiān)督者,專家,管理者,高級專家,領(lǐng)導(dǎo)者,資深專家,4,學(xué)習(xí)態(tài)度？,一天，三年甲班的楊過忘了交作業(yè)，導(dǎo)師郭靖問他：“為什么沒交作業(yè)？” 楊過答曰：“作業(yè)為什么要交？交了不一定是自己寫的； 寫了又不一定會；（不小心破了珍瓏的虛竹不好意思地看了逍遙子一眼） 會了又不一定會考；（苦心準(zhǔn)備當(dāng)盟主的左冷禪背后響起悶響） 考了又不一定會過；（白眉鷹王身邊秋風(fēng)吹過陣陣凄涼的落葉） 過了又不一定能畢業(yè)；（被古墓派退學(xué)的李莫

2、愁臉色一變） 畢業(yè)又不一定會找到工作；樂天的令狐沖正在酒醉中沒聽見） 找得到工作又不一定保得住工作；（蕭峰奪門而出） ？” 只見現(xiàn)場沉默三秒之后，眾人聯(lián)手圍毆楊過,5,先從語法課講起,用戶是一個(gè)或者多個(gè)名詞； 產(chǎn)品是名詞，一般由很多個(gè)名詞組成； 產(chǎn)品設(shè)計(jì)過程 功能需求就是找出“動賓短語”的集合 性能需求就是找出“形容詞”的集合,6,訂書機(jī)為例（僅供參考）,產(chǎn)品 訂書機(jī): n. 一種裝訂文件的文具 訂書機(jī)包括： 杠桿結(jié)構(gòu)：n. 進(jìn)釘結(jié)構(gòu)；n. 壓釘結(jié)構(gòu)；n. 釘書釘(消耗品):n.,用戶 用戶：n. 使用訂書機(jī)的人，應(yīng)大于3周歲；且有手或者類似可以發(fā)出至少1kg力量的人。最常用(80%以上)為女

3、性(21-40)。,需求 功能需求 裝訂文件； Load釘書釘； Unload釘書釘； 性能需求 外觀、顏色、省力、材質(zhì).,7,產(chǎn)品設(shè)計(jì)過程,定義好用戶 定義好產(chǎn)品 先分析功能需求 再分析性能需求,80/20的誤區(qū)： 產(chǎn)品日趨同質(zhì)化， 公司之間的差別， 市場競爭的成敗， 往往是由性能決定,8,互聯(lián)網(wǎng)本質(zhì)論,計(jì)算機(jī)為什么叫計(jì)算機(jī)？ 互聯(lián)網(wǎng)其實(shí)是一個(gè)大數(shù)據(jù)庫 大部分應(yīng)用都是數(shù)據(jù)庫應(yīng)用 Search? B2B、B2C、C2C? Gaming? Avatar？ Blog? 小部分應(yīng)用是即時(shí)的存儲轉(zhuǎn)發(fā)類 IM VoIP,復(fù)習(xí)數(shù)據(jù)庫的知識!,9,課程概述,10,課程內(nèi)容,Use Case分析方法 找尋用戶

4、 定義產(chǎn)品 發(fā)掘功能需求 性能需求的“套路” 需求文檔的撰寫 產(chǎn)品經(jīng)理常用“技法” 工作組織方法 常用圖表和繪圖方法,11,需求分析與人文,需求分析是一個(gè)工業(yè)化的寫作過程 80的套路20的創(chuàng)意 好的語文水平： 有利于抓住關(guān)鍵詞匯 有利于培養(yǎng)數(shù)字敏感 有利于增強(qiáng)形容能力 有利于組織文檔結(jié)構(gòu) 有利于提高溝通能力,讀書吧！ 寫博客吧！,12,Use Case分析法,13,USE-CASE的歷史,1967年Jacobson在愛立信工作的時(shí)候開始使用這種思想 這種想法最早應(yīng)用于大型交換機(jī)系統(tǒng)的需求獲取 1971年完成了這種方法的最初原型 1985年推出了改進(jìn)版，并發(fā)布了面向?qū)ο蟮腛OSE方法 大部分面向

5、對象技術(shù)都采用這種需求方法，UML建模語言也已將它包容進(jìn)去 它還被廣泛的應(yīng)用于工業(yè)領(lǐng)域,14,需求獲取的前提,用戶必須告訴你他想要什么 你必須完整地了解用戶的業(yè)務(wù) 你必須知道與系統(tǒng)有關(guān)的任何人和任何東西 如果用戶不能告訴你他們想要什么，你必須花費(fèi)時(shí)間去觀察和記錄他們現(xiàn)在是怎么工作的 從專家那里了解用戶業(yè)務(wù)的原理和規(guī)則 你是去了解要做什么而不是怎么做,15,首先，您需要把系統(tǒng)看成黑盒,一開始就深入細(xì)節(jié)的產(chǎn)品經(jīng)理，忙亂而又沒有績效 往往陷入細(xì)節(jié)的泥坑，甚至是技術(shù)細(xì)節(jié)，甚至UI細(xì)節(jié) 被層出不窮的需求點(diǎn)和例外處理困擾 控制不住滿腦袋亂冒的ideas 請相信！ 系統(tǒng)內(nèi)部無論多么復(fù)雜 他總是可以被“使用說

6、明書”說清楚,16,Actor,17,需求分析的第一個(gè)問題,誰是這個(gè)產(chǎn)品的用戶？ 或者，誰是這個(gè)產(chǎn)品系統(tǒng)中的角色？,18,什么是角色(Actor),與系統(tǒng)發(fā)生交互作用的、系統(tǒng)之外的任何東西都是角色 可以是人 也可以是機(jī)器 角色不等同于使用者 角色存在于系統(tǒng)外部 角色不是活動的準(zhǔn)確描述 使用者是行駛某個(gè)角色職責(zé)的系統(tǒng)的使用人員 如小王是個(gè)采購員,19,角色（續(xù)）,每個(gè)Actor都通過不同的方式使用系統(tǒng)，除非他們是相同的Actor Actor使用系統(tǒng)的每一種方式就是一個(gè)Use Case,20,角色分類,主動角色：Use Case的動作序列是由他先發(fā)起的，通常系統(tǒng)返回最后結(jié)果 主叫方，采購人員，票據(jù)

7、錄入員等 被動角色：系統(tǒng)通過調(diào)用角色來完成Use Case的動作序列（或其中的某一個(gè)動作） 不是初始動作的發(fā)起者 當(dāng)系統(tǒng)需要它們幫助的時(shí)候 最終是為了滿足主動角色的需要 通常是機(jī)器或其他系統(tǒng),Use Case1,Use Case2,21,Script,22,腳本Script,腳本是一個(gè)角色與系統(tǒng)之間的一組交互作用 通常具有詳細(xì)的真實(shí)數(shù)據(jù)及實(shí)際的期望輸出值 一個(gè)應(yīng)用系統(tǒng)可能具有成千上萬個(gè)腳本 即使同一件事，所得到的腳本可能也會有細(xì)微的區(qū)別 腳本是描繪Use Case的重要的背景信息,23,腳本示例,1：小王輸入他的賬號#413597 2：小王輸入他的密碼#119823 3：小王查詢98.7.1至

8、98.12.31日之間的平均余額 4：系統(tǒng)顯示余額 1：小張輸入他的賬號#413343 2：小張輸入他的密碼#646788 3：小張查詢98.3.1至98.5.31日之間的平均余額 4：系統(tǒng)顯示余額 1：小李輸入她的賬號#346780 2：小李輸入她的密碼#435645 3：小李查詢98.7.1至98.12.31日之間的平均余額 4：系統(tǒng)顯示余額,24,腳本與Use Case,一個(gè)Use Case代表一組潛在的腳本 通過研究一組相似的腳本，可以得到它們內(nèi)在的邏輯 相似的腳本通常遵循相似的模式工作，并提供相似類型的結(jié)果 一個(gè)Use Case通常關(guān)注某一個(gè)目標(biāo) 例如：查詢存折余額,Use Case

9、,25,Use Case,26,轉(zhuǎn)讓群,通過Use Case描述系統(tǒng)功能需求,一個(gè)系統(tǒng)具有無限個(gè)潛在的腳本 但一個(gè)系統(tǒng)可以被有限的Use Case完整說明 系統(tǒng)的每一個(gè)Use Case都必須列舉，否則系統(tǒng)將會遺漏功能,創(chuàng)建群,解散群,加入群,贊助群,邀請加入群,群內(nèi)發(fā)言,授權(quán)群管理,27,Use Case,描述系統(tǒng)提供的交互功能 一個(gè)Use Case可以被其他的Use Case調(diào)用 Use Case可以組合完成某一項(xiàng)更大的功能 Use Case說明系統(tǒng)需要提供什么而不是怎么提供 用戶并不關(guān)心你如何給他們提供所需要的功能 Use Case一般是用“動賓”短語命名,創(chuàng)建群,解散群,加入群,贊助群,

10、邀請加入群,群內(nèi)發(fā)言,授權(quán)群管理,28,Use Case,Use Case不是分析設(shè)計(jì)文檔 雖然它們支持后續(xù)的分析設(shè)計(jì)工作 Use Case不是操作腳本 它不是用戶使用系統(tǒng)時(shí)實(shí)際操作的具體步驟的記錄 雖然它可能是通過操作腳本得來的,29,Use Case是很好的測試單元,Use Case清晰地描述了系統(tǒng)的功能界面 測試人員可以在開發(fā)初期制定測試計(jì)劃 每一個(gè)Use Case都嚴(yán)格地說明了系統(tǒng)的某一項(xiàng)功能 它的輸入 它的輸出 期間的交互作用 Use Case是黑盒測試的基準(zhǔn),30,Use Case的闡述,應(yīng)該包含Use Case的所有重要細(xì)節(jié) 應(yīng)該包括角色與系統(tǒng)交互的關(guān)鍵步驟，可以使用順序圖（Se

11、quence Diagram） 要表述有關(guān)角色的信息 要分清哪些是角色所具有的職能、哪些是系統(tǒng)所應(yīng)提供的 要列清使用這些功能是所應(yīng)滿足的前提條件 如果某些功能具有質(zhì)量上的要求（如性能），也要列出來,創(chuàng)建群,Dddddddddddd Dddddxxafsdfads Dddddddddddd Ddddfcadsfasd ddddccdasdwe,31,Use Case：標(biāo)記方法簡單,Use Case名稱,32,Use Case：主動角色,經(jīng)紀(jì)管理系統(tǒng),33,Use Case：被動角色,經(jīng)紀(jì)管理系統(tǒng),34,畫Use Case圖規(guī)則,主動角色畫在圖的左邊 被動角色畫在圖的右邊 每個(gè)Use Case必須

12、為用戶提供確切的功能 Use Case名稱必須寫在橢圓里面 保持圖面整潔 每一張圖里不能有太多的Use Case 為每一個(gè)Use Case編號便于檢索 為Use Case建立目錄（編號和名稱）便于管理,35,Use Case 高級概念,36,Use Case高級概念,通過分析Use Case圖，分析人員可以找出不同的業(yè)務(wù)過程之間的共性 擴(kuò)展、包含、派生、使用等關(guān)系 通過這些關(guān)系可以降低系統(tǒng)的復(fù)雜度 為重用提供了條件 將共性提出來，可以幫助我們發(fā)現(xiàn)重復(fù)的過程 二次開發(fā)應(yīng)該關(guān)注的地方,37,Actor 的繼承,類似于Use Case的擴(kuò)展，角色之間可以繼承 其他銀行不僅具有儲戶的所有功能，還有其他

13、的功能,38,Actor 繼承的好處,在不丟失信息的前提下，簡化了Use Case圖 繼承說明了角色間的層次關(guān)系 派生者繼承了父角色的所有能力 父角色不知道派生者,39,擴(kuò)展關(guān)系：extend,擴(kuò)展關(guān)系通常用來表示某一個(gè)Use Case的可選擇部分 擴(kuò)展關(guān)系允許分析人員在沒有改變基Use Case的情況下增加或修改基Use Case的功能 復(fù)雜的可替代途徑應(yīng)該使用擴(kuò)展關(guān)系把它們分成多個(gè)Use Case 也可以這樣看擴(kuò)展關(guān)系： 在基Use Case上插入功能，而基Use Case本身不知道這個(gè)擴(kuò)展,40,擴(kuò)展關(guān)系(extend )示圖,41,使用關(guān)系,如果Use Case A包含Use Case

14、 B，表示在執(zhí)行Use Case的動作序列過程中，在某一點(diǎn)上將開始執(zhí)行Use Case B的動作序列，完成后將回到同一點(diǎn)上繼續(xù)執(zhí)行完Use Case A的動作序列 它與擴(kuò)展關(guān)系的區(qū)別是： 擴(kuò)展是可選的 包含是必做的（更象一個(gè)子過程） 和擴(kuò)展關(guān)系一樣，一個(gè)Use Case可以包含很多個(gè)子Use Case，也可以被很多個(gè)父Use Case所包含,42,包含關(guān)系(include)示例,43,包含關(guān)系(include)示圖,44,關(guān)于擴(kuò)展和包含關(guān)系,45,Use Case發(fā)掘?qū)嵅?46,Use Case發(fā)掘過程,定義Actor 發(fā)掘Actor使用系統(tǒng)的腳本Script 總結(jié)Use Case組合 研究A

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

16、”引導(dǎo)的國家代碼； 如+86代表中國，+1代表美國； 必須包含地區(qū)代碼和電話號碼，其間用“-”分隔； 010-38454233； 如果包含國家代碼，則地區(qū)代碼的長途前綴（如“0”）應(yīng)省略； 如+86-755-26441099；+86-10-38454233 如果某外線號碼包含分機(jī)號碼，其間用“-”分隔； 384；+86-755-26551099-384 對于中國移動電話號碼，合法格式為： 國家代碼和移動電話號碼 或移動電話號碼 在被叫號碼中無需根據(jù)對外地手機(jī)加入0前綴。 不包

17、含Omni PCX交換機(jī)的外線撥號前綴。 如某Omni PCX交換機(jī)的外線撥號前綴為“9”，但在RTX系統(tǒng)中的電話號碼資料中不需要具備這個(gè)外線撥號前綴。,RTX Omni PCX插件軟件需求規(guī)格說明書.doc,49,Use Case的Pattern,大部分互聯(lián)網(wǎng)服務(wù)本質(zhì)上是DB： 增刪改查 導(dǎo)入導(dǎo)出 批量操作 計(jì)算機(jī)應(yīng)用的基礎(chǔ)支撐功能： 安裝卸載 啟動停止重啟動 OAM（運(yùn)營、管理、監(jiān)視）,50,自定義頭像的Use Case,用戶,Server組管理員,PMM,第三方頭像CP,設(shè)置自定義頭像,從本機(jī)設(shè)置,從網(wǎng)絡(luò)硬盤設(shè)置,從第三方系統(tǒng)設(shè)置,第三方 頭像系統(tǒng),網(wǎng)絡(luò)硬盤 系統(tǒng),extend,exte

18、nd,extend,添加第三方CP,查看頭像運(yùn)營數(shù)據(jù),51,Use Case闡述,52,Use Case：開始走向需求規(guī)格說明書,Use Case圖并不是需求文檔的必備部分 Use Case分析是過程，不是結(jié)果 Use Case闡述，等于：,53,Use Case闡述的基本四要素,進(jìn)入條件 描述Use Case在何種情況下進(jìn)入 如用戶必須具備什么條件？之前發(fā)生了什么？ 基本流程 不考慮任何異常例外，沒有if then else 從用戶角度闡述Use Case如何運(yùn)作 結(jié)束條件 Use Case成功結(jié)束后，發(fā)生了什么變化 用戶發(fā)生什么變化？系統(tǒng)發(fā)生什么變化？ 例外流程 逐個(gè)闡述在基本流程中某個(gè)環(huán)

19、節(jié)出現(xiàn)異常時(shí)的處理,54,Use Case闡述的幾個(gè)禁止,禁止假設(shè)系統(tǒng)由哪些技術(shù)實(shí)現(xiàn)模塊組成 “系統(tǒng)從服務(wù)器基礎(chǔ)DB中刪除好友關(guān)系” 禁止假設(shè)用戶可以使用哪些UI界面 “系統(tǒng)彈出錯(cuò)誤提示窗口” 禁止使用沒有主謂賓的語句 “給出提示” 禁止使用沒有任何意義、意義不全的語句 “系統(tǒng)給出狀態(tài)提示信息” “系統(tǒng)立即顯示”、“等”、“或者”、“其他”、“通?！?禁止給出沒有值域的定義 “系統(tǒng)顯示天氣溫度信息”,55,Use Case 闡述的逐步細(xì)化 1 基本流程,a)當(dāng)郵件用戶要求管理郵件信息時(shí)功能夾啟動，系統(tǒng)顯示信息。 b)郵件用戶可以按照以下的一個(gè)或多個(gè)步驟執(zhí)行： c)按照發(fā)送這或主題整理郵件信息；

20、 d)閱讀郵件信息的內(nèi)容； e)把郵件信息保存為文件； f)把郵件信息的附件保存為文件； g)當(dāng)郵件用戶要求退出管理新來郵件信息時(shí)，功能夾終止。,56,Use Case 闡述的逐步細(xì)化 2 期望擴(kuò)展,a)當(dāng)郵件用戶要求管理郵件信息時(shí)功能夾啟動，系統(tǒng)顯示信息。用戶必須能夠區(qū)分新的、已讀過的、未讀過的消息。用戶還必須能夠看見每個(gè)消息的發(fā)送者、主題和優(yōu)先級。 b)郵件用戶可以按照以下的一個(gè)或多個(gè)步驟執(zhí)行： c)按照發(fā)送這或主題整理郵件信息； d)閱讀郵件信息的內(nèi)容； e)把郵件信息保存為文件； f)把郵件信息的附件保存為文件； 用戶必須能夠看見附件的文件類型 g)當(dāng)郵件用戶要求退出管理新來郵件信息時(shí)

21、，功能夾終止。,57,Use Case 闡述的逐步細(xì)化 3 補(bǔ)充值域,a)當(dāng)郵件用戶要求管理郵件信息時(shí)功能夾啟動，系統(tǒng)顯示信息。用戶必須能夠區(qū)分新的、已讀過的、未讀過的消息。用戶還必須能夠看見每個(gè)消息的發(fā)送者、主題和優(yōu)先級。 平均每100個(gè)同時(shí)顯示的未讀郵件消息中，其中90%的消息主題行少于40個(gè)字符。 b)郵件用戶可以按照以下的一個(gè)或多個(gè)步驟執(zhí)行： c)按照發(fā)送這或主題整理郵件信息； d)閱讀郵件信息的內(nèi)容； 平均消息內(nèi)容包括100字符。 e)把郵件信息保存為文件； f)把郵件信息的附件保存為文件； 用戶必須能夠看見附件的文件類型 這種情況下，95%的郵件都少于2個(gè)附件。 g)當(dāng)郵件用戶要求

22、退出管理新來郵件信息時(shí)，功能夾終止。,58,Use Case 闡述的逐步細(xì)化 4 補(bǔ)充發(fā)生概率,a)當(dāng)郵件用戶要求管理郵件信息時(shí)功能夾啟動，系統(tǒng)顯示信息。用戶必須能夠區(qū)分新的、已讀過的、未讀過的消息。用戶還必須能夠看見每個(gè)消息的發(fā)送者、主題和優(yōu)先級。 平均每100個(gè)同時(shí)顯示的未讀郵件消息中，其中90%的消息主題行少于40個(gè)字符。 b)郵件用戶可以按照以下的一個(gè)或多個(gè)步驟執(zhí)行： c)按照發(fā)送這或主題整理郵件信息；(在這種情況下，有超過60%做了此項(xiàng)操作。) d)閱讀郵件信息的內(nèi)容； 平均消息內(nèi)容包括100字符。 e)把郵件信息保存為文件；(在這種情況下，少于5%做了此項(xiàng)操作。) f)把郵件信息的

23、附件保存為文件； 用戶必須能夠看見附件的文件類型 這種情況下，95%的郵件都少于2個(gè)附件。 (在這種情況下，有少于30%做了此項(xiàng)操作。) g)當(dāng)郵件用戶要求退出管理新來郵件信息時(shí)，功能夾終止。,59,Use Case闡述后,發(fā)現(xiàn)詞匯，并給以定義 詳細(xì)的解釋，值域的描述 形成需求文檔中的“定義” 發(fā)現(xiàn)功能需求和性能需求 整理文字，形成功能需求規(guī)格說明和性能需求說明,60,性能需求,61,性能需求的Pattern,性能指標(biāo) 易用性 安全性 兼容性 可擴(kuò)展性 可維護(hù)性 可延展性 可移植性 可編程性 可靠性 可測試性,產(chǎn)品關(guān)注,技術(shù)關(guān)注,62,性能需求的專業(yè)化撰寫態(tài)度,產(chǎn)品經(jīng)理應(yīng)忘記自己懂技術(shù)、交互

24、從用戶、市場角度把要求提出來 弄清楚自己的專業(yè)發(fā)展方向 User-Oriented，Market-Oriented 其他的，不妨“扮豬吃老虎”,63,Good News：天下文章一大抄,在一個(gè)產(chǎn)品系統(tǒng)中，性能需求是可以Copy的 第一份性能需求是重點(diǎn)，大家一起作 之后的需求文檔往往只需改變： 性能指標(biāo) 可擴(kuò)展性 易用性 可延展性 安全性 兼容性 可維護(hù)性 可移植性 可編程性 可靠性 可測試性,這里簡簡單單幾句話要求， 讓開發(fā)同事、設(shè)計(jì)師作半年,64,需求規(guī)格說明書,65,沒有高質(zhì)量的需求 軟件就象一個(gè)巧克力的盒子 你不會知道你將要得到什么,66,高質(zhì)量需求敘述的特性,正確 可行性 必要性 優(yōu)先

25、權(quán) 明確 可證實(shí),67,高質(zhì)量需求敘述的特性 1/6,正確： 每個(gè)需求必須精確描述要交付的功能。 正確性依據(jù)于需求的來源，如真實(shí)的客戶或高級別的系統(tǒng)需求說明書。 只有用戶的代表能夠決定用戶需求的正確性，這就是為什么在檢查需求時(shí)，要包括他們或他們的代理的關(guān)鍵所在。不包括用戶的需求檢查就會導(dǎo)致開發(fā)人員的：“這是沒意義的”，“這可能是他們的意思”等眾所周知的猜測。,68,高質(zhì)量需求敘述的特性 2/6,可行性： 在已知的能力、有限的系統(tǒng)及其環(huán)境中每個(gè)需求必須是可實(shí)現(xiàn)的。 為了避免需求的不可行性，在需求分析階段應(yīng)該有一個(gè)開發(fā)人員參與，這個(gè)開發(fā)人員應(yīng)能檢查 在技術(shù)上什么能做什么不能做 哪些需要需要額外的付

26、出或者和其他的權(quán)衡。 在抽象階段應(yīng)該有市場人員參與。,69,高質(zhì)量需求敘述的特性 3/6,必要性： 每個(gè)需求應(yīng)載明什么是客戶確實(shí)需要的，什么要順應(yīng)于外部的需求，接口或標(biāo)準(zhǔn)。 每個(gè)需求源于你認(rèn)可或者具有授權(quán)的原始資料 跟蹤每個(gè)需求回溯到出處，如用例，系統(tǒng)需求，規(guī)章，或來自其他用戶（特別是Boss）的意見。 如果你不能標(biāo)識出處，可能需求只是個(gè)鍍金的例子，沒有真正的必須。,70,高質(zhì)量需求敘述的特性 4/6,優(yōu)先權(quán)： 為了表明在一個(gè)詳細(xì)的產(chǎn)品版本中應(yīng)包含哪些要點(diǎn)，需要為每個(gè)需求，特征，或用例分配實(shí)現(xiàn)的優(yōu)先權(quán)。 客戶或其代理都應(yīng)有強(qiáng)烈的責(zé)任建立優(yōu)先權(quán)。 如果所有的需求都被視為同等重要，那么由于在開發(fā)中

27、，預(yù)算削減，計(jì)劃超時(shí)或組員的離開導(dǎo)致新的需求時(shí)， 項(xiàng)目經(jīng)理將不能起到作用。 優(yōu)先權(quán)的作用是提供給客戶的價(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)只能從其得到唯一的解釋說明，同樣，一個(gè)需求的多個(gè)讀者也應(yīng)達(dá)成共識。 自然語言極易導(dǎo)致含糊。要避免使用一些對于SRS作者很清楚但對于讀者不清楚的主觀詞匯，如： 用戶友好性，容易，簡單，快速，有效，幾個(gè)，藝術(shù)級，改善的，最大，最小等等。 每寫一個(gè)需要都應(yīng)簡潔，簡單，直觀的采用用戶熟知的語言，不要采用計(jì)算機(jī)術(shù)語。 檢查需求

28、模糊的有效方式包括需求說明書的正規(guī)檢查，根據(jù)需求寫測試，建立用戶的假想來說明產(chǎn)品某個(gè)特定部分預(yù)期的特性。,72,高質(zhì)量需求敘述的特性 6/6,可證實(shí)： 看你是否能夠做出測試計(jì)劃或其他驗(yàn)證方式，如檢查和實(shí)證，來決定在產(chǎn)品中每個(gè)需求是否正確的實(shí)現(xiàn)。 如果需求是不可驗(yàn)證的，決定需求是不是正確的實(shí)現(xiàn)就成了判斷的事。 需求之間不一致，不可行，不明確也能導(dǎo)致不可證實(shí)。 任何需求如果說產(chǎn)品將要支持什么也是不可證實(shí)的。,73,高質(zhì)量需求說明書的特征,完整 一致性 可修改性 可追蹤,74,高質(zhì)量需求說明書的特征 1/4,完整： 不應(yīng)該遺漏要求和必需的信息。 完整性也是一個(gè)需求應(yīng)具備的。 發(fā)現(xiàn)缺少的信息很難，因?yàn)?/p>

29、根本不存在。 在SRS中將需求以分層目錄方式組織，將幫助評審人員理解功能性描述的結(jié)構(gòu)，使他們很容易指出遺失的東西。 在需求抽象上，應(yīng)用Use Case方法會發(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ì)量需求說明書的特征 2/4,一致性： 一致性需求就是不要于其他的軟件需求或高級別的系統(tǒng)（商業(yè)）需求發(fā)生沖突。 需求中的不一致必須在開發(fā)開始前得到解決。 只有經(jīng)過調(diào)研才能確定哪些是正確的。 修改需求

30、時(shí)一定要謹(jǐn)慎 如果只審定修改的部分，沒有審定于修改相關(guān)的部分，就可能導(dǎo)致不一致性。,76,高質(zhì)量需求說明書的特征 3/4,可修改性： 當(dāng)每個(gè)需求的要求修改了或維護(hù)其歷史更改時(shí)，你必須能夠?qū)彾⊿RS。 每個(gè)需求必須相對于其他需求有其單獨(dú)的標(biāo)示和分開的說明，便于清晰的查閱。 通過良好的組織可以使需求易于修改，如： 將相關(guān)的需求分組，建立目錄表，索引，以及前后參考 Feature List.xls 是很好的工具,77,高質(zhì)量需求說明書的特征 4/4,可追蹤： 應(yīng)能將一個(gè)軟件與其原始材料相對應(yīng) 如高級系統(tǒng)需求，用例，用戶的提議等。 能夠?qū)④浖枨笈c設(shè)計(jì)元素，源代碼，用于構(gòu)造實(shí)現(xiàn)和驗(yàn)證需求的測試相對應(yīng)。

31、 可追蹤的需求應(yīng)該具有獨(dú)立標(biāo)示，細(xì)密和結(jié)構(gòu)化的編寫，不應(yīng)過大，不應(yīng)是敘述性的文字和公告式的列表。,78,幾個(gè)不好的需求,“產(chǎn)品應(yīng)在不少于每60秒（？）的正常周期（？）內(nèi)提供狀態(tài)信息” “產(chǎn)品應(yīng)瞬間在顯示和隱藏不可打印字符間切換” “HTML分析器可以產(chǎn)生HTML標(biāo)記錯(cuò)誤報(bào)告，幫助HTML入門者快速解決錯(cuò)誤”。 “如果可能，主管號碼應(yīng)通過聯(lián)機(jī)校驗(yàn)，而不是通過主全體主管號碼列表校驗(yàn)”。,79,編寫高質(zhì)量需求的方針,句子和段落要短 采用主動語氣 使用正確的語法，拼寫，標(biāo)點(diǎn) 使用術(shù)語保持一致性，并在術(shù)語表或數(shù)據(jù)字典中定義它們 以開發(fā)人員的觀點(diǎn)看需求是否被有效的定義 需求編寫者還要努力正確地把握細(xì)化程度 要避免包含多個(gè)需求的長的敘述段落 把正常流程和異常流程分開 密切關(guān)注多個(gè)需求合成了單個(gè)需求 通篇文檔細(xì)節(jié)上要保持一致 避免在SRS中過多的重復(fù)需求 在多處包含相同的需求可以使文檔更易于閱讀，但也會給文檔的維護(hù)增加困難。文檔的多份文本要在同一時(shí)間內(nèi)全部更新，避免不一致性。 使用Word的“超鏈接”功能！,換位思考，不要太自信 Review再Review，朗讀自己的作品！ 當(dāng)成高考作文來認(rèn)真對待