軟件體系結(jié)構(gòu)課件：第3章 軟件需求與架構(gòu)

第3章軟件需求與架構(gòu)教學(xué)內(nèi)容軟件需求概述架構(gòu)師與需求軟件需求面臨的主要困難需求工程需求獲取技術(shù)需求分類和結(jié)構(gòu)化需求建模編寫軟件需求規(guī)格說明書教學(xué)內(nèi)容需求確認(rèn)需求跟蹤技術(shù)需求變更控制軟件需求概述經(jīng)典的“四拍”決策時(shí)拍腦袋——就這么定了

指揮時(shí)拍胸脯——保證沒問題失誤時(shí)拍大腿——我怎么木想到

追查時(shí)拍屁股——老子不干了軟件需求概述看一個(gè)小故事……

外籍人員管理系統(tǒng)軟件需求概述根據(jù)StandishGroup對(duì)23000個(gè)項(xiàng)目進(jìn)行的研究結(jié)果表明，28%的項(xiàng)目徹底失敗，46%的項(xiàng)目超出經(jīng)費(fèi)預(yù)算或者超出工期，只有約26%的項(xiàng)目獲得成功在于這些高達(dá)74%的不成功項(xiàng)目中，有約60%的失敗是源于需求問題也就是說，有近45%的項(xiàng)目最終因?yàn)樾枨蟮膯栴}最終導(dǎo)致失敗需求-導(dǎo)致項(xiàng)目失敗的罪魁禍?zhǔn)总浖枨蟾攀鲈蛐枨蟛幻鞔_

(現(xiàn)實(shí)：軟件項(xiàng)目中40%-60%的問題都是在需求分析階段埋下的禍根，需求錯(cuò)誤消耗整個(gè)項(xiàng)目預(yù)算的30%-50%)不充分的計(jì)劃和過于樂觀的評(píng)估采用新技術(shù)管理方法缺乏或不恰當(dāng)性能問題團(tuán)隊(duì)組織不當(dāng)人際因素軟件需求概述導(dǎo)致的后果需求問題項(xiàng)目徹底失敗項(xiàng)目進(jìn)度拖延項(xiàng)目成本增加項(xiàng)目質(zhì)量失控系統(tǒng)生命縮短……軟件需求概述軟件需求概述軟件需求概述需求分析人員的位置軟件需求概述需求的基本概念

需求的形式需求的主體需求的內(nèi)容

誰(shuí)需要什么樣的

東西？軟件需求概述需求的基本概念I(lǐng)EEE(1997)(1)用戶解決問題或達(dá)到目標(biāo)所需的條件或能力(2)系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其他正式規(guī)定文檔所需具有的條件或能力(3)一種反映上面（1）或（2）所描述的條件或能力的文檔說明SommervilleandSawyer(1997)需求是指明必須實(shí)現(xiàn)什么的規(guī)格說明。它描述了系統(tǒng)的行為、特性或?qū)傩?，是在開發(fā)過程中對(duì)系統(tǒng)的約束。

軟件需求概述客戶、最終用戶&間接用戶

客戶：客戶是掏錢買軟件的人，所以他是“上帝”。與客戶打交道的主要目的是：一是獲取需求，二是簽訂合同最終用戶：即使最終用戶不是上帝，也算是“上帝”的“親戚”，同樣怠慢不得

間接用戶：重視“間接用戶”，千萬(wàn)別“大意失荊州”軟件需求概述需求的重要性FrederickBrooks在他1987年經(jīng)典文章“NoSilverBullet”中闡述了需求的重要性：開發(fā)軟件系統(tǒng)最困難的部分就是準(zhǔn)確說明開發(fā)什么。最困難的概念性工作是編寫出詳細(xì)的需求。需求是產(chǎn)品的根源，需求工作的優(yōu)劣對(duì)產(chǎn)品影響最大。軟件需求概述軟件需求流程軟件需求概述需求分類軟件需求概述業(yè)務(wù)需求反映組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，通常問題定義本身就是業(yè)務(wù)需求背景描述：XX保險(xiǎn)公司希望充分利用日益完善的移動(dòng)通信技術(shù)，在原有的辦公系統(tǒng)的基礎(chǔ)上進(jìn)行擴(kuò)展，使得在外的業(yè)務(wù)人員能夠及時(shí)地獲得客戶、業(yè)務(wù)相關(guān)的動(dòng)態(tài)信息，與此同時(shí)，還要實(shí)現(xiàn)企業(yè)內(nèi)部的即時(shí)通信。業(yè)務(wù)需求/目標(biāo)：通過該系統(tǒng)的實(shí)施，將人工保費(fèi)續(xù)繳、投保手續(xù)辦理兩項(xiàng)業(yè)務(wù)運(yùn)轉(zhuǎn)周期縮短10％以上，使企業(yè)內(nèi)部溝通效率大幅改善，以幫助企業(yè)運(yùn)轉(zhuǎn)效率得以提高。軟件需求概述用戶需求描述用戶使用產(chǎn)品必須要完成什么任務(wù)，怎么完成的需求，通常是在問題定義的基礎(chǔ)上進(jìn)用戶訪談、調(diào)查，對(duì)用戶使用的場(chǎng)景進(jìn)行整理，從而建立從用戶角度的需求。用戶有不同類型：

管理型、事務(wù)型信息系統(tǒng)、人

決策層、使用層常用者、偶用者組織方法：用例等例：對(duì)快到期的客戶，系統(tǒng)將通過短信將續(xù)保信息發(fā)給該客戶的代理人軟件需求概述系統(tǒng)需求從系統(tǒng)的角度來說明軟件的需求，包括用特性說明的功能需求、質(zhì)量屬性，以及其他非功能需求，還有設(shè)計(jì)約束等。領(lǐng)域?qū)＜遥簶I(yè)務(wù)需求用戶：用戶需求開發(fā)人員：系統(tǒng)需求

功能需求大部分來源于系統(tǒng)需求軟件需求概述功能需求需求的主體，需求的本質(zhì)功能需求定義：系統(tǒng)必須完成的那些事，即為了向它的用戶提供有用的功能，產(chǎn)品必須執(zhí)行的動(dòng)作零散（需求項(xiàng)）

整理（特性、用例）軟件需求概述非功能需求指產(chǎn)品必須具備的屬性或品質(zhì)，如正確性、可靠性、性能、容錯(cuò)性和可擴(kuò)展性等。質(zhì)量屬性：

