it項目需求分析與管理

1、.信息系統(tǒng)集成項目管理人員繼續(xù)教育管理理論與實踐篇it項目需求分析與管理1、需求分析的重要性需求的重要性開發(fā)軟件系統(tǒng)最困難的部分就是準確說明開發(fā)什么。最困難的概念性工作是編寫出詳細的需求，包括所有面向用戶、面向機器和其它軟件系統(tǒng)的接口。此工作一旦做錯，將會給系統(tǒng)帶來極大的損害，并且以后對它修改也極為困難需求是產(chǎn)品的根源，需求工作的優(yōu)劣對產(chǎn)品影響最大。項目成敗因素分析成功因素權(quán)重失敗因素權(quán)重用戶的參與15.9%不完整的需求13.1%執(zhí)行層的支持13.9%缺乏用戶參與12.4%清晰的需求描述13.0%資源不足10.6%合適的規(guī)劃9.6%不切實際的用戶期望9.9%現(xiàn)實的客戶期望8.2%缺乏執(zhí)行層的支

2、持9.3%較小的里程碑7.7%需求變更頻繁8.7%有才能的員工7.2%規(guī)劃不足8.1%主權(quán)5.3%提供了不再需要的7.5%清晰的愿景和目標2.9%缺乏it管理6.2%努力地工作和穩(wěn)定的員工2.4%技術(shù)能力缺乏4.3%其他13.9%其他9.9%精品.精品.信息系統(tǒng)的多維視圖精品.軟件產(chǎn)品的需求視圖精品.精品.1、需求分析的重要性2、需求的概念與層次3、需求開發(fā)與需求管理4、軟件需求分析技術(shù)5、需求分析工具軟件2、需求的概念與屬性軟件需求的定義i ieee的軟件工程標準術(shù)語表將需求定義為：1、用戶所需的解決某個問題或達到某個目標所要具備的條件或能力。2、系統(tǒng)或系統(tǒng)組件為符合合同、標準、規(guī)范或其他正

3、式文檔而必須滿足的條件或必須具備的能力。3、上述第一項或第二項中定義的條件和能力的文檔表述i而rup是這樣定義需求的：需求描述了系統(tǒng)必須滿足的情況和提供的能力，它就可以是直接來自客戶需要，也可以來自合同、標準、規(guī)范或其他正規(guī)約束力的文檔。需求的層次業(yè)務(wù)需求業(yè)務(wù)需求業(yè)務(wù)需求是組織或客戶對于系統(tǒng)的高層次目標要求，定義了項目的遠景和范圍，即確定軟件產(chǎn)品的發(fā)展方向、功能范圍、目標客戶和價值來源精品.。業(yè)務(wù)需求的內(nèi)容-業(yè)務(wù)：產(chǎn)品屬于哪類業(yè)務(wù)范疇？應(yīng)該完成什么功能？需要為什么服務(wù)？-客戶：產(chǎn)品為誰服務(wù)？目標客戶是誰？-特性：產(chǎn)品區(qū)別于其他競爭產(chǎn)品的特性是什么？-價值：產(chǎn)品的價值體現(xiàn)在什么方面？-優(yōu)先級：產(chǎn)

4、品功能特性的優(yōu)先級次序是什么？用戶需求用戶需求是從用戶角度描述的系統(tǒng)功能需求和非功能需求，通常只涉及系統(tǒng)的外部行為，而不涉及系統(tǒng)的內(nèi)部特性。用戶需求的描述-原則：應(yīng)該易于用戶的理解。一般不采用技術(shù)性很強的語言，而是采用自然語言和直觀圖形相結(jié)合的方式進行描述。-問題：自然語言表達容易含糊和不準確。系統(tǒng)需求系統(tǒng)需求是更加詳細地描述系統(tǒng)應(yīng)該做什么，通常包括許多不同的分析模型，諸如對象模型、數(shù)據(jù)模型、狀態(tài)模型等。系統(tǒng)需求模型的描述-結(jié)構(gòu)化語言-可視化模型-形式化方法系統(tǒng)需求主要是面向開發(fā)人員進行描述，是開發(fā)人員進行軟件設(shè)計的基礎(chǔ)。精品.軟件需求的類型功能需求描述系統(tǒng)應(yīng)該提供的功能或服務(wù)，通常涉及用戶或

5、外部系統(tǒng)與該系統(tǒng)之間的交互，一般不考慮系統(tǒng)的實現(xiàn)細節(jié)。舉例：圖書館功能需求-用戶可從圖書資料庫中查詢或選擇其中的一個子集。-系統(tǒng)可提供適當?shù)臑g覽器供用戶閱讀電子文獻。-用戶每次借閱圖書應(yīng)該對應(yīng)一個唯一的標識號，它被記錄到用戶的帳戶上。非功能需求從各個角度對系統(tǒng)的約束和限制，反映了應(yīng)用對軟件系統(tǒng)質(zhì)量和特性的額外要求，例如響應(yīng)時間、數(shù)據(jù)精度、可靠性、開發(fā)過程的標準等。舉例：圖書館非功能需求-系統(tǒng)應(yīng)在20秒之內(nèi)響應(yīng)所有的請求。-系統(tǒng)每周7天、每天24小時都可以使用?？梢允褂孟到y(tǒng)的所有功能。需求屬性需求屬性是在每個需求所描述的功能之外，為每個需求建立一個上下文和背景資料，目的是方便對需求的管理和跟蹤常

6、用的需求屬性包括：需求創(chuàng)建時間版本號作者需求來源精品.確認需求的客戶代表需求涉及的子系統(tǒng)需求對應(yīng)的產(chǎn)品版本號需求狀態(tài)需求優(yōu)先級測試標準需求的穩(wěn)定性(非功能）需求的質(zhì)量屬性開發(fā)期質(zhì)量屬性：開發(fā)人員和維櫨人員兵主的所有質(zhì)量屬性。送行期質(zhì)量屬性：最終用戶可以直接感爰到的一類屬性。1運行期質(zhì)里屬性i開發(fā)期質(zhì)里屬性 性能（performance )易理解性（understandabuity )安全性(security)可擴展性（extensibility )易用性（usability)可重用性（reusability )持續(xù)可用性（availability )可測試性（testability )可伸縮性

