教學(xué)課件-軟件需求工程-駱斌

第1章.需求工程導(dǎo)論主要內(nèi)容軟件的需求問(wèn)題軟件的發(fā)展軟件生產(chǎn)狀況調(diào)查需求問(wèn)題的原因分析需求工程需求工程師1.1軟件的發(fā)展

——60年代的發(fā)展1.1軟件的發(fā)展

——

軟件危機(jī)1968年北大西洋公約組織的計(jì)算機(jī)科學(xué)家在聯(lián)邦德國(guó)召開(kāi)的國(guó)際學(xué)術(shù)會(huì)議上第一次提出了“軟件危機(jī)”(softwarecrisis)這個(gè)名詞。軟件危機(jī)指的是在計(jì)算機(jī)軟件的開(kāi)發(fā)和維護(hù)過(guò)程中所遇到的一系列嚴(yán)重問(wèn)題開(kāi)發(fā)成本超出預(yù)算，實(shí)際進(jìn)度比預(yù)定計(jì)劃一再拖延。用戶(hù)對(duì)“已完成”系統(tǒng)不滿(mǎn)意的現(xiàn)象經(jīng)常發(fā)生。件產(chǎn)品的質(zhì)量往往靠不住。Bug一大堆，Patch一個(gè)接一個(gè)。件的可維護(hù)程度非常之低。軟件通常沒(méi)有適當(dāng)?shù)奈臋n資料。軟件的成本不斷提高。軟件開(kāi)發(fā)生產(chǎn)率的提高趕不上硬件的發(fā)展和人們需求的增長(zhǎng)1.1軟件的發(fā)展

——

軟件工程概括來(lái)說(shuō)，軟件危機(jī)包含兩方面問(wèn)題：一、如何開(kāi)發(fā)軟件，以滿(mǎn)足不斷增長(zhǎng)，日趨復(fù)雜的需求；二、如何維護(hù)數(shù)量不斷膨脹的軟件產(chǎn)品。解決方案：軟件工程[IEEE]：（1）應(yīng)用系統(tǒng)化的、學(xué)科化的、定量的方法，來(lái)開(kāi)發(fā)、運(yùn)行和維護(hù)軟件，即，將工程應(yīng)用到軟件。（2）對(duì)（1）中各種方法的研究”1.1軟件的發(fā)展

——90年代的發(fā)展1.290年代的軟件生產(chǎn)狀況調(diào)查

——StandishGroup1995365家公司的8380個(gè)項(xiàng)目成功項(xiàng)目Success：在預(yù)計(jì)的時(shí)間之內(nèi)，在預(yù)算的成本之下，完成預(yù)期的所有功能問(wèn)題項(xiàng)目Challenged：已經(jīng)完成，軟件產(chǎn)品能夠正常工作，但在生產(chǎn)中或者超支，或者超期，或者實(shí)現(xiàn)的功能不全失敗項(xiàng)目Impaired：因無(wú)法進(jìn)行而被中途撤銷(xiāo)，或者最終產(chǎn)品無(wú)法提交使用1.290年代的軟件生產(chǎn)狀況調(diào)查

——StandishGroup1995大公司開(kāi)發(fā)項(xiàng)目的平均成本是232.2萬(wàn)美元，中等公司是133.1萬(wàn)美元，小型公司是43.4萬(wàn)美元大約31％的項(xiàng)目在完成之前被取消，52.7％的項(xiàng)目成本是原來(lái)預(yù)算的189%大公司9%按預(yù)算交付，小公司16%按預(yù)算交付1.290年代的軟件生產(chǎn)狀況調(diào)查

——

影響因素[StandishGroup1995]成功項(xiàng)目的影響要素影響指數(shù)用戶(hù)參與15.9％高層管理支持13.9％清晰的需求說(shuō)明13.0％正確的項(xiàng)目計(jì)劃9.6％切合實(shí)際的期望8.2％細(xì)化的項(xiàng)目里程碑7.7％員工能力7.2％主人翁精神5.3％清晰的目標(biāo)和前景2.9％努力工作2.4％其他13.9％1.290年代的軟件生產(chǎn)狀況調(diào)查

——

影響因素[StandishGroup1995]問(wèn)題項(xiàng)目的影響要素影響指數(shù)缺少用戶(hù)輸入12.8％不完整的需求說(shuō)明12.3％需求變化11.8％缺乏高層管理支持7.5％技術(shù)能力不足7.0％缺乏資源6.4％不切實(shí)際的期望5.9％目標(biāo)不清晰5.3％不現(xiàn)實(shí)的時(shí)間要求4.3％新技術(shù)的影響3.7％其他23.0％1.290年代的軟件生產(chǎn)狀況調(diào)查

——

影響因素[StandishGroup1995]失敗項(xiàng)目的影響要素影響指數(shù)不完整的需求說(shuō)明13.1％缺少用戶(hù)輸入12.4％缺乏資源10.6％不切實(shí)際的期望9.9％缺乏高層管理支持9.3％需求變化8.7％缺乏計(jì)劃8.1％額外的無(wú)用功能7.5％缺乏IT管理6.2％技術(shù)能力不足4.3％其他9.9％1.290年代的軟件生產(chǎn)狀況調(diào)查

——

影響因素[StandishGroup1995]需求因素用戶(hù)參與（用戶(hù)輸入）高層管理支持清晰的需求說(shuō)明切合實(shí)際的期望清晰的目標(biāo)和前景需求變化額外的無(wú)用功能綜合來(lái)看，需求因素對(duì)成功項(xiàng)目的影響指數(shù)為53.9％對(duì)問(wèn)題項(xiàng)目的影響指數(shù)為55.6％對(duì)失敗項(xiàng)目的影響指數(shù)為60.9％1.290年代的軟件生產(chǎn)狀況調(diào)查

——ESPITI，1996歐洲軟件協(xié)會(huì)ESI歐洲軟件過(guò)程改進(jìn)培訓(xùn)計(jì)劃項(xiàng)目ESPITI17個(gè)國(guó)家的超過(guò)3800個(gè)組織1.290年代的軟件生產(chǎn)狀況調(diào)查

——需求問(wèn)題的典型案例[Bray2002]PROMS（演出權(quán)益協(xié)會(huì)）,11M￡,1992,未能以常人能理解和檢查的形式表述軟件需求，軟件規(guī)格說(shuō)明也考慮不周RISP（西薩克斯地區(qū)信息系統(tǒng)計(jì)劃）,43M￡,1990,缺少清晰的項(xiàng)目范圍定義TAURUS(倫敦股票交易),75M￡(1.4B￡),1993,未能協(xié)調(diào)不一致的需求LASDS(倫敦救護(hù)車(chē)服務(wù)派遣系統(tǒng)),1992,社會(huì)服務(wù)領(lǐng)域糟糕的需求分析ATC(空中交通控制系統(tǒng)),1.8B￡,1998-2001,缺乏健壯的需求規(guī)格說(shuō)明主要內(nèi)容軟件的需求問(wèn)題需求問(wèn)題的原因分析應(yīng)用軟件的模擬特性需求問(wèn)題的技術(shù)原因分析需求工程需求工程師2.1應(yīng)用軟件的模擬特性

——軟件的三種類(lèi)型軟件類(lèi)別純工具型軟件應(yīng)用型軟件專(zhuān)業(yè)用戶(hù)普通用戶(hù)評(píng)判標(biāo)準(zhǔn)功能的復(fù)雜性使用的高效性技術(shù)的先進(jìn)性功能的有用性使用的方便性技術(shù)的可行性功能的“模擬”性使用的方便性技術(shù)的可行性關(guān)注點(diǎn)創(chuàng)新性有效性模擬性示例系統(tǒng)編程環(huán)境DBMSOffice語(yǔ)言翻譯MISEAI2.1應(yīng)用軟件的模擬特性

——軟件的分析活動(dòng)2.1應(yīng)用軟件的模擬特性

——軟件模擬性的實(shí)踐調(diào)查對(duì)應(yīng)用型軟件的“模擬”特性理解及應(yīng)用問(wèn)題CapersJones[Capers1996]在調(diào)查了幾百個(gè)公司之后發(fā)現(xiàn)超過(guò)75％的企業(yè)在需求處理環(huán)節(jié)存在不足。2000年Nikula等人在對(duì)芬蘭的中小型公司進(jìn)行需求處理實(shí)踐情況評(píng)價(jià)時(shí)發(fā)現(xiàn)[Nikula2000]：在以30分為標(biāo)準(zhǔn)線(xiàn)的情況下，75%的公司竟然在10分以下。Hofmann等人在歐洲的需求工程實(shí)踐調(diào)查中發(fā)現(xiàn)僅有約1/3的項(xiàng)目有明確的需求處理過(guò)程[Hofmann2001]。Juristo等人在對(duì)歐洲的150多名RE實(shí)踐者進(jìn)行調(diào)查后發(fā)現(xiàn)，在需求處理的諸多技術(shù)當(dāng)中，需求獲取和沖突協(xié)商的技術(shù)沒(méi)有得到充分的應(yīng)用[Juristo2002]。研究也發(fā)現(xiàn)當(dāng)軟件生產(chǎn)面臨時(shí)間、市場(chǎng)等其他壓力時(shí)，漠視“模擬”特性的情況就更為嚴(yán)重[Lubars1993，F(xiàn)rancisco2003]2.2需求問(wèn)題的技術(shù)原因分析非技術(shù)性和社會(huì)性因素組織機(jī)構(gòu)文化、社會(huì)背景、商業(yè)目標(biāo)、利益協(xié)商關(guān)注軟件系統(tǒng)和現(xiàn)實(shí)之間的互動(dòng)效應(yīng)軟件系統(tǒng)環(huán)境的組織機(jī)構(gòu)文化、社會(huì)背景和系統(tǒng)涉眾的目標(biāo)與利益比軟件內(nèi)部的數(shù)據(jù)流與狀態(tài)更應(yīng)該得到重視解決方案和具體應(yīng)用環(huán)境相關(guān)的不能忽視具體應(yīng)用環(huán)境中的相關(guān)因素，例如組織機(jī)構(gòu)的文化、組織結(jié)構(gòu)的規(guī)范、組織的行業(yè)規(guī)范、組織的社會(huì)背景等等單純通過(guò)技術(shù)的運(yùn)用來(lái)建立一個(gè)一致、完整的需求模型是不太可能的面對(duì)沖突要能夠分析社會(huì)原因和組織機(jī)構(gòu)方面的原因，引導(dǎo)涉眾進(jìn)行利益協(xié)商2.2需求問(wèn)題的技術(shù)原因分析結(jié)構(gòu)化分析和面向?qū)ο蠓治鼍哂幸欢ǖ南忍烊毕菥幊蹋?gt;設(shè)計(jì)－>分析設(shè)計(jì)和編程都有構(gòu)建高質(zhì)量（健壯性、可維護(hù)性、適應(yīng)性等等）軟件的共同目標(biāo)，而且使用相同的概念和組織機(jī)制保證了從設(shè)計(jì)到編程的平滑過(guò)渡，所以，它們?cè)谠O(shè)計(jì)領(lǐng)域的應(yīng)用也取得了成功但是需求分析除了擁有構(gòu)建高質(zhì)量軟件的目標(biāo)之外，還有一個(gè)更加重要的目標(biāo)是理解現(xiàn)實(shí)2.2需求問(wèn)題的技術(shù)原因分析以“企業(yè)”為中心的軟件反映了軟件規(guī)模日益擴(kuò)大一方面提高了需求處理中非技術(shù)性和社會(huì)性因素的影響比重另一方面也進(jìn)一步放大了傳統(tǒng)技術(shù)在需求處理階段的不適應(yīng)性2.2需求問(wèn)題的技術(shù)原因分析需求錯(cuò)誤的高代價(jià)性主要內(nèi)容軟件的需求問(wèn)題需求問(wèn)題的原因分析需求工程簡(jiǎn)介基本活動(dòng)需求工程與系統(tǒng)工程需求工程特性需求工程師3.1需求工程是軟件工程的一個(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ī)格說(shuō)明之間的聯(lián)系關(guān)注以上因素與其隨時(shí)間或跨產(chǎn)品族而演化之后的相關(guān)因素之間的聯(lián)系3.2需求工程的基本活動(dòng)3.3需求工程與系統(tǒng)工程3.4需求工程的特性

——必要性軟件開(kāi)發(fā)是這樣一個(gè)工程問(wèn)題利用通用的計(jì)算機(jī)結(jié)構(gòu)，構(gòu)建一個(gè)有用的軟件系統(tǒng)，來(lái)滿(mǎn)足人們的某些目的計(jì)算機(jī)應(yīng)用于現(xiàn)實(shí)世界的廣泛性新的問(wèn)題和新的解決方案定義問(wèn)題就是需求工程的任務(wù)3.4需求工程的特性