開發(fā)期質(zhì)量：可擴(kuò)展性、可復(fù)用性、可維護(hù)性等運(yùn)行期質(zhì)量：正確性、健壯性、性能、可靠性、容錯(cuò)性、易用性、安全性、可移植性、兼容性等軟件需求概述設(shè)計(jì)約束也稱為“限制條件”或“補(bǔ)充規(guī)約”，通常是對(duì)解決方案的一些約束說明。例如必須采用國(guó)有自主知識(shí)產(chǎn)權(quán)的數(shù)據(jù)庫(kù)系統(tǒng)，必須運(yùn)行在UNIX操作系統(tǒng)之下等。架構(gòu)師與需求需求進(jìn)架構(gòu)出1.TheRequirementsStatement2.EmergingRequirements3.Redesign4.SixMonthsLater架構(gòu)師與需求架構(gòu)師與需求架構(gòu)師是客戶需求和開發(fā)者之間的橋梁。架構(gòu)師的工作職責(zé)是在一個(gè)軟件項(xiàng)目開發(fā)過程中，將客戶的需求轉(zhuǎn)換為規(guī)范的開發(fā)計(jì)劃和文本，并制定這個(gè)項(xiàng)目的總體架構(gòu)，指導(dǎo)整個(gè)開發(fā)團(tuán)隊(duì)完成這個(gè)計(jì)劃。架構(gòu)師需要參與項(xiàng)目開發(fā)的全部過程，負(fù)責(zé)在整個(gè)項(xiàng)目中對(duì)技術(shù)活動(dòng)和技術(shù)說明進(jìn)行指導(dǎo)和協(xié)調(diào)。架構(gòu)師的主要任務(wù)不是從事具體的項(xiàng)目程序的編寫，而是從事更高層次的開發(fā)架構(gòu)工作。架構(gòu)師必須對(duì)開發(fā)技術(shù)非常了解，并且需要有良好的組織管理能力。從項(xiàng)目架構(gòu)層面上說，一個(gè)架構(gòu)師的工作好壞決定了整個(gè)項(xiàng)目開發(fā)的成敗。架構(gòu)師與需求架構(gòu)師與需求一線架構(gòu)師的六個(gè)經(jīng)典困惑將系統(tǒng)劃分模塊，如何更合理？大系統(tǒng)架構(gòu)設(shè)計(jì)，如何起步？總覺需求很糟糕，影響了架構(gòu)設(shè)計(jì)？非功能需求重要，但如何設(shè)計(jì)？架構(gòu)新手：缺乏指導(dǎo)，架構(gòu)設(shè)計(jì)不知所措。架構(gòu)老手：缺乏總結(jié)，仍“怕”下一個(gè)項(xiàng)目。架構(gòu)師與需求架構(gòu)師必須熟悉需求把握需求特點(diǎn)，確定架構(gòu)驅(qū)動(dòng)力根據(jù)重大需求，確定概念架構(gòu)細(xì)化架構(gòu)設(shè)計(jì)，關(guān)注不同視圖軟件需求面臨的主要困難需求，真難！軟件需求面臨的主要困難知識(shí)技能問題領(lǐng)域知識(shí)學(xué)習(xí)培訓(xùn)軟件需求面臨的主要困難態(tài)度問題用戶說不清楚需求或者需求發(fā)生變更——常見的問題不能把這些問題當(dāng)成了借口需求分析員的天職就是在有限的時(shí)間內(nèi)獲取準(zhǔn)確而細(xì)致的用戶需求，如果做不到就是失職，不要找借口軟件需求面臨的主要困難合作關(guān)系如果需求分析員不能與用戶建立良好的合作關(guān)系，那么他們?cè)谛枨箝_發(fā)過程中會(huì)很疲憊。對(duì)于一些競(jìng)標(biāo)項(xiàng)目，在合同未簽訂之前的需求開發(fā)工作尤為困難。用戶未必會(huì)買你的產(chǎn)品，他不會(huì)投入很多精力來協(xié)助你搞需求開發(fā)。需求分析員不是銷售人員，他們不可能象銷售人員那樣通過某些手段籠絡(luò)住用戶就能成功。出色的需求分析員不僅要有過硬的專業(yè)知識(shí)，還要具備較強(qiáng)的交流、溝通能力。軟件需求面臨的主要困難合作關(guān)系（續(xù)）開發(fā)方和用戶方在開展需求開發(fā)之前，雙方協(xié)商并撰寫“用戶在需求工程中的權(quán)利與義務(wù)”，即以協(xié)議的方式確定合作關(guān)系。如果條件允許的話，開發(fā)方最好為用戶舉辦關(guān)于需求工程的培訓(xùn)，這樣的培訓(xùn)將使用戶明白需求的重要性以及忽視需求的危害性，從而促使他們積極友善地參加需求工程中的各項(xiàng)活動(dòng)。軟件需求面臨的主要困難合作關(guān)系（續(xù)）用戶在需求工程中的“權(quán)利”1.有權(quán)要求開發(fā)方派遣資質(zhì)合格的需求分析員和相關(guān)人員。2.有權(quán)要求開發(fā)方采用用戶熟悉的語(yǔ)言來描述需求，即開發(fā)方必須提供用戶看得懂得需求文檔。3.有權(quán)審查需求文檔，并對(duì)有爭(zhēng)議的需求作出決策。如果認(rèn)為需求文檔不能準(zhǔn)確地反映用戶真實(shí)的意愿，可以拒絕在需求文檔上簽字。4.如果用戶想要變更需求，有權(quán)要求開發(fā)方對(duì)該變更將產(chǎn)生的影響作出真實(shí)可信的評(píng)估，以便用戶決定是否變更需求。軟件需求面臨的主要困難合作關(guān)系（續(xù)）用戶在需求工程中的“義務(wù)”1.以積極友善的態(tài)度與開發(fā)方人員交流、協(xié)作，盡可能地為開發(fā)方人員提供工作和生活上的便利。2.樂意接受需求分析員的采訪，在不泄漏機(jī)密的前提下盡可能地回答需求分析員的問題。3.在不泄漏機(jī)密的前提下，盡可能地向需求分析員提供與需求相關(guān)的材料。4.與需求分析員共同評(píng)審需求文檔，確保需求文檔準(zhǔn)確地反映用戶真實(shí)的意愿。軟件需求面臨的主要困難用戶說不清楚需求普遍現(xiàn)象，讓開發(fā)人員頭痛的大問題有些用戶雖然心里明白想要什么，但卻說不清楚需求需求分析員：絕不能以用戶說不清楚需求為借口而草率地對(duì)待需求開發(fā)工作，否則會(huì)連累整個(gè)開發(fā)團(tuán)隊(duì)無論是什么原因?qū)е掠脩粽f不清楚需求，需求分析員必須設(shè)法搞清楚用戶真正的需求，這是需求分析員的職責(zé)，也是職業(yè)的挑戰(zhàn)軟件需求面臨的主要困難雙方誤解需求不論是復(fù)雜的項(xiàng)目還是簡(jiǎn)單的項(xiàng)目，需求分析員和用戶都有可能誤解需求需求確認(rèn)工作（屬于需求管理）必不可少軟件需求面臨的主要困難開發(fā)人員寫不好需求文檔需求調(diào)查工作不充分，獲取的需求信息太少或者太亂，以至于寫不成需求文檔開發(fā)人員寫作能力比較差，雖然在調(diào)查過程中已經(jīng)獲得了不少需求信息，卻寫不出好的需求文檔來?？梢院敛豢鋸埖卣f，國(guó)內(nèi)90％以上的軟件開發(fā)人員，寫作能力遠(yuǎn)不及開發(fā)能力提高開發(fā)人員寫作能力的根本辦法就是多練習(xí)寫文檔，熟能生巧。另外，應(yīng)當(dāng)提供合適的文檔模板以及比較好的示例文檔，盡可能地降低寫作難度軟件需求面臨的主要困難用戶經(jīng)常變更需求需求變更通常會(huì)對(duì)項(xiàng)目的進(jìn)度、人力資源、經(jīng)費(fèi)產(chǎn)生很大的影響，這是開發(fā)商非常畏懼的問題需求變更并不可怕，可怕的是需求變更失去控制，導(dǎo)致項(xiàng)目混亂，因此需求變更控制是需求工程的重要活動(dòng)軟件需求面臨的主要困難如何解決？需求工程！需求工程什么是需求工程把所有與需求直接相關(guān)的活動(dòng)通稱為需求工程。需求工程是軟件工程的一個(gè)分支，它關(guān)注于軟件系統(tǒng)所應(yīng)予實(shí)現(xiàn)的現(xiàn)實(shí)世界目標(biāo)、軟件系統(tǒng)的功能和軟件系統(tǒng)應(yīng)當(dāng)遵守的約束，同時(shí)它也關(guān)注以上因素和準(zhǔn)確的軟件行為規(guī)格說明之間的聯(lián)系，關(guān)注以上因素與其隨時(shí)間或跨產(chǎn)品族而演化之后的相關(guān)因素之間的聯(lián)系。需求工程創(chuàng)建的第一份文檔是需求陳述，用于在項(xiàng)目開發(fā)之初理解客戶的需求。需求工程中的活動(dòng)可分為兩大類：需求開發(fā)需求管理需求工程需求工程結(jié)構(gòu)圖需求工程需求開發(fā)過程域

需求開發(fā)的目的是通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求需求調(diào)查（需求獲?。┑哪康氖峭ㄟ^各種途徑獲取用戶的需求信息（原始材料），產(chǎn)生《需求陳述》。需求分析的目的是對(duì)各種需求信息進(jìn)行分析，消除錯(cuò)誤，刻畫細(xì)節(jié)等。常見的需求分析方法有“問答分析法”和“建模分析法”兩類。需求定義的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果，進(jìn)一步定義準(zhǔn)確無誤的產(chǎn)品需求，產(chǎn)生《軟件需求規(guī)格說明書》。系統(tǒng)設(shè)計(jì)人員將依據(jù)《軟件需求規(guī)格說明書》開展系統(tǒng)設(shè)計(jì)工作。需求工程需求管理過程域

