軟件需求工程的概念

1、編輯課件1軟件需求工程的概念軟件需求工程的概念2013.22013.2第7版 編輯課件2軟件需求工程的概念軟件需求工程的概念 對(duì)軟件需求的認(rèn)識(shí) 軟件需求工程的基本框架 需求與其他項(xiàng)目過(guò)程的聯(lián)系 需求工程描述編輯課件3對(duì)軟件需求的認(rèn)識(shí)對(duì)軟件需求的認(rèn)識(shí)編輯課件41.1 1.1 對(duì)軟件需求的初級(jí)認(rèn)識(shí)對(duì)軟件需求的初級(jí)認(rèn)識(shí) 需求不是根本問(wèn)題，編碼才是軟件開(kāi)發(fā)工作。 給我一個(gè)項(xiàng)目，無(wú)論需求多么復(fù)雜我一定能完成它。需求很重要，但很容易搞清它。 在初級(jí)軟件開(kāi)發(fā)人員的潛意識(shí)中需求不是那么可怕,編程技術(shù)才是重要的。 當(dāng)這些問(wèn)題與需求管理處理技能不足,缺乏管理工具，出現(xiàn)需求管理混現(xiàn)時(shí)才會(huì)逐漸引起項(xiàng)目管理者的重視。編

2、輯課件51.1.2 2 業(yè)界的當(dāng)前狀況業(yè)界的當(dāng)前狀況 根本某軟件公司近五年的實(shí)踐總結(jié), 在軟件項(xiàng)目開(kāi)發(fā)中的主要分類10種問(wèn)題; 總結(jié)的10種問(wèn)題分類中需求過(guò)程占了30%30%; 需求問(wèn)題占了47%47%;編輯課件6總結(jié)問(wèn)題分類總結(jié)問(wèn)題分類問(wèn)題分類問(wèn)題分類數(shù)量數(shù)量比例比例1需求獲取447%47%2需求變更83需求控制44過(guò)程規(guī)范617.6%5項(xiàng)目管理26%6重用構(gòu)件48.8%7售前12.9%8風(fēng)險(xiǎn)評(píng)估12.9%9技術(shù)風(fēng)險(xiǎn)12.9%10團(tuán)隊(duì)建設(shè)411.7%35編輯課件7具體問(wèn)題實(shí)例具體問(wèn)題實(shí)例 我們不了解客戶的配合工作執(zhí)行情況，很難有機(jī)會(huì)與客戶交流項(xiàng)目進(jìn)度情況，存在溝通理解偏差溝通理解偏差的情況;

3、 前期需求方面加大力度，明確及確認(rèn)各項(xiàng)需求邊界，做好需求變更控制需求變更控制; xx項(xiàng)目需求變更過(guò)大，不能有效控制不能有效控制; 頻繁的人員變動(dòng)及需求變更導(dǎo)致進(jìn)度不斷延遲; 需求沒(méi)有在實(shí)際開(kāi)發(fā)開(kāi)展之前與客戶需求沒(méi)有在實(shí)際開(kāi)發(fā)開(kāi)展之前與客戶達(dá)成共識(shí)達(dá)成共識(shí); ;編輯課件8具體問(wèn)題實(shí)例具體問(wèn)題實(shí)例 總體感覺(jué)項(xiàng)目范圍界限沒(méi)有用需求規(guī)格說(shuō)明書(shū)或者需求說(shuō)明書(shū)規(guī)范，導(dǎo)致在系統(tǒng)設(shè)計(jì)、開(kāi)發(fā)的過(guò)程中發(fā)現(xiàn)發(fā)現(xiàn)問(wèn)題無(wú)據(jù)可查問(wèn)題無(wú)據(jù)可查。 客戶不斷的提出修改要求,使最初的有序開(kāi)發(fā)，逐步轉(zhuǎn)變?yōu)槠Ｓ趹?yīng)付疲于應(yīng)付客戶新要求 面對(duì)需求頻繁變更需求頻繁變更給我們帶來(lái)的許多不確定性的問(wèn)題，目前沒(méi)有太好的辦法來(lái)解決。 客戶方對(duì)自己