——重要性FrederickBrooks[Brooks1987]“開(kāi)發(fā)軟件系統(tǒng)最為困難的部分就是準(zhǔn)確說(shuō)明開(kāi)發(fā)什么。最為困難的概念性工作便是編寫(xiě)出詳細(xì)技術(shù)需求，這包括所有面向用戶(hù)、面向機(jī)器和其它軟件系統(tǒng)的接口。同時(shí)這也是一旦做錯(cuò)，將最終會(huì)給系統(tǒng)帶來(lái)極大損害的部分，并且以后再對(duì)它進(jìn)行修改也極為困難?！比菀缀雎孕枨蠊こ讨匾缘牡胤絾?wèn)題廣為人知電梯調(diào)度、圖書(shū)管理問(wèn)題小而簡(jiǎn)單出錯(cuò)也無(wú)所謂3.4需求工程的特性

——復(fù)雜性處理范圍廣泛現(xiàn)實(shí)世界和計(jì)算機(jī)世界涉及諸多參與方客戶(hù)、用戶(hù)、領(lǐng)域?qū)＜?、需求工程師、軟件開(kāi)發(fā)者、系統(tǒng)維護(hù)者等處理內(nèi)容多樣功能需求、非功能需求、環(huán)境及其約束處理活動(dòng)互相交織需求開(kāi)發(fā)的各項(xiàng)活動(dòng)雖然在理論上具有順序處理的特性，但在實(shí)際執(zhí)行過(guò)程中往往是迭代和互相交織的處理結(jié)果要求苛刻正確性、完整性和一致性主要內(nèi)容軟件的需求問(wèn)題需求問(wèn)題的原因分析需求工程需求工程師知識(shí)要求技能要求4.1需求工程師需要具備的知識(shí)軟件技術(shù)尤其是軟件建模與分析技術(shù)認(rèn)知學(xué)和社會(huì)學(xué)等方面的知識(shí)認(rèn)知心理學(xué)人類(lèi)學(xué)社會(huì)學(xué)語(yǔ)言學(xué)哲學(xué)知識(shí)掌握涉眾的信仰與理念（認(rèn)識(shí)論）分析在現(xiàn)實(shí)中觀察到的各種現(xiàn)象（現(xiàn)象學(xué)）4.2需求工程師需要具備的技能專(zhuān)業(yè)技能需求工程的相關(guān)知識(shí)分析技能抽象能力整合能力系統(tǒng)化思想交流技能交談和提問(wèn)的技巧傾聽(tīng)的技巧4.2需求工程師需要具備的技能觀察技能建模技能寫(xiě)作技能文檔組織能力語(yǔ)言駕馭能力創(chuàng)新技能發(fā)現(xiàn)連用戶(hù)都沒(méi)有意識(shí)到的潛在需求

協(xié)調(diào)能力本章小結(jié)從20世紀(jì)60年代末期軟件工程產(chǎn)生起，需求分析就一直是軟件開(kāi)發(fā)的重要主題20世紀(jì)90年代的調(diào)查狀況表明，單純的需求分析已經(jīng)不能很好的解決軟件生產(chǎn)中的“需求”問(wèn)題應(yīng)用型軟件的模擬性和一系列的技術(shù)原因表明軟件生產(chǎn)需要進(jìn)行一個(gè)比需求分析更加復(fù)雜和完整的需求工程需求工程是軟件工程當(dāng)中一項(xiàng)重要和復(fù)雜的活動(dòng)，需求工程需要具備一定的知識(shí)和技能才可以很好的執(zhí)行需求工程活動(dòng)

第2章.需求基礎(chǔ)主要內(nèi)容需求的涵義需求的類(lèi)型需求工程的路線(xiàn)優(yōu)秀需求的特性常見(jiàn)的需求錯(cuò)誤1.需求的涵義

——需求的定義（1）用戶(hù)為了解決問(wèn)題或達(dá)到某些目標(biāo)所需要的條件或能力；（2）系統(tǒng)或系統(tǒng)部件為了滿(mǎn)足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式文檔所規(guī)定的要求而需要具備的條件或能力；（3）對(duì)（1）或（2）中的一個(gè)條件或一種能力的一種文檔化表述。1.需求的涵義

——問(wèn)題域與解系統(tǒng)（1）軟件系統(tǒng)與外部環(huán)境1.需求的涵義

——問(wèn)題域與解系統(tǒng)當(dāng)現(xiàn)實(shí)的狀況與人們期望的狀況產(chǎn)生差距時(shí)，就產(chǎn)生了問(wèn)題。要解決問(wèn)題，就需要改變現(xiàn)實(shí)當(dāng)中某些實(shí)體的狀態(tài)或改變實(shí)體狀態(tài)變化的演進(jìn)順序，使其達(dá)到期望的狀態(tài)或演進(jìn)順序。這些實(shí)體和狀態(tài)構(gòu)成了問(wèn)題解決的基本范圍，稱(chēng)為該問(wèn)題的問(wèn)題域（ProblemDomain）軟件系統(tǒng)通過(guò)影響問(wèn)題域，能夠幫助人們解決問(wèn)題，稱(chēng)為解系統(tǒng)

1.需求的涵義

——共享現(xiàn)象軟件系統(tǒng)能夠與問(wèn)題域進(jìn)行交互和相互影響的原因在于，軟件系統(tǒng)中的某些部分對(duì)問(wèn)題域中的某些部分的具有模擬特性。換句話(huà)說(shuō)，軟件系統(tǒng)當(dāng)中含有問(wèn)題域某些部分的模型（或模擬），常見(jiàn)的模型包括數(shù)據(jù)模型、對(duì)象模型、處理模型等。問(wèn)題域中的某些信息能夠和模型中的信息建立映射關(guān)系這些通過(guò)映射建立的共同知識(shí)，就是問(wèn)題域和解系統(tǒng)之間的共享現(xiàn)象1.需求的涵義

——需求需求是用戶(hù)對(duì)問(wèn)題域當(dāng)中的實(shí)體狀態(tài)或事件的期望描述R2.2.3-1：一旦書(shū)籍被借出，則在歸還之前，它不能被再次借閱。R2.2.3-2：在歸還的書(shū)超過(guò)30天的歸還期限時(shí)，歸還后應(yīng)該進(jìn)行超期處罰。直接需求間接需求1.需求的涵義

——規(guī)格說(shuō)明規(guī)格說(shuō)明是解系統(tǒng)為滿(mǎn)足用戶(hù)需求而提供的解決方案，規(guī)定了解系統(tǒng)的行為特征主要包括兩個(gè)部分（如圖2－3(b)）：（1）對(duì)共享現(xiàn)象（模型）的描述；（2）系統(tǒng)對(duì)共享現(xiàn)象所施加的操作的描述。也可以看作是一種需求完全針對(duì)系統(tǒng)行為發(fā)出的期望一種理想的、完全不需要進(jìn)行任何額外努力即可以轉(zhuǎn)換為系統(tǒng)行為的需求。1.需求的涵義

——問(wèn)題域特性問(wèn)題域自治的規(guī)律性稱(chēng)為問(wèn)題域特性包括結(jié)構(gòu)特性和行為特性等問(wèn)題域特性的重要性要想解決問(wèn)題，它就需要了解問(wèn)題域特性，將解決方案和問(wèn)題域特性結(jié)合起來(lái)要防止解系統(tǒng)的引入在問(wèn)題域當(dāng)中引發(fā)未預(yù)見(jiàn)的連鎖反應(yīng)需要關(guān)注的問(wèn)題域特性間接特性約束和假設(shè)1.需求的涵義

——從問(wèn)題域、需求和規(guī)格說(shuō)明的關(guān)系看需求工程

描述明確的問(wèn)題域特性E;定義良好的系統(tǒng)行為S;預(yù)期的需求R需求工程的目的就是根據(jù)E，構(gòu)建S，使得需求工程的困難之處：（1）不存在描述明確的E；（2）不存在確定的針對(duì)S的評(píng)估標(biāo)準(zhǔn)R；（3）是一個(gè)創(chuàng)造性的過(guò)程。需求工程的主要工作需求開(kāi)發(fā),確定R研究問(wèn)題背景，描述問(wèn)題域特性E構(gòu)建解系統(tǒng)，描述解系統(tǒng)行為S，使得主要內(nèi)容需求的涵義需求的類(lèi)型分類(lèi)方式功能需求性能需求質(zhì)量屬性對(duì)外接口約束需求工程的路線(xiàn)優(yōu)秀需求的特性常見(jiàn)的需求錯(cuò)誤2.1需求的分類(lèi)方式(1)功能需求（FunctionalRequirement）：和系統(tǒng)主要工作相關(guān)的需求，即在不考慮物理約束的情況下，用戶(hù)希望系統(tǒng)所能夠執(zhí)行的活動(dòng)，這些活動(dòng)可以幫助用戶(hù)完成任務(wù)。功能需求主要表現(xiàn)為系統(tǒng)和環(huán)境之間的行為交互。性能需求（PerformanceRequirement）：系統(tǒng)整體或系統(tǒng)組成部分應(yīng)該擁有的性能特征，例如CPU使用率、內(nèi)存使用率等。質(zhì)量屬性（QualityAttribute）：系統(tǒng)完成工作的質(zhì)量，即系統(tǒng)需要在一個(gè)“好的程度”上實(shí)現(xiàn)功能需求，例如可靠性程度、可維護(hù)性程度等。對(duì)外接口（ExternalInterface）：系統(tǒng)和環(huán)境中其他系統(tǒng)之間需要建立的接口，包括硬件接口、軟件接口、數(shù)據(jù)庫(kù)接口等等。約束進(jìn)行系統(tǒng)構(gòu)造時(shí)需要遵守的約束，例如編程語(yǔ)言、硬件設(shè)施等2.1需求的分類(lèi)方式(2)系統(tǒng)需求（SystemRequirement）硬件需求（HardwareRequirement）軟件需求（SoftwareRequirement）其他需求2.2功能需求

——層次性2.2功能需求

——業(yè)務(wù)需求系統(tǒng)建立的戰(zhàn)略出發(fā)點(diǎn)，表現(xiàn)為高層次的目標(biāo)（Objective），它描述了組織為什么要開(kāi)發(fā)系統(tǒng)為了滿(mǎn)足用戶(hù)的業(yè)務(wù)需求，需求工程師需要描述系統(tǒng)高層次的解決方案，定義系統(tǒng)應(yīng)該具備的特性（Feature）參與各方必須要對(duì)高層次的解決方案達(dá)成一致，以建立一個(gè)共同的前景（Vision）特性說(shuō)明了系統(tǒng)為用戶(hù)提供的各項(xiàng)功能，它限定了系統(tǒng)的范圍（Scope）2.2功能需求

——用戶(hù)需求執(zhí)行實(shí)際工作的用戶(hù)對(duì)系統(tǒng)所能完成的具體任務(wù)的期望，描述了系統(tǒng)能夠幫助用戶(hù)做些什么直接用戶(hù)間接用戶(hù)對(duì)所有的用戶(hù)需求，都應(yīng)該有充分的問(wèn)題域知識(shí)作為背景支持特性模糊、不清晰多特性混雜多邏輯混雜2.2功能需求

——系統(tǒng)需求用戶(hù)對(duì)系統(tǒng)行為的期望，一系列的系統(tǒng)行為聯(lián)系在一起可以幫助用戶(hù)完成任務(wù)，滿(mǎn)足業(yè)務(wù)需求系統(tǒng)需求可以直接映射為系統(tǒng)行為，定義了系統(tǒng)中需要實(shí)現(xiàn)的功能，描述了開(kāi)發(fā)人員需要實(shí)現(xiàn)什么將用戶(hù)需求轉(zhuǎn)化為系統(tǒng)需求的過(guò)程是一個(gè)復(fù)雜的過(guò)程首先需要分析問(wèn)題領(lǐng)域及其特性，從中發(fā)現(xiàn)問(wèn)題域和計(jì)算機(jī)系統(tǒng)的共享知識(shí)，建立系統(tǒng)的知識(shí)模型；然后將用戶(hù)需求部署到系統(tǒng)模型當(dāng)中，即定義系列的系統(tǒng)行為，讓它們聯(lián)合起來(lái)實(shí)現(xiàn)用戶(hù)需求，每一個(gè)系統(tǒng)行為即為一個(gè)系統(tǒng)需求。該過(guò)程就是需求工程當(dāng)中最為重要的需求分析活動(dòng)，又稱(chēng)建模與分析活動(dòng)。2.2功能需求