7、（scalability )可維護性（maintainabuity )互操作性（interoperabuity )可移植性（portability )可靠性(reliability)魯棒性(robustness )運行期質(zhì)量屬性性能（terformancej。性能是指軟件系統(tǒng)及對提供相應(yīng)服務(wù)能力。具體而古，性能也括速度，吞吐量和持續(xù)高速性三方面的要求：吞吐量通過單位對問題處理的夂易故柬夂量；達灰往往邋過平均響應(yīng)對問來灰量；而持續(xù)高達牲是指保持高速此理達夂的能力。故率 feffidencyj 和性能（performancej 的關(guān)系： 他們反映了統(tǒng)一問題的“表” “里”兩面，性能為“表”故率為“

8、里”。故半是指軟件糸浼對cpu此理能力和存貯能力達兩大類計算資源的使用故率。安全性 fsecurityj。指軟件糸洗同對兼顏合法用戶提供服務(wù)，以及阻止非援權(quán)使用的能力。高妾全性意味著“同對兼顏”，達是因為有些攻去的g的是使軟件系統(tǒng)拒絕向合法用戶提供服務(wù)而不是非法訪問。易用性 fusabilityj。不少文故也稱為可用性favailabilityj，但為了避免和持續(xù)可用性混淆，達里采用洗行的“易用性”的叫法，指軟件系統(tǒng)易于使用的程皮。持續(xù)可用性 ravailabilityj。 不少文故也稱為可用性，為避免混淆，采用“持繞可用性”指長對問無故障送行的能力。精品.可伸縮性 rscalabilityj

9、 。指當用戶敖和敖據(jù)量增加對，故件糸洗持續(xù)高服務(wù)質(zhì)量的能力?；ゲ僮餍?flnteroperabilityj。指本故件糸洗與其它糸洗支換敖據(jù)和互相調(diào)用服務(wù)的難易程可靠性 rreliabilityj。故件糸洗在一定的對間內(nèi)無故障廷行的能汐。魯棒性 frobustnessj。也稱為健壯性、東錯性。指故件糸洗在以下情況下仍能夠正常廷行的能力：用戶進行了非法操作；相迷的故硬件系統(tǒng)發(fā)生了故障，以及其地非正常情況。開發(fā)期質(zhì)量屬性易理鮮性funderstandabilityj。尤指設(shè)計故開發(fā)人員理鮮的難易程皮。可護展性fextensibilityj。為逄應(yīng)_禽求或需求的支化為軟件增加功能的能力。成們在賣際工作

10、中，經(jīng)常將可護展性稱為靈潔性?？芍赜眯裕╮eusabilityj。重用軟件系統(tǒng)式其一部分的能力的難易程皮。開發(fā)期質(zhì)量屬性可洌武牲ftestabilityj。對軟件冽武以證明其滿足需求規(guī)約的難易程皮。在類際工作中立要指政行單元測甙、插核測甙等的難易程皮?？删S護牲rmaintainability；。為了達到下列三種目的之一，而文隹修故點并賣洗修政的難易程皮：修故bug、增加功能、提高！量屬牲?？梢浦采黵portabilityj。將軟件系統(tǒng)從一個泛行壞境轉(zhuǎn)移到另一個不同的泛行環(huán)埝的難易程皮。需求開發(fā)與需求管理精品.需求開發(fā)目標 需求開發(fā)階段與任務(wù)循環(huán)工作任務(wù)對應(yīng)的rup階段初始循環(huán)明確項目的目標與范

11、圍，完成子系統(tǒng)劃分，明確每個子系統(tǒng)的內(nèi)容（業(yè)務(wù)事件與報表）和相互之間的接口初始階段脈絡(luò)循環(huán)通過對每個業(yè)務(wù)事件進行流程分析、業(yè)務(wù)實體分析、并標示出所有用例細化階段的第一次迭代細節(jié)循環(huán)對每個用例的細節(jié)進行分析，包括事件流、用戶界面原型等細化階段的第二次迭代構(gòu)建階段表：需求開發(fā)的三次循環(huán)精品.需求基線精品.需求分析的任務(wù)需求分析的基本任務(wù)是軟件人員和用戶一起完全弄清用戶對系統(tǒng)的確切要求。這是關(guān)系到軟件開發(fā)成敗的關(guān)鍵步驟，也是整個系統(tǒng)開發(fā)的基礎(chǔ)。需求分析活動提供功能需求、質(zhì)量屬性需求以及約束性需求等不同需求的明確定義。需求分析的任務(wù)就是借助于當前系統(tǒng)的邏輯模型導(dǎo)出目標系統(tǒng)的邏輯模型，解決目標系統(tǒng)的“做

12、什么”的問題。需求分析模型通常軟件開發(fā)項目是要實現(xiàn)目標系統(tǒng)的物理模型，該物理模型是由它的邏輯模型的實例化，即具體到某個業(yè)務(wù)領(lǐng)域而得到的。需求管理工作要點統(tǒng)- 明確的需求項劃分標準引入基線管理引入變更管理精品.引入需求跟蹤需求分析人員的來源開發(fā)人員選擇的解決方案更合理缺乏領(lǐng)域知識，溝通能力不強用戶更善于理清業(yè)務(wù)脈絡(luò)軟件知識欠缺，難以表述需求領(lǐng)域?qū)＜覍I(yè)務(wù)領(lǐng)域十分精通易于按自己的偏好來構(gòu)建系統(tǒng)各種能力培養(yǎng)的要點技能類型培養(yǎng)要點說明業(yè)務(wù)能力類比例如，在很多非銷售型企業(yè)中也能找到“產(chǎn)、售、供”的線索宏觀思考過于陷入細節(jié)就會影響宏觀理解溯源分析技術(shù)的發(fā)展歷史，可以更好地了解其作用技術(shù)能力優(yōu)/缺點了解優(yōu)缺

13、點就能夠在正確的地方應(yīng)用它溝通能力思維模式通過改變思維模式、不斷訓練是可以提高的軟件需求最佳實踐seru模型seru模型s:subject area,表示子問題域，其核心思想是要通過業(yè)務(wù)來分解系統(tǒng)，盡量保證業(yè)務(wù)獨立和低耦合。e:event,表示業(yè)務(wù)事件，通過業(yè)務(wù)事件能夠找到流程，通過流程能夠找到不同場景和用例。r:report,表示報表，統(tǒng)一處理查詢，分析和統(tǒng)計類需求。u:use case,表示用例，需求組織的最小單位，到了需求分析階段的重要活動和產(chǎn)出。 seru過程框架模型將需求過程分解為了三個階段:第一個階段是需求定義，重點是主題域劃分和業(yè)務(wù)事件識別。第二個階段是需求分析，理清需求框架和脈