需求管理的目的是在客戶與開發(fā)方之間建立對(duì)需求的共同理解，維護(hù)需求與其它工作成果的一致性，并控制需求的變更。需求確認(rèn)是指開發(fā)方和客戶共同對(duì)需求文檔進(jìn)行評(píng)審，雙方對(duì)需求達(dá)成共識(shí)后作出書面承諾，使需求文檔具有商業(yè)合同效果。需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對(duì)應(yīng)關(guān)系，建立與維護(hù)“需求跟蹤矩陣”，確保產(chǎn)品依據(jù)需求文檔進(jìn)行開發(fā)。需求變更控制是指依據(jù)“變更申請(qǐng)－審批－更改－重新確認(rèn)”的流程處理需求的變更，防止需求變更失去控制而導(dǎo)致項(xiàng)目發(fā)生混亂。需求工程需求工程的一些感悟不論是合同項(xiàng)目還是自主研發(fā)的產(chǎn)品，都必須開展需求開發(fā)和需求管理活動(dòng)。開發(fā)者對(duì)待需求工程的態(tài)度可分“被動(dòng)型”、“主動(dòng)型”和“領(lǐng)先型”三種，只有后兩種才有可能開發(fā)出成功的產(chǎn)品。“被動(dòng)型”是指開發(fā)者被動(dòng)地對(duì)待需求工程中的各項(xiàng)活動(dòng)，能少干則少干，能偷懶則偷懶?！爸鲃?dòng)型”是指開發(fā)者積極地開展需求工程中的各項(xiàng)活動(dòng)。他們把獲取準(zhǔn)確的需求當(dāng)作自己的職責(zé)，會(huì)想盡一切辦法克服需求開發(fā)和需求管理過程中的困難，而不是找借口推卸責(zé)任?！邦I(lǐng)先型”是需求工程的最高境界。開發(fā)者發(fā)掘了連用戶自己都沒有意識(shí)到的需求，導(dǎo)致用戶跟著新產(chǎn)品跑而不是新產(chǎn)品圍著用戶轉(zhuǎn)，這叫引導(dǎo)消費(fèi)。需求工程做到這個(gè)份上，才能使產(chǎn)品立于不敗之地，長(zhǎng)盛不衰。需求獲取技術(shù)需求獲取是需求工程的主體。對(duì)于所建議的軟件產(chǎn)品，獲取需求是一個(gè)確定和理解不同用戶類的需要和限制的過程需求獲取是在問題及其最終解決方案之間架設(shè)橋梁的第一步需求獲取可能是軟件開發(fā)中最困難、最關(guān)鍵、最易出錯(cuò)及最需要交流的方面需求獲取是一個(gè)需要高度合作的活動(dòng)，而并不是客戶所說需求的簡(jiǎn)單拷貝需求獲取技術(shù)需求獲取簡(jiǎn)單嗎？表面上實(shí)質(zhì)上

范圍問題

理解問題