——從功能需求的層次性看需求開(kāi)發(fā)2.3性能需求速度（Speed），系統(tǒng)的響應(yīng)時(shí)間，例如PR2.3.3-1。PR2.3.3-1：所有的用戶(hù)查詢(xún)都必須在10秒內(nèi)完成。容量（Capacity），系統(tǒng)所能存儲(chǔ)的數(shù)據(jù)量，例如PR2.3.3-2。PR2.3.3-2：系統(tǒng)應(yīng)該能夠存儲(chǔ)至少10萬(wàn)條銷(xiāo)售記錄。吞吐量（Throughput），系統(tǒng)在連續(xù)的時(shí)間內(nèi)完成的事務(wù)數(shù)量，例如PR2.3.3-3。PR2.3.3-3：解釋器每分鐘應(yīng)該至少解析5000條沒(méi)有錯(cuò)誤的語(yǔ)句。負(fù)載（Load），系統(tǒng)可以承載的并發(fā)工作量，例如PR2.3.3-4。PR2.3.3-4：系統(tǒng)應(yīng)該允許200個(gè)用戶(hù)同時(shí)進(jìn)行正常的工作。實(shí)時(shí)性（Time-Critical），嚴(yán)格的實(shí)時(shí)要求，例如PR2.3.3-5。PR2.3.3-5：監(jiān)測(cè)到病人異常后，監(jiān)控器必須在0.5秒內(nèi)發(fā)出警報(bào)。2.4質(zhì)量屬性系統(tǒng)為了滿(mǎn)足規(guī)定的及隱含的所有要求而需要具備的要素稱(chēng)為質(zhì)量質(zhì)量屬性是為了度量質(zhì)量要素而選用的特征質(zhì)量模型就是能夠?yàn)橘|(zhì)量需求的描述和評(píng)價(jià)提供工作基礎(chǔ)的特征集及特征之間的聯(lián)系質(zhì)量屬性的重要性對(duì)設(shè)計(jì)的影響很大對(duì)越復(fù)雜的系統(tǒng)越為重要[Robert19901]：真實(shí)的現(xiàn)實(shí)系統(tǒng)中，在決定系統(tǒng)的成功或失敗的因素中，滿(mǎn)足非功能屬性往往被滿(mǎn)足功能性需求更為重要。2.4質(zhì)量屬性

——ISO/IEC91262.4質(zhì)量屬性

——ISO/IEC9126特征子特征簡(jiǎn)要描述功能性精確性軟件準(zhǔn)確依照規(guī)定條款程度，規(guī)定確定了權(quán)利、協(xié)議的結(jié)果或者協(xié)議的效果依從性軟件符合法定的相關(guān)標(biāo)準(zhǔn)、協(xié)定、規(guī)則或其他類(lèi)似規(guī)定的程度互操作性軟件和指定系統(tǒng)進(jìn)行交互的能力安全性軟件阻止對(duì)其程序和數(shù)據(jù)進(jìn)行未授權(quán)訪(fǎng)問(wèn)的能力，未授權(quán)的訪(fǎng)問(wèn)可能是有意，也可能是無(wú)意的適合性指定任務(wù)的相應(yīng)功能是否存以及功能的適合程度2.4質(zhì)量屬性

——ISO/IEC9126可靠性成熟性因軟件缺陷而導(dǎo)致的故障頻率程度容錯(cuò)性軟件在故障或者外界違反其指定接口的情況下維持其指定性能水平的能力可恢復(fù)性軟件在故障后重建其性能水平、恢復(fù)其受影響數(shù)據(jù)的能力、時(shí)間和精力依從性同上2.4質(zhì)量屬性

——ISO/IEC9126易用性可理解性用戶(hù)認(rèn)可軟件的邏輯概念和其適用性需要花費(fèi)的精力可學(xué)習(xí)性用戶(hù)為了學(xué)會(huì)使用軟件需要花費(fèi)的精力可操作性用戶(hù)執(zhí)行軟件操作和控制軟件操作需要花費(fèi)的精力吸引性軟件吸引用戶(hù)的能力依從性同上2.4質(zhì)量屬性

——ISO/IEC9126效率時(shí)間行為執(zhí)行功能時(shí)的響應(yīng)時(shí)間、處理時(shí)間和吞吐速度資源行為執(zhí)行功能時(shí)使用資源的數(shù)量和時(shí)間依從性同上2.4質(zhì)量屬性

——ISO/IEC9126可維護(hù)性可分析性診斷軟件中的缺陷、故障的原因或者識(shí)別待修改部分需要花費(fèi)的精力可改變性進(jìn)行功能修改、缺陷剔除或者應(yīng)付環(huán)境改變需要花費(fèi)的精力穩(wěn)定性因修改導(dǎo)致未預(yù)料結(jié)果的風(fēng)險(xiǎn)程度可測(cè)試性確認(rèn)已修改軟件需要花費(fèi)的精力依從性同上2.4質(zhì)量屬性

——ISO/IEC9126可移植性適應(yīng)性不需采用額外的活動(dòng)或手段就能適應(yīng)不同指定環(huán)境的能力可安裝性在指定的環(huán)境中安裝軟件需要花費(fèi)的精力共存性在公共環(huán)境中同分享公共資源的其他獨(dú)立軟件共存的能力可替換性在另一個(gè)指定軟件的環(huán)境下，替換該指定軟件的能力和需要花費(fèi)的精力依從性同上2.4質(zhì)量屬性

——質(zhì)量屬性的開(kāi)發(fā)用戶(hù)并不能明確地提出他們對(duì)產(chǎn)品質(zhì)量的期望并不了解軟件系統(tǒng)的開(kāi)發(fā)過(guò)程，也就無(wú)從判斷哪些質(zhì)量屬性會(huì)在怎樣的程度上給設(shè)計(jì)帶來(lái)多大的影響，也無(wú)法將他們對(duì)軟件系統(tǒng)的質(zhì)量要求細(xì)化成一組組的可量化的質(zhì)量屬性需求工程師質(zhì)量屬性大都是和功能需求聯(lián)系在一起的，因此需要對(duì)照軟件的質(zhì)量屬性檢查每一項(xiàng)功能需求，盡力去判斷質(zhì)量屬性存在的可能性形容詞和副詞通常意味著質(zhì)量屬性的存在對(duì)于一些不和任何功能需求相聯(lián)系的全局性質(zhì)量屬性，需求工程師要在碰到特定的實(shí)例時(shí)意識(shí)到它們的存在2.5對(duì)外接口解系統(tǒng)和其他系統(tǒng)之間的軟硬件接口接口的用途接口的輸入輸出數(shù)據(jù)格式命令格式異常處理要求用戶(hù)界面利用專(zhuān)門(mén)的人機(jī)交互設(shè)計(jì)文檔記錄2.6約束總體上限制了開(kāi)發(fā)人員設(shè)計(jì)和構(gòu)建系統(tǒng)時(shí)的選擇范圍系統(tǒng)開(kāi)發(fā)及運(yùn)行的環(huán)境。包括目標(biāo)機(jī)器、操作系統(tǒng)、網(wǎng)絡(luò)環(huán)境、編程語(yǔ)言、數(shù)據(jù)庫(kù)管理系統(tǒng)等。問(wèn)題域內(nèi)的相關(guān)標(biāo)準(zhǔn)。包括法律法規(guī)、行業(yè)協(xié)定、企業(yè)規(guī)章等。商業(yè)規(guī)則。用戶(hù)在任務(wù)執(zhí)行中的一些潛在規(guī)則也會(huì)限制開(kāi)發(fā)人員設(shè)計(jì)和構(gòu)建系統(tǒng)的選擇范圍主要內(nèi)容需求的涵義需求的類(lèi)型需求工程的路線(xiàn)優(yōu)秀需求的特性常見(jiàn)的需求錯(cuò)誤3.需求工程的路線(xiàn)問(wèn)題分析和背景分析發(fā)現(xiàn)問(wèn)題比發(fā)現(xiàn)需求要簡(jiǎn)單的多進(jìn)行背景分析，以更好的理解用戶(hù)的問(wèn)題問(wèn)題分析明確問(wèn)題。定義業(yè)務(wù)需求。制定解決方案。確定系統(tǒng)特性。3.需求工程的路線(xiàn)需求獲取根據(jù)項(xiàng)目范圍，確定問(wèn)題域的范圍確定需求獲取的源頭確定獲取的主題和內(nèi)容選擇需求獲取的方法圍繞獲取的內(nèi)容，運(yùn)用需求獲取的方法，從源頭獲取需求

對(duì)獲取過(guò)程中出現(xiàn)的分歧和問(wèn)題，在項(xiàng)目前景的指導(dǎo)下進(jìn)行解決經(jīng)過(guò)需求獲取過(guò)程，可以得到獲取的文檔資料，其中以獲取筆錄為主3.需求工程的路線(xiàn)需求分析建立一個(gè)綜合考慮了問(wèn)題域特性和需求的系統(tǒng)模型根據(jù)系統(tǒng)模型將用戶(hù)需求轉(zhuǎn)化為系統(tǒng)需求文檔化和驗(yàn)證產(chǎn)生規(guī)格說(shuō)明進(jìn)行驗(yàn)證主要內(nèi)容需求的涵義需求的類(lèi)型需求工程的路線(xiàn)優(yōu)秀需求的特性常見(jiàn)的需求錯(cuò)誤4.優(yōu)秀需求的特性完整性

不需要做更多的擴(kuò)展就可以充分的說(shuō)明用戶(hù)所需要的系統(tǒng)功能。每一個(gè)需求的描述都應(yīng)該包含開(kāi)發(fā)人員設(shè)計(jì)和實(shí)現(xiàn)這項(xiàng)功能需要的所有信息R2.5-1：系統(tǒng)應(yīng)該允許被擴(kuò)展。（更好）R2.5-2：系統(tǒng)的調(diào)度算法應(yīng)該允許被擴(kuò)展。

4.優(yōu)秀需求的特性正確性

真實(shí)的反映用戶(hù)的意圖必須請(qǐng)需求的提出者予以確認(rèn)精確性

描述僅包含必要的信息簡(jiǎn)潔、清晰（不好）R2.5-3：在實(shí)現(xiàn)之后，系統(tǒng)的調(diào)度算法應(yīng)該允許被擴(kuò)展。

4.優(yōu)秀需求的特性可行性

由開(kāi)發(fā)人員進(jìn)行檢查需要進(jìn)行一定的分析和研究，而不是單純的憑借經(jīng)驗(yàn)和直覺(jué)必要的時(shí)候要通過(guò)開(kāi)發(fā)原型來(lái)加以驗(yàn)證必要性

滿(mǎn)足用戶(hù)的業(yè)務(wù)需求所必需的4.優(yōu)秀需求的特性無(wú)歧義

每一項(xiàng)需求都應(yīng)該有而且只能有一種解釋定義一個(gè)可以共同理解的詞匯表（Glossary）可驗(yàn)證