14、絡(luò)，重點是通過業(yè)務(wù)流程圖轉(zhuǎn)到具體的領(lǐng)域類圖和用例圖精品.到了第三個階段是需求細化，重點就是填充需求細節(jié)，包括用例的詳細編寫，界面和交互設(shè)計等。4、軟件需求分析技術(shù)根據(jù)用戶需求，通過反復(fù)討論、分析，最終明確一個唯一性的用戶需求，這個結(jié)果其實就是我們的軟件需求分析報告。一般我們采用word、powerpoint、visio、frontpage、excel 等 off ice 工具，同時可能采用一些開發(fā)工具，如vc或bc等，同樣也會使用一些圖形工具，如photoshop、調(diào)色板等畫圖工具。使用各種工具表達軟件需求分析，其具體表達手段可以分為：效果圖描述。主要是用戶ui界面的描述反映用戶需求功能；邏輯

15、圖描述。根據(jù)用戶需求功能，使用抽象化理論，以及需求分析理論，對用戶需求功能進行全面的分析，建立功能性邏輯關(guān)系圖，流程邏輯關(guān)系圖等；關(guān)系圖表描述。主要是對信息關(guān)系、數(shù)據(jù)庫表格、接口函數(shù)等描述；工程數(shù)學描述。分析用戶需求，分析用戶需求信息，運用工程數(shù)學進行算法推導(dǎo)，進行合理化需求分析推導(dǎo)；甘特圖描述。主要是軟件項目工作安排，開發(fā)周期預(yù)估；其它方法描述。保證完整性合理性的有效描述。軟件需求分析評估軟件需求分析評估是為了檢查我們進行軟件需求分析工作，保證軟件需求分析工作正確性、完整性、有效性、合理性、可確認性、可實施性，完全保證用戶所需求的功能。組織結(jié)構(gòu)與責任管理滿足用戶需求的功能保證可實施性需求分析

16、評價指標工作周期需求不確定更改與可確認保證兩類分析建模技術(shù)傳統(tǒng)建模技術(shù)：結(jié)構(gòu)化分析建模sa (structured analysis)，又分面向數(shù)據(jù)律樟和而向教據(jù)流建模主要應(yīng)用技術(shù)：數(shù)據(jù)流圖（dfd)；數(shù)據(jù)字典（dd)；加工說明（pespec)；實體關(guān)系圖（e-r)；狀態(tài)變遷圖（std)等ea現(xiàn)代建模技術(shù)：t面型對象分析建模ooa (object-oriented analysis)主要應(yīng)用視圖：用例圖（use case)；時序圖（sequence);狀態(tài)圖（state chart)；類圖（class)；構(gòu)件圖（component)；部署圖（deployment)等結(jié)構(gòu)化分析方法精品.結(jié)構(gòu)化分

17、析建模又分面向數(shù)據(jù)建模和面向數(shù)據(jù)流建模結(jié)構(gòu)化分析方法面向數(shù)據(jù)流進行需求分析的方法，結(jié)構(gòu)化分析方法適合于數(shù)據(jù)處理類型軟件的需求分析。sa法建模就是用抽象模型的概念，按照軟件內(nèi)部數(shù)據(jù)傳遞、變換的關(guān)系，自頂向下逐層分解,直到找到滿足功能要求的所有可實現(xiàn)的軟件模型為止。5、需求分析工具軟件采用適當?shù)墓ぞ?，有可能顯著減少需求階段的錯誤，也可大幅度提高需求分析的質(zhì)量和工作效率。當然工具的選用應(yīng)當與實際的項目相結(jié)合，充分地發(fā)揮工具的作用。ibm rational roserational rose是一個完全的，具有能滿足所有建模環(huán)境（web開發(fā)，數(shù)據(jù)建模，visual studio和c+ )需求能力和靈活性

18、的一套解決方案。rose允許將需求和系統(tǒng)的體系架構(gòu)轉(zhuǎn)換成代碼，對需求和系統(tǒng)的體系架構(gòu)進行可視化，理解和精練。rose是美國的rational公司的面向?qū)ο蠼９ぞ撸ū籭bm收購），利用這個工具，可以建立用uml描述的軟件系統(tǒng)的模型，而且可以自動生成和維護c+、java、vb和oracle等語言和系統(tǒng)的代碼。rational rose包括了統(tǒng)一建模語言（uml)，00se,以及 0 m t。其中統(tǒng)一建模語言（uml)由rational公司3位世界級面向?qū)ο蠹夹g(shù)專家grady booch、ivar jacobson、和jim rumbaugh通過對早期面向?qū)ο笱芯亢驮O(shè)計方法的進一步擴展而得來的，它

19、為可視化建模軟件奠定了堅實的理論基礎(chǔ)。第二講：需求開發(fā)與管理過程%需求開發(fā)過程:、需求管理過程精品.軟件需求工程一、需求開發(fā)過程開發(fā)需求一般要經(jīng)歷如下過程：調(diào)研收集需求，細化整理并轉(zhuǎn)化為客戶需求分析分析產(chǎn)品需求，定義進行需求定義評審?fù)谢驅(qū)＜以u審確認需求規(guī)格說明書rup需求開發(fā)過程初始：學會進行項目目標分解、進行項目目標可研分析，構(gòu)造提交項目目標模型，形成項目大綱細化：學會進行用例圖建模，進行客戶需求分析，構(gòu)造提供軟件功能模型，形成客戶需求文檔構(gòu)造：學會對用例進行“三位” 一體的描述方式，分析軟件用例的動態(tài)行為，構(gòu)造提交用例的業(yè)務(wù)流程圖、實體類圖、原型圖，形成產(chǎn)品需求說明書。交付：學會從需求類