易變問題需求獲取技術(shù)怎樣獲取需求需求采集需求分析需求定義用戶開發(fā)商方法論引導(dǎo)《軟件需求規(guī)格說明書》需求獲取技術(shù)獲取需求第一步需求采集1需求分析2需求定義3采集什么內(nèi)容？系統(tǒng)建設(shè)目標(biāo)業(yè)務(wù)項(xiàng)業(yè)務(wù)流程非功能需求從哪里采集？橫向：各業(yè)務(wù)科室縱向：省、部標(biāo)準(zhǔn)規(guī)范經(jīng)驗(yàn)：核心平臺(tái)、同行業(yè)其他城市、現(xiàn)有系統(tǒng)怎么采集？調(diào)查問卷座談考察、培訓(xùn)需求采集的定義需求獲取技術(shù)討論：需求從哪里來？人（決策者，使用者，…）物（文件，單據(jù)，報(bào)表，…）系統(tǒng)（其他類似系統(tǒng)，其他應(yīng)用，…）需求獲取技術(shù)需求的來源訪問并與有潛力的用戶探討市場(chǎng)調(diào)查和用戶問卷調(diào)查觀察正在工作的用戶用戶任務(wù)的內(nèi)容分析相關(guān)文件及文檔，包括手冊(cè)、文書、表格和報(bào)表等把對(duì)目前的競(jìng)爭(zhēng)產(chǎn)品的描述寫成文檔對(duì)當(dāng)前系統(tǒng)的問題報(bào)告和增強(qiáng)要求需求獲取技術(shù)不同層次的用戶，需求也存在不同需求獲取技術(shù)獲取需求的方法面談（訪談）問卷調(diào)查會(huì)議（需求討論會(huì)、重點(diǎn)問題討論會(huì)、業(yè)務(wù)專題討論會(huì)、設(shè)計(jì)專題討論會(huì)）文檔研究任務(wù)示范（觀察）用例與角色扮演原型設(shè)計(jì)（小規(guī)模試驗(yàn)）研究類似公司需求獲取技術(shù)需求獲取前準(zhǔn)備需求分析前最好明確系統(tǒng)要采用的技術(shù)體系組織隊(duì)伍準(zhǔn)備相應(yīng)的文檔聯(lián)系和了解用戶方編寫計(jì)劃需求獲取技術(shù)需求獲取技術(shù)-面談訪談適合于了解域中的當(dāng)前工作以及當(dāng)前問題作為主要的獲取技術(shù)局限就是需求獲取障礙訪談?dòng)?jì)劃與問題清單（訪談模板）技巧：錄音筆需求獲取技術(shù)需求獲取技術(shù)-面談面談問題基本上可以分為兩種類型：開放式問題和封閉式問題開放式問題（Open-Ended）封閉式問題（Closed）需求獲取技術(shù)需求獲取技術(shù)-面談開放式問題被會(huì)見者對(duì)答復(fù)的選擇可以是開放和不受限制的，他們可能答復(fù)兩個(gè)詞，也可能答復(fù)兩段話在希望得到豐富（具有一定深度和廣度）信息時(shí)，開放式問題比較合適例如：“你覺得把所有的經(jīng)理都置于一個(gè)內(nèi)聯(lián)網(wǎng)內(nèi)怎么樣？”“請(qǐng)解釋你是如何做進(jìn)度決策的？”“對(duì)公司中企業(yè)對(duì)企業(yè)電子商務(wù)的當(dāng)前狀態(tài)有何看法？”需求獲取技術(shù)需求獲取技術(shù)-面談開放式問題優(yōu)缺點(diǎn)優(yōu)點(diǎn)：讓被會(huì)見者感到自在；會(huì)見者可以收集被會(huì)見者使用的詞匯，這能反應(yīng)他的教育、價(jià)值標(biāo)準(zhǔn)、態(tài)度和信念；提供豐富的細(xì)節(jié)；對(duì)沒采用的進(jìn)一步的提問有啟迪作用；讓被會(huì)見者更感興趣；容許更多的自發(fā)性；會(huì)見者可以在沒有太多準(zhǔn)備的情況下進(jìn)行面談。缺點(diǎn)：提此類問題可能會(huì)產(chǎn)生太多不相干的細(xì)節(jié)；面談可能失控；開放式的回答會(huì)花費(fèi)大量的時(shí)間才能獲得有用的信息量；可能會(huì)使會(huì)見者看上去沒有準(zhǔn)備。需求獲取技術(shù)需求獲取技術(shù)-面談封閉式問題優(yōu)缺點(diǎn)優(yōu)點(diǎn)：節(jié)省時(shí)間；切中要點(diǎn)；保持對(duì)面談的控制；快速探討大范圍問題；得到貼切的數(shù)據(jù)缺點(diǎn)：使得被會(huì)見者厭煩；得不到豐富的細(xì)節(jié)；出于上述原因，失去主要思想；不能建立和面談?wù)叩挠押藐P(guān)系需求獲取技術(shù)需求獲取技術(shù)-面談封閉式問題答案有基本的形式，被會(huì)見者的回答是受到限制的例如：“項(xiàng)目存儲(chǔ)庫(kù)每個(gè)星期更新多少次？”“電話中心一個(gè)月平均收到多少個(gè)電話？”“下列信息中哪個(gè)對(duì)你最有用：（1）填好的客戶投訴單；（2）訪問web站點(diǎn)的客戶的電子郵件投訴；（3）與客戶面對(duì)面的交流；（4）退回的貨物?！薄傲谐鲱^兩項(xiàng)需要優(yōu)先考慮的改善技術(shù)基礎(chǔ)設(shè)施的事項(xiàng)。”需求獲取技術(shù)需求獲取技術(shù)-面談需求獲取技術(shù)需求獲取技術(shù)-面談其他重要的問題類型探究式問題為什么？你能舉個(gè)例子嗎？你能詳細(xì)描述一下嗎？誘導(dǎo)性問題“你和其他經(jīng)理一樣，都同意把財(cái)產(chǎn)管理計(jì)算機(jī)化，是嗎”雙筒問題“每天你通常會(huì)做什么決策，你是怎樣做的”元問題我的問題看起來相關(guān)嗎？你的回答正式嗎？你是回答這些問題的最佳人選嗎？我問了太多的問題嗎？我還應(yīng)該見什么人？需求獲取技術(shù)需求獲取技術(shù)-面談其他重要的問題類型提示示例總結(jié)和反饋你能不能總結(jié)一下系統(tǒng)的功能？你能不能總結(jié)一下一個(gè)成功系統(tǒng)的必備特征？在使用的時(shí)候，你希望能夠從系統(tǒng)當(dāng)中得到什么類型的信息反饋？重復(fù)和改述能不能再說一次系統(tǒng)的哪些特征是重要的？你能不能詳細(xì)的重新敘述一下使用系統(tǒng)的步驟？在使用系統(tǒng)的時(shí)候你會(huì)做出什么決定？建立場(chǎng)景和細(xì)節(jié)描述有什么是你現(xiàn)在能做，卻在新系統(tǒng)中不能做的？在什么情況下，功能是必需的？設(shè)想現(xiàn)在是6個(gè)月之后，你需要評(píng)估系統(tǒng)的成功狀況，你會(huì)使用哪些標(biāo)準(zhǔn)來做出評(píng)價(jià)？抗辯你能不能想出什么不使用系統(tǒng)的理由？你為什么會(huì)不想使用系統(tǒng)呢？你能不能想出將來可能導(dǎo)致系統(tǒng)失敗或故障的原因？需求獲取技術(shù)需求獲取技術(shù)-面談面談結(jié)構(gòu)金字塔型漏斗型菱形需求獲取技術(shù)需求獲取技術(shù)-面談金字塔結(jié)構(gòu)需求獲取技術(shù)需求獲取技術(shù)-面談漏斗結(jié)構(gòu)需求獲取技術(shù)需求獲取技術(shù)-面談菱形結(jié)構(gòu)需求獲取技術(shù)需求獲取技術(shù)-面談面談報(bào)告應(yīng)該盡快的復(fù)查面談?dòng)涗?，總結(jié)面談信息，完成面談報(bào)告。需求獲取技術(shù)實(shí)例分析Tom是某軟件公司系統(tǒng)分析員團(tuán)隊(duì)中的一員，他受委任去與組織成員面談，為系統(tǒng)研究收集材料。企業(yè)稱為FallBack工業(yè)，它有5個(gè)管理層人員。此外，生產(chǎn)、會(huì)計(jì)、營(yíng)銷、系統(tǒng)、物流和高層管理是將受到所建議的系統(tǒng)影響的職能區(qū)域。每個(gè)階層大約有40人。生產(chǎn)層共有80人，會(huì)計(jì)層有35人，營(yíng)銷層有42人，系統(tǒng)層有10人，物流層有28人。高層管理有5人。Tom應(yīng)該怎樣選擇面談對(duì)象?為什么?解答：（1）選擇面談對(duì)象的時(shí)候采用隨機(jī)抽樣，從5個(gè)階層以及生產(chǎn)、會(huì)計(jì)、營(yíng)銷、系統(tǒng)、物流各選擇2-3名客戶參與面談；高層管理均要參加面談。因?yàn)樵谶x擇面談的時(shí)候要力爭(zhēng)均衡地收集用戶的需求，因此要涉及各方面受系統(tǒng)影響的人。采樣的規(guī)則：控制人數(shù)（4-8）。（2）高層管理的人最先面談；然后是系統(tǒng)層；其余層的面談對(duì)象根據(jù)實(shí)際情況可以先后安排面談的時(shí)間，不一定要分先后順序。跟高層管理人員進(jìn)行面談，采用漏斗結(jié)構(gòu)，因?yàn)楦鱾€(gè)高層管理人員對(duì)各自管理的層次從大體上有準(zhǔn)確的把握，有助于開發(fā)人員首先獲取對(duì)項(xiàng)目的廣度方面的認(rèn)識(shí)，也能獲取一些較為詳細(xì)的信息。跟具體部門人員進(jìn)行面談，采用菱形(必要時(shí)，金字塔)結(jié)構(gòu)，因?yàn)檫@種面談?shì)^為具體，問題常為封閉式問題，這樣有助于分析人員獲得深度認(rèn)識(shí)。面談基本規(guī)則：（1）先業(yè)務(wù)需求，后用戶需求，所以先領(lǐng)導(dǎo)后普通（2）開始漏斗，領(lǐng)導(dǎo)漏斗（3）普通用戶菱形，必要時(shí)金字塔需求獲取技術(shù)需求獲取技術(shù)-問卷調(diào)查當(dāng)潛在使用者太多或分布太廣時(shí)，可以考慮采用問卷調(diào)查方式一般來說，問卷調(diào)查適合于大型企業(yè)或公眾信息系統(tǒng)的設(shè)計(jì)，因?yàn)樗婕暗氖褂梅秶驅(qū)ο筇珡V，需求分析人員無法逐一親自調(diào)查，所以利用問卷調(diào)查方式來收集使用者需求比較好。如何進(jìn)行問卷調(diào)查：設(shè)計(jì)問卷、預(yù)先測(cè)試、調(diào)查對(duì)象劃分、問卷總結(jié)等調(diào)查問卷實(shí)例需求獲取技術(shù)需求獲取技術(shù)-需求專題討論會(huì)一種適用于任何情景的技術(shù)頭腦風(fēng)暴如何計(jì)劃并實(shí)施需求專題討論會(huì)專題討論會(huì)準(zhǔn)備實(shí)施總結(jié)需求獲取技術(shù)需求獲取技術(shù)-文檔研究研究企業(yè)內(nèi)部的規(guī)章制度、企業(yè)或部門報(bào)表、工作流程（手冊(cè)）是了解企業(yè)工作流程的第一步工作一般來講，企業(yè)組織內(nèi)部很少有完整的文件資料來詳細(xì)描述清楚企業(yè)業(yè)務(wù)工作流程的全貌，同時(shí)可能工作流程已經(jīng)經(jīng)過多次修改，而文件往往沒有及時(shí)更新，因此用這種方法收集需求信息常有過時(shí)之慮需求獲取技術(shù)需求獲取技術(shù)-文檔研究硬數(shù)據(jù)收集數(shù)據(jù)表格反映了組織的信息流收集正在使用的每張空白表格表格、填寫和分發(fā)說明對(duì)比填寫好的表格表格中是否有從來都不填寫的數(shù)據(jù)項(xiàng)；應(yīng)該收到表格的人是否真的收到了；他們是否按照正常程序使用、存儲(chǔ)和丟棄表格等等需求獲取技術(shù)需求獲取技術(shù)-文檔研究硬數(shù)據(jù)統(tǒng)計(jì)報(bào)表反映了組織過去的主要業(yè)務(wù)和業(yè)務(wù)目標(biāo)統(tǒng)計(jì)規(guī)則也是一種豐富的知識(shí)，統(tǒng)計(jì)項(xiàng)分解為細(xì)節(jié)業(yè)務(wù)數(shù)據(jù)的過程往往也就是組織目標(biāo)分解到具體業(yè)務(wù)的過程根據(jù)實(shí)際工作填寫過的統(tǒng)計(jì)報(bào)表，就可以發(fā)現(xiàn)組織實(shí)際的業(yè)務(wù)執(zhí)行狀況，從中發(fā)現(xiàn)組織面臨的具體問題需求獲取技術(shù)需求獲取技術(shù)-文檔研究硬數(shù)據(jù)整個(gè)組織的描述文檔組織結(jié)構(gòu)圖：幫助發(fā)現(xiàn)項(xiàng)目的關(guān)鍵涉眾門戶網(wǎng)站：反映組織的業(yè)務(wù)開展?fàn)顩r業(yè)務(wù)指導(dǎo)文檔工作指南和規(guī)章手冊(cè)：解釋業(yè)務(wù)的詳細(xì)執(zhí)行過程，反映業(yè)務(wù)的具體細(xì)節(jié)業(yè)務(wù)備忘反映業(yè)務(wù)的實(shí)際執(zhí)行情況形成對(duì)組織工作過程的清晰理解需求獲取技術(shù)需求獲取技術(shù)-觀察一般來說，現(xiàn)場(chǎng)觀察所獲得的資料比查閱資料正確性要高，也能驗(yàn)證所收集資料的正確性和補(bǔ)充資料的不完整，通過觀察可以獲得第一手的資料。觀察能大大地增加對(duì)當(dāng)前工作和部分相關(guān)問題的了解，也能作為其它信息的檢查觀察的局限性。往往無法捕捉到一些真正關(guān)鍵問題火焰信息轉(zhuǎn)爐煉鋼終點(diǎn)預(yù)報(bào)系統(tǒng)需求獲取技術(shù)需求獲取技術(shù)-用例和角色扮演用例描述了用戶和系統(tǒng)之間的交互，其重點(diǎn)是系統(tǒng)為用戶做什么用例模型描述全部的系統(tǒng)功能性行為需求獲取技術(shù)需求獲取技術(shù)-原型開發(fā)軟件需求原型定義為：它是軟件系統(tǒng)的部分實(shí)現(xiàn)，構(gòu)建該原型幫助開發(fā)人員、用戶以及客戶更好地理解系統(tǒng)的需求原型解決“是的，但是”問題以及“尚未發(fā)現(xiàn)的遺址”綜合癥尤其有效為“模糊”需求建立原型