通過(guò)分析、檢查、模擬或者測(cè)試等方法能夠判斷需求是否被滿(mǎn)足不可驗(yàn)證的需求往往是因?yàn)槊枋瞿：蛘哌^(guò)于抽象，所以在進(jìn)行需求的描述時(shí)要讓需求具體化小心形容詞和副詞的使用避免程度詞的使用主要內(nèi)容需求的涵義需求的類(lèi)型需求工程的路線(xiàn)優(yōu)秀需求的特性常見(jiàn)的需求錯(cuò)誤5.常見(jiàn)的需求定義錯(cuò)誤需求并沒(méi)有反映用戶(hù)的真實(shí)需要用戶(hù)在表達(dá)自己的需要時(shí)，可能會(huì)在潛意識(shí)下進(jìn)行一定的加工發(fā)現(xiàn)問(wèn)題背后的問(wèn)題在人際交流當(dāng)中，信息會(huì)發(fā)生自然的衰減，甚至扭曲檢查和確認(rèn)5.常見(jiàn)的需求定義錯(cuò)誤模糊和歧義的需求無(wú)意中寫(xiě)出模糊和歧義的需求定義往往是因?yàn)檫x詞造句不當(dāng)為項(xiàng)目中重要的詞匯建立一個(gè)公共的可共同理解的詞匯表有意產(chǎn)生的模糊和歧義的需求定義往往是為了應(yīng)付對(duì)需求持有不同立場(chǎng)的用戶(hù)在項(xiàng)目前景的指導(dǎo)下，促進(jìn)用戶(hù)之間的協(xié)商解決5.常見(jiàn)的需求定義錯(cuò)誤明顯的信息遺漏明顯的信息遺漏，其主要原因在于項(xiàng)目的范圍定義不當(dāng)加強(qiáng)對(duì)業(yè)務(wù)需求的處理不明顯的信息遺漏，往往是因?yàn)橄嚓P(guān)信息難以發(fā)現(xiàn)該類(lèi)問(wèn)題是最難以解決的問(wèn)題，只能靠需求工程師的經(jīng)驗(yàn)來(lái)加以避免5.常見(jiàn)的需求定義錯(cuò)誤不必要的需求其一是用戶(hù)將之作為和開(kāi)發(fā)人員談判的籌碼談判技巧其二是用戶(hù)在交流當(dāng)中，用戶(hù)總是傾向于表達(dá)各種各樣的需要根據(jù)業(yè)務(wù)需求進(jìn)行用戶(hù)需求的過(guò)濾和選擇其三是需求開(kāi)發(fā)人員“畫(huà)蛇添足”保持以用戶(hù)為中心不切實(shí)際的期望用戶(hù)并不掌握關(guān)于軟件系統(tǒng)構(gòu)建的相關(guān)技術(shù)知識(shí)，所以用戶(hù)可能會(huì)提出一些已有軟件技術(shù)無(wú)法實(shí)現(xiàn)的期望軟件開(kāi)發(fā)者提供可行性、成本等足夠的技術(shù)參考信息，幫助用戶(hù)對(duì)其進(jìn)行取舍和調(diào)整5.常見(jiàn)的需求定義錯(cuò)誤實(shí)例分析（系統(tǒng)A—招標(biāo)書(shū)）請(qǐng)說(shuō)出下列需求的類(lèi)型，是否存在問(wèn)題？1、實(shí)現(xiàn)各部門(mén)的公文流轉(zhuǎn)無(wú)紙化、文檔一體化、業(yè)務(wù)管理的規(guī)范化、自動(dòng)化和網(wǎng)絡(luò)化；2、實(shí)現(xiàn)工作流程合理化、高效化，決策支持科學(xué)化、準(zhǔn)確化；3、統(tǒng)一辦公流程、規(guī)范公文格式，加強(qiáng)信息交流和共享，提高工作效率。實(shí)例分析（系統(tǒng)A—招標(biāo)書(shū)）請(qǐng)說(shuō)出下列需求的類(lèi)型，是否存在問(wèn)題？先進(jìn)性：軟件系統(tǒng)采用三層B/S系統(tǒng)結(jié)構(gòu)，以“界面表示層－邏輯處理層－數(shù)據(jù)訪(fǎng)問(wèn)層”分層設(shè)計(jì)實(shí)現(xiàn)。采用國(guó)際上先進(jìn)成熟的、廠商廣泛支持的計(jì)算機(jī)技術(shù)、網(wǎng)絡(luò)技術(shù)與軟件技術(shù)對(duì)系統(tǒng)進(jìn)行規(guī)劃，保證系統(tǒng)整體架構(gòu)在未來(lái)幾年內(nèi)都處于國(guó)際領(lǐng)先的地位。安全性：軟件系統(tǒng)具有較高的安全要求，系統(tǒng)必須具備充分的安全措施，包括具備嚴(yán)格的權(quán)限控制機(jī)制和完備的日志記錄，以確保信息安全。可靠性：保證系統(tǒng)核心功能可以7×24小時(shí)連續(xù)運(yùn)行；規(guī)范性：系統(tǒng)必須遵循國(guó)家有關(guān)法律法規(guī)要求，符合國(guó)家有關(guān)標(biāo)準(zhǔn)要求以及關(guān)于信息系統(tǒng)建設(shè)的各項(xiàng)標(biāo)準(zhǔn)和規(guī)范。實(shí)例分析（系統(tǒng)A—招標(biāo)書(shū)）請(qǐng)說(shuō)出下列需求的類(lèi)型，是否存在問(wèn)題？收文管理應(yīng)包括:來(lái)文登記、擬辦、領(lǐng)導(dǎo)審批、辦理、歸檔、查詢(xún)統(tǒng)計(jì)等功能。附件支持WORD、PDF、EXCEL、HTML等文檔類(lèi)型格式；需提供方便、靈活、直觀的文件批示處理；對(duì)收文的處理全過(guò)程進(jìn)行自動(dòng)化管理、跟蹤和記錄；在收文處理的過(guò)程中，支持電子印章、電子簽名或手寫(xiě)批注等功能。來(lái)文登記：完成來(lái)文登記功能。登記來(lái)文基本信息（來(lái)文編號(hào)、來(lái)文標(biāo)題、主題詞、來(lái)文單位、來(lái)文時(shí)間），還要對(duì)原文進(jìn)行掃描處理，引入到公文庫(kù)中。并可完成收文辦文單打印功能。完成后啟動(dòng)收文流轉(zhuǎn)流程。擬辦：查看公文的基本信息，原文內(nèi)容。簽錄擬辦意見(jiàn)，發(fā)送給領(lǐng)導(dǎo)審批。領(lǐng)導(dǎo)審批：查看公文的基本信息，原文內(nèi)容。簽錄批示意見(jiàn)，確定主辦部門(mén)、協(xié)辦部門(mén)。辦理：辦理人根據(jù)領(lǐng)導(dǎo)批示辦理，記錄辦理情況。歸檔：對(duì)辦理完結(jié)的來(lái)文歸檔，將來(lái)文信息、擬辦意見(jiàn)、領(lǐng)導(dǎo)批示、辦理情況等信息及來(lái)文掃描件發(fā)送到檔案管理系統(tǒng)，檔案科確認(rèn)接收的文件，才屬于己歸檔文件。查詢(xún)統(tǒng)計(jì)：提供按來(lái)文編號(hào)、來(lái)文標(biāo)題、主題詞、來(lái)文單位、來(lái)文時(shí)間等查詢(xún)統(tǒng)計(jì)功能，要求查詢(xún)統(tǒng)計(jì)結(jié)果可以打印。實(shí)例分析（系統(tǒng)A—招標(biāo)書(shū)）請(qǐng)說(shuō)出下列需求的類(lèi)型，是否存在問(wèn)題？編程應(yīng)遵循如下原則：唯一性：每個(gè)實(shí)體及其屬性必須有唯一的代碼來(lái)確切地定義?？蓴U(kuò)充性：考慮到系統(tǒng)以后的發(fā)展，編號(hào)要留有余地。當(dāng)增加新的實(shí)體時(shí)，可以直接在原代碼的基礎(chǔ)上加以擴(kuò)充，擴(kuò)充后不會(huì)引起代碼體系的混亂，這樣就避免了重新設(shè)計(jì)代碼系統(tǒng)的麻煩。通用性：凡國(guó)家、行業(yè)、地方對(duì)編碼有統(tǒng)一標(biāo)準(zhǔn)和規(guī)定的，應(yīng)盡量使用標(biāo)準(zhǔn)代碼，代碼適用范圍越廣越好。沒(méi)有標(biāo)準(zhǔn)代碼的，投標(biāo)方設(shè)計(jì)的代碼也應(yīng)該統(tǒng)一，如代碼長(zhǎng)度與格式的統(tǒng)一。便于記憶和識(shí)別：代碼不但要具有一定的邏輯定義，也要盡量考慮用戶(hù)的使用習(xí)慣，使代碼便于記憶和識(shí)別，做到簡(jiǎn)單明了簡(jiǎn)短性：在滿(mǎn)足需要的前提下，代碼要盡可能短。編程人員必須對(duì)所有代碼進(jìn)行嚴(yán)格自測(cè)。實(shí)例分析（系統(tǒng)A—招標(biāo)書(shū)）請(qǐng)說(shuō)出下列需求的類(lèi)型，是否存在問(wèn)題？驗(yàn)收投標(biāo)方需提供以下文檔：軟件需求分析報(bào)告軟件總體設(shè)計(jì)報(bào)告軟件操作手冊(cè)軟件配置手冊(cè)軟件試運(yùn)行報(bào)告應(yīng)用軟件介質(zhì)實(shí)例分析（系統(tǒng)A—招標(biāo)書(shū)）請(qǐng)說(shuō)出下列需求的類(lèi)型，是否存在問(wèn)題？培訓(xùn)要求投標(biāo)人必須提供相應(yīng)的應(yīng)用軟件技術(shù)和系統(tǒng)操作等方面的培訓(xùn)。投標(biāo)人須在文件中提出全面、詳細(xì)的培訓(xùn)課程以及時(shí)間表交給業(yè)主，并在合同簽定后征得業(yè)主同意后實(shí)施。投標(biāo)人應(yīng)提供面向系統(tǒng)管理員的應(yīng)用軟件系統(tǒng)結(jié)構(gòu)、日常維護(hù)等方面的培訓(xùn)。對(duì)于所有培訓(xùn)，投標(biāo)人必須派出具有相應(yīng)專(zhuān)業(yè)資格和實(shí)際工作經(jīng)驗(yàn)的人員進(jìn)行培訓(xùn)。投標(biāo)人須提供詳細(xì)的培訓(xùn)計(jì)劃。

以上培訓(xùn)內(nèi)容的培訓(xùn)費(fèi)用均包含在投標(biāo)報(bào)價(jià)內(nèi)，項(xiàng)目采購(gòu)人不再另行支付實(shí)例分析（系統(tǒng)B—需求規(guī)格說(shuō)明）請(qǐng)說(shuō)出下列需求的類(lèi)型，是否存在問(wèn)題？2.1.開(kāi)發(fā)意圖1.減少人力成本2.提高辦公效率3.成本統(tǒng)計(jì)、查詢(xún)4.歷史信息查詢(xún)5.支持WEB操作實(shí)例分析（系統(tǒng)B—需求規(guī)格說(shuō)明）請(qǐng)說(shuō)出下列需求的類(lèi)型，是否存在問(wèn)題？2.3.產(chǎn)品功能2.3.1.人員管理對(duì)本公司的人力資源進(jìn)行管理。提供功能：新員工信息錄入、信息修改（晉升、部門(mén)調(diào)動(dòng)、休假、婚姻狀況變更）、離職人員歸檔。注）該操作需要具有人員管理權(quán)限的人才可以進(jìn)行。2.3.2.業(yè)務(wù)管理對(duì)本公司的業(yè)務(wù)進(jìn)行管理。提供功能：新業(yè)務(wù)錄入、現(xiàn)有業(yè)務(wù)變更（計(jì)劃提前或延后、合同金額或付款方式變更、業(yè)務(wù)內(nèi)容變更）、已完成的業(yè)務(wù)歸檔。注）該操作需要具有業(yè)務(wù)管理權(quán)限的人才可以進(jìn)行。實(shí)例分析（系統(tǒng)B—需求規(guī)格說(shuō)明）請(qǐng)說(shuō)出下列需求的類(lèi)型，是否存在問(wèn)題？2.4.1.擴(kuò)展性要求結(jié)構(gòu)設(shè)計(jì)良好，二次開(kāi)發(fā)成本要求低于本次開(kāi)發(fā)成本30%能夠簡(jiǎn)單的進(jìn)行多語(yǔ)言版本改造。2.4.2.靈活性支持主流瀏覽器：IE7,8,FireFox2.0,Google瀏覽器。2.4.3.精度金額相關(guān)：小數(shù)點(diǎn)后保留2位有效數(shù)字；時(shí)間相關(guān)：精確到秒；傳輸過(guò)程中的精度：小數(shù)點(diǎn)后保留5位有效數(shù)字。2.4.4.響應(yīng)要求用戶(hù)登陸：<=0.5秒頁(yè)面跳轉(zhuǎn)：<=2秒2.4.5.安全性系統(tǒng)管理員（admin）負(fù)責(zé)系統(tǒng)維護(hù)；根據(jù)公司體制指定各部門(mén)負(fù)責(zé)人，并賦予相應(yīng)的操作權(quán)限；所有信息保存在MySQL數(shù)據(jù)庫(kù)中；用戶(hù)密碼采用密文形式保存實(shí)例分析（系統(tǒng)B—需求規(guī)格說(shuō)明）請(qǐng)說(shuō)出下列需求的類(lèi)型，是否存在問(wèn)題？實(shí)例分析（系統(tǒng)B—需求規(guī)格說(shuō)明）請(qǐng)說(shuō)出下列需求的類(lèi)型，是否存在問(wèn)題？3.3.2.人員信息變更目的：修改員工信息。功能：提供員工信息修改界面，并將修改后的信息保存進(jìn)MySQL數(shù)據(jù)庫(kù)。步驟：1.在界面上修改員工信息。2.操作者權(quán)限檢查。3.操作成功，返回人員管理界面；操作失敗，提示錯(cuò)誤信息。流程圖：實(shí)例分析（系統(tǒng)C）請(qǐng)說(shuō)出下列需求的類(lèi)型，是否存在問(wèn)題？4.1業(yè)務(wù)現(xiàn)狀與分析單一客戶(hù)經(jīng)理渠道從“綠色通道”變成制約集團(tuán)發(fā)展的瓶頸其他營(yíng)銷(xiāo)服務(wù)界面缺乏有效識(shí)別集團(tuán)客戶(hù)的工具目前公司缺少一套貫穿全省各級(jí)公司和各部門(mén)的統(tǒng)一業(yè)務(wù)調(diào)度系統(tǒng)來(lái)協(xié)助跨部門(mén)工作各節(jié)點(diǎn)缺乏受理標(biāo)準(zhǔn)時(shí)限規(guī)范，內(nèi)部資源調(diào)度無(wú)法快速響應(yīng)，客戶(hù)經(jīng)理在面對(duì)客戶(hù)時(shí)無(wú)法進(jìn)行服務(wù)時(shí)限承諾，降低了集團(tuán)業(yè)務(wù)的客戶(hù)滿(mǎn)意業(yè)務(wù)支撐平臺(tái)不斷增多，且均需要分散維護(hù)，服務(wù)質(zhì)量難以保障實(shí)例分析（系統(tǒng)C）請(qǐng)說(shuō)出下列需求的類(lèi)型，是否存在問(wèn)題？分策經(jīng)理審批分策經(jīng)理信息員工工號(hào)登陸后自動(dòng)顯示員工姓名根據(jù)工號(hào)系統(tǒng)自動(dòng)顯示姓名審批信息是否需要審批是/否審批意見(jiàn)輸入行業(yè)部經(jīng)理審批行業(yè)部經(jīng)理信息員工工號(hào)登陸后自動(dòng)顯示員工姓名根據(jù)工號(hào)系統(tǒng)自動(dòng)顯示姓名審批信息是否需要審批是/否審批意見(jiàn)輸入產(chǎn)品部經(jīng)理審批產(chǎn)品部經(jīng)理信息員工工號(hào)登陸后自動(dòng)顯示員工姓名根據(jù)工號(hào)系統(tǒng)自動(dòng)顯示姓名審批信息是否需要審批是/否審批意見(jiàn)輸入分策部經(jīng)理審批分策部經(jīng)理信息員工工號(hào)登陸后自動(dòng)顯示員工姓名根據(jù)工號(hào)系統(tǒng)自動(dòng)顯示姓名審批信息是否需要審批是/否審批意見(jiàn)輸入本章小結(jié)需求是人們對(duì)現(xiàn)實(shí)世界問(wèn)題解決的期望解系統(tǒng)通過(guò)共享知識(shí)和問(wèn)題域進(jìn)行互動(dòng)，從而解決現(xiàn)實(shí)世界中的問(wèn)題具體的需求包括功能需求、性能需求、質(zhì)量屬性、對(duì)外接口和約束需求工程活動(dòng)是依據(jù)需求的內(nèi)涵與外延逐步展開(kāi)的書(shū)寫(xiě)的需求應(yīng)該具有優(yōu)秀的特性，尤其要避免出現(xiàn)常見(jiàn)的錯(cuò)誤