4、的需求并不清晰客戶方對(duì)自己的需求并不清晰，開(kāi)發(fā)項(xiàng)目過(guò)程受客戶方影響過(guò)大，客戶方在適用階段才提出了不少的變更;編輯課件9具體問(wèn)題實(shí)例具體問(wèn)題實(shí)例 沒(méi)有受控的需求沒(méi)有受控的需求,甚至需求還未完成的基礎(chǔ)上就已開(kāi)始了測(cè)試工作; 一份與客戶達(dá)成共識(shí)的需求規(guī)格說(shuō)明書(shū)很重要需求規(guī)格說(shuō)明書(shū)很重要！ 售前工作方面提升的空間很大，包括與客戶溝通、收集客戶需求、編寫(xiě)方案、等等技術(shù)技能方面都比較欠缺，對(duì)行業(yè)領(lǐng)域內(nèi)的專業(yè)知識(shí)還需要進(jìn)一步的積累;編輯課件10總結(jié)評(píng)估總結(jié)評(píng)估 說(shuō)明大部分軟件項(xiàng)目所遇到的問(wèn)題是基本一致的; 說(shuō)明軟件研發(fā)人員對(duì)所遇到的問(wèn)題的認(rèn)識(shí)是基本一致的; 說(shuō)明大多數(shù)軟件項(xiàng)目的技術(shù)過(guò)程瓶頸是基本一致的; 說(shuō)

5、明軟件需求過(guò)程問(wèn)題是當(dāng)前項(xiàng)目研發(fā)中的主要過(guò)程技術(shù)瓶頸;編輯課件111.1.3 3 項(xiàng)目失敗的根本原因項(xiàng)目失敗的根本原因 需求來(lái)源：市場(chǎng)需求主導(dǎo)不足 不完整的需求 缺乏用戶介入 不實(shí)際的客戶期望 需求和規(guī)范的變更 缺乏高層的支持 勝任的團(tuán)隊(duì)成員大少 缺乏項(xiàng)目管理經(jīng)驗(yàn)編輯課件121.1.4 4 相對(duì)重要的軟件問(wèn)題相對(duì)重要的軟件問(wèn)題 一次調(diào)查以確定在產(chǎn)業(yè)中相對(duì)重要的軟件問(wèn)題,根據(jù)3800個(gè)被調(diào)查人的回答,大約半數(shù)的被調(diào)查者回答的兩個(gè)最大問(wèn)題是: 1)需求規(guī)格說(shuō)明 2)管理客戶需求 相對(duì)而言編碼不是問(wèn)題 很顯然,我們完全可以把需求當(dāng)作導(dǎo)致軟件問(wèn)題的最根本原因。 編輯課件13需求錯(cuò)誤的頻率需求錯(cuò)誤的頻率

6、 缺陷來(lái)源缺陷來(lái)源 潛在缺陷潛在缺陷 排除的效率排除的效率 提交的缺陷提交的缺陷 需求 1.00 77% 0.230.23 設(shè)計(jì) 1.25 85% 0.19 編碼 1.75 95%1.75 95% 0.09 建檔 0.60 80% 0.12 不恰當(dāng)修復(fù) 0.40 70% 0.12 合計(jì) 5.00 85% 0.75 編輯課件14需求錯(cuò)誤的頻率需求錯(cuò)誤的頻率 需求錯(cuò)誤在提交缺陷(用戶著到的缺陷)中是最高的,占了大約全部提交缺陷的三分之一。 因此需求錯(cuò)誤是系統(tǒng)開(kāi)發(fā)錯(cuò)誤中最常見(jiàn)的一類錯(cuò)誤。 編輯課件151.1.5 5 需求錯(cuò)誤的高昂代價(jià)需求錯(cuò)誤的高昂代價(jià) 如果把編碼階段發(fā)現(xiàn)和修復(fù)一個(gè)錯(cuò)誤所需要的努力用