一個(gè)更加真實(shí)的原型……需求獲取技術(shù)實(shí)例分析下面是系統(tǒng)分析團(tuán)隊(duì)的一名成員提出的第一份面談報(bào)告：在我看來，面談進(jìn)行得很好，我和他就一些問題聊了兩個(gè)半小時(shí)，他告訴我有關(guān)公司的所有歷史，很有意思。他也提到，自他來到該公司的16年間，公司沒有任何變化。我們不久將再次舉行會(huì)面，因?yàn)槲覀冞€沒有深入研究我準(zhǔn)備的問題?！?1)試評(píng)論這個(gè)面談報(bào)告。假設(shè)你要團(tuán)隊(duì)成員使用下圖提供的報(bào)表，那么他漏了什么主要信息？(2)什么信息對(duì)面談報(bào)告來說是無關(guān)緊要的？(3)如果真的發(fā)生了報(bào)告中提及的情況，則必須向同事提出哪些建議，以幫助他更好地舉行下一次面談。解答：(1)面談時(shí)間稍長(zhǎng)，而且控制不佳；遺漏了關(guān)于“最新建議的系統(tǒng)的觀點(diǎn)”。(2)有關(guān)公司的所有歷史(3)面談主體階段：①控制面談的過程。面談開始的時(shí)候可以通過例如談公司歷史來醞釀一下交流的氣氛，但是不能偏離主題；如果長(zhǎng)時(shí)間的談?wù)摬幌嚓P(guān)的信息的時(shí)候，需求分析人員就可以委婉的提醒面談對(duì)象，并重新切回正題。②注意保持面談的主題。針對(duì)每個(gè)面談的目標(biāo)，要在面談的過程中安排合適的提示，逐一引導(dǎo)面談對(duì)象對(duì)各個(gè)主題的敘述。③總結(jié)面談的要點(diǎn)。注意此次面談過程的成功和失誤，明確下次的目標(biāo)，以便為下次面談做充分的準(zhǔn)備。需求獲取技術(shù)需求陳述需求陳述是一份文檔，陳述用戶對(duì)軟件的期望和需要，并對(duì)可能的規(guī)格要求加以說明。需求陳述用來明確軟件的用途，它不僅要說明軟件有什么用，還要在宏觀層次上明確軟件應(yīng)具備的特性。需求獲取技術(shù)需求陳述核心內(nèi)容開發(fā)該軟件的動(dòng)機(jī)（愿景）是什么？該項(xiàng)目的主要涉眾是誰(shuí)？希望該軟件具備哪些主要功能和特性？附加內(nèi)容：

組織機(jī)構(gòu)描述軟件開發(fā)計(jì)劃風(fēng)險(xiǎn)需求獲取技術(shù)需求陳述實(shí)例SuperMart公司財(cái)務(wù)系統(tǒng)需求獲取技術(shù)挖掘隱性需求顯性需求：直接由需求主體聲稱，可以從需求調(diào)查中直接得到的需求；隱性需求：可能沒有人會(huì)直接提出，而是有賴于需求分析員進(jìn)行挖掘、分析和推導(dǎo)的需求。需求獲取技術(shù)挖掘隱性需求：案例分析案例

FlowerStore鮮花預(yù)訂系統(tǒng)仔細(xì)閱讀上述情景，回答下列問題：1.為什么網(wǎng)站會(huì)遇到這個(gè)問題？2.怎樣才能預(yù)計(jì)到這個(gè)問題？需求獲取技術(shù)挖掘隱性需求：案例分析解決方案任務(wù)解答解答原理1解答：當(dāng)交易量上升時(shí)，網(wǎng)站不堪負(fù)荷，導(dǎo)致癱瘓。之所以會(huì)發(fā)生這樣的事件，是因?yàn)榉治鲂〗M沒有充分考慮到用戶的購(gòu)買行為、系統(tǒng)性能、以及系統(tǒng)最大負(fù)載等諸多因素。分析小組把大部分時(shí)間都花在了收集與項(xiàng)目操作有關(guān)的需求上。系統(tǒng)分析員強(qiáng)調(diào)了系統(tǒng)的用戶需求，但沒有注意到購(gòu)物旺季交易量會(huì)上升，對(duì)系統(tǒng)性能估計(jì)不足。2解答：分析小組應(yīng)該分析顧客的購(gòu)買行為（購(gòu)買時(shí)間、頻率等），并充分考慮到系統(tǒng)的性能、最大負(fù)載等因素。

需求分析和技術(shù)實(shí)現(xiàn)不能只側(cè)重于系統(tǒng)的功能性，還要考慮到一些潛在的需求。需求分類和結(jié)構(gòu)化需求理解的大局觀任何需求都可定位于業(yè)務(wù)級(jí)需求、用戶級(jí)需求和開發(fā)級(jí)需求這三個(gè)需求層次的某一層必屬于功能、質(zhì)量、約束這三類需求的某一類需求分類和結(jié)構(gòu)化需求分類原始問題描述用戶需求系統(tǒng)需求軟件設(shè)計(jì)描述原始問題空間解決方案空間需求分類和結(jié)構(gòu)化需求分類功能需求：更多體現(xiàn)各級(jí)直接目標(biāo)要求質(zhì)量屬性：運(yùn)行期質(zhì)量+開發(fā)期質(zhì)量約束需求：業(yè)務(wù)環(huán)境因素+使用環(huán)境因素+構(gòu)建環(huán)境因素+技術(shù)環(huán)境因素需求分類和結(jié)構(gòu)化需求的層次化業(yè)務(wù)級(jí)需求：包含客戶或出資者要達(dá)到的業(yè)務(wù)目標(biāo)、預(yù)期投資、工期要求，以及要符合哪些標(biāo)準(zhǔn)、對(duì)哪些遺留系統(tǒng)進(jìn)行整合等約束條件。用戶級(jí)需求：用戶使用系統(tǒng)來輔助完成哪些工作？對(duì)質(zhì)量有何要求？用戶群及所處的使用環(huán)境方面有何特殊要求？開發(fā)級(jí)需求：開發(fā)人員需要實(shí)現(xiàn)什么？開發(fā)期間、維護(hù)期間有何質(zhì)量考慮？開發(fā)團(tuán)隊(duì)的哪些情況會(huì)反過來影響架構(gòu)？需求分類和結(jié)構(gòu)化需求的層次化：案例分析根據(jù)下列描述，說明新的銷售和財(cái)務(wù)處理系統(tǒng)的業(yè)務(wù)需求有哪些?FlyJewelry是一個(gè)小珠寶零售商。在過去的兩年里，F(xiàn)lyJewelry在它的商業(yè)方面經(jīng)歷了極大的發(fā)展，可是，它的財(cái)務(wù)業(yè)績(jī)卻與它的發(fā)展不同步?，F(xiàn)在的事務(wù)處理系統(tǒng)部分手動(dòng)、部分自動(dòng)，不能有效地追蹤客戶賬單和收據(jù)，F(xiàn)lyJewelry難以確定為什么它的成本這么高。此外，F(xiàn)lyJewelry頻繁地實(shí)行特價(jià)以吸引顧客，它不知道這些特價(jià)是否有利可圖，是否帶來其他的銷售。FlyJewelry也想增加回頭客，所以它需要一個(gè)客戶數(shù)據(jù)庫(kù)。FlyJewelry想開發(fā)一個(gè)新的銷售和財(cái)務(wù)處理系統(tǒng)以幫助解決這些問題。解答：業(yè)務(wù)需求BR如下：BR1：實(shí)現(xiàn)客戶賬單和收據(jù)的有效追蹤；BR2：實(shí)現(xiàn)產(chǎn)品特價(jià)時(shí)的利潤(rùn)和相關(guān)銷售情況檢查；BR3：實(shí)現(xiàn)一個(gè)客戶數(shù)據(jù)庫(kù)。需求分類和結(jié)構(gòu)化二維需求矩陣需求分類和結(jié)構(gòu)化二維需求矩陣（需求層次——需求方面矩陣）需求分類和結(jié)構(gòu)化二維需求矩陣實(shí)例需求建模建模是開發(fā)優(yōu)秀軟件的所有活動(dòng)中核心部分之一需求模型分類功能模型——如UC業(yè)務(wù)流程模型——如DFD數(shù)據(jù)建模模型——如ER用例建模技術(shù)UMLUnifiedModelingLanguage統(tǒng)一建模語(yǔ)言統(tǒng)一建模語(yǔ)言統(tǒng)一建模語(yǔ)言用例建模技術(shù)UML是一種直觀化、明確化、構(gòu)建和文檔化軟件系統(tǒng)產(chǎn)物的通用可視化建模語(yǔ)言用戶視圖：以用戶的觀點(diǎn)表示系統(tǒng)的目標(biāo)，它是所有視圖的核心，該視圖描述系統(tǒng)的需求。用戶視圖通過用例圖來呈現(xiàn)。用例建模技術(shù)用例建模（UseCaseModeling）是使用用例的方法來描述系統(tǒng)的功能需求的過程，用例建模促進(jìn)并鼓勵(lì)了用戶參與，這是確保項(xiàng)目成功的關(guān)鍵因素之一。用例建模主要包括以下兩部分內(nèi)容：用例圖(UseCaseDiagram)用例描述文檔(UseCaseSpecification)用例建模技術(shù)用例文檔（規(guī)約）執(zhí)行者用例圖用例模型補(bǔ)充規(guī)約術(shù)語(yǔ)表全局性功能、非功能需求用例建模技術(shù)用例建模步驟識(shí)別執(zhí)行者識(shí)別用例繪制用例圖書寫用例文檔檢查用例模型繪制用例圖識(shí)別執(zhí)行者執(zhí)行者——Actor定義：在系統(tǒng)之外，透過系統(tǒng)邊界與系統(tǒng)進(jìn)行有意義交互的任何事物。引入執(zhí)行者的目的：幫助確定系統(tǒng)邊界。繪制用例圖識(shí)別執(zhí)行者人其它系統(tǒng)自動(dòng)發(fā)生的事件思路誰(shuí)使用系統(tǒng)？誰(shuí)改變系統(tǒng)的數(shù)據(jù)？誰(shuí)從系統(tǒng)獲取信息？誰(shuí)需要系統(tǒng)的支持以完成日常工作任務(wù)？誰(shuí)負(fù)責(zé)維護(hù)、管理并保持系統(tǒng)正常運(yùn)行？系統(tǒng)需要和哪些外部系統(tǒng)交互？有沒有自動(dòng)發(fā)生的事件？繪制用例圖識(shí)別執(zhí)行者都對(duì)，不丟用例就行（慢慢清理）哪個(gè)是正確的執(zhí)行者？？繪制用例圖識(shí)別執(zhí)行者繪制用例圖識(shí)別執(zhí)行者繪制用例圖識(shí)別用例繪制用例圖識(shí)別用例用例用例是在系統(tǒng)中執(zhí)行的一系列動(dòng)作，這些動(dòng)作將生成特定執(zhí)行者可見的價(jià)值結(jié)果。一個(gè)用例定義一組用例實(shí)例。繪制用例圖識(shí)別用例用例要點(diǎn)：有意義的目標(biāo)價(jià)值結(jié)果由系統(tǒng)生成業(yè)務(wù)語(yǔ)言，用戶觀點(diǎn)注意用例的命名用例的“粒度”繪制用例圖識(shí)別用例錯(cuò)！對(duì)！有沒有意義？涉眾說了算！有意義的目標(biāo)繪制用例圖識(shí)別用例價(jià)值結(jié)果由系統(tǒng)生成?繪制用例圖識(shí)別用例業(yè)務(wù)語(yǔ)言而非技術(shù)語(yǔ)言繪制用例圖識(shí)別用例用戶觀點(diǎn)而非系統(tǒng)觀點(diǎn)用戶觀點(diǎn)系統(tǒng)觀點(diǎn)對(duì)！錯(cuò)！繪制用例圖識(shí)別用例用例命名