20、型與屬性角度評估需求的質(zhì)量，移交產(chǎn)品需求說明書1調(diào)研收集需求，并轉(zhuǎn)化為客戶需求精品.制定需求調(diào)研計劃確定交流角色和方式準備規(guī)范文件和問卷組織考察、交流和討論活動形成需求調(diào)研記錄需求人員能力要求以好溝通的能力熟悉你公司的軟件產(chǎn)品滿足需求的能力懂得管理知識和技術(shù)知識融會貫通軟件需求方法充滿技巧的管理矛盾的協(xié)調(diào)者企業(yè)需求的傳遞者和控制者制定調(diào)研計劃書*erp系統(tǒng)需求調(diào)研計劃第一章調(diào)研目的第二章調(diào)研的范圍調(diào)研的職能范圍（職能部門、人數(shù)、姓名、人員資格條件）調(diào)研的業(yè)務(wù)范圍（基本情況、銷售、采購、倉庫管理、bom、計劃、生產(chǎn)、質(zhì)量、財務(wù)、成本、基礎(chǔ)數(shù)據(jù)、特殊要求等）調(diào)研的地點范圍第三章調(diào)研的方式（收集資料

21、、問卷調(diào)查、個別交流、開會討論）第四章調(diào)研的階段（任務(wù)、起止時間、實施者、客戶負責人員、工作成果)第五章具體時間安排需求開發(fā)角色精品.準備規(guī)范文件規(guī)程準備規(guī)范文件需求開發(fā)方針需求開發(fā)過程模板需求規(guī)格說明書用戶需求說明書用戶需求調(diào)研記錄檢查表需求開發(fā)qa檢查單需求調(diào)研需求獲取是通過積極與用戶交流，捕捉、分析和修訂用戶對目標系統(tǒng)的需求，并提煉出符合問題解決領(lǐng)域的用戶需呆?，F(xiàn)場考察。到用戶的實際工作環(huán)境中對用戶的工作流程進行觀察，了解用戶實際的操作環(huán)境、操作過程和操作要求，對照用戶提交的問題陳述，對用戶需求可以有更全面、更細致的認識。i獲取需求的策略：建立順暢的溝通機制調(diào)研、訪談與調(diào)查精品.觀察用戶

22、操作流程聯(lián)合需求分析會議需求提取方法一般有問卷法、面談法、數(shù)據(jù)采集法、用例法、情景實例法以及基于目標的方法等，還有知識工程方法，如場記分析法、卡片分類法、分類表格技術(shù)和基于模型的知識獲取等。訪談提綱和調(diào)查問卷有助于提高交流的有效性。在具體的實踐屮，通常采用折衷的方法，即適當?shù)赜媱澓妹嬲勌峋V，但不要過于詳細，允許有一定的靈活性。一般按照如下原則進行準備：所提的問題應(yīng)該循序漸進，從整體的方面開始提問，接下來的問題應(yīng)有助于對前面的問題更好的理解和細化；不要限制用戶對問題的回答，這有可能會引出原先沒有注意的問題；提問和回答在匯總后應(yīng)能夠反映用戶需求的全貌。聯(lián)合需求分析會說的瑪?shù)耐ㄟ^聯(lián)合需求分析會說的討

23、袼，讓血務(wù)專象、信息技術(shù)專象和領(lǐng)城專象在一起尤分地文洗與溝通，鮮決賣際需求最大阪皮地連免了由于用戶參與不足或用戶與開發(fā)團p人無法溝通而凌成的需求失敗協(xié)甫付倫需求沖臾，我出使更多人滿意的析泉方素在會說結(jié)東店訧得到了：用例列表執(zhí)行者列表業(yè)務(wù)規(guī)則列表 扣步走立用例旗型rup初始：目標建模第一步:業(yè)務(wù)目標建模建立業(yè)務(wù)目標到軟件功能目標的轉(zhuǎn)化模型精品.每一個需求用-個需求用一個包來表示，稱為需求包。精品.包與包之間用組成關(guān)系關(guān)聯(lián)起來。包圖需求包可以逐層分解，構(gòu)成分層用例需求結(jié)構(gòu)。第二步業(yè)務(wù)限制因素分析建立業(yè)務(wù)限制因素到軟件非功能目標的轉(zhuǎn)化第三步.兩種底層目標的束定建立軟件功能目標與非功能目標之間的雙向束

24、定關(guān)系2分析細化客戶需求，形成顧客、用戶及產(chǎn)品需求定義系統(tǒng)的邊界建立系統(tǒng)與其外部實體間的界限，明確接口處的信息流。分析需求可彳亍t生和i充分t生，分析每一個需求實現(xiàn)的可行性和充分性，確定與實現(xiàn)相關(guān)的開發(fā)風險。確定需求伙:先級，需求優(yōu)先級有助于建立和維護必要的需求，有利于開發(fā)組織和版本規(guī)劃。建立需求分析模型，通過建立需求的多種視圖，揭示出需求的不正確、不一致、遺漏和冗余等更深的問題，采取多種手段確認需求。定義系統(tǒng)的邊界繪制關(guān)聯(lián)圖：繪制系統(tǒng)關(guān)聯(lián)圖是用于定義系統(tǒng)與系統(tǒng)外部實體間的界限和接u的簡單模型。同時它也明確了通過接u的信息流和物質(zhì)流。創(chuàng)建開發(fā)原型：創(chuàng)建用戶接u原型，當開發(fā)人員或用戶不能確定需求

25、時，開發(fā)一個用戶接u原型，這樣使得許多概念和可能發(fā)生的事更為直觀明了。用戶通過評價原型將使項目參與者能更好地相互理解所要解決的問題。注意要找出需求文檔與原型之間所存的沖突之處。分析可行性分析需求可行性在允許的成本、性能要求下，分析每項需求實施的可行性，明確與每項需求實現(xiàn)相聯(lián)系的風險，包括與其它需求的沖突，對外界因素的依賴和技術(shù)障礙。確定需求優(yōu)先級確定軟件工程需求的優(yōu)先級別應(yīng)用分析方法來確定使用實例、產(chǎn)品特性或單項需求實現(xiàn)的優(yōu)先級別。以優(yōu)先級為基礎(chǔ)確定產(chǎn)品版木將包括哪些特性或哪類需求。當允許需求變更時，在特定的版木屮加入每一項變更，并在那個版本計劃屮作出需要的變更。為需求建立模型為需求建立模型需