第3章.需求工程過(guò)程主要內(nèi)容需求工程過(guò)程需求工程過(guò)程的活動(dòng)需求工程過(guò)程的并發(fā)和迭代性實(shí)踐方法的應(yīng)用1.需求工程過(guò)程過(guò)程是一組相關(guān)活動(dòng)的集成，通過(guò)這些活動(dòng)的執(zhí)行，可以完成一項(xiàng)任務(wù)或者達(dá)到一個(gè)目標(biāo)。需求工程過(guò)程是系統(tǒng)開(kāi)發(fā)當(dāng)中需求開(kāi)發(fā)活動(dòng)的集成，它的模版是產(chǎn)生一個(gè)能夠在用戶(hù)環(huán)境下解決用戶(hù)業(yè)務(wù)問(wèn)題的系統(tǒng)方案需求工程過(guò)程可能會(huì)表現(xiàn)出極大的差異，但是除了少數(shù)情況之外，主要的需求工程活動(dòng)是比較固定的1.需求工程過(guò)程1.需求工程過(guò)程主要內(nèi)容需求工程過(guò)程需求工程過(guò)程的活動(dòng)需求工程過(guò)程的并發(fā)和迭代性實(shí)踐方法的應(yīng)用2.需求工程過(guò)程的活動(dòng)需求獲取需求獲取是從人、文檔或者環(huán)境當(dāng)中獲取需求的過(guò)程需求工程師必須要利用各種方法和技術(shù)來(lái)“發(fā)現(xiàn)”需求需求獲取和需求分析是交織在一起的2.需求工程過(guò)程的活動(dòng)需求獲取子活動(dòng)收集背景資料定義項(xiàng)目前景和范圍選擇信息的來(lái)源選擇獲取方法，執(zhí)行獲取記錄獲取結(jié)果2.需求工程過(guò)程的活動(dòng)需求分析建模來(lái)整合各種信息，以使得人們更好的理解問(wèn)題為問(wèn)題定義出一個(gè)需求集合，這個(gè)集合能夠?yàn)閱?wèn)題界定一個(gè)有效的解決方案檢查需求當(dāng)中存在的錯(cuò)誤、遺漏、不一致等各種缺陷，并加以修正2.需求工程過(guò)程的活動(dòng)需求分析子活動(dòng)背景分析確定系統(tǒng)邊界需求建模需求細(xì)化確定優(yōu)先級(jí)需求協(xié)商2.需求工程過(guò)程的活動(dòng)需求規(guī)格說(shuō)明獲取的需求需要被編寫(xiě)成文檔，主要目的是為了在系統(tǒng)涉眾之間交流需求信息業(yè)務(wù)需求被寫(xiě)入項(xiàng)目前景和范圍文檔用戶(hù)需求被寫(xiě)入用戶(hù)需求文檔（或者用例文檔）系統(tǒng)需求被寫(xiě)入需求規(guī)格說(shuō)明需求規(guī)格說(shuō)明子活動(dòng)定制文檔模版編寫(xiě)文檔2.需求工程過(guò)程的活動(dòng)需求驗(yàn)證確保需求規(guī)格說(shuō)明文檔能正確、準(zhǔn)確的反映用戶(hù)的意圖確保文檔的高質(zhì)量文檔內(nèi)每條需求都正確、準(zhǔn)確的反映了用戶(hù)的意圖；文檔記錄的需求集在整體上具有完整性和一致性；文檔的組織方式和需求的書(shū)寫(xiě)方式具有可讀性和可修改性需求驗(yàn)證子活動(dòng)執(zhí)行驗(yàn)證問(wèn)題修正2.需求工程過(guò)程的活動(dòng)需求管理保證需求作用在整個(gè)軟件的產(chǎn)品生命周期中的續(xù)、穩(wěn)定和有效發(fā)揮需求管理子活動(dòng)建立和維護(hù)需求基線(xiàn)集建立需求跟蹤信息進(jìn)行變更控制主要內(nèi)容需求工程過(guò)程需求工程過(guò)程的活動(dòng)需求工程過(guò)程的并發(fā)和迭代性實(shí)踐方法的應(yīng)用3.需求工程過(guò)程的并發(fā)和迭代性

——需求開(kāi)發(fā)中的分析模型復(fù)雜度3.需求工程過(guò)程的并發(fā)和迭代性

——迭代的需求開(kāi)發(fā)過(guò)程模型3.需求工程過(guò)程的并發(fā)和迭代性

——需求開(kāi)發(fā)活動(dòng)的并發(fā)性主要內(nèi)容需求工程過(guò)程需求工程過(guò)程的活動(dòng)需求工程過(guò)程的并發(fā)和迭代性實(shí)踐方法的應(yīng)用4.實(shí)踐方法的應(yīng)用個(gè)人才智實(shí)踐方法知識(shí)體系需求工程師需要為組織或項(xiàng)目選擇、定制和應(yīng)用一些有效的實(shí)踐方法見(jiàn)教材表3-1有效實(shí)踐內(nèi)容技術(shù)、方法需求獲取定義項(xiàng)目前景定義項(xiàng)目前景問(wèn)題分析

明確問(wèn)題

發(fā)現(xiàn)業(yè)務(wù)需求

定義問(wèn)題解決方案和系統(tǒng)特性控制項(xiàng)目范圍控制項(xiàng)目范圍定義問(wèn)題解決方案的邊界

定義系統(tǒng)邊界需求獲取實(shí)現(xiàn)用戶(hù)價(jià)值涉眾識(shí)別

涉眾描述

涉眾分析涉眾識(shí)別方法

涉眾的描述特征

涉眾的優(yōu)先級(jí)評(píng)估

涉眾的風(fēng)險(xiǎn)評(píng)估

涉眾的共贏分析促進(jìn)用戶(hù)參與涉眾采樣

用戶(hù)參與代表采樣

制定參與策略

使用用戶(hù)替代源

用戶(hù)參與需求獲取識(shí)別并使用各種需求源涉眾分析

硬數(shù)據(jù)采樣

需求重用涉眾分析的各種方法（如前述）

硬數(shù)據(jù)采樣有效的獲取需求建立有效交流機(jī)制建立合作關(guān)系，維護(hù)交流氣氛

利用適當(dāng)?shù)慕涣魍緩?、交流方式正確使用需求獲取方法面談/調(diào)查問(wèn)卷

群體會(huì)議面談/頭腦風(fēng)暴原型

觀察

文檔分析/需求重用/需求剝離收集和組織需求獲取的結(jié)果建立收集和組織需求需求結(jié)果的機(jī)制面向目標(biāo)的方法

基于場(chǎng)景的方法

基于用例的方法需求分析

為需求建模通過(guò)建模手段明確和理解需求信息上下文圖和系統(tǒng)用例圖

ERD和數(shù)據(jù)字典

DFD、FDD和PDD

狀態(tài)(轉(zhuǎn)移)圖/矩陣

UML（分析部分）使用多種手段從多角度建模相同的內(nèi)容多視點(diǎn)方法

Wiegrnga框架

Zachman框架在合適的層次上描述需求需求細(xì)化唯一的標(biāo)識(shí)每一條需求需求細(xì)化劃分需求的優(yōu)先級(jí)確定需求優(yōu)先級(jí)累計(jì)投票

區(qū)域劃分

Top-N

數(shù)據(jù)量化分析系統(tǒng)的背景前期需求階段的建模與分析面向目標(biāo)的方法

面向問(wèn)題域的分析

領(lǐng)域分析

企業(yè)建模有效實(shí)踐內(nèi)容技術(shù)、方法需求規(guī)格說(shuō)明使用模版使用需求文檔模版[IEEE1998]的模版創(chuàng)建需求規(guī)格說(shuō)明文檔創(chuàng)建正式的軟件需求規(guī)格說(shuō)明文檔文檔的類(lèi)型

文檔的內(nèi)容

文檔的使用進(jìn)行良好的寫(xiě)作綜合使用各種描述手段形式化、半形式和非形式化描述學(xué)習(xí)有效的寫(xiě)作實(shí)踐發(fā)揮創(chuàng)造性

以交流為目標(biāo)組織內(nèi)容得當(dāng)

不要重復(fù)

形式依賴(lài)內(nèi)容

使用術(shù)語(yǔ)表和數(shù)據(jù)字典

避免干擾文本

避免歧義詞匯需求驗(yàn)證驗(yàn)證需求使用有效方法進(jìn)行需求的驗(yàn)證和確認(rèn)需求評(píng)審

原型與模擬

開(kāi)發(fā)測(cè)試用例

用戶(hù)手冊(cè)編制

利用跟蹤關(guān)系

自動(dòng)化分析需求管理建立和維護(hù)需求基線(xiàn)建立和維護(hù)需求基線(xiàn)配置管理狀態(tài)維護(hù)進(jìn)行變更控制進(jìn)行變更控制變更控制過(guò)程變更控制事項(xiàng)（策略）建立需求跟蹤信息建立需求跟蹤信息低端/高端的需求跟蹤使用需求跟蹤矩陣需求依賴(lài)實(shí)踐方法內(nèi)容過(guò)程管理建立需求工程過(guò)程建立需求過(guò)程過(guò)程框架選擇需求工程過(guò)程工作組件維護(hù)和使用有效的實(shí)踐方法維護(hù)和使用有效的實(shí)踐方法持續(xù)改進(jìn)需求工程過(guò)程評(píng)價(jià)需求工程過(guò)程持續(xù)改進(jìn)需求工程過(guò)程項(xiàng)目管理制定需求開(kāi)發(fā)計(jì)劃提供充足的資源支持選擇需求開(kāi)發(fā)的生命周期建立需求工程團(tuán)隊(duì)組建團(tuán)隊(duì)維持團(tuán)隊(duì)內(nèi)部的交流氛圍管理需求風(fēng)險(xiǎn)管理需求風(fēng)險(xiǎn)思考題1.除了需求開(kāi)發(fā)的四個(gè)活動(dòng)和需求管理活動(dòng)之外，需求工程當(dāng)中還有沒(méi)有需要執(zhí)行的活動(dòng)？如果有的話(huà)，它們是哪些活動(dòng)？給出你的理由。2.需求開(kāi)發(fā)過(guò)程具有迭代特性，但是不是所有項(xiàng)目的需求開(kāi)發(fā)過(guò)程都必須是迭代完成的？如果不是，請(qǐng)給出舉例和理由。3.需求開(kāi)發(fā)的迭代特性與軟件開(kāi)發(fā)過(guò)程的迭代式開(kāi)發(fā)有什么關(guān)系？它們之間會(huì)互相影響嗎？如果會(huì)，那么有哪些影響？4.需求工程細(xì)節(jié)知識(shí)的實(shí)踐性對(duì)不同項(xiàng)目的需求開(kāi)發(fā)過(guò)程的差異性有沒(méi)有影響？如果有，請(qǐng)說(shuō)明影響是什么。如果沒(méi)有，請(qǐng)說(shuō)明是哪些因素產(chǎn)生了不同項(xiàng)目的需求開(kāi)發(fā)過(guò)程的差異性。本章小結(jié)需求工程有著屬于它自己的生命周期模型，存在著針對(duì)需求開(kāi)發(fā)的需求工程過(guò)程需求工程過(guò)程擁有一些常見(jiàn)的需求工程活動(dòng)：需求獲取、需求分析、需求規(guī)格說(shuō)明、需求驗(yàn)證和需求管理需求開(kāi)發(fā)活動(dòng)是互相交織、并發(fā)、迭代和遞增的需求工程過(guò)程的成功執(zhí)行需要應(yīng)用很多的有效實(shí)踐方法