動(dòng)詞（＋賓語(yǔ)）狀語(yǔ)定語(yǔ)繪制用例圖識(shí)別用例用例命名：慎用弱動(dòng)詞弱名詞弱動(dòng)詞：進(jìn)行、使用、復(fù)制、加載、重復(fù)弱名詞：數(shù)據(jù)、報(bào)表、表格、表單、系統(tǒng)會(huì)掩蓋真正的業(yè)務(wù)！繪制用例圖識(shí)別用例用例的“粒度”粒度原則：用例要有路徑，路徑要有步驟。而這一切都是“可觀測(cè)”的。繪制用例圖識(shí)別用例用例的“粒度”最常犯錯(cuò)誤－－把步驟當(dāng)作用例把執(zhí)行者動(dòng)作當(dāng)作用例把系統(tǒng)活動(dòng)當(dāng)作用例繪制用例圖用例的“粒度”四輪馬車警惕CRUD泛濫！識(shí)別用例繪制用例圖用例的“粒度”四輪馬車識(shí)別用例繪制用例圖用例的“粒度”四輪馬車也可以把包含復(fù)雜交互的路徑獨(dú)立出去形成用例識(shí)別用例繪制用例圖形式檢查【執(zhí)行者】使用系統(tǒng)來【用例】識(shí)別用例繪制用例圖執(zhí)行者與用例之間的關(guān)聯(lián)關(guān)系在用例圖中，執(zhí)行者和用例之間進(jìn)行交互，相互之間的關(guān)系用一根直線來表示，稱為關(guān)聯(lián)關(guān)系(Association)或通信關(guān)系(Communication)。繪制用例圖執(zhí)行者之間的泛化關(guān)系執(zhí)行者之間可以有泛化(Generalization)關(guān)系（或稱為“繼承”關(guān)系）。