26、求的圖形分析模型是軟件需求規(guī)格說明極好的補充說明。它們能提供不同的信息與關(guān)系以宥助于找到不正確的、不一致的、遺漏的和冗余的需求。這樣的模型包括數(shù)據(jù)流圖、實體關(guān)系圖、狀態(tài)變換圖、對話框圖、對象類及交互作用圖。精品.(在后續(xù)章節(jié)詳細講述，此處省略)rup細化：用例建模用例(use case)是一種描述系統(tǒng)需求的方法，使用用例的方法來描述系統(tǒng)需求的過程就是用例建模。用例方法敁早是由iva jackboson博士提山的，后來被綜合到uml規(guī)范之中，成為一種標準化的需求表述體系。從用產(chǎn)的角度釆看他們笄不想了解系統(tǒng)的閃部結(jié)構(gòu)和設(shè)計，他們所哭心的是系：統(tǒng)所能提偌的服務(wù),圯就慝衹開芡幽來的系：統(tǒng)將慝忉何衹丨更

27、用的,這就用彳列方法的基不慝想。用例是系統(tǒng)功能需求的反映。軟件目標是用例建模的依據(jù)。軟件目標是用例引入的主要來源。用例圖描述用例建模的結(jié)果。 一個系統(tǒng)的全部用例圖構(gòu)成該軟件包的需求模型。建立用例模型1用例的泠法來描遠系統(tǒng)的功能需求的遠程就是用例建棋，用例棋型立要包招以下兩部分內(nèi)東：用例圖(use case diagram)確定系統(tǒng)屮所包含的參與者、用例和兩者之間的對應(yīng)關(guān)系，用例圖描述的是關(guān)于系統(tǒng)功能的一個概述。用例規(guī)約(use case specification)針對每一個用例都應(yīng)該存一個用例規(guī)約文檔與之相對應(yīng)，該文檔描述用例的細節(jié)內(nèi)容。用例的厭用在p中鈹推崇備至：鼙個足程鄄絞秫飽慝用例驅(qū)勱

28、” (vse-casedriven)$各神券型的訐亥話勁窆括項目管理、分柝埂計、測芪、賓現(xiàn)等鄠夏以系:統(tǒng)用閔竅歪耍褕入工t牛用例鏌型黧定了鼙個系統(tǒng)5u牛開茨：的基礎(chǔ)。用例圖（use case diagram)用來描述軟件系統(tǒng)向交互活動卷與者提供的一組相關(guān)的功能。在一個用例圖中，有一個或多個參與者與一個或多個用例相互關(guān)聯(lián)。精品.用例模型元素:參與者(jlctot)參與者是指存在于被定義系統(tǒng)外部并與該系統(tǒng)發(fā)生交互的人或其他系統(tǒng)，他們代表的是系統(tǒng)的使用者或使用環(huán)境。用例用于表示系統(tǒng)所提供的服務(wù)，它定義了系統(tǒng)是如何被參與者所使用的，它描述的是參與者為了使用系統(tǒng)所提供的某一完整功能而與系統(tǒng)之間發(fā)生的一段

29、對話。通訊笑聯(lián)(communication association)通訊關(guān)聯(lián)用于表示參與者和用例之間的對應(yīng)關(guān)系，它表示參與者使用了系統(tǒng)中的哪些服務(wù)（用例），或者說系統(tǒng)所提供的服務(wù)（用例）是被哪些參與者所使用的。參與關(guān)聯(lián)描述角色和用例之間有信息交流或系統(tǒng)為誰提供哪些功能與服務(wù)。使用關(guān)聯(lián)指一個用例使用另一個用例的功能行為，用于在用例間共享公共的功能行為。（也是一種泛化（繼承）關(guān)聯(lián)、也稱包含關(guān)聯(lián)）擴展關(guān)聯(lián)通過對已有用例增加一些額外的步驟來建立新的用例。用例規(guī)約提供了用例規(guī)約的模杈，每一個用例的用例規(guī)約都應(yīng)該包含以下內(nèi)容：簡要說明(brief description)簡要介紹該用例的作用和目的。精品.

30、事件流(flow of event)包括基本流和備選流，事件流應(yīng)該表示出所有的場景。用例場景(use-case scenario)包括成功場景和失敗場景，場景主要是由基本流和備選流組合而成的。特殊需求(special requirement)描述與該用例相關(guān)的非功能性需求（包括性能、可靠性、可用性和可擴展性等）和設(shè)計約束（所使用的操作系統(tǒng)、開發(fā)工具等）。前置條件(pre-condition)執(zhí)行用例之前系統(tǒng)必須所處的狀態(tài)。后置條件(post-condition)用例執(zhí)行完畢后系統(tǒng)可能處于的一組狀態(tài)。事件流：基本流基本洗描連的是該用例最正常的一種場景，在暮本洗中系統(tǒng)機行一糸列活動步腺東嘀應(yīng)參與者

31、提出的服務(wù)錆求。成們建說用以下格式來描連基本洗：1)每一個步驟都需要用數(shù)字編呈以清楚地標明步驟的先后順序。2)用一句簡短的來概括每一步驟的主要內(nèi)容，這樣閱讀者可以通過丨 (1)參與者向系統(tǒng)提交了什么信息；(2)對此系統(tǒng)有什么樣的響應(yīng)。具體例子請參見附錄。事件流：備選流備迷洗負責描遂用例執(zhí)行過程中弄常的或偶糸發(fā)生的一些情況，備速洗和基本洗的組合應(yīng)該能夠棗蓋該用例所有可能發(fā)生的場景。在描遂備迷洗對，應(yīng)該包楊以下幾個要素：1)起點：該備選流從事件流的哪一步開始；2)條件：在什么條件下會觸發(fā)該備選流；3)動作：系統(tǒng)在該備選流下會采取哪些動作；4)恢復(fù)：該備選流結(jié)束之后，該用例應(yīng)如何繼續(xù)執(zhí)行。備速洗的描

32、14格式可以與基木洗的格式一玫，也需要編號并以標題概連其a東，編號前可以加以孝母前敬a (alternative)以示與基木洗步腺相區(qū)別。3.定義精品.建立并維護操作概念和相關(guān)場景創(chuàng)建數(shù)據(jù)字典確?？蛻艉烷_發(fā)人員使用一致的定義和術(shù)語。應(yīng)用質(zhì)量功能調(diào)配將產(chǎn)品特性、屬性與對客戶的重要性聯(lián)系起來。編寫需求規(guī)格說明書建立需求跟蹤矩陣構(gòu)造：用例的動態(tài)行為分析用例分析是軟件行為分析的手段諸如：在線支付用例的三位一體描述業(yè)務(wù)流程圖實體類圖界面原型圖多數(shù)情況下，使用順序圖來闡明用例實現(xiàn)，即說明對象如何通過交互來執(zhí)行全部或部分用例的行為?？梢杂靡粋€或多個順序圖來闡明實現(xiàn)用例的對象交互過程。在典型的組織結(jié)構(gòu)屮，主事