7、1個(gè)成本單元表示的話,那么需求階段的錯(cuò)誤修復(fù)成本是它的5到10倍。而且,在維護(hù)階段發(fā)現(xiàn)和修復(fù)一個(gè)錯(cuò)誤的成本超過(guò)20倍。 在項(xiàng)目的需求階段發(fā)現(xiàn)錯(cuò)誤所花費(fèi)的成本與維護(hù)階段發(fā)現(xiàn)錯(cuò)誤的成本比例是200:1 編輯課件16在生命周期不同階段修復(fù)缺陷的相對(duì)成本在生命周期不同階段修復(fù)缺陷的相對(duì)成本205210.50.1需求設(shè)計(jì)編碼單元測(cè)試驗(yàn)收測(cè)試維護(hù)編輯課件17結(jié)論結(jié)論 需求錯(cuò)誤可能是最常見(jiàn)的錯(cuò)誤。 需求錯(cuò)誤可能是修改花費(fèi)最昂貴的錯(cuò)誤。 需求錯(cuò)誤可能消耗整個(gè)項(xiàng)目預(yù)算的25%到40%。 給定需求錯(cuò)誤的頻率及其“修改成本”的倍增效果因子,可以預(yù)言,需求錯(cuò)誤將占去返工成本的70%或更多。 返工通常會(huì)消耗項(xiàng)目預(yù)算的3

8、0%到50%,因此得出:需求錯(cuò)誤很容易就消耗掉整個(gè)項(xiàng)目預(yù)算的25%到40%! 編輯課件181.1.6 6 軟件需求的主要問(wèn)題軟件需求的主要問(wèn)題 領(lǐng)域知識(shí)領(lǐng)域知識(shí) 需求過(guò)程需求過(guò)程 需求方法需求方法 需求技術(shù)需求技術(shù) 需求工具需求工具 需求需求管理經(jīng)驗(yàn)管理經(jīng)驗(yàn) 高層管理的支持高層管理的支持 勝任的團(tuán)隊(duì)成員勝任的團(tuán)隊(duì)成員 資金與時(shí)間資金與時(shí)間編輯課件19軟件需求的主要問(wèn)題軟件需求的主要問(wèn)題領(lǐng)域領(lǐng)域知識(shí)知識(shí)領(lǐng)域領(lǐng)域知識(shí)知識(shí)需求需求過(guò)程過(guò)程需求需求方法方法需求需求工具工具需求管理經(jīng)驗(yàn)高層支持勝任的團(tuán)隊(duì)資金與時(shí)間需求需求技術(shù)技術(shù)編輯課件20什么是好的需求什么是好的需求 好的需求是正確的、無(wú)歧義的、可檢驗(yàn)

9、和可驗(yàn)證的并且是可跟蹤的。 好的需求集合是完整的、一致的和可修改的。(IEEE軟件需求規(guī)格說(shuō)明標(biāo)準(zhǔn))編輯課件21對(duì)現(xiàn)代軟件需求的認(rèn)識(shí)對(duì)現(xiàn)代軟件需求的認(rèn)識(shí) 軟件需求是領(lǐng)域知識(shí)的學(xué)習(xí)、經(jīng)驗(yàn)積累的過(guò)程。 軟件需求是領(lǐng)域知識(shí)的傳遞過(guò)程。 軟件需求是在軟件開(kāi)發(fā)過(guò)程中迭代增量的認(rèn)識(shí)過(guò)程。 軟件需求是不斷變化的,我們要承認(rèn)和適應(yīng)這種變化,要學(xué)習(xí)適應(yīng)軟件變化的技術(shù)和方法。 軟件需求是軟件開(kāi)發(fā)過(guò)程中最關(guān)鍵的過(guò)程。編輯課件22軟件需求工程的基本框架軟件需求工程的基本框架編輯課件23軟件需求工程的概念軟件需求工程的概念 軟件需求工程包括了以下主要內(nèi)容： 對(duì)軟件需求基本知識(shí)需求基本知識(shí)的學(xué)習(xí)和了解 掌握一個(gè)基本的需求