繪制用例圖執(zhí)行者之間的泛化關(guān)系繪制用例圖用例之間的關(guān)系包含關(guān)系描述在多個(gè)用例中都有的公共行為，由用例A指向用例B，表示用例A中使用了用例B中的行為或功能，包含關(guān)系是通過在依賴關(guān)系上應(yīng)用<<include>>構(gòu)造型（衍型）來表示的。繪制用例圖用例之間的關(guān)系包含關(guān)系繪制用例圖用例之間的關(guān)系擴(kuò)展關(guān)系擴(kuò)展用例可以在基用例之上添加新的行為，但是基用例必須聲明某些特定的“擴(kuò)展點(diǎn)”，并且擴(kuò)展用例只能在這些擴(kuò)展點(diǎn)上擴(kuò)展新的行為。在擴(kuò)展（extend）關(guān)系中，基礎(chǔ)用例(Base)中定義有一至多個(gè)已命名的擴(kuò)展點(diǎn)，擴(kuò)展關(guān)系是指將擴(kuò)展用例(Extension)的事件流在一定的條件下按照相應(yīng)的擴(kuò)展點(diǎn)插入到基礎(chǔ)用例(Base)中。擴(kuò)展關(guān)系是通過在依賴關(guān)系上應(yīng)用<<extend>>構(gòu)造型（衍型）來表示的。繪制用例圖用例之間的關(guān)系擴(kuò)展關(guān)系繪制用例圖用例之間的關(guān)系泛化關(guān)系當(dāng)多個(gè)用例共同擁有一種類似的結(jié)構(gòu)和行為的時(shí)候，可以將它們的共性抽象成為父用例，其他的用例作為泛化關(guān)系中的子用例。在用例的泛化關(guān)系中，子用例是父用例的一種特殊形式，子用例繼承了父用例所有的結(jié)構(gòu)、行為和關(guān)系。泛化關(guān)系一般很少使用。繪制用例圖用例之間的關(guān)系泛化關(guān)系繪制用例圖實(shí)例：討論某酒店訂房系統(tǒng)描述如下：(1)顧客可以選擇在線預(yù)訂，也可以直接去酒店通過前臺(tái)服務(wù)員預(yù)訂；(2)前臺(tái)服務(wù)員可以利用系統(tǒng)直接在前臺(tái)預(yù)訂房間；(3)不管采用哪種預(yù)訂方式，都需要在預(yù)訂時(shí)支付相應(yīng)訂金；(4)前臺(tái)預(yù)訂可以通過現(xiàn)金或信用卡的形式進(jìn)行訂金支付，但是網(wǎng)上預(yù)訂只能通過信用卡進(jìn)行支付；(5)利用信用卡進(jìn)行支付時(shí)需要和信用卡系統(tǒng)進(jìn)行通信；(6)客房部經(jīng)理可以隨時(shí)查看客房預(yù)訂情況和每日收款情況。構(gòu)造該系統(tǒng)的用例模型。繪制用例圖解決方案——識(shí)別執(zhí)行者(1)顧客可以選擇在線預(yù)訂，也可以直接去酒店通過前臺(tái)服務(wù)員預(yù)訂；(2)前臺(tái)服務(wù)員可以利用系統(tǒng)直接在前臺(tái)預(yù)訂房間；(3)不管采用哪種預(yù)訂方式，都需要在預(yù)訂時(shí)支付相應(yīng)訂金；(4)前臺(tái)預(yù)訂可以通過現(xiàn)金或信用卡的形式進(jìn)行訂金支付，但是網(wǎng)上預(yù)訂只能通過信用卡進(jìn)行支付；(5)利用信用卡進(jìn)行支付時(shí)需要和信用卡系統(tǒng)進(jìn)行通信；(6)客房部經(jīng)理可以隨時(shí)查看客房預(yù)訂情況和每日收款情況。繪制用例圖解決方案——識(shí)別用例(1)顧客可以選擇在線預(yù)訂，也可以直接去酒店通過前臺(tái)服務(wù)員預(yù)訂；(2)前臺(tái)服務(wù)員可以利用系統(tǒng)直接在前臺(tái)預(yù)訂房間；(3)不管采用哪種預(yù)訂方式，都需要在預(yù)訂時(shí)支付相應(yīng)訂金；(4)前臺(tái)預(yù)訂可以通過現(xiàn)金或信用卡的形式進(jìn)行訂金支付，但是網(wǎng)上預(yù)訂只能通過信用卡進(jìn)行支付；(5)利用信用卡進(jìn)行支付時(shí)需要和信用卡系統(tǒng)進(jìn)行通信；(6)客房部經(jīng)理可以隨時(shí)查看客房預(yù)訂情況和每日收款情況。繪制用例圖解決方案——繪制用例圖書寫用例文檔用例是文本文檔，而非圖形用例建模主要是編寫文本的活動(dòng)，而非制圖書寫用例文檔用例的內(nèi)容用例編號(hào)用例名執(zhí)行者前置條件后置條件涉眾利益基本路徑1…..××××2……××××3…..××××擴(kuò)展路徑2a.××××：2a1….×××××字段列表業(yè)務(wù)規(guī)則非功能需求設(shè)計(jì)約束書寫用例文檔書寫用例文檔前置、后置條件開始用例前所必需的系統(tǒng)及其環(huán)境的狀態(tài)注意：系統(tǒng)必須能檢測(cè)到用例成功結(jié)束后系統(tǒng)應(yīng)該具備的狀態(tài)書寫用例文檔前置、后置條件必須是系統(tǒng)能檢測(cè)到的前置條件：顧客提著商品來結(jié)賬前置條件：收銀員已通過身份識(shí)別錯(cuò)！對(duì)！書寫用例文檔前置、后置條件前置條件必須是系統(tǒng)在用例開始前能檢測(cè)到的前置條件：用戶賬戶中有足夠的余額錯(cuò)！書寫用例文檔涉眾利益書寫用例文檔基本路徑把基本路徑單獨(dú)分離，凸現(xiàn)用例的核心價(jià)值。核心的核心：客戶最想看到、最關(guān)心的路徑書寫用例文檔基本路徑用例交互四步曲在步驟中寫需求！書寫用例文檔基本路徑只書寫“可觀測(cè)”的（說人話）使用主動(dòng)語(yǔ)句句子必須以執(zhí)行者或系統(tǒng)作為主語(yǔ)每一句都要朝目標(biāo)邁進(jìn)分支和循環(huán)不要涉及界面細(xì)節(jié)書寫用例文檔基本路徑系統(tǒng)通過ADO建立數(shù)據(jù)庫(kù)連接，傳送SQL查詢語(yǔ)句，從“零件”表查詢…系統(tǒng)按照查詢條件搜索零件只書寫“可觀測(cè)”的錯(cuò)對(duì)書寫用例文檔基本路徑歐文從貝克漢姆處得到傳球，守門員…貝克漢姆傳球給歐文，歐文射門，守門員撲救….主動(dòng)語(yǔ)句－－球在誰(shuí)那里？錯(cuò)對(duì)書寫用例文檔基本路徑系統(tǒng)從會(huì)員處獲取用戶名和密碼會(huì)員提交用戶名和密碼用戶名和密碼被驗(yàn)證系統(tǒng)驗(yàn)證用戶名和密碼使用主動(dòng)語(yǔ)句錯(cuò)對(duì)錯(cuò)對(duì)書寫用例文檔基本路徑執(zhí)行者×××××系統(tǒng)×××××系統(tǒng)×××××執(zhí)行者×××××句子必須以執(zhí)行者或系統(tǒng)作為主語(yǔ)書寫用例文檔基本路徑執(zhí)行者填寫姓名執(zhí)行者填寫電話執(zhí)行者填寫聯(lián)系地址執(zhí)行者提交××××××每一句都要朝目標(biāo)邁進(jìn)X書寫用例文檔基本路徑分支：放到擴(kuò)展路徑循環(huán)：直接描述分支和循環(huán)書寫用例文檔基本路徑會(huì)員從下拉框中選擇類別會(huì)員在相應(yīng)文本框中輸入查詢條件會(huì)員點(diǎn)擊“確定”按鈕……不要涉及界面細(xì)節(jié)X書寫用例文檔擴(kuò)展路徑注意意外和分支替換路徑異常路徑書寫用例文檔補(bǔ)充約束可以直接放在用例中，也可以單獨(dú)集中到另外的文檔，從用例文檔指向字段列表業(yè)務(wù)規(guī)則非功能需求設(shè)計(jì)約束書寫用例文檔用例文檔實(shí)例書寫用例文檔用例文檔實(shí)例用例文檔示例一用例文檔示例二檢查用例模型用例模型完成之后，需要對(duì)用例模型進(jìn)行檢查，看看是否有遺漏或錯(cuò)誤之處。主要可以從以下幾個(gè)方面來進(jìn)行檢查：功能需求的完備性模型是否易于理解是否存在不一致性避免語(yǔ)義二義性檢查用例模型用例1用例2用例3用例4用例5…需求1●●需求2●需求3需求4●需求5●●…其他幾種UML圖形對(duì)象狀態(tài)的描述——狀態(tài)圖工作流程的描述——活動(dòng)圖交互次序的描述——順序圖DFD建模數(shù)據(jù)流圖(DataFlowDiagram,DFD)是結(jié)構(gòu)化方法中用于表示系統(tǒng)邏輯模型的一種工具，它以圖形的方式描繪數(shù)據(jù)在系統(tǒng)中流動(dòng)和處理的過程。DFD建模自外向內(nèi)，自頂向下，逐層細(xì)化，完善求精DFD建模ER建模ER建模用于對(duì)數(shù)據(jù)進(jìn)行建模（概念模型）在ER圖中包含三個(gè)圖形符號(hào)，分別表示：實(shí)體屬性聯(lián)系ER建模醫(yī)院門診系統(tǒng)局部ER圖編寫軟件需求規(guī)格說明書軟件需求規(guī)格說明書需求分析的主要成果：軟件需求規(guī)格說明書(SoftwareRequirementSpecification,SRS)為用戶、需求分析人員、系統(tǒng)設(shè)計(jì)人員、開發(fā)人員及測(cè)試人員之間相互理解和交流提供了方便是系統(tǒng)設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試和驗(yàn)收的主要依據(jù)需要及時(shí)更新編寫軟件需求規(guī)格說明書兩個(gè)世界三種設(shè)計(jì)編寫軟件需求規(guī)格說明書正確需求規(guī)格說明書應(yīng)當(dāng)正確地反映用戶的真實(shí)意圖，“正確”是《軟件需求規(guī)格說明書》最重要的屬性。如果“不正確”僅僅是由于錯(cuò)別字造成的，那么多檢查幾遍文檔就能解決問題。真正的困難是開發(fā)者和用戶自己都不明白用戶究竟“想要什么”和“不要什么”。為確保需求是正確的，開發(fā)方和用戶必須對(duì)《軟件需求規(guī)格說明書》進(jìn)行確認(rèn)。編寫軟件需求規(guī)格說明書清楚清楚的需求讓人易讀易懂，不在于文檔的厚度。清楚的反義詞是“難讀”、“難理解”。你可以采用反問的方式來判斷需求文檔是否清楚：文檔的結(jié)構(gòu)、段落是否亂七八糟？上下文是否不連貫？文檔的語(yǔ)句是否含糊其詞、羅里羅嗦？每句話都是對(duì)的，但是看了半天是否還不明白需求究竟是什么。編寫軟件需求規(guī)格說明書無二義性“無二義性”是指每個(gè)需求只有唯一的含義。如果一個(gè)人說的話，不同的人可能有不同的理解，那么這句話就有二義性。如果需求存在二義性，將會(huì)導(dǎo)致人們誤解需求而開發(fā)出偏離需求的產(chǎn)品。為了使需求無二義性，人們?cè)趯憽盾浖枨笠?guī)格說明書》時(shí)措詞應(yīng)當(dāng)準(zhǔn)確，切勿模棱兩可。編寫軟件需求規(guī)格說明書一致“一致”（Consistent）是指《軟件需求規(guī)格說明書》中各個(gè)需求之間不會(huì)發(fā)生矛盾。矛盾常常潛伏在需求文檔的上下文中。編寫軟件需求規(guī)格說明書必要《軟件需求規(guī)格說明書》中的各項(xiàng)需求對(duì)用戶而言應(yīng)當(dāng)都是必要的。可以把“必要”比喻為“雪中送炭”?！氨匾蓖耙徊?，要么是“畫蛇添足”要么是“錦上添花”。“畫蛇添足”顯然是壞事，會(huì)導(dǎo)致開發(fā)人員多干一些吃力不討好的工作。所以要盡量剔除需求規(guī)格說明書中“畫蛇添足”的那些需求。“錦上添花”是好事，可能會(huì)讓用戶獲得比期望更多的喜悅，但是眼前用戶不會(huì)為此多付錢。開發(fā)者應(yīng)當(dāng)集中精力先完成必要的需求，如果條件允許則再做“錦上添花”的需求。為了避免主次顛倒，應(yīng)當(dāng)在《軟件需求規(guī)格說明書》中將那些“錦上添花”的需求設(shè)置為較低的優(yōu)先級(jí)。編寫軟件需求規(guī)格說明書完備“完備”（Complete）是指《軟件需求規(guī)格說明書》中沒有遺漏一些必要的需求。人們往往傾向于關(guān)注系統(tǒng)的特色功能，而忽視了其它一些不起眼的但卻是必需的功能。不完備的《軟件需求規(guī)格說明書》將導(dǎo)致產(chǎn)生功能不完整的軟件，用戶在使用該軟件時(shí)可能無法完成預(yù)期的任務(wù)。