33、件流將有一個順序圖，而每個獨立的用例分支流都分別有一個丨序圖。精品.協(xié)作圖協(xié)作圖強調(diào)參加交互的對象的組織。順序圖和協(xié)作圖都來自uml的元模型中相同的信息，所以兩者在語義上是等價的。它們可以從一種形式的圖轉(zhuǎn)換為另一種形式的圖，而不丟失任何伯息。交互圖用于對系統(tǒng)的動態(tài)方面建模。這些動態(tài)方面可能涉及一個系統(tǒng)的體系結(jié)構(gòu)的任意視圖中的任何種類的實例的交互，包括類(含主動類）、接口、構(gòu)件和節(jié)點的實例的交互。協(xié)作圖中的基本原素l.對象：用于表示協(xié)作圖中參與交互的類的實例多個對象：用于表不一組對象。協(xié)作圖中的對象屬性定義對象名稱：在可視化表示屮所用的對象的名字。用冒號與類名分隔。類名：對象所屬的類的名稱。用冒

34、號與對象名分隔。限制類型：可供選擇的類型有：none ：對對象不做限制。new：說明對象在交互期間被創(chuàng)建。destroyed說明對象在交互期間被刪除。transient說明對象是臨時的。描述： 關(guān)于對象的文字描述。應(yīng)用質(zhì)量功能調(diào)配使用質(zhì)量功能調(diào)配質(zhì)量功能調(diào)配是一種高級系統(tǒng)技術(shù)，它將產(chǎn)品特性、屬性與對客戶的要性聯(lián)系起來。該技術(shù)提供了一種分析方法以明確那些是客戶最為關(guān)注的特性。kano模型將需求分為三類：普通需求;必須有的基本需求期望需求，即客戶或許并未提及，但如若缺少會讓他們感到不滿意；興奮需求，即實現(xiàn)了會給客戶帶去驚喜，但若未實現(xiàn)也不會受到責備。精品.創(chuàng)建數(shù)據(jù)字典數(shù)據(jù)字典是對系統(tǒng)用到的所存數(shù)據(jù)

35、項和結(jié)構(gòu)的定義，以確保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。在需求階段，數(shù)據(jù)字典至少應(yīng)定義客戶數(shù)據(jù)項以確?？蛻襞c開發(fā)小組是使用一致的定義和術(shù)語。分析和設(shè)計工具通常包括數(shù)據(jù)字典組件。用例說明用例說明（usecase explanation)是對功能用例圖中的用例做出的說明。在用例說明中，需要描述用例的編號、名稱、參與者和用例的功能以及交互過程。（說明文本格式目前尚未統(tǒng)一，下表僅供參考。)名稱。名稱無疑應(yīng)該表明用戶的意圖或用例的用途，如“研究班招生”。標識符可選。唯一標識符，如uc1701，在項目的其他元素（如類模型）中可用它表引用這個用例。說明。概述用例的幾句話。參與者可選。與此用例相關(guān)的參與者列表。盡管

36、這則信息包含在用例本身中，但在沒有用例圖時，它有助于增加對該用例的理解。狀態(tài)、可選。指示、用例的狀態(tài)，通常為以下幾種之一：進行中、等待審查、通過華i或菜通過帝查。頻手。參與者訪a7此用例的頻率。這是一個自由式問題，如用戶每次錄訪問一次戒每月一次。前置條件。一個條件列表，如果其中包含條件，則這些條件必須在訪問用例之if得到滿足。后置條件。一個條件列表，如果其中包含條件，則這些條件將在用例成功完成以后得到滿足。需求規(guī)約軟件需求規(guī)約是分析任務(wù)的最終產(chǎn)物，通過建立完整的信息描述、詳細的功能和行為描述、性能需求和設(shè)計約束的說明、合適的驗收標準，給出對目標軟件的各種需求。需求規(guī)約遵循如下原則：.從現(xiàn)實中分

37、離功能，即描述要“做什么”而不是“怎樣實現(xiàn)”。(2).要求使用面向處理的規(guī)約語言，討論來自環(huán)境的各種剌激可能導(dǎo)致系統(tǒng)做出什么樣的功能性反應(yīng)，來定義一個行為模型，從而得到“做什么”的規(guī)約。(3).如果被開發(fā)軟件系統(tǒng)規(guī)模很小，那么整個系統(tǒng)也包括在規(guī)格說明的描述之中。精品.規(guī)約必須包括系統(tǒng)運行環(huán)境。.規(guī)約必須是一個認識模型，而不是設(shè)計或?qū)崿F(xiàn)的模型。(6).規(guī)約必須是可操作的，以便能夠利用它決定對于任意給定的測試用例，巳提出的解決方案是否都能滿足規(guī)約。(7).規(guī)約必須允許不完備性并允許擴充。.規(guī)約必須局部化和松散耦合。它所包括的信息必須局部化，這樣當信息被修改時，只要修改某個單個的段落（理想情況）。同

38、時，規(guī)約應(yīng)被松散地構(gòu)造，以便能夠很容易地加入和刪去一些段落。軟件需求規(guī)約的一種典型格式1引言1.1需求規(guī)格說明的目的1.2軟件產(chǎn)品的作用范圍1.3定義、同義詞與縮寫1.4參考文獻1.5需求規(guī)格說明概覽2 一般性描述2.1產(chǎn)品與其環(huán)境之間的關(guān)聯(lián)2.2產(chǎn)品功能23用戶特征2.4限制與約束2.5假設(shè)與前提條件軟件需求規(guī)約模板3特殊需求3.1功能或巧為需求3.1.1功能或行為需求13.1.1.1引言3.1.1.2輸入3.1.1.3處理過程描迷3.1.1.4 輸出3.1.2功能或巧為需求23.1.n功能或行為需求n3.2外部界面需求3.2.1用戶界面3.2.2硬件界面3.2.3故件界面3.3性能需求精品