第4章.需求獲取概述主要內(nèi)容需求獲取的非平凡性需求獲取的活動(dòng)過(guò)程需求獲取活動(dòng)的要點(diǎn)需求獲取的實(shí)踐調(diào)查情況1.需求獲取的非平凡性用戶(hù)和開(kāi)發(fā)人員的背景不同，立場(chǎng)不同首先是知識(shí)理解的困難。盡力去研究應(yīng)用的背景，理解組織的狀況，形成一個(gè)能夠和用戶(hù)進(jìn)行有效溝通的粗略的知識(shí)框架默認(rèn)（Tacit）知識(shí)現(xiàn)象利用有效的獲取方法與技巧（角色扮演、觀察等）來(lái)發(fā)現(xiàn)并獲取默認(rèn)知識(shí)1.需求獲取的非平凡性普通用戶(hù)缺乏概括性、綜合性的表述能力普通用戶(hù)的知識(shí)結(jié)構(gòu)就相對(duì)局限于一些具體的業(yè)務(wù)細(xì)節(jié)善于表達(dá)具體業(yè)務(wù)的細(xì)節(jié)問(wèn)題專(zhuān)家用戶(hù)的知識(shí)結(jié)構(gòu)因其淵博性而具有概括性和廣泛性能夠回答概括性和綜合性的問(wèn)題開(kāi)發(fā)人員在與用戶(hù)接觸之前就先行確定獲取的內(nèi)容主題，然后設(shè)計(jì)具體的應(yīng)用環(huán)境和場(chǎng)景條件，由用戶(hù)根據(jù)細(xì)節(jié)業(yè)務(wù)的執(zhí)行來(lái)描述問(wèn)題、表達(dá)期望。1.需求獲取的非平凡性用戶(hù)存在認(rèn)知困境潛在（Latency）知識(shí)需要利用各種有效的需求獲取方法和技巧用戶(hù)越俎代庖用戶(hù)提出的不是需求，而是解決方案注意保持業(yè)務(wù)領(lǐng)域和解決方案的區(qū)分界限用戶(hù)固執(zhí)的堅(jiān)持某些特征和功能分析用戶(hù)的深層目的，找到隱藏在背后的需求1.需求獲取的非平凡性缺乏用戶(hù)參與用戶(hù)數(shù)量太多，選擇困難用戶(hù)認(rèn)識(shí)不足，不愿參與用戶(hù)情緒抵制，消極參與沒(méi)有明確的用戶(hù)對(duì)系統(tǒng)的用戶(hù)以及用戶(hù)的替代源等相關(guān)涉眾進(jìn)行分析主要內(nèi)容需求獲取的非平凡性需求獲取的活動(dòng)過(guò)程子活動(dòng)過(guò)程描述需求獲取活動(dòng)的要點(diǎn)需求獲取的實(shí)踐調(diào)查情況2.1需求獲取的子活動(dòng)研究應(yīng)用背景，建立初始的知識(shí)框架；根據(jù)獲取的需要，采用必要的獲取方法和技巧；先行確定獲取的內(nèi)容和主題，設(shè)定場(chǎng)景；分析用戶(hù)的高（深）層目標(biāo)，理解用戶(hù)的意圖；進(jìn)行涉眾分析，針對(duì)涉眾的特點(diǎn)開(kāi)展工作。2.2需求獲取的活動(dòng)過(guò)程主要內(nèi)容需求獲取的非平凡性需求獲取的活動(dòng)過(guò)程需求獲取活動(dòng)的要點(diǎn)獲取的內(nèi)容獲取的來(lái)源獲取的方法獲取的過(guò)程獲取的結(jié)果需求獲取的實(shí)踐調(diào)查情況3.1獲取的內(nèi)容在項(xiàng)目的范圍之內(nèi)所有為用戶(hù)創(chuàng)建解決系統(tǒng)必須的信息需求通常體現(xiàn)為用戶(hù)的觀點(diǎn)、看法、目標(biāo)或者問(wèn)題問(wèn)題域特性需要注意的是不要忽略系統(tǒng)的環(huán)境和約束獲取的內(nèi)容不是一次得到的，而是逐步積累的3.2獲取的來(lái)源涉眾用戶(hù)客戶(hù)領(lǐng)域?qū)＜沂袌?chǎng)人員、銷(xiāo)售人員等其他用戶(hù)替代源相關(guān)產(chǎn)品原有系統(tǒng)競(jìng)爭(zhēng)產(chǎn)品協(xié)作產(chǎn)品（和解系統(tǒng)存在接口的其他軟件系統(tǒng)）硬數(shù)據(jù)登記表格、單據(jù)、報(bào)表等定量文檔備忘錄、日志等定性文檔重要文檔原有系統(tǒng)的規(guī)格說(shuō)明競(jìng)爭(zhēng)產(chǎn)品的規(guī)格說(shuō)明協(xié)作產(chǎn)品的規(guī)格說(shuō)明客戶(hù)的需求文檔（委托開(kāi)發(fā)的規(guī)格說(shuō)明、招標(biāo)書(shū)）相關(guān)技術(shù)標(biāo)準(zhǔn)和法規(guī)相關(guān)法律、法規(guī)及規(guī)章制度行業(yè)規(guī)范、行業(yè)標(biāo)準(zhǔn)3.3獲取的方法傳統(tǒng)方法問(wèn)卷調(diào)查、面談、硬數(shù)據(jù)分析、文檔檢查、需求剝離等集體獲取方法頭腦風(fēng)暴（Brainstorming）、專(zhuān)題討論會(huì)（Workshop）、JAD等原型認(rèn)知方法任務(wù)分析（TaskAnalysis）、協(xié)議分析（ProtocolAnalysis）等基于上下文的方法觀察、民族志（Ethnography）和話(huà)語(yǔ)分析（ConversationAnalysis）3.4獲取的過(guò)程

——注意事項(xiàng)在整體上制定組織方案確定系統(tǒng)的邊界，建立上下文圖或系統(tǒng)用例圖維護(hù)項(xiàng)目的前景和范圍引導(dǎo)和控制獲取過(guò)程接受需求的不穩(wěn)定性控制探索性工作3.4獲取的過(guò)程

——

防止需求遺漏務(wù)必讓所有的涉眾都表達(dá)出自己的意見(jiàn)。不要以抽象和模糊的需求作為結(jié)束。對(duì)抽象和模糊的需求，要進(jìn)行細(xì)化，讓真正的需求顯露出來(lái)。使用多種方法表達(dá)需求信息。利用不同的分析技術(shù)為相同的需求進(jìn)行建模，通過(guò)分析不同的關(guān)注點(diǎn)，考察需求是否完整。注意檢查邊界值和布爾邏輯。3.4獲取的過(guò)程

——結(jié)束獲取活動(dòng)的判斷條件用戶(hù)想不出更多的用例；用戶(hù)想出的新用例都是導(dǎo)出用例（通過(guò)其他用例的結(jié)合可以推導(dǎo)出該用例）；用戶(hù)只是在重復(fù)已經(jīng)討論過(guò)的問(wèn)題；新提出的特性、需求等都在項(xiàng)目范圍之外；新提出的需求優(yōu)先級(jí)都很低；用戶(hù)提出的新功能都屬于后繼版本，而非當(dāng)前版本3.5獲取的結(jié)果肯定會(huì)產(chǎn)生獲取筆錄（ElicitationNotes）用戶(hù)需求、問(wèn)題域知識(shí)和約束可能具有組織差、冗余、遺漏、自相矛盾等諸多問(wèn)題可以包括文字記錄、錄音、攝像等各種形式可能會(huì)產(chǎn)生兩份定義明確的正式文檔項(xiàng)目前景和范圍文檔用例文檔主要內(nèi)容需求獲取的非平凡性需求獲取的活動(dòng)過(guò)程需求獲取活動(dòng)的要點(diǎn)需求獲取的實(shí)踐調(diào)查情況4.需求獲取的實(shí)踐調(diào)查情況實(shí)踐中的需求獲取活動(dòng)主要關(guān)注以下幾個(gè)問(wèn)題：項(xiàng)目目標(biāo)；項(xiàng)目成功的十大影響因素之一[StandishGroup]項(xiàng)目范圍；用戶(hù)參與；交流問(wèn)題；獲取方法的使用；4.需求獲取的實(shí)踐調(diào)查情況項(xiàng)目范圍項(xiàng)目的邊界定義不清晰，或者根本就沒(méi)有定義項(xiàng)目的邊界；定義的項(xiàng)目邊界錯(cuò)誤，使得最終的需求不完備或者冗余；沒(méi)有控制已建立的項(xiàng)目邊界，使得項(xiàng)目范圍失控尤其是因?yàn)闀r(shí)間壓力而拋棄需求的問(wèn)題和開(kāi)發(fā)人員“鍍金”的問(wèn)題非常普遍4.需求獲取的實(shí)踐調(diào)查情況用戶(hù)參與不足沒(méi)有能夠有效的選擇參與項(xiàng)目的用戶(hù)認(rèn)識(shí)不足用戶(hù)抵制沒(méi)有明確的用戶(hù)管理上的障礙4.需求獲取的實(shí)踐調(diào)查情況交流問(wèn)題最大的問(wèn)題就是理解偏差常用的交流方式：非正式的電話(huà)交談、正式的電話(huà)交談（例如客戶(hù)熱線(xiàn)或者遠(yuǎn)程電話(huà)會(huì)議）、郵件、web反饋表、文檔以及一些面對(duì)面的交流（例如JAD會(huì)議、原型等）面對(duì)面的交流方式是最有效，也是最受歡迎的直接交流途徑優(yōu)于間接交流途徑4.需求獲取的實(shí)踐調(diào)查情況獲取方法的使用沒(méi)有在實(shí)踐當(dāng)中得到充分的應(yīng)用存在選擇問(wèn)題五個(gè)方面的選擇依據(jù)需求的目的知識(shí)的類(lèi)型知識(shí)內(nèi)化的特性要求可觀察的現(xiàn)象約束維度類(lèi)型采樣觀察非結(jié)構(gòu)化面談結(jié)構(gòu)化面談?lì)^腦風(fēng)暴原型場(chǎng)景分析民族志群體面談需求的目的建立規(guī)格說(shuō)明x-√-√√-xx選擇軟件開(kāi)發(fā)工具包x-√---xx建立需求方案-√√√√√-√√-√√知識(shí)的類(lèi)型抽象行為√√√√√√√√√√√√處理過(guò)程√√√√√√√√√√√數(shù)據(jù)----√√√√√知識(shí)內(nèi)化的特性要求新知識(shí)x√√√√√√√x√√明顯的知識(shí)-√√√√√-√√-√√已認(rèn)知知識(shí)xxx√√√√√x√√默認(rèn)知識(shí)√√---√√√√√情景性工作知識(shí)xxxxxxxx慣性知識(shí)√√---√√√√√潛在知識(shí)√√---√√√√√可觀察的現(xiàn)象√√xx-xx√√-約束需要開(kāi)會(huì)x√√√√√x√需要準(zhǔn)備時(shí)間√√√√-√√--√√√需要采集信息的時(shí)間√√√√√√√√√√√xx需要獲得需求的時(shí)間-√√√√√√xx需求工程師數(shù)量11111111涉眾數(shù)量11111126需要涉眾友好-√√√√√√xx無(wú)前導(dǎo)技術(shù)要求√√√√√√√xx√x本章小結(jié)需求獲取是一個(gè)困難和復(fù)雜的任務(wù)需求獲取的成功執(zhí)行需要有效組織子活動(dòng)過(guò)程執(zhí)行需求獲取時(shí)既要盡可能全面，又要防止不完備，更要注意進(jìn)行過(guò)程控制實(shí)踐調(diào)查情況表明，需求獲取活動(dòng)還是一個(gè)具有挑戰(zhàn)性的任務(wù)

第5章.確定項(xiàng)目的前景和范圍主要內(nèi)容確定項(xiàng)目前景和范圍的活動(dòng)問(wèn)題分析建立系統(tǒng)邊界項(xiàng)目前景和范圍文檔1.確定項(xiàng)目前景和范圍的活動(dòng)

——為什么要確定項(xiàng)目的前景和范圍在看待現(xiàn)實(shí)世界時(shí)世界是復(fù)雜的從不同的角度觀察，會(huì)看到不同的內(nèi)容例如，對(duì)桌子，木匠、商人、考古學(xué)家、工藝學(xué)家…觀察到的內(nèi)容是不一樣的因此…如何保證項(xiàng)目涉眾以符合項(xiàng)目需要的角度描述現(xiàn)實(shí)世界？描述哪些事物和事件才會(huì)盡可能的符合項(xiàng)目的需要？方法是…定義項(xiàng)目前景所有的涉眾都從共同認(rèn)同的項(xiàng)目前景出發(fā)，理解和描述問(wèn)題域及需求定義項(xiàng)目范圍范圍內(nèi)的事物和事件是描述的目標(biāo)1.確定項(xiàng)目前景和范圍的活動(dòng)

——確定項(xiàng)目前景和范圍的位置和作用1.確定項(xiàng)目前景和范圍的活動(dòng)

——

確定項(xiàng)目前景和范圍的關(guān)鍵定義業(yè)務(wù)需求和能夠滿(mǎn)足需求的高層解決方案，包括:業(yè)務(wù)目標(biāo)、目的高層業(yè)務(wù)功能每個(gè)高層業(yè)務(wù)功能所關(guān)聯(lián)的高層數(shù)據(jù)每個(gè)功能相關(guān)的項(xiàng)目涉眾等等如果存在不同業(yè)務(wù)需求之間的沖突，那么在確定項(xiàng)目前景和范圍階段必須予以解決1.確定項(xiàng)目前景和范圍的活動(dòng)