10、過(guò)程需求過(guò)程 熟練過(guò)程活動(dòng)的方法和技術(shù)方法和技術(shù)編輯課件24軟件需求過(guò)程的六個(gè)主要活動(dòng)軟件需求過(guò)程的六個(gè)主要活動(dòng) 軟件需求過(guò)程包括需求開(kāi)發(fā)需求開(kāi)發(fā)和需求管理需求管理兩大類活動(dòng)。 需求開(kāi)發(fā)活動(dòng)需求開(kāi)發(fā)活動(dòng) 需求獲取 需求分析 需求定義 需求管理活動(dòng)需求管理活動(dòng) 需求驗(yàn)證和確認(rèn) 需求跟蹤 需求變更控制編輯課件25需求獲取、需求分析、需求定義、需求驗(yàn)證變更控制、版本控制、需求跟蹤、需求狀態(tài)跟蹤業(yè)務(wù)需求 用戶需求 功能需求管理過(guò)程管理過(guò)程開(kāi)發(fā)過(guò)程開(kāi)發(fā)過(guò)程需求層次軟件需求規(guī)格說(shuō)明軟件需求規(guī)格說(shuō)明需求屬性 功能需求 非功能需求 質(zhì)量屬性管理過(guò)程產(chǎn)品開(kāi)發(fā)過(guò)程產(chǎn)品軟件需求工程的基本框架軟件需求工程的基本框架編

11、輯課件26需求處理過(guò)程的生命周期需求處理過(guò)程的生命周期 需求處理過(guò)程系統(tǒng)分析產(chǎn)品設(shè)計(jì)構(gòu)建實(shí)現(xiàn)產(chǎn)品使用需求規(guī)格需求規(guī)格說(shuō)明書(shū)說(shuō)明書(shū)風(fēng)險(xiǎn)承擔(dān)者的 想法與需要目標(biāo)操作環(huán)境反饋反饋編輯課件27軟件需求過(guò)程軟件需求過(guò)程 軟件需求過(guò)程包括需求開(kāi)發(fā)和需求管理兩大類活動(dòng)。 需求開(kāi)發(fā)活動(dòng)需求開(kāi)發(fā)活動(dòng)需求獲取、需求分析、需求定義 需求管理活動(dòng)需求管理活動(dòng) 需求驗(yàn)證和確認(rèn)、需求跟蹤、需求變更控制編輯課件28需求開(kāi)發(fā)與需求管理之間的界限需求開(kāi)發(fā)與需求管理之間的界限 需求規(guī)格說(shuō)明基線需求規(guī)格說(shuō)明基線 需求開(kāi)發(fā)需求開(kāi)發(fā)需求管理需求管理獲取獲取分析分析定義定義變更變更 當(dāng)前基線修正后基線修正后基線需求需求變更變更過(guò)程過(guò)程編

12、輯課件29基本的軟件需求過(guò)程基本的軟件需求過(guò)程 編輯課件30好的過(guò)程屬性好的過(guò)程屬性 過(guò)程被書(shū)面化 過(guò)程是靈活的，可變的 每個(gè)人都同意遵循這個(gè)過(guò)程 過(guò)程包含度量，該度量用于測(cè)量過(guò)程的有效性 度量是修改過(guò)程的基礎(chǔ) 過(guò)程被主動(dòng)管理編輯課件31軟件需求工程框架軟件需求工程框架 我們把所有與軟件需求相關(guān)的活動(dòng)通稱為軟件需求工程軟件需求工程。 需求工程中的活動(dòng)可分為兩大類: 需求開(kāi)發(fā)需求開(kāi)發(fā) 需求管理需求管理 編輯課件32需求開(kāi)發(fā)需求開(kāi)發(fā) 需求開(kāi)發(fā)包括三個(gè)知需求開(kāi)發(fā)包括三個(gè)知識(shí)和實(shí)踐要點(diǎn)識(shí)和實(shí)踐要點(diǎn): :1.1.需求獲取需求獲取2.2.需求分析需求分析3.3.需求定義需求定義編輯課件33需求開(kāi)發(fā)需求開(kāi)發(fā)