編寫軟件需求規(guī)格說明書可實(shí)現(xiàn)

《軟件需求規(guī)格說明書》中的各項(xiàng)需求對(duì)開發(fā)方而言應(yīng)當(dāng)都是可實(shí)現(xiàn)的?！翱蓪?shí)現(xiàn)”意味著在技術(shù)上是可行的，并且滿足時(shí)間、費(fèi)用、質(zhì)量等約束。營(yíng)銷人員和用戶談生意時(shí)，為了能拿到“單子”，他們往往對(duì)用戶提出的需求“來者不拒”。吹牛皮雖然不犯法，但是《軟件需求規(guī)格說明書》可是白紙黑字啊。經(jīng)過雙方確認(rèn)的《軟件需求規(guī)格說明書》相當(dāng)于商業(yè)合同，如果開發(fā)方不能夠?qū)崿F(xiàn)《軟件需求規(guī)格說明書》中的內(nèi)容，那就是違約，可能會(huì)被罰款的。對(duì)于合同項(xiàng)目，如果開發(fā)方不能確信某些需求是否可實(shí)現(xiàn)，則應(yīng)事先與用戶協(xié)商，達(dá)成一致的處理意見，避免將來發(fā)生商業(yè)糾紛。編寫軟件需求規(guī)格說明書可驗(yàn)證

《軟件需求規(guī)格說明書》中的各項(xiàng)需求對(duì)用戶方而言應(yīng)當(dāng)都是可驗(yàn)證的（Verifiable）。如果需求是不可驗(yàn)證的，那么用戶就無法驗(yàn)收軟件，可能會(huì)發(fā)生商業(yè)糾紛。例如，摩天大樓的一項(xiàng)需求是“抗十二級(jí)臺(tái)風(fēng)”，這個(gè)需求看起來堂而皇之，但是如何驗(yàn)證呢？當(dāng)摩天大樓完工后驗(yàn)收時(shí)，用戶又不是巫師，他怎能造個(gè)十二級(jí)臺(tái)風(fēng)來試驗(yàn)？如果雙方都認(rèn)可“采用計(jì)算機(jī)模擬十二級(jí)臺(tái)風(fēng)”等效于實(shí)際測(cè)試，那么這項(xiàng)需求就是“可驗(yàn)證”的。編寫軟件需求規(guī)格說明書確定優(yōu)先級(jí)為什么要確定需求的“優(yōu)先級(jí)”？理論上講，軟件的所有需求都應(yīng)當(dāng)被實(shí)現(xiàn)。但是在現(xiàn)實(shí)之中，項(xiàng)目存在“進(jìn)度、費(fèi)用、人力資源”等限制。在項(xiàng)目剛開始的時(shí)候，開發(fā)方和客戶比較樂觀，什么都要做，可是做著做著，人們常常會(huì)面臨“進(jìn)度延誤、費(fèi)用超支、人員不足”等問題，這時(shí)就亂套了。人們想出了“取舍”辦法：先做優(yōu)先級(jí)高的需求，后做（甚至放棄）優(yōu)先級(jí)低的需求，這樣可以將風(fēng)險(xiǎn)降到最低。需求的優(yōu)先級(jí)其實(shí)就是需求“輕重緩急”的分級(jí)表述，例如劃分為“高、中、低”三級(jí)。一般地，由用戶和開發(fā)方共同確定需求的優(yōu)先級(jí)。編寫軟件需求規(guī)格說明書闡述“做什么”而不是“怎么做”《軟件需求規(guī)格說明書》的重點(diǎn)是闡述“做什么”，而不是闡述“怎么做”?！霸趺醋觥笔窍到y(tǒng)設(shè)計(jì)和實(shí)現(xiàn)階段的事情。國(guó)內(nèi)的很多軟件公司里，開發(fā)人員常常身兼數(shù)職，可能把需求開發(fā)、系統(tǒng)設(shè)計(jì)、編程等工作從頭做到尾。所以他們?cè)谡{(diào)查、分析、定義需求時(shí)，自然會(huì)想到“怎么做”，這并沒有什么過錯(cuò)。如果在調(diào)查、定義需求時(shí)想好了“怎么做”，當(dāng)然應(yīng)該寫下來，否則豈不浪費(fèi)！關(guān)鍵是不要將“怎么做”寫到需求規(guī)格說明書里面，記錄在其它文檔里就行了。編寫軟件需求規(guī)格說明書如何使軟件需求規(guī)格說明書更加有效？參見《中國(guó)系統(tǒng)分析員》2004年第1期（徐峰）鏈接編寫軟件需求規(guī)格說明書軟件需求規(guī)格說明書實(shí)例分析首創(chuàng)證券影像檔案管理系統(tǒng)軟件需求說明書湖南移動(dòng)24小時(shí)自助營(yíng)業(yè)廳銀行卡交費(fèi)軟件需求規(guī)格說明書福建中煙企業(yè)門戶及協(xié)同辦公平臺(tái)項(xiàng)目需求規(guī)格說明書需求確認(rèn)需求確認(rèn)是指開發(fā)方和客戶方共同對(duì)《軟件需求規(guī)格說明書》進(jìn)行評(píng)審，雙方對(duì)需求達(dá)成共識(shí)后作出承諾。需求確認(rèn)包含兩個(gè)重要工作：“需求評(píng)審”和“需求承諾”。需求確認(rèn)需求評(píng)審面臨的困難需求評(píng)審的一個(gè)通病是“虎頭蛇尾”。需求評(píng)審的確乏味，也比較費(fèi)腦子。剛開始評(píng)審時(shí)，大家都比較認(rèn)真，越到后頭越馬虎。需求評(píng)審涉及的人員可能比較多，有些時(shí)候讓這么多人聚在一起花費(fèi)比較長(zhǎng)的時(shí)間開會(huì)并不容易（例如有些人可能出差在外，有些人可能事務(wù)纏身）。沒有必要把所有事情擠在一塊做，需求開發(fā)是循序漸進(jìn)的過程，需求評(píng)審也可以分段進(jìn)行。這樣每次評(píng)審的時(shí)間比較短，參加評(píng)審的人員也少一些，組織會(huì)議就比較容易。需求確認(rèn)需求評(píng)審面臨的困難（續(xù)）開評(píng)審會(huì)議時(shí)經(jīng)常會(huì)“跑題”，導(dǎo)致評(píng)審效率很低。有時(shí)話匣子一打開后關(guān)不上，大家越扯越遠(yuǎn)，結(jié)果評(píng)審會(huì)議變成了聊天會(huì)議。主持人應(yīng)當(dāng)控制話題，避免大家討論與主題無關(guān)的東西。開評(píng)審會(huì)議時(shí)經(jīng)常會(huì)發(fā)生爭(zhēng)議。適當(dāng)?shù)臓?zhēng)議有利于澄清問題，比什么東西都一致贊成要好。然而當(dāng)爭(zhēng)議變?yōu)闋?zhēng)吵時(shí)就壞事了，爭(zhēng)吵不僅對(duì)評(píng)審工作沒有好處，而且會(huì)無意中傷害同事們的感情。人們?cè)诤芏鄷r(shí)候分不清楚自己究竟是“堅(jiān)持真理”還是“固執(zhí)己見”。毫不妥協(xié)或者輕易妥協(xié)都不是好辦法。我們應(yīng)當(dāng)養(yǎng)成良好的習(xí)慣：不要一棍子打死異己的觀點(diǎn)，嘗試著讓自己站在他人的立場(chǎng)思考問題，這樣會(huì)找到比較滿意的答案。需求確認(rèn)需求承諾需求承諾是指開發(fā)方和客戶方的責(zé)任人對(duì)通過了正式技術(shù)評(píng)審的《軟件需求規(guī)格說明書》作出承諾，該承諾具有商業(yè)合同的效果。需求承諾的“八股文”如下：本《軟件需求規(guī)格說明書》建立在雙方對(duì)需求的共同理解基礎(chǔ)之上，我同意后續(xù)的開發(fā)工作根據(jù)該《軟件需求規(guī)格說明書》開展。如果需求發(fā)生變化，我們將按照“變更控制規(guī)程”執(zhí)行。我明白需求的變更將導(dǎo)致雙方重新協(xié)商成本、資源和進(jìn)度等。甲方簽字乙方簽字人們?cè)谧鞒龀兄Z之前務(wù)必要認(rèn)真閱讀文檔，一定要明白簽字意味著什么。