——業(yè)務(wù)需求沖突示例對(duì)一個(gè)配有嵌入式軟件的售貨機(jī)而言：銷(xiāo)售機(jī)開(kāi)發(fā)者的業(yè)務(wù)目標(biāo)：向零售商出售或出租售貨機(jī)，并由此獲利。通過(guò)售貨機(jī)向顧客銷(xiāo)售消費(fèi)品。吸引客戶(hù)對(duì)商品的興趣。生產(chǎn)出多種類(lèi)型的售貨機(jī)。零售商的業(yè)務(wù)目標(biāo)：將單位營(yíng)業(yè)面積的收益最大化。吸引更多的顧客來(lái)商店購(gòu)買(mǎi)。用售貨機(jī)替代人工，帶來(lái)銷(xiāo)量和利潤(rùn)的增長(zhǎng)?？赡墚a(chǎn)生的矛盾：開(kāi)發(fā)者重技術(shù)、零售商要求簡(jiǎn)單可直接投入使用、顧客希望方便和功能性1.確定項(xiàng)目前景和范圍的活動(dòng)

——

過(guò)程描述主要內(nèi)容確定項(xiàng)目前景和范圍的活動(dòng)問(wèn)題分析明確問(wèn)題發(fā)現(xiàn)業(yè)務(wù)需求定義解決方案及系統(tǒng)特性建立系統(tǒng)邊界項(xiàng)目前景和范圍文檔2.1明確問(wèn)題一、對(duì)問(wèn)題達(dá)成共識(shí)二、收集背景資料，判斷問(wèn)題的明確性三、分析不明確問(wèn)題，發(fā)現(xiàn)問(wèn)題背后的問(wèn)題2.1明確問(wèn)題

——一、對(duì)問(wèn)題達(dá)成共識(shí)描述問(wèn)題在涉眾之間取得認(rèn)同元素內(nèi)容ID問(wèn)題涉眾影響解決問(wèn)題標(biāo)識(shí)問(wèn)題描述受問(wèn)題影響的風(fēng)險(xiǎn)承擔(dān)人問(wèn)題對(duì)風(fēng)險(xiǎn)承擔(dān)人和業(yè)務(wù)活動(dòng)的影響指出可能的解決方案及主要優(yōu)點(diǎn)2.1明確問(wèn)題

——二、判斷問(wèn)題的明確性問(wèn)題的明確性要求它們具備一下兩點(diǎn)：易于理解；P1.圖書(shū)管理員：圖書(shū)總是無(wú)法上架。P2.圖書(shū)管理員：圖書(shū)的內(nèi)容分類(lèi)不合適，無(wú)法分類(lèi)上架圖書(shū)上架的工作太繁雜，導(dǎo)致來(lái)不及上架。圖書(shū)的借閱不遵守章程，不能保證上架。能指明解決的方向P3.決策者：生產(chǎn)的廢品過(guò)多。

2.1明確問(wèn)題

——三、發(fā)現(xiàn)問(wèn)題背后的問(wèn)題對(duì)于不明確的問(wèn)題直接咨詢(xún)涉眾是第一選擇利用收集的資料和業(yè)務(wù)數(shù)據(jù)是第二選擇必要時(shí)需要使用一些簡(jiǎn)單的問(wèn)題分析技巧2.1明確問(wèn)題

——發(fā)現(xiàn)深層問(wèn)題的示例當(dāng)前問(wèn)題：產(chǎn)生了太多的廢品進(jìn)一步問(wèn)題：產(chǎn)生太多廢品的原因？用魚(yú)骨圖列出所有的可能原因請(qǐng)用戶(hù)確認(rèn)（通?？梢越鉀Q問(wèn)題）如果用戶(hù)無(wú)法確認(rèn)，則搜集數(shù)據(jù)進(jìn)行分析重新定義新的問(wèn)題（不準(zhǔn)確的銷(xiāo)售訂單）2.2發(fā)現(xiàn)業(yè)務(wù)需求每一個(gè)明確、一致的問(wèn)題都意味著涉眾存在一些相應(yīng)的期望目標(biāo)，即業(yè)務(wù)需求。P3.決策者：生產(chǎn)的廢品過(guò)多BR2：提供銷(xiāo)售訂單的準(zhǔn)確性，在系統(tǒng)使用后3個(gè)月內(nèi)，減少50%因此而產(chǎn)生的廢品。注意：業(yè)務(wù)目標(biāo)要具有第二章所述的各種優(yōu)秀特性，尤其是要有可驗(yàn)證性2.3定義解決方案及系統(tǒng)特性一、確定高層次的解決方案二、確定系統(tǒng)特性和解決方案的邊界三、確定解決方案的約束2.3定義解決方案及系統(tǒng)特性

——一、確定高層次的解決方案發(fā)現(xiàn)各種可行的高層次解決方案，分析不同方案的業(yè)務(wù)優(yōu)勢(shì)和代價(jià)，然后通過(guò)和涉眾的協(xié)商，選定其中一個(gè)要素內(nèi)容ID問(wèn)題標(biāo)識(shí)解決方案方案描述概要描述解決方案業(yè)務(wù)優(yōu)勢(shì)該解決方案所能帶來(lái)的業(yè)務(wù)優(yōu)勢(shì)代價(jià)該解決方案將花費(fèi)的代價(jià)2.3定義解決方案及系統(tǒng)特性

——確定解決方案示例背景：對(duì)一個(gè)設(shè)備制造商的IS系統(tǒng)升級(jí)問(wèn)題：改進(jìn)同經(jīng)銷(xiāo)商之間的通信涉眾：制造商、經(jīng)銷(xiāo)商開(kāi)發(fā)人員提出的解決方案：提供更好的財(cái)務(wù)報(bào)告、更好的發(fā)票和陳述的格式、在線(xiàn)的零件訂購(gòu)以及電子郵件最終希望能實(shí)現(xiàn)公司和經(jīng)銷(xiāo)商間的電子資金轉(zhuǎn)賬客戶(hù)討論修正后的方案：首要任務(wù)是提供電子資金轉(zhuǎn)賬最好能有電子郵件及其它的通信特性2.3定義解決方案及系統(tǒng)特性

——二、確定問(wèn)題解決邊界明確該解決方案需要具備的功能特征，即系統(tǒng)特性分析解決方案需要和周?chē)h(huán)境形成的交互作用，定義解決方案的邊界尤其是信息流的輸入/輸出關(guān)系它需要的信息由誰(shuí)提供？它產(chǎn)生的信息由誰(shuí)使用？誰(shuí)控制它的執(zhí)行？誰(shuí)會(huì)影響它的執(zhí)行？2.3定義解決方案及系統(tǒng)特性

——三、確定解決方案的約束約束源問(wèn)題示例經(jīng)濟(jì)的有哪些財(cái)政或者預(yù)算上的約束？有貨物成本和價(jià)格上的要求嗎？有任何法律許可問(wèn)題嗎？行政的有產(chǎn)生影響的內(nèi)部或外部政治問(wèn)題嗎？有什么需要部門(mén)間協(xié)調(diào)的問(wèn)題嗎？技術(shù)的在技術(shù)的選擇上有什么限制嗎？是否必須使用既有的平臺(tái)和技術(shù)進(jìn)行工作？對(duì)新技術(shù)的應(yīng)用會(huì)被禁止嗎？有可能使用COTS軟件包嗎？系統(tǒng)的要建立在現(xiàn)有系統(tǒng)基礎(chǔ)之上嗎？要維護(hù)和現(xiàn)有系統(tǒng)的兼容性嗎？環(huán)境的需要支持哪些操作系統(tǒng)和環(huán)境？有環(huán)境的約束嗎？其靈活度怎樣？符合法律法規(guī)嗎？有安全性需求嗎？可能會(huì)被哪些其他標(biāo)準(zhǔn)限制？進(jìn)度及資源的進(jìn)度要求如何？會(huì)被限制在已有資源上嗎？可以使用外部人力嗎？可以暫時(shí)或永久的擴(kuò)展資源嗎？2.3定義解決方案及系統(tǒng)特性

——三、確定解決方案約束示例對(duì)“新的銷(xiāo)售訂單系統(tǒng)”的約束約束源約束理由操作性系統(tǒng)技術(shù)要求設(shè)備預(yù)算銷(xiāo)售訂單數(shù)據(jù)的一份完全備份必須保存在已有數(shù)據(jù)庫(kù)中一年的時(shí)間應(yīng)用在服務(wù)器上占用的空間不應(yīng)該超過(guò)20M應(yīng)用新的面向?qū)ο蟮姆椒ā瓟?shù)據(jù)丟失的風(fēng)險(xiǎn)太大存儲(chǔ)空間有限該技術(shù)會(huì)增加可靠性…主要內(nèi)容確定項(xiàng)目前景和范圍的活動(dòng)問(wèn)題分析建立系統(tǒng)邊界項(xiàng)目前景和范圍文檔3.建立系統(tǒng)邊界隨著問(wèn)題數(shù)量的增加，系統(tǒng)的問(wèn)題解決方案的復(fù)雜性也會(huì)增加，這就需要講各個(gè)分散的問(wèn)題解決方案整合起來(lái)，建立解系統(tǒng)的整體解決方案可以從總體上來(lái)理解系統(tǒng)中的業(yè)務(wù)靜態(tài)結(jié)構(gòu)和動(dòng)態(tài)行為確保不同問(wèn)題的涉眾在系統(tǒng)總體上也能達(dá)成一致問(wèn)題分析僅僅是確保了涉眾在具體問(wèn)題上達(dá)成一致將所有問(wèn)題的解決方案進(jìn)行綜合，就可以得到整個(gè)解系統(tǒng)的功能和邊界系統(tǒng)邊界的常用技術(shù)描述手段是系統(tǒng)用例圖和上下文圖3.建立系統(tǒng)邊界

——系統(tǒng)用例圖示例3.建立系統(tǒng)邊界

——上下文圖示例圖5－5、自助餐廳訂餐系統(tǒng)上下文圖自助餐廳在線(xiàn)訂餐系統(tǒng)顧客工資系統(tǒng)菜單管理人送餐人員自助餐廳工作人員送餐請(qǐng)求從工資中扣除餐費(fèi)的請(qǐng)求付款要求菜單內(nèi)容送餐請(qǐng)求付款請(qǐng)求食物訂單菜單食物訂單食物訂購(gòu)信息注冊(cè)從工資中扣除餐費(fèi)自助餐廳庫(kù)存系統(tǒng)食物訂單可提供的食物信息從工資中扣除餐費(fèi)的響應(yīng)更新食物狀態(tài)主要內(nèi)容確定項(xiàng)目前景和范圍的活動(dòng)問(wèn)題分析建立系統(tǒng)邊界項(xiàng)目前景和范圍文檔4.前景和范圍文檔業(yè)務(wù)需求、高層次解決方案和系統(tǒng)特性都應(yīng)該被定義到項(xiàng)目前景與范圍文檔之中前景與范圍文檔主要由需求工程師來(lái)完成，但文檔的負(fù)責(zé)人一般是項(xiàng)目的投資負(fù)責(zé)人、執(zhí)行主管或其他類(lèi)似角色文檔中記錄的應(yīng)該是清晰、明確的業(yè)務(wù)需求、高層次解決方案和系統(tǒng)特性項(xiàng)目合約或抽象的業(yè)務(wù)用例文檔也可以實(shí)現(xiàn)類(lèi)似目的

4.前景和范圍文檔

——結(jié)構(gòu)實(shí)例分析（一戶(hù)式存儲(chǔ)軟件）問(wèn)題描述在軟件開(kāi)發(fā)期間造成很大的麻煩。由于時(shí)間比較緊張，并沒(méi)有仔細(xì)去明確業(yè)務(wù)需求結(jié)果在開(kāi)發(fā)過(guò)程中，技術(shù)人員與業(yè)務(wù)人員通過(guò)交流，發(fā)現(xiàn)很多問(wèn)題，這樣就不斷修改業(yè)務(wù)需求，再修改程序，浪費(fèi)了很多時(shí)間。特別是由于單位領(lǐng)導(dǎo)參與到這次需求之中，提出的需求有的不是很符合系統(tǒng)整體的功能，甚至是超出一戶(hù)式儲(chǔ)存軟件的范圍業(yè)務(wù)實(shí)例分析（一個(gè)管理信息系統(tǒng)）問(wèn)題在公司內(nèi)部，為確定項(xiàng)目的前景和范圍，一般通過(guò)用戶(hù)開(kāi)會(huì)，進(jìn)行摸底。由于公司的用戶(hù)一般都是非計(jì)算機(jī)專(zhuān)業(yè)出生，一般對(duì)于項(xiàng)目的前景和范圍，主要從實(shí)際工作出發(fā)，提出構(gòu)想和思路，但是有個(gè)明顯的問(wèn)題是，有些構(gòu)想太過(guò)理想化，有些思路又太過(guò)細(xì)節(jié)。解決問(wèn)題

業(yè)務(wù)需求用戶(hù)

問(wèn)題；開(kāi)發(fā)人員