13、 需求開(kāi)發(fā)可分為兩個(gè)階段：“用戶需求需求調(diào)查調(diào)查階段”和“產(chǎn)品需求定義需求定義階段”，“需求分析需求分析”則貫穿于上述兩個(gè)階段。 需求調(diào)查階段和需求定義階段在邏輯上存在先后關(guān)系，實(shí)際工作中二者通常是迭代進(jìn)行的。我們把從事需求開(kāi)發(fā)工作的人員稱為需求分析員（系統(tǒng)分析員） 編輯課件34需求管理需求管理 需求管理包括三個(gè)知需求管理包括三個(gè)知識(shí)和實(shí)踐要點(diǎn)識(shí)和實(shí)踐要點(diǎn)1.需求驗(yàn)證和確認(rèn)2.需求跟蹤3.需求變更控制編輯課件35什么是需求管理什么是需求管理 需求定義了系統(tǒng)必須具有的能力,一個(gè)項(xiàng)目的成功與否往往取決于它是否符合一系列的需求。因此,探討需求的確切含義、把它們寫(xiě)下來(lái)、組織起來(lái)、跟蹤它們的變更就顯得非

14、常有意義。 需求管理定義為需求管理定義為: :為系統(tǒng)的需求進(jìn)行啟發(fā)、組為系統(tǒng)的需求進(jìn)行啟發(fā)、組織、建檔的系統(tǒng)方法織、建檔的系統(tǒng)方法, ,建立和維護(hù)客戶和項(xiàng)目建立和維護(hù)客戶和項(xiàng)目團(tuán)隊(duì)之間關(guān)于變更系統(tǒng)需求所達(dá)成的一致性的團(tuán)隊(duì)之間關(guān)于變更系統(tǒng)需求所達(dá)成的一致性的過(guò)程過(guò)程。 編輯課件36需求管理需求管理 任何曾經(jīng)參與過(guò)復(fù)雜軟件系統(tǒng)的人,無(wú)論是作為用戶還是開(kāi)發(fā)人員,都知道從用戶和風(fēng)險(xiǎn)承從用戶和風(fēng)險(xiǎn)承擔(dān)人那里獲取需求的能力是非常關(guān)鍵的技能擔(dān)人那里獲取需求的能力是非常關(guān)鍵的技能; ; 與一個(gè)系統(tǒng)相關(guān)的需求即使沒(méi)有上千條,也至少有數(shù)百條,因此把它們合理地組織起來(lái)非常重要。 我們無(wú)法記憶太多的信息,因此為需求建

15、檔能夠有效支持風(fēng)險(xiǎn)承擔(dān)人之間的溝通。 必須把需求用可訪問(wèn)的介質(zhì)來(lái)記錄:文檔,模型。 編輯課件37需求管理需求管理 需求管理與項(xiàng)目的大小和復(fù)雜度有關(guān) 兩個(gè)人、十條需求的項(xiàng)目,不需要管理需求。但是,如果要驗(yàn)證一個(gè)有500-1000條需求的軟件產(chǎn)品,我們就面臨著必須對(duì)這些需求進(jìn)行組織、劃定優(yōu)先級(jí)、控制對(duì)它們的訪問(wèn)以及為它們提供存儲(chǔ)資源的問(wèn)題。 可以把需求管理看成處理重要的復(fù)雜項(xiàng)目需求的一系列理有組織的、標(biāo)準(zhǔn)化的、系統(tǒng)化的過(guò)程和技術(shù)。 編輯課件38需求獲取需求獲取需求分析需求分析需求定義需求定義需求驗(yàn)證需求驗(yàn)證 需求跟蹤需求跟蹤設(shè)計(jì)編碼測(cè)試設(shè)計(jì)編碼測(cè)試變更控制變更控制需求開(kāi)發(fā)需求開(kāi)發(fā)需求管理需求管理軟