39、.3.4設(shè)計約束3.4.1標準化約東3.4.2硬件約東3.5屬性3.5.1可用性3.5.2安全性3.5.3可維護性3.5.4可移植性3.6其它需求3.6.1數(shù)據(jù)庫需求3.6.2用戶操作需求3.6.3工作場地需求軟件(產(chǎn)品）需求說明書1.引言/. /項目筒介12編寫說明!. 3參考資料2.目標2. 1概述2.2此務(wù)標2. 2. ； ,# b標2. 2. 2此務(wù)標2.2. 3羅制性因案3.軟件功能結(jié)構(gòu)3./較件包結(jié)構(gòu)圖3.2致件包的說明4.軟件功能規(guī)約自查法由需求分析人員對自己所確定的用例需求進行審核和驗證，糾正需求中存在的問題。自查法又可以分為多種具體方法。第一種是小組審查法，即由一名分析人員向

40、開發(fā)小組中其他人員介紹用例需求,小組中的成員進行提問，由介紹人進行解答。2)專家審查法精品.專家審查法是指聘請業(yè)務(wù)領(lǐng)域、用例、政策、法律等方面的專家對用例需求進行審查。3)用戶審查法分析人員可以把用例需求說明書提交給用戶，有條件時可以同時編寫一份針對此需求的用戶使用說明書并提交給用戶，用戶找出不滿意或認為不能實現(xiàn)的需求，雙方再對這些有爭議的需求進行討論，最后達成一致認識。4)原型法原型法是對存在的有爭議或拿不準的需求，通過建立原型進行驗證，以確定需求的正確性。需求移交的目的：(1)形成甲乙雙方的工程實施技術(shù)合同(2)確定了施工團隊的施工方案、依據(jù)(3)達成了多方公認的驗收依據(jù)、標準需求管理11

41、變更控制版本控制需求跟蹤需求狀態(tài)跟蹤建議變更確定需求文定義對其它定義需求狀分析影響檔的版本需求的鏈接態(tài)作出決策確定需求條定義對其它跟蹤需求的交流目的版本系統(tǒng)元素的每一個狀態(tài)合并確定需求體接鏈測量需求的系的版本需求文檔跟穩(wěn)定性蹤變更控制需求變更的表現(xiàn)形式是多方面的，如老板臨時改變想法、項目預(yù)算增加或減少、客戶對功能的需求改變等。在it項目中，變更可能來自方案服務(wù)商、客戶或產(chǎn)品供應(yīng)商等，也可能來源于項目組內(nèi)部。雖然需求變更的表現(xiàn)形式千差萬別，但究其根本不外乎以下幾種原因：(1)、范圍沒有圈定就開始細化(2)、沒存指定需求的基線(3)、沒存良好的軟件結(jié)構(gòu)適應(yīng)變化版本控制精品.版本控制透過文檔控制（d

42、ocumentation control)記錄程序各個模組的改動，并為每次改動編上序號。這種方法是工程圖（engineering drawings)維護(maintenance)的標準做法，它伴隨著工程圖從圖的誕生一直到圖的定型。 一種簡單的版木控制形式，例如，賦給圖的初版二個版本等級“a”。當做了第一次改變后，版木等級改為“b”，以此類推等等。.需求體系的版本今天，越來越多的公司采用迭代或增量開發(fā)模式。為了降低風險，將開發(fā)過程分為多個增量部分可以加快整個開發(fā)過程。每個階段結(jié)束后，是不是要將整個項目的文檔做一個快照呢？通常是需要的，那此時的項目基線也就是我們這里說的需求體系的版木。需求體系的版

43、木包含自需求而來的多個相關(guān)文檔，此時的版本管理不僅應(yīng)將這些文檔打上統(tǒng)一的基線，并且將該組文檔之間的追蹤關(guān)系也進行基線化的管理。需求變更決策七步法需求變更決策過程可分為七步：第一步:變更申請。第二步:技術(shù)評審。第三步:評價對工期的影響第四步:評價對成本的影響第五步:評價對質(zhì)量的影響第六步:風險評價第七步:變更決策七步法印證了我經(jīng)常鼓吹的項目管理三部曲:細化、量化、圖形化，七步法主要驗證了細化和量化的必要性和好處。第三講結(jié)構(gòu)化分析方法(dfd、 dd、 pespec)結(jié)構(gòu)化開發(fā)方法是現(xiàn)有的軟件開發(fā)方法中最成熟，應(yīng)用最廣泛的方法，主要特點是快速、自然和方便。結(jié)構(gòu)化開發(fā)方法包含三部分：結(jié)構(gòu)化分析方法(

44、sa法）-精品.結(jié)構(gòu)化設(shè)計方法(sd法）結(jié)構(gòu)化程序設(shè)計方法(sp法)sa法建模就是用抽象模型的概念，按照軟件內(nèi)部數(shù)據(jù)傳遞、變換的關(guān)系，自頂向下逐層分解,直到找到滿足功能要求的所有可實現(xiàn)的軟件模型為止。結(jié)構(gòu)化分析方法是傳統(tǒng)軟件工程中公認的技術(shù)成熟和使用廣泛的需求分析方法。它主要借助于分層數(shù)據(jù)流圖和數(shù)據(jù)字典等圖形及半形式化的工具表達系統(tǒng)的需求。結(jié)構(gòu)化分析方法是面向數(shù)據(jù)流進行需求分析的方法，適合于數(shù)據(jù)處理類型軟件的需表分析。結(jié)構(gòu)化分析方法結(jié)構(gòu)化分析方法(structured analysis,簡稱sa法)是面向數(shù)據(jù)流的需求分析方法，是70年代末辦pbwrcfoc cons taint ine及dem

45、arco箏乂提出和發(fā)展，并得到廣泛的應(yīng)用。它適合于分析a：型的數(shù)椐處理系統(tǒng)，特別是企事業(yè)管理系統(tǒng)。主要應(yīng)用技術(shù)和工具：數(shù)據(jù)流圖（dfd)；數(shù)據(jù)字典（dd)；加工說明(pespec)；實體關(guān)系圖(e-r)；狀態(tài)變遷圖（std)等1、數(shù)據(jù)流圖（dpd)2、數(shù)據(jù)字典3、加工說明參 結(jié)構(gòu)化語言參 判定表參 判斷樹精品.主要應(yīng)用技術(shù)和工具:數(shù)據(jù)流圖（dfd)；數(shù)據(jù)字典（dd)；加工說明(pespec)；實體關(guān)系圖(e-r)；狀態(tài)變遷圖（std)等sa法的基本思想結(jié)構(gòu)化分析的基本思想：“分解”和u抽象”分解：把系統(tǒng)的復(fù)雜性降低到可以掌握的程度，把大問題分解成若干小問題，然后分別解決。抽象：即先考慮問題最本