方案；用戶(hù)

評(píng)價(jià)思考題你被任命為替換學(xué)生財(cái)務(wù)資助項(xiàng)目的項(xiàng)目經(jīng)理。你想開(kāi)發(fā)一個(gè)工作陳述來(lái)定義范圍并降低范圍蔓延的風(fēng)險(xiǎn)。財(cái)務(wù)資助部門(mén)的主管堅(jiān)持要你15個(gè)月、600000美元的預(yù)算內(nèi)替換他現(xiàn)有的系統(tǒng)就可以了。他說(shuō)這就是你需要知道的全部，不需要浪費(fèi)時(shí)間開(kāi)發(fā)一個(gè)工作陳述了。省略工作陳述的風(fēng)險(xiǎn)是什么？你將如何說(shuō)服主管？思考題一個(gè)需求工程師正在為一個(gè)信息系統(tǒng)考慮三個(gè)可選的解決方案，所有三個(gè)方案都滿(mǎn)足了用戶(hù)的業(yè)務(wù)需求。第一個(gè)方案被認(rèn)為與開(kāi)發(fā)人員的技術(shù)知識(shí)最一致，第二個(gè)方案被認(rèn)為是最快的實(shí)現(xiàn)方案，第三個(gè)方案是最劃算的方案。這三個(gè)方案中是否有一個(gè)可行方案？如果是這樣，你認(rèn)為需求工程師應(yīng)該如果做出最后決定？思考題某大銀行的一位銀行卡辦公室的收賬經(jīng)理Liz遇到了一個(gè)問(wèn)題。她每周都收到一份過(guò)期未付款的賬戶(hù)名單。這份報(bào)告已經(jīng)從兩年前的250個(gè)賬戶(hù)增加到現(xiàn)在的1250個(gè)賬戶(hù)。為了確定那些嚴(yán)重拖欠債務(wù)的賬戶(hù)，Liz需要通讀這份報(bào)告。嚴(yán)重拖欠債務(wù)的賬戶(hù)由幾個(gè)不同的規(guī)則確定，每個(gè)規(guī)則都要求Liz檢查客戶(hù)的一項(xiàng)或幾項(xiàng)數(shù)據(jù)。過(guò)去半天的工作量現(xiàn)在增加到了每周三天。即使在確定了嚴(yán)重拖欠債務(wù)的賬戶(hù)后，如果沒(méi)有查閱該賬戶(hù)三年內(nèi)的歷史資料，Liz也不能做出最后的信用決定（例如嚴(yán)厲的催款電話(huà)、斷絕信用或?qū)⑦@個(gè)賬戶(hù)轉(zhuǎn)給一個(gè)收賬代理）。另外，Liz需要報(bào)告所有賬戶(hù)中過(guò)期未付款的、拖欠債務(wù)的、嚴(yán)重拖欠債務(wù)的和呆死賬的比例。目前的報(bào)告中并沒(méi)有給她提供這個(gè)信息。假設(shè)現(xiàn)在需要你來(lái)開(kāi)發(fā)一個(gè)軟件，解決Liz面對(duì)的難題。那么你認(rèn)為L(zhǎng)iz現(xiàn)在遇到的問(wèn)題有哪些？你希望新的軟件應(yīng)該達(dá)成哪些業(yè)務(wù)目標(biāo)？你怎樣設(shè)計(jì)軟件的高層解決方案和系統(tǒng)特性？本章小結(jié)確定項(xiàng)目的前景和范圍是需求工程以及整個(gè)項(xiàng)目的重要工作，它決定著整個(gè)項(xiàng)目后繼工作的方向確定項(xiàng)目的前景和范圍要首先從分析問(wèn)題著手然后依據(jù)明確的問(wèn)題發(fā)現(xiàn)業(yè)務(wù)需求最后再為業(yè)務(wù)需求定義問(wèn)題的解決方案依據(jù)系統(tǒng)特性各個(gè)單獨(dú)問(wèn)題的解決方案整合起來(lái)，就是整個(gè)解系統(tǒng)的整體解決方案項(xiàng)目的前景和范圍需要以文檔的方式明確的固定下來(lái)

第6章.涉眾分析與硬數(shù)據(jù)采樣主要內(nèi)容涉眾分析的必要性涉眾分析的主要內(nèi)容涉眾分析過(guò)程硬數(shù)據(jù)采樣1.涉眾分析的必要性

——回顧：獲取的源頭兩種類(lèi)型人腦內(nèi)知識(shí)困難，有很多問(wèn)題如何尋找合適的人？如何有效的與他們進(jìn)行交流？…人腦外知識(shí)1.涉眾分析的必要性

——涉眾所有能夠影響軟件系統(tǒng)的實(shí)現(xiàn)，或者會(huì)被實(shí)現(xiàn)后的軟件系統(tǒng)所影響的個(gè)人和團(tuán)體。用戶(hù):最終使用和操作產(chǎn)品的人關(guān)注軟件功能客戶(hù):為軟件系統(tǒng)的開(kāi)發(fā)付費(fèi)的人關(guān)注經(jīng)濟(jì)上的成本、收益開(kāi)發(fā)者:負(fù)責(zé)實(shí)現(xiàn)軟件系統(tǒng)的人關(guān)注技術(shù)上的成本和收益1.涉眾分析的必要性

——涉眾所有能夠影響軟件系統(tǒng)的實(shí)現(xiàn)，或者會(huì)被實(shí)現(xiàn)后的軟件系統(tǒng)所影響的個(gè)人和團(tuán)體。管理者：參與軟件系統(tǒng)開(kāi)發(fā)事務(wù)管理的人投資方管理者、執(zhí)行負(fù)責(zé)人、項(xiàng)目管理者關(guān)注系統(tǒng)的開(kāi)發(fā)進(jìn)程領(lǐng)域?qū)＜?在問(wèn)題域中具有豐富知識(shí)的專(zhuān)家關(guān)注軟件中的知識(shí)政府力量:法律法規(guī)、長(zhǎng)遠(yuǎn)規(guī)劃、政策意向等起約束和指導(dǎo)作用市場(chǎng)力量：組織中的市場(chǎng)部門(mén)人員關(guān)注用戶(hù)的想法1.涉眾分析的必要性

——涉眾涉眾類(lèi)別需要細(xì)分每一類(lèi)涉眾的所有成員都能夠一致、穩(wěn)定的從相同立場(chǎng)、相同視角來(lái)看待相同的軟件系統(tǒng)發(fā)現(xiàn)比較關(guān)鍵的涉眾需要分析他們各自的贏利條件，以在相互妥協(xié)中盡力實(shí)現(xiàn)一個(gè)共贏的結(jié)局涉眾群體不是固定不變的對(duì)涉眾的理解不是一個(gè)完成之后就可以結(jié)束的活動(dòng)，而是應(yīng)該在完成之后繼續(xù)保持適當(dāng)?shù)年P(guān)注涉眾分析就是為軟件系統(tǒng)尋找并理解關(guān)鍵涉眾的過(guò)程主要內(nèi)容涉眾分析的必要性涉眾分析的主要內(nèi)容涉眾分析過(guò)程硬數(shù)據(jù)采樣2.涉眾分析的主要內(nèi)容

——涉眾分析/尋找涉眾信息系統(tǒng)的四種類(lèi)型小型系統(tǒng)（SmallSystem）小型系統(tǒng)是指那些能夠支持組織的部分工作，但又不會(huì)影響整個(gè)組織基礎(chǔ)工作的信息系統(tǒng)關(guān)注于某個(gè)特定問(wèn)題功能較為固定，界限較為清晰涉眾有限且明顯組織級(jí)系統(tǒng)（Organization-WideSystem）其功能能夠影響整個(gè)組織基礎(chǔ)工作的系統(tǒng)，它的功能在質(zhì)量上和小型系統(tǒng)有著明顯的差異。它可能會(huì)影響用戶(hù)群體之外的組織內(nèi)其他群體，甚至改變組織現(xiàn)存的權(quán)力結(jié)構(gòu)用戶(hù)不再有限和明顯，而且用戶(hù)之外的其他群體尤其不明顯發(fā)現(xiàn)直接和間接群體，防止抵制2.涉眾分析的主要內(nèi)容

——涉眾分析/尋找涉眾信息系統(tǒng)的四種類(lèi)型戰(zhàn)略信息系統(tǒng)（StrategicInformationSystem）作為組織戰(zhàn)略決策而得以開(kāi)發(fā)的系統(tǒng)無(wú)法根據(jù)現(xiàn)有的業(yè)務(wù)和技術(shù)狀況來(lái)確定系統(tǒng)將來(lái)的應(yīng)用效果系統(tǒng)的影響范圍也難以確定，涉眾數(shù)量更多而且更加難以確定在業(yè)務(wù)環(huán)境內(nèi)分析各種可能的機(jī)遇和風(fēng)險(xiǎn)，并據(jù)此發(fā)現(xiàn)可能的涉眾，防止抵制2.涉眾分析的主要內(nèi)容

——涉眾分析/尋找涉眾信息系統(tǒng)的四種類(lèi)型組織間系統(tǒng)（Inter-OrganizationalSystems）通過(guò)系統(tǒng)自身的實(shí)施建立或增強(qiáng)組織之間的合作關(guān)系系統(tǒng)的很多決定不是單個(gè)組織所能控制的在主動(dòng)參與和抵制系統(tǒng)的問(wèn)題上有著更多的困難涉眾比組織內(nèi)系統(tǒng)的涉眾更加難以尋找和選擇考慮組織之間的合作關(guān)系和利益分配方案，在組織的大框架下進(jìn)行涉眾的尋找和選擇2.涉眾分析的主要內(nèi)容

——涉眾分析/理解涉眾公共組織中干預(yù)措施的活動(dòng)分析2.涉眾分析的主要內(nèi)容

——涉眾分析/理解涉眾L1：根據(jù)軟件系統(tǒng)的功能前景尋找涉眾L2：從涉眾對(duì)象那里獲取需求L3:分析涉眾的輸贏條件,實(shí)施共贏策略L(fǎng)4:了解涉眾實(shí)現(xiàn)、監(jiān)控和評(píng)估軟件系統(tǒng)的能力，分析涉眾的力量和影響范圍；了解涉眾實(shí)現(xiàn)、監(jiān)控和評(píng)估軟件系統(tǒng)的意愿，即分析涉眾的關(guān)注點(diǎn)和興趣取向。L5:了解涉眾的個(gè)人特征和工作特征，以便在涉眾固定的情況下對(duì)軟件系統(tǒng)的功能進(jìn)行合理的調(diào)整。主要內(nèi)容涉眾分析的必要性涉眾分析的主要內(nèi)容涉眾分析過(guò)程總體過(guò)程識(shí)別描述評(píng)估選擇硬數(shù)據(jù)采樣3.1涉眾分析的過(guò)程尋找軟件系統(tǒng)的涉眾類(lèi)別，辨別關(guān)鍵的涉眾類(lèi)別；描述不同涉眾類(lèi)別的特征，包括個(gè)人特征、工作特征；分析不同涉眾類(lèi)別的輸贏條件和受影響程度；描述不同涉眾類(lèi)別的關(guān)注點(diǎn)和興趣取向；分析不同涉眾類(lèi)別的重要性和影響力；為每種涉眾類(lèi)別選擇合適的代表參與項(xiàng)目開(kāi)發(fā)。3.1涉眾分析的過(guò)程

——涉眾分析結(jié)果的應(yīng)用關(guān)鍵涉眾類(lèi)別的確定可以幫助判斷的和選擇需求獲取的對(duì)象；涉眾個(gè)人特征和工作特征的描述可以幫助更好的確定功能需求；涉眾的輸贏條件和受影響程度可以幫助解決涉眾之間的需求沖突；涉眾的重要性、影響力、關(guān)注點(diǎn)和興趣取向可以用來(lái)發(fā)現(xiàn)項(xiàng)目的潛在風(fēng)險(xiǎn)；所有的關(guān)于涉眾的信息描述可以幫助開(kāi)發(fā)者制定更好的項(xiàng)目策略，促進(jìn)項(xiàng)目參與者的交流和信任；涉眾分析確定的項(xiàng)目參與者將會(huì)共同決定項(xiàng)目中的重大變更（例如需求變化），最大程度保證項(xiàng)目的最終成功。3.2涉眾識(shí)別目的是尋找和發(fā)現(xiàn)各種涉眾類(lèi)別基本過(guò)程：從一些比較容易發(fā)現(xiàn)的涉眾出發(fā)，通常包括客戶(hù)、管理者和相關(guān)的投資者由初始涉眾集體討論，列出一個(gè)涉眾類(lèi)別列表對(duì)上一步產(chǎn)生的涉眾類(lèi)別列表進(jìn)行分析，縮減為一個(gè)關(guān)鍵涉眾類(lèi)別列表由上一步的各個(gè)關(guān)鍵涉眾類(lèi)別選擇代表，集中討論，列出新的涉眾類(lèi)別列表如果涉眾類(lèi)別列表趨于穩(wěn)定，就結(jié)束涉眾識(shí)別過(guò)程，否則轉(zhuǎn)向第2步3.2涉眾識(shí)別