16、件需求工程的螺旋模型軟件需求工程的螺旋模型編輯課件39過(guò)程活動(dòng)的方法和技術(shù)過(guò)程活動(dòng)的方法和技術(shù) 需求獲取的方法和技術(shù) 發(fā)現(xiàn)(方法：角色、活動(dòng)、資源、產(chǎn)品) 收集(方法：用例、流程圖) 分類(方法：按活動(dòng)、角色相關(guān)度) 評(píng)估(方法：風(fēng)險(xiǎn)、原因) 優(yōu)先級(jí)(方法：重要性、價(jià)值) 文檔(用戶需求說(shuō)明書(shū)) 需求分析的方法和技術(shù) 結(jié)構(gòu)化分析方法和面向?qū)ο蟮幕痉椒?基于UML的用例分析技術(shù))編輯課件40過(guò)程活動(dòng)的方法和技術(shù)過(guò)程活動(dòng)的方法和技術(shù) 需求定義的方法和技術(shù)(需求規(guī)格說(shuō)明書(shū)) 用例模型建模方法和用例補(bǔ)充規(guī)約說(shuō)明 需求驗(yàn)證和確認(rèn)的方法和技術(shù) 驗(yàn)證與評(píng)審和測(cè)試方法技術(shù) 需求跟蹤的方法和技術(shù) 需求跟蹤矩陣

17、 需求變更控制的方法和技術(shù) 需求變更控制流程和變更控制委員會(huì)編輯課件41需求與其他項(xiàng)目過(guò)程的聯(lián)系需求與其他項(xiàng)目過(guò)程的聯(lián)系 需求需求構(gòu)造構(gòu)造用戶編用戶編制文檔制文檔項(xiàng)目跟蹤項(xiàng)目跟蹤和控制和控制制定項(xiàng)制定項(xiàng)目計(jì)劃目計(jì)劃系統(tǒng)測(cè)試系統(tǒng)測(cè)試變更控制變更控制狀態(tài)范圍基礎(chǔ)參考估算基線編輯課件42需求工程描述需求工程描述編輯課件43需求工程的用例需求工程的用例編輯課件44涉眾涉眾 涉眾是所有會(huì)受到項(xiàng)目結(jié)果重大影響的人。 要有效地解決任何復(fù)雜的問(wèn)題，就會(huì)涉及到滿足不同涉眾的需要。涉眾通常會(huì)對(duì)問(wèn)題持有不同的觀點(diǎn)，因而必須用所提供的解決方案來(lái)滿足不同的需要。 許多涉眾都是系統(tǒng)的用戶。其中許多涉眾只是系統(tǒng)的間接用戶，

18、或者只受到系統(tǒng)所影響的業(yè)務(wù)結(jié)果的影響。還有許多涉眾是系統(tǒng)的經(jīng)濟(jì)型買(mǎi)主或支持者。 了解涉眾的組成及其特定需要是開(kāi)發(fā)有效解決方案的關(guān)鍵。編輯課件45風(fēng)險(xiǎn)承擔(dān)者風(fēng)險(xiǎn)承擔(dān)者 風(fēng)險(xiǎn)承擔(dān)者是高層需求的提出者，他們往往對(duì)需求細(xì)節(jié)不是很關(guān)心。 系統(tǒng)的主要功能產(chǎn)生的作用及效益是他們關(guān)心的重點(diǎn)。 注意系統(tǒng)風(fēng)險(xiǎn)承擔(dān)者的宏觀需求是有效解決問(wèn)題的關(guān)鍵和項(xiàng)目成功的保證之一。編輯課件46客戶客戶 客戶有兩種: 系統(tǒng)的操作者和維護(hù)者，他們對(duì)系統(tǒng)的界面、易使用性、易維護(hù)性、穩(wěn)定性比較關(guān)心。 系統(tǒng)的用戶，對(duì)系統(tǒng)的功能可以給他們帶來(lái)的便利程度、舒適度、工作效率、工作滿意度比較關(guān)心。編輯課件47領(lǐng)域?qū)＜翌I(lǐng)域?qū)＜?領(lǐng)域?qū)＜揖哂胸S富的業(yè)

