軟件體系結(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)典的“四拍”決策時拍腦袋——就這么定了

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

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

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

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

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

誰需要什么樣的

東西？軟件需求概述需求的基本概念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)需求是指明必須實現(xiàn)什么的規(guī)格說明。它描述了系統(tǒng)的行為、特性或?qū)傩裕窃陂_發(fā)過程中對系統(tǒng)的約束。

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

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

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

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

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

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

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

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

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

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

范圍問題

理解問題

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

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

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

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

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

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

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

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

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