46、質(zhì)的屬性，暫把細節(jié)略去，以后再逐層添加細節(jié)，直至涉及到最詳細的內(nèi)容。自頂向下逐甚分解如圖所示，頂層抽象地描述了整個系統(tǒng)，底層具體地畫出了系統(tǒng)的每一個細節(jié)，而中間層是從抽象到具體的逐層過渡。建立當前系統(tǒng)的“物理模型”系統(tǒng)的“物理模型”就是現(xiàn)實環(huán)境的忠實寫照，即將當前系統(tǒng)用dfd圖描述出來。這樣的表達與當前系統(tǒng)完全對應(yīng)，因此用戶容易理解。精品.抽象出當前系統(tǒng)的邏輯模型;分析系統(tǒng)的“物理模型”，抽象出其本質(zhì)的因素，排除次要因素，獲得用dfd圖描述的當前系統(tǒng)的“邏輯模型建立目標系統(tǒng)的邏輯模型;分析目標系統(tǒng)與當前系統(tǒng)邏輯上的差別，從而進一步明確目標系統(tǒng)“做什么”，建立目稱系統(tǒng)的“邏輯模型”為了對目標系統(tǒng)

47、作完整的描述，還需要考慮人機界面和其它一些問題。數(shù)據(jù)流圖dfd2、數(shù)據(jù)流圖數(shù)據(jù)流圖(data flow diagram,簡稱dfd)是描述系統(tǒng)屮數(shù)據(jù)流程的圖形工具，它標識了一個系統(tǒng)的邏輯輸入和邏輯輸出，以及把邏輯輸入轉(zhuǎn)換成邏輯輸出所需的加工處理。精品.dfd描述系統(tǒng)選輯模型信息在系統(tǒng)中的流動和處理dfd用途交流信息的工具結(jié)構(gòu)化分析和設(shè)計的工具(1)數(shù)據(jù)流圖（dfd)圖形符號輔助的圖形符號dfd基本繪圖符號說明精品.數(shù)據(jù)流 是數(shù)據(jù)在系統(tǒng)內(nèi)傳播的路徑，由一組成固定的數(shù)據(jù)項組成。數(shù)據(jù)流可以從加工流向加工，也可以從加工流向文件或從文件流向加工，也可以從源點流向加工或從加工流向終點。除了與數(shù)據(jù)存儲(文件

48、)之間的數(shù)據(jù)流不用命名外，其余數(shù)據(jù)流都應(yīng)該用名詞或名詞短語命名。加工 也稱為數(shù)據(jù)處理，它對數(shù)據(jù)流進行某些操作或變換。每個加工也要存名字，通常是動詞短語，簡明地描述完成什么加i:。在分層的數(shù)據(jù)流圖屮，加工還應(yīng)有編號。(3)數(shù)據(jù)存儲指暫時保存的數(shù)據(jù)，它可以是數(shù)據(jù)庫文件或任何形式的數(shù)據(jù)組織。流向數(shù)據(jù)存儲的數(shù)據(jù)流可理解為寫入文件，或查詢文件，從數(shù)據(jù)存儲流出的數(shù)據(jù)可理解為從文件讀數(shù)據(jù)或得到查詢結(jié)果。數(shù)據(jù)源點和終點是軟件系統(tǒng)外部環(huán)境屮的實體(包括人員、組織或其他軟件系統(tǒng)），統(tǒng)稱為外部實體。一般只出現(xiàn)在數(shù)據(jù)流圖的頂層圖屮。注意事項特別要注意的是：數(shù)據(jù)流圖不是傳統(tǒng)的流程圖或框圖，數(shù)據(jù)流也不是控制流。數(shù)據(jù)流圖是

49、從數(shù)據(jù)的角度來描述一個系統(tǒng)，而框圖則是從對數(shù)據(jù)進行加工的工作人員的角度來描述系統(tǒng)。數(shù)據(jù)流圖中的箭頭是數(shù)據(jù)流，而框圖中的箭頭則是控制流，控制流表達的是程序執(zhí)行的次序。(2)數(shù)據(jù)流圖的細化分層理由下圖是培訓中心管理系統(tǒng)的數(shù)據(jù)流圖，由于只有一層，因此分解的加工較多不易理解，而且如果其中某個加工較復(fù)雜，影響需求分析結(jié)果的可讀性。 數(shù)據(jù)流圖分層分層理由如果系統(tǒng)規(guī)模較大，僅用一個dfd圖難以描述，會使得系統(tǒng)變得復(fù)雜，且難以理解。為了降低系統(tǒng)的復(fù)雜性，采取“逐層分解”的技術(shù)，畫分層的dfd圖。精品.分層dfd酬“分解”與“抽象”i “先全局后局部，先整體后細節(jié)，先抽象后具體”通常將這種分層的dfd圖，分為頂

50、層、中間層、底層。頂層圖說明了系統(tǒng)的邊界，即系統(tǒng)的輸入和輸出數(shù)據(jù)流，頂層圖只有一張。底層圖由一些不能再分解的加工組成，這些加工都已足夠簡單，稱為基本加工。在頂層和底層之間的是屮間層。屮間層的數(shù)據(jù)流圖描述了某個加工的分解，而它的組成部分又要進一步分解。畫各層dfd圖時，應(yīng)“由外向內(nèi)”。畫分層dfd圖的具體步驟先確定系統(tǒng)范圍，畫出頂層的dfd圖。按照結(jié)構(gòu)化分析方法中“自頂向下，逐步分解”的思想，可以先將整個系統(tǒng)看作是一個加工，它的輸入數(shù)據(jù)和輸出數(shù)據(jù)表明了系統(tǒng)和外部環(huán)境的接口，從而首先畫出系統(tǒng)的頂層數(shù)據(jù)流圖逐層分解頂層dfd圖，獲得若干屮間層dfd圖。為了能夠清楚地表明系統(tǒng)加工的詳細過程，接著從頂層數(shù)據(jù)流圖出發(fā)，逐層地對系統(tǒng)進行分解。每分解一次，系統(tǒng)中加工的數(shù)量就隨之增加，每個加工的功能描