19、務(wù)領(lǐng)域經(jīng)驗(yàn)，是系統(tǒng)業(yè)務(wù)流程、業(yè)務(wù)規(guī)則的提供者。 領(lǐng)域?qū)＜沂菢I(yè)務(wù)建模的主要角色。 但是領(lǐng)域?qū)＜乙话闳狈I(yè)務(wù)模型轉(zhuǎn)化為計(jì)算機(jī)邏輯模型的經(jīng)驗(yàn)和能力。 具有領(lǐng)域經(jīng)驗(yàn)和計(jì)算機(jī)建模經(jīng)驗(yàn)的專家是非常少的，兩者的結(jié)合是需求成功的保證。編輯課件48變更控制經(jīng)理變更控制經(jīng)理 變更控制經(jīng)理負(fù)責(zé)對(duì)變更控制過(guò)程進(jìn)行監(jiān)督。 此角色通常由配置（或變更）控制委員會(huì) (CCB) 來(lái)?yè)?dān)任，該委員會(huì)應(yīng)該由有關(guān)各方（包括客戶、開(kāi)發(fā)人員和用戶）的代表組成。 在小型項(xiàng)目中，項(xiàng)目經(jīng)理或軟件構(gòu)架設(shè)計(jì)師一人即可承擔(dān)此角色。 編輯課件49系統(tǒng)分析員系統(tǒng)分析員 系統(tǒng)分析員通過(guò)概括系統(tǒng)的功能和界定系統(tǒng)來(lái)領(lǐng)導(dǎo)和協(xié)調(diào)需求獲取及用例建模。例如，確定存在

20、哪些主角和用例，以及他們之間如何交互。 擔(dān)任系統(tǒng)分析員的人員應(yīng)該善于協(xié)調(diào)，并且具有良好的溝通技巧。擔(dān)任此角色的人員中必須要有具備業(yè)務(wù)和技術(shù)領(lǐng)域知識(shí)的人才，但這些知識(shí)并不是所有人都必須具備的。 編輯課件501.1.需求獲取需求獲取 需求調(diào)查的目的是通過(guò)各種途徑獲取用戶的需求信息（原始材料），產(chǎn)生用戶需求說(shuō)明書(shū)。編輯課件51需求獲取需求獲取 需求獲取本質(zhì)上是一個(gè)涉及不同團(tuán)體的交流過(guò)程?？煞纸鉃橄铝谢顒?dòng): 發(fā)現(xiàn)(方法：角色、活動(dòng)、資源、產(chǎn)品) 收集(方法：用例、流程圖) 分類(方法：按活動(dòng)、角色相關(guān)度) 評(píng)估(方法：風(fēng)險(xiǎn)、原因) 優(yōu)先級(jí)(方法：重要性、價(jià)值) 文檔：(用戶需求說(shuō)明書(shū))編輯課件522. 2. 需求分析需求分析 需求分析的目的是對(duì)各種需求信息進(jìn)行分析，消除錯(cuò)誤，刻畫(huà)細(xì)節(jié)等。 常用的需求分析方法有 “結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇ā薄?面向?qū)ο蠓治龇壳俺Ｓ玫姆椒ㄊ腔赨ML的用例分析技術(shù),產(chǎn)品是用例模型