需求工程復習2 - Copy_第1頁
需求工程復習2 - Copy_第2頁
需求工程復習2 - Copy_第3頁
需求工程復習2 - Copy_第4頁
需求工程復習2 - Copy_第5頁
已閱讀5頁,還剩40頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1、第二章復習題:IEEE是怎樣定義需求的?從中你可以得到什么認識?IEEE對需求的定義:(1)用戶為了解決問題或達到某些目標所需要的條件或能力;(2)系統(tǒng)或系統(tǒng)部件為了滿足合同、標準、規(guī)范或其它正式文檔所規(guī)定的要求而需要具備的條件或能力;(3)對(1)或(2)中的一個條件或一種能力的一種文檔化表述。為了融合不同群體的看法,IEEE的定義當中同時包括了用戶的觀點(第一種條件和能力)和開發(fā)者的觀點(第二種條件和能力),但是即便如此,不同群體的人們也很難就IEEE的定義進行一致和準確的解讀,因為需求概念的內(nèi)涵和外延都非常豐富。解釋下列名詞:問題域、解系統(tǒng)和共享現(xiàn)象,并結(jié)合它們的含義說明軟件系統(tǒng)是如何與

2、現(xiàn)實世界形成互動的?問題域:當現(xiàn)實的狀況與人們期望的狀況產(chǎn)生差距時,就產(chǎn)生了問題。要解決問題,就需要改變現(xiàn)實當中某些實體的狀態(tài)或改變實體狀態(tài)變化的演進順序,使其達到期望的狀態(tài)或演進順序。這些實體和狀態(tài)構(gòu)成了問題解決的基本范圍,稱為該問題的問題域(Problem Domain)解系統(tǒng):軟件系統(tǒng)通過影響問題域,能夠幫助人們解決問題,稱為解系統(tǒng)。共享現(xiàn)象: 軟件系統(tǒng)能夠與問題域進行交互和相互影響的原因在于,軟件系統(tǒng)中的某些部分對問題域中的某些部分的具有模擬特性。 換句話說,軟件系統(tǒng)當中含有問題域某些部分的模型(或模擬),常見的模型包括數(shù)據(jù)模型、對象模型、處理模型等。 問題域中的某些信息能夠和模型中的

3、信息建立映射關(guān)系這些通過映射建立的共同知識,就是問題域和解系統(tǒng)之間的共享現(xiàn)象共享現(xiàn)象就是問題域和解系統(tǒng)實現(xiàn)交互和互相影響的途徑與接口,問題域和解系統(tǒng)都通過改變這些共同知識來影響對方,或者通過認同這些共同知識的改變來接受對方的影響。解釋下列名詞:需求、規(guī)格說明、問題域特性和約束,并結(jié)合它們的含義說明需求工程的主要任務(wù)是什么?需求:用戶對問題域當中的實體狀態(tài)或事件的期望描述。直接需求是可以通過更改共享現(xiàn)象被滿足的需求; 間接需求是需要修改共享現(xiàn)象,同時連鎖影響問題域才能滿足的需求。規(guī)格說明:解系統(tǒng)為滿足用戶需求而提供的解決方案,規(guī)定了解系統(tǒng)的行為特征。規(guī)格說明主要包括兩個部分:(1)對共享現(xiàn)象(模

4、型)的描述;(2)系統(tǒng)對共享現(xiàn)象所施加的操作的描述。需求關(guān)注的是現(xiàn)實世界中的部分,軟件關(guān)注的是解系統(tǒng),而規(guī)格說明關(guān)注的是共享現(xiàn)象問題域特性:問題域自治的規(guī)律性稱為問題域特性,包括結(jié)構(gòu)特性和行為特性等。約束和假設(shè):(依賴特性: 問題域共享現(xiàn)象、解系統(tǒng);問題域共享現(xiàn)象、解系統(tǒng))依賴特性明確:約束;依賴特性不明確:假設(shè)(問題域當中有些特性完全不受共享現(xiàn)象的影響,即完全不受解系統(tǒng)的影響,同時卻可能很大程度上影響共享現(xiàn)象,影響解系統(tǒng),甚至關(guān)乎解系統(tǒng)的成敗。這些特性被認為是解系統(tǒng)對環(huán)境的依賴特性。當這些特性非常明確時,稱之為約束;不明確時,需要限定特性的變化范圍,稱之為假設(shè))需求主要任務(wù):需求開發(fā),明確需

5、求研究問題背景,描述問題域特性構(gòu)建解系統(tǒng),描述解系統(tǒng)行為需求有哪些常見的類別?功能需求和非功能需求有什么差異?需求的分類1:功能需求(Functional Requirement):性能需求(Performance Requirement):質(zhì)量屬性(Quality Attribute):對外接口(External Interface):約束 需求的分類2:系統(tǒng)需求(System):硬件需求(Hardware)、軟件需求(Software)、其他需求項目需求過程需求 除功能需求之外的其他四種類別需求又被統(tǒng)稱為非功能需求。在非功能需求當中,質(zhì)量屬性對系統(tǒng)成敗的影響極大,因此在某些情況下,非功能需

6、求又被用來特指質(zhì)量屬性。描述業(yè)務(wù)需求、用戶需求和系統(tǒng)(級)需求的區(qū)別與聯(lián)系。功能需求包括:業(yè)務(wù)需求、用戶需求、系統(tǒng)級需求業(yè)務(wù)需求: 系統(tǒng)建立的戰(zhàn)略出發(fā)點,表現(xiàn)為高層次的目標,它描述了組織為什么要開發(fā)系統(tǒng) 。用戶需求: 執(zhí)行實際工作的用戶對系統(tǒng)所能完成的具體任務(wù)的期望描述了系統(tǒng)能夠助用戶做些什么。 系統(tǒng)需求: 用戶對系統(tǒng)行為的期望,一系列的系統(tǒng)行為聯(lián)系在一起可以幫助用戶完成任務(wù),滿足業(yè)務(wù)需求;系統(tǒng)需求可以直接映射為系統(tǒng)行為,定義了系統(tǒng)中需要實現(xiàn)的功能,描述了開發(fā)人員需要實現(xiàn)什么。業(yè)務(wù)需求業(yè)務(wù)需求指導需求獲取用戶需求轉(zhuǎn)化用戶需求為系統(tǒng)需求系統(tǒng)需求優(yōu)秀的需求哪些特性?試為每一個特性都舉出一個不符合的

7、示例。優(yōu)秀的需求特性:完整性:不需要做更多的擴展就可以充分的說明用戶所需要的系統(tǒng)功能。每一個需求的描述都應(yīng)該包含開發(fā)人員設(shè)計和實現(xiàn)這項功能需要的所有信息(不完整):系統(tǒng)應(yīng)該允許被擴展正確性:真實的反映用戶的意圖;必須請需求的提出者予以確認精確性:描述僅包含必要的信息;簡潔、清晰R8(不精確):在實現(xiàn)之后,系統(tǒng)的調(diào)度算法應(yīng)該允許被擴展??尚行裕河砷_發(fā)人員進行檢查需要進行一定的分析和研究,而不是單純的憑借經(jīng)驗和直覺 必要的時候要通過開發(fā)原型來加以驗證示例:保證系統(tǒng)核心功能可以724小時連續(xù)運行必要性:滿足用戶的業(yè)務(wù)需求所必需的無歧義:每一項需求都應(yīng)該有而且只能有一種解釋 定義一個可以共同理解的詞匯

8、表(Glossary)可驗證:通過分析、檢查、模擬或者測試等方法能夠判斷需求是否被滿足示例:實現(xiàn)工作流程合理化、高效化,決策支持科學化、準確化;案例題:解答一:(1)她沒有仔細認真地分析問題; (2)她沒有及時跟相關(guān)人員交流信息,沒能把握住有價值信息; (3)她沒能及時跟公司員工交流,引用過時的文件結(jié)構(gòu); (4)她沒有仔細研究分析新引進的系統(tǒng)的性能需求是否滿足; (5)她沒有仔細研究新引進的系統(tǒng)的功能需求是否滿足; (6)她沒有仔細研究引進的系統(tǒng)的質(zhì)量屬性,對外接口是否滿足。解答二:業(yè)務(wù)需求中沒有和高層管理人員溝通好;她提出的用戶需求沒有和用戶(自己的職員)溝通好,也沒有向開發(fā)人員提出可行性、

9、質(zhì)量屬性(可擴展性)等。解答三:沒有獲得高層支持;財政部支持;下屬抵制使用;信息不流通,文件使用不一致;要求的圖形報告沒有;不知道是否能修改業(yè)務(wù)需求:保持財務(wù)業(yè)績與它的發(fā)展同步;有效地追蹤客戶賬單和收據(jù);降低成本;實行特價時能夠知道是否有利可圖,是否帶動去他的銷售;增加回頭客。解答:業(yè)務(wù)需求如BR。BR1:實現(xiàn)客戶賬單和收據(jù)的有效追蹤;BR2:實現(xiàn)產(chǎn)品特價時的利潤和相關(guān)銷售情況檢查;BR3:實現(xiàn)一個客戶數(shù)據(jù)庫。先定義明確的業(yè)務(wù)需求,獲得開發(fā)系統(tǒng)的必要性,根據(jù)業(yè)務(wù)需求,協(xié)調(diào)涉眾的立場,限定問題的范圍,指導用戶需求的獲取過程:和涉眾溝通(即向業(yè)務(wù)人員了解相關(guān)的業(yè)務(wù)知識,業(yè)務(wù)流程;再和銷售人員溝通,

10、由于他們的顧客是流動的,不確定的,只能通過銷售人員間接獲取來自于顧客的用戶需求,了解他們的背景和習慣),最后根據(jù)業(yè)務(wù)需求對用戶需求進行過濾和選擇,得到充分必要用戶需求。UR1:使用戶可以根據(jù)系統(tǒng)的明確操作提示做出正確的反應(yīng);UR2:用戶插入銀行卡后需要輸入密碼,得到驗證后才可進行有效的具體操作;UR3:在用戶進入系統(tǒng)后,可以選擇使用查詢金額、存取現(xiàn)金、轉(zhuǎn)賬的功能;UR4:用戶能夠正確、安全地退出系統(tǒng)。SR1:(1) 系統(tǒng)顯示用戶插入磁卡的動態(tài)圖像,正確標明插卡位置;(2)用戶根據(jù)提示,正確插入磁卡;(3)系統(tǒng)讀取磁卡卡號,界面顯示輸入密碼的提示; SR2:(1)對用戶輸入的密碼,系統(tǒng)自動進行字

11、符匹配; (2)匹配正確的話,進入具體操作界面; (3)匹配不正確的話,警告密碼不正確,并提示再次輸入; SR3:(1)若用戶選擇查詢金額圖標和查詢金額幣種,系統(tǒng)讀取銀行數(shù)據(jù)庫中用戶對應(yīng)的信息,反饋在用戶界面上; (2)若用戶選擇取款圖標和金額幣種及輸入金額數(shù)目,系統(tǒng)讀取用戶請求,接受金額,修改數(shù)據(jù)庫中該用戶對應(yīng)的信息,并提示成功與否; (3)若用戶選擇存款圖標和金額幣種,系統(tǒng)彈出存款框,用戶放入現(xiàn)金,系統(tǒng)接收現(xiàn)金并辨認真?zhèn)?,并反饋存入金額數(shù)目,得到用戶確認后,修改數(shù)據(jù)庫中該用戶對應(yīng)的信息,并提示成功與否; (4)若用戶選擇轉(zhuǎn)賬圖標和金額幣種并輸入對方賬號和轉(zhuǎn)賬金額數(shù)目,系統(tǒng)讀取用戶請求,修改

12、數(shù)據(jù)庫中所涉及到的用戶的信息,并提示成功與否; SR4:(1)用戶選擇退出圖標; (2)系統(tǒng)提示拔卡信息。性能需求:在用戶點擊圖標后,系統(tǒng)在3s內(nèi)作出反應(yīng)。質(zhì)量屬性:易用、可靠、安全、容錯、可恢復、可維護。約束:當用戶輸入密碼次數(shù)等于3次后就不再提示輸入密碼,并自動鎖定銀行卡。第三章思考題:除了需求開發(fā)的四個活動和需求管理活動之外,需求工程中還有沒有需要執(zhí)行的活動?如果有的話,它們是哪些活動?給出你的理由。四個活動包括:需求獲取、需求分析、需求規(guī)格說明、需求驗證有。項目管理(人力、資金的管理)、過程管理(還有其他一些活動,例如:過程管理活動和項目管理活動。過程管理活動是跟蹤項目開發(fā)過程,記錄項

13、目開發(fā)過程當中所遇到的問題或者教訓等等。項目管理活動是管理項目開發(fā)的一系列問題與進度,管理人員配置,以求達到最大效益。)需求開發(fā)過程具有迭代特性,但是不是所有項目的需求開發(fā)過程都必須是迭代完成的?如果不是,試給出舉例和理由。 不是,在問題域很簡單或者非常成熟的情況下不需要迭代完成。(不是,一般對于業(yè)務(wù)領(lǐng)域不熟悉的項目,需求是具有迭代性的,需要對業(yè)務(wù)領(lǐng)域的認知,有一個從認識到知識重構(gòu)的過程。對于某些固定需求且熟悉的項目,比如學校課程的作業(yè)、軟件工程實踐、電梯系統(tǒng),就不需要迭代開發(fā))(需求獲取需求分析需求規(guī)格說明需求驗證。當然并不是所有項目的需求開發(fā)過程是迭代完成的,比如:當某一項目開發(fā)過程中,用

14、戶需求非常簡單,開發(fā)人員已經(jīng)相當明確用戶需求,這時,就不需要返回到需求獲取階段以繼續(xù)用戶需求的獲取,這樣,也就不需要迭代完成。當然,這種情況非常少見。)需求開發(fā)的迭代特性與軟件開發(fā)過程的迭代式開發(fā)有什么關(guān)系?它們之間會相互影響嗎?如果會,那么有哪些影響?需求開發(fā)的迭代性指的是對于開發(fā)者對知識的認知水平在某一點上,發(fā)生重構(gòu),使得知識體系復雜性下降,而繼續(xù)積累知識的過程。軟件開發(fā)的迭代性指的是在軟件生命周期整體開發(fā)迭代,針對變更的需求或者新增的需求一種減少風險的開發(fā)模式。需求開發(fā)迭代不會導致軟件開發(fā)過程的迭代,但有時會有影響。(需求開發(fā)的迭代特性只是軟件開發(fā)過程的迭代式開發(fā)的一個子過程,軟件開發(fā)過

15、程是一個相當龐大的工程,需要在軟件開發(fā)過程的各個階段都需要進行開發(fā)工作的迭代,當然也包括需求開發(fā)中的迭代。它們之間互相影響。如果需求開發(fā)中的迭代不能很好地完成需求分析任務(wù),就必將影響到軟件開發(fā)過程的其他迭代階段的進行。)4. 需求工程細節(jié)知識的實踐性對不同項目的需求開發(fā)過程的差異性有沒有影響?如果有,說明影響是什么,如果沒有,說明是哪些因素產(chǎn)生了不同項目的需求開發(fā)過程的差異性。沒有影響。其實是需求開發(fā)過程的差異性一定程度上導致了細節(jié)知識的實踐性。現(xiàn)實世界問題的復雜性和差異性主要導致了需求開發(fā)過程的差異性第四章復習題:3.在各種關(guān)于軟件的調(diào)研中,無一例外地發(fā)現(xiàn)“缺乏用戶參與”是導致軟件失敗的最大

16、原因,試說明有哪些原因會使得用戶參與不足?應(yīng)該怎樣解決?原因:1未有效得選擇參與項目的用戶2認識不足3用戶抵制4沒有明確的用戶5管理上的障礙解決方案:1.依據(jù)“個人領(lǐng)域知識”來選擇參與項目的用戶2.重視用戶參與需求工程的重要性3.在項目開始之初就在開發(fā)者和用戶之間建立一致和默契的工作氛圍4.有效利用用戶的替代源5.讓用戶擁有一定的權(quán)威影響力,才能較好地保證他們能夠本職工作中為軟件活動抽出足夠的時間。第五章復習題:3.要完整地描述系統(tǒng)的高層解決方案,需要描述哪些方面?概要描述解決方案、該解決方案能帶來的業(yè)務(wù)優(yōu)勢,該解決方案將花費的代價,系統(tǒng)特性和解決方案的邊界,解決方案的約束。案例題:不做工作陳

17、述的風險:在獲取需求時,用戶往往從各自的立場出發(fā)考慮問題,提出相應(yīng)的功能需求。如果沒有工作陳述,用戶就不會從共同的方向上考慮和理解問題,對系統(tǒng)的期望也就產(chǎn)生了較大的差距。沒有工作陳述,就等于在用戶之間發(fā)生需求沖突時,就沒有可以用來指導并且調(diào)節(jié)協(xié)商的項目前景,沖突問題也就很難解決。風險:1需求理解錯誤2不能按時完成(超期超資)3做出來的不是想要的定義范圍的必要性:1.加強用戶和開發(fā)人員的理解,定義一致的理解2.降低風險解答二:省略工作陳述的風險是不能明確項目的前景和范圍。如果省略了工作陳述的話,你就不能和用戶進行很好的溝通與交流,這樣,項目的問題也就不能明確,即,開發(fā)人員無法與涉眾對問題達成共識

18、;無法明確問題,也就無法發(fā)現(xiàn)正確的業(yè)務(wù)需求,無法定義良好的解決方案及系統(tǒng)特性,繼而無法明確項目的前景和范圍,這樣就會造成項目的不穩(wěn)定甚至失?。?. 問題業(yè)務(wù)目標(業(yè)務(wù)需求)高層解決方案系統(tǒng)特性帳戶太多,工作量太大減少檢查人員的工作量降低檢查人員工作復雜度減少檢察人員50%的工作量實現(xiàn)一個數(shù)據(jù)庫子系統(tǒng),管理賬戶,實現(xiàn)一個數(shù)據(jù)處理系統(tǒng),數(shù)據(jù)庫系統(tǒng)和數(shù)據(jù)管理系統(tǒng)協(xié)調(diào)統(tǒng)一管理。所有賬戶信息貯存在數(shù)據(jù)庫子系統(tǒng)中數(shù)據(jù)管理系統(tǒng)通過查詢和修改數(shù)據(jù)庫中數(shù)據(jù)達到管理賬戶的目的檢查人員通過運行數(shù)據(jù)管理系統(tǒng)能夠簡單方便的管理賬戶需查閱賬戶的大量歷史數(shù)據(jù)能夠給出一個問題賬戶的三年內(nèi)的歷史數(shù)據(jù)數(shù)據(jù)庫子系統(tǒng)中儲存各個賬戶對

19、應(yīng)的歷史數(shù)據(jù)檢察人員按賬戶號查詢該賬戶三年歷史數(shù)據(jù)數(shù)據(jù)庫系統(tǒng)能快速的顯示賬戶歷史數(shù)據(jù)問題賬戶所占比例沒有顯示能夠分析篩選出問題賬戶,并給出問題賬號所占比例實現(xiàn)一個查找計算系統(tǒng),能夠即時顯示問題賬戶所占比例系統(tǒng)能夠查找數(shù)據(jù)庫中各個賬戶的信息,查找出問題賬戶。通過簡單的數(shù)字處理,即時顯示出問題賬戶比例4.解答:她現(xiàn)在遇到的問題有:問題業(yè)務(wù)目標(=業(yè)務(wù)需求?)要注意描述需求特征:可行性,可驗證性等高層解決方案不能有效地從信息部門獲得工資和個人數(shù)據(jù)減少從信息部門獲得工資和個人數(shù)據(jù)的時間;度量標準(Scale):一次從信息部門獲得工資和個人數(shù)據(jù)的時間;計量方法(Meter):檢查信息部門數(shù)據(jù)庫日志;理想

20、標準:減少50%;一般標準:減少30%;最低標準:減少20%;實現(xiàn)一個數(shù)據(jù)庫子系統(tǒng),統(tǒng)一儲存和管理員工工資和個人信息系統(tǒng)特性:由軟件從信息部門的數(shù)據(jù)庫中檢索出工資和個人數(shù)據(jù),成對的顯示出來工作人員通過個人編號查找個人數(shù)據(jù)與工資數(shù)據(jù)雇員數(shù)據(jù)太過分散,而且不能及時正確地更新集中雇員數(shù)據(jù),并且正確更新錯誤率小于等于每一千份錯誤2份實現(xiàn)一個數(shù)據(jù)搜集與驗證子系統(tǒng),即時查找到特定數(shù)據(jù)并集中處理。系統(tǒng)特性:子系統(tǒng)搜集、驗證雇員數(shù)據(jù)。子系統(tǒng)能將驗證通過的數(shù)據(jù)自動存儲在數(shù)據(jù)庫子系統(tǒng)中。對于沒有驗證通過的數(shù)據(jù)提交給管理員處理管理員可以處理不合格數(shù)據(jù),并能方便的添加到數(shù)據(jù)庫子系統(tǒng)中計算復雜通過系統(tǒng)處理數(shù)據(jù),避免人工

21、計算。90%的計算步驟通過軟件系統(tǒng)實現(xiàn)實現(xiàn)一個數(shù)據(jù)處理子系統(tǒng),處理各種計算問題,簡化計算復雜度。系統(tǒng)特性:子系統(tǒng)高效的處理數(shù)據(jù),實現(xiàn)多種功能的數(shù)據(jù)處理方式管理員通過可根據(jù)任務(wù)要求系統(tǒng)以不同方式處理數(shù)據(jù),高效快速地獲取計算結(jié)果,避免人工計算數(shù)據(jù)安全性受到質(zhì)疑及時更新用戶信息,確保用戶信息不會顯示給無關(guān)人員用戶信息更新頻率高于2天一次建立一個檢查和更新數(shù)據(jù)子系統(tǒng)。系統(tǒng)特性:系統(tǒng)定時高頻率地更新數(shù)據(jù)。再向其他人員和機構(gòu)展示用戶信息前,系統(tǒng)先進行數(shù)據(jù)檢查和更新工作。計算中可變條件的復雜性導致經(jīng)常出錯增強對錯誤的檢查力度,能夠及時找到錯誤并修改。90%的錯誤能在出現(xiàn)2小時內(nèi)檢測出來。實現(xiàn)一個檢查子系統(tǒng),

22、檢查和糾正計算錯誤系統(tǒng)特性:在計算結(jié)果存入數(shù)據(jù)庫子系統(tǒng)之前對數(shù)據(jù)的有效性和正確性進行驗證和檢查系統(tǒng)能對錯誤結(jié)果進行自動修復,對于不能修復的數(shù)據(jù)交由管理員手動處理。重要的約束有: 約束源 約束操作性雇員信息必須有備份數(shù)據(jù)庫管理系統(tǒng)統(tǒng)一使用Oracle數(shù)據(jù)庫管理系統(tǒng)操作系統(tǒng)系統(tǒng)運行在Windows XP 操作系統(tǒng)上法律法規(guī)系統(tǒng)遵循相關(guān)的法律法規(guī)。運行環(huán)境系統(tǒng)運行在安全穩(wěn)定的環(huán)境下第六章思考題:1.涉眾分析可以從哪些方面實現(xiàn)“用戶為中心”和“重視用戶價值”?用戶是最終使用和操作產(chǎn)品的人,他們是使用軟件的目的是為了更好的完成自己的任務(wù),滿足組織的目標要求。因此,一個成功的軟件要能夠協(xié)助用戶有效的完成實

23、際工作,用戶也就自然應(yīng)該是需求獲取的主要信息來源。需求工程師需要了解用戶實際工作的開展狀況和用戶希望軟件系統(tǒng)能夠給予他們的幫助。用戶參與是以用戶為中心的設(shè)計方法的核心思想,它要求開發(fā)者建立和用戶的直接聯(lián)系,盡早地關(guān)注與用戶和用戶的執(zhí)行過程,通過及時獲得用戶的反饋來調(diào)整軟件設(shè)計,以完成高質(zhì)量的設(shè)計。另一方面,用戶參與就是反對通過和市場人員、管理者等中間媒介來了解用戶。在以用戶為中心的設(shè)計方法中,用戶需要參與軟件開發(fā)的全過程,并且對最終軟件設(shè)計和質(zhì)量具有非常重要的影響,所以在該方法中參與用戶的選擇和普通的涉眾代表采樣有所不同,要吧他們區(qū)分開來。2.哪些手段可以建立和用戶的良好合作關(guān)系分析涉眾的輸贏

24、條件,實施共贏策略分析涉眾的關(guān)注點和興趣取向了解涉眾的個人特征和工作特征,合理調(diào)整系統(tǒng)功能讓涉眾代表在合適的時間參與合適的工作改善會議條件,避免用戶消極參與案例題:4.涉眾分析包括:涉眾識別、描述涉眾特征、涉眾評估以及選擇涉眾代表。Jeannine并沒有進行涉眾分析,就擅自做出了決定。她應(yīng)該先對涉眾進行分析。分析涉眾的種類,對每種涉眾的特征(個人特征、工作特征、地理和社會特征)進行描述,評估涉眾的優(yōu)先級,以及風險評估,進一步作出共贏分析。對每種涉眾進行代表采樣。根本沒有尋找涉眾,沒有涉眾分析,使用的是組織級的系統(tǒng),應(yīng)該進行涉眾分析。5.見6.3.2例:個人特征:年齡:老年人 字大工作特征:電腦

25、使用程度地理和社會特征:文化背景:中國和臺灣關(guān)注點和興趣:反對還是贊同目標期望:領(lǐng)導的目標被影響程度:使用頻率力量程度:是否可以影響項目實施,領(lǐng)導對個人特征和工作特征的描述可以幫助更好地確定功能需求;也可以幫助形成對涉眾類別的理解6.解答:(1)選擇面談對象的時候采用隨機抽樣,從5個階層以及生產(chǎn)、會計、營銷、系統(tǒng)、物流各選擇2-3名客戶參與面談。高層管理均要參加面談。因為在選擇面談的時候要力爭均衡的收集用戶的需求,因此要涉及各方面受系統(tǒng)影響的人。采樣的規(guī)則:控制人數(shù)(48),教材上冊,6.3.4(2)高層管理的人最先面談。然后是系統(tǒng)層。其余層的面談對象根據(jù)實際情況可以先后安排面談的時間,不一定

26、要分先后順序。跟高層管理人員進行面談,采用漏斗結(jié)構(gòu),因為各個高層管理人員對各自管理的層次從大體上有準確的把握,有助于開發(fā)人員首先獲取對項目的廣度方面的認識,也能獲取一些較為詳細的信息。跟具體部門人員進行面談,采用菱形(必要時,金字塔)結(jié)構(gòu),因為這種面談較為具體,問題常為封閉式問題,這樣有助于分析人員獲得深度認識。基本規(guī)則:(1)先業(yè)務(wù)需求,后用戶需求,所以先領(lǐng)導后普通; (2)開始漏斗,領(lǐng)導漏斗 (3)普通用戶菱形,必要時金字塔面談的結(jié)構(gòu)及其特點:教材上冊,7.2.27解答:定量硬數(shù)據(jù):發(fā)貨及收貨的明細表貨物的中轉(zhuǎn)表拖拉機和倉庫的使用情況表定性硬數(shù)據(jù):日常業(yè)務(wù)描述文檔描述發(fā)貨人、收貨人和承運公

27、司的伙伴關(guān)系文檔參考硬數(shù)據(jù)的類型:教材上冊,6.5(2)將這15年公司的情況用圖表表達出來,形成對15年以來公司狀況的認識,獲取生產(chǎn)情況的時候?qū)⒋笾孪嗤哪攴萘谐鰜?,采樣時候只需要在大致相同的年份中抽取一份作為樣本。參考采樣規(guī)則:教材上冊,6.6第7章 需求獲取方法之面談在重新瀏覽面談日程的時候,你發(fā)現(xiàn)有幾個問題看上去不合適。下面是準備問Sampson紙產(chǎn)品公司銷售經(jīng)理的原問題。這家公司想把它的一些銷售信息放到Web上去,以便經(jīng)理們可以交互地評論它,從而優(yōu)化他們的銷售方案。用更合適的方式,重新寫下面的問題。(有錯誤問題:同時問兩個問題;隱含和暗示;提問題時上下文相關(guān);問的問題牽扯到了被問的對象

28、,如最后一題的陳舊)你的下屬告訴我,你非常渴望有一臺計算機。這是真的么?你對計算機的使用態(tài)度如何?你認為作為一個銷售經(jīng)理,是不是應(yīng)該擁有一臺計算機?(誘導性問題)我是這個領(lǐng)域的新手,我有沒有忽略什么呢?我問的問題如何,你有什么要補充的么?我是不是還忽略了什么?(上下文無關(guān)問題)你在銷售計算中最常用的信息資源是什么,使用頻度如何? 將兩個問題分開1、你在銷售計算中最常用的信息資源是什么(雙筒問題)2、使用頻度如何?其它銷售經(jīng)理認為,把一些月度銷售商品放到Web上,然后做趨勢分析,將會是一種主要改進,你同意他們的做法嗎?你和其他經(jīng)理一樣,都同意。,是嗎? 你認為把一些月度銷售商品放到Web上,然后

29、做趨勢分析會是一種改進嗎?(誘導性問題)沒有比你現(xiàn)在使用的陳舊的方法更好的銷售方案嗎?對于現(xiàn)在的銷售方法,你有什么更好的改進方法么?還有比目前方法更好的銷售方案嗎?(上下文無關(guān)問題)作為系統(tǒng)分析項目的一部分,需要為生產(chǎn)數(shù)字鐘的Chronos公司更新自動化會計功能。你將要同首席會計Harry Straiter面談。寫出4到6個涉及他所使用的信息資源、信息格式、決策頻度、需求的信息性質(zhì)和決策樣式的面談目標。說明你將如何聯(lián)系Harry以安排一次面談。(打電話,預約:聯(lián)系個人,安排一次會見,內(nèi)容,選個時間,讓他找個時間,安排個地點)提前打電話或者發(fā)送電子郵件通知Harry,告知面談內(nèi)容,商定面談時間和

30、地點;提前通知可以給Harry時間去考慮面談事宜。如果要進行一次深入的面談,可以把問題通過電子郵件提前發(fā)給Harry,讓他有時間仔細考慮答復。(P120)說明在這場面談中你會使用哪種面談結(jié)構(gòu)?為什么?(首席會計師,leader,專家型的人面談結(jié)構(gòu)同普通用戶不同)漏斗結(jié)構(gòu),適合領(lǐng)導專家(根據(jù)上課筆記)Harry有3個下屬也使用這個系統(tǒng)。你和他們面談嗎?為什么?(涉眾分析中不同涉眾有不同特點,下屬和他之間有沒有差異,有差異則要;沒差異,則為什么)應(yīng)當面談,因為Harry和其下屬對軟件系統(tǒng)的開發(fā)和應(yīng)用具有的發(fā)言權(quán)和決定權(quán)不同,屬于不同的涉眾類別。Harry屬于領(lǐng)域?qū)<?,而其下屬屬于該系統(tǒng)的用戶,下屬

31、和領(lǐng)導使用這個系統(tǒng)的目標不同,下屬是為了更好的完成自己的任務(wù),滿足組織的目標,他們是主要的信息來源,所以應(yīng)當面談。應(yīng)當面談,因為下屬和領(lǐng)導應(yīng)該具有不同的目標,而這些目標是領(lǐng)導不能提供的考察點:涉眾的分類寫出3個開放式問題,在面談前通過電子郵件寄給Harry。用一句話解釋為什么應(yīng)當由人而不是由電子郵件來指導面談?獲取許多語言文字之外的其它信息,如聲音動作語氣等(三個開放式問題隨便寫,紙面記錄和其他幾種記錄方式的優(yōu)缺點,人的信息傳達有幾個方面,每個方面各占多少。只靠郵件就只剩文字了,交流中只剩文字的手段了,會產(chǎn)生什么缺點)(好像很多不知怎么一句話概括)由于面談中可能會實現(xiàn)很多目標,涉及很多復雜問題

32、,所以面談一般應(yīng)該由人而不是電子郵件來來管理(P120)。筆錄的優(yōu)點有:使會見者專心和集中精力;幫助回憶重要的問題;表現(xiàn)會見者對面談的興趣;表明會見者是有準備的。雖然筆錄有一些好的優(yōu)點,但也有一些缺點:丟失很多被會見者在談話中表現(xiàn)出來的語調(diào)、停頓等語音信息;做筆記時,會讓被會見者說話猶豫;造成對事實注意過多,而對感覺及觀點注意過少。 錄音和攝像的優(yōu)點有:記錄了更多的信息;會見者能輕松地傾聽并更快速地做出響應(yīng);可以完整的重現(xiàn)面談過程。錄音和攝像也有很多的缺點:被會見者可能會緊張,回答不自在;數(shù)據(jù)采集的代價較高;事后進行信息尋找時難以定位。 對第6章的案例題6,說明Phil應(yīng)該怎樣開展他的面談工作

33、?包括:面談對象選擇的先后順序,每次的面談結(jié)構(gòu)。說明原因。(列了需求的計劃打算安排幾輪面談,每次的參與人員每次面談結(jié)構(gòu),可能的話可以安排第三個輪次的面談,分析原因第一個輪次獲得前景和范圍第二個輪次詳細第三個輪次驗證需求)進行三輪面談,具體安排如下:第一輪面談:面談對象:高層管理員面談結(jié)構(gòu):漏斗式結(jié)構(gòu)因為第一輪面談主要是為了獲得項目的前景和范圍,通過探討一些高層次的問題來和項目目標推導出業(yè)務(wù)需求,并根據(jù)問題幫助確定系統(tǒng)高層次的解決方案和系統(tǒng)特性,從而到了項目的前景和范圍文檔。而這種問題的討論需要高層的管理員和對整個業(yè)務(wù)了解的人,所以第一輪的面談對象是高層管理員。根據(jù)面談結(jié)構(gòu)的特性,漏斗式的面談結(jié)

34、構(gòu)適合于領(lǐng)導和專家這樣的被會見對象,所以選擇漏斗式結(jié)構(gòu)。第二輪面談:面談對象:管理層以下的員工面談結(jié)構(gòu):菱形式結(jié)構(gòu)?第二輪面談的目標是為了獲取詳細的需求。詳細的需求涉及系統(tǒng)的各個層次,而各個層的工作目標和工作特性各不相同,所以需要要各個層次的工作人員進行面談。第三輪面談:面談對象:各個層次的職員面談結(jié)構(gòu):長序列的封閉式問題?第三輪面談的目標是為了驗證已獲取的需求。分析匯總了獲取的需求后,將獲得的需求分類羅列后,根據(jù)具體不同的需求需要向各個層面的涉眾確認驗證已經(jīng)獲取的需求,保證需求的正確性,完整性,一致性。由于需求已經(jīng)基本確定,所以采取封閉式問題。下面是系統(tǒng)分析團隊的一名成員提出的第一份面談報告

35、:“在我看來,面談進行的很好。我和他就這個問題聊了一個半小時。他告訴我有關(guān)公司的所有歷史,很有意思。他也提到,自他來到該公司的16年間,公司沒有任何變化。我們不久將再次舉行會面,以及結(jié)束這次面談,因為我們還沒有深入研究我準備的問題?!痹囋u論這個面談報告。假設(shè)你要團隊成員使用圖1提供的報表,那么他漏了什么主要信息?(打算干嘛面談目標,實際有沒有)面談時間稍長,而且控制不佳。遺漏了關(guān)于“最新建議的系統(tǒng)的觀點”什么信息對面談報告來說是無關(guān)緊要的?(面談目標和內(nèi)容無關(guān))有關(guān)公司所有的歷史。如果真的發(fā)生了報告中提及的情況,則必須向隊友提出哪3個建議,以幫助他更好地舉行下一次面談。(三個建議的重點是那些是

36、幫助控制面談主題的)1控制面談的過程。面談開始的時候可以通過例如談公司歷史來醞釀一下交流的氣氛,但是不能偏離主題。如果長時間的談?wù)摬幌嚓P(guān)的信息的時候,需求分析人員就可以委婉的提醒面談對象,并重新切回正題。2注意保持面談的主題。針對每個面談的目標,要在面談的過程中安排合適的提示,逐一引導面談對象對各個主題的敘述。3總結(jié)面談的要點,注意此次面談過程的成功和失誤,明確下次的目標,以便為下次面談做充分的準備。面談對象:SalDomask 日期:3月3日會見者:S.Cabbot 主題:計算機使用面談的目標:找出關(guān)于計算機使用的態(tài)度; 獲得用戶的使用估計;看最新建議的系統(tǒng)的觀點是否滿足目標嗎?下次面談的目

37、標: 找出Sal怎樣看待系統(tǒng)支持部門。 找出下一個面談對象的觀點。面談的要點:Sal說道:“計算機是我的朋友?!薄耙恢薄倍荚谟糜嬎銠C。迫不及待地要熟悉新系統(tǒng)。會見者的觀點:對了解更對有關(guān)系統(tǒng)如何促進工作感興趣。如果不使用計算機進行工作,會感到枯燥。將成為新系統(tǒng)的熱情支持者/促進者。假設(shè)現(xiàn)在由你來負責所在學校選課系統(tǒng)的需求工作,現(xiàn)在需要你來安排一次群體面談,你打算怎么做?(群體面談的準備階段)計劃面談1.確定參與人員(涉眾、主持人、負責人、分析人員、記錄人員、觀察員 )2.安排會談時間 (全職的24天參與會議 ,擬定一份議程 )3.選擇會談地點 (充足的空間,道具支持,良好的餐飲服務(wù) )4.準備

38、會談內(nèi)容 (面談的主題和范圍,會議的議程,需求的預期和會談的目標,各種材料) 第八章 需求獲取方法之原型案例題(第一道題目,第三道題目,第五道題目第二問 不會做額)“每當我認為已經(jīng)獲取用戶的信息需求時,他們卻已經(jīng)發(fā)生了變化。這就像試圖射中一個運動目標。在半數(shù)時間里,我認為甚至用戶自己也不知道需要什么。”Flo Chart說。他是2Good 2 Be True公司的需求工程師,該公司負責為幾家制造公司的營銷部門調(diào)查產(chǎn)品的用途。用一段話向Flo chart解釋,原型化方法怎樣才能幫他更好地定義用戶的信息需求。用一段話評論Flo Chart的觀察:“在半數(shù)時間里,我認為甚至用戶自己也不知道需要什么。

39、”一定要解釋原型化方法怎樣才能真正地幫助用戶更好地理解和闡明他們自己的信息需求。用一段話向Flo Chart建議:一個具備原型特征的交互式Web站點緣何能解決Flo關(guān)于捕獲用戶信息需求的問題。解答:(1)答案主題:為什么要原型以及原型的作用(1)根據(jù)需要確定原型類型;(2)進行原型開發(fā);(3)獲得用戶反饋;(4)定義所得需求 (2)答案要以“隱含知識”和“用戶表述時的主觀加工”為主題 (3)原型化方法利用直觀化的界面來最快程度的得到用戶的反饋,通過用戶的反饋來獲知其實際的需求“我有一個絕妙的主意!”Bea Kwicke宣布,他是系統(tǒng)團隊的一位新來的需求工程師,“讓我們跳過所有的SDLC垃圾,直

40、接為一切設(shè)計原型。我們的項目會進展的更快,還可以節(jié)省時間和金錢,并且所有的用戶會感到我們似乎很在意他們,而不是連續(xù)幾個月不與他們交談?!绷谐瞿悖ㄗ鳛榕cBea同一個團隊的成員)用來勸阻她不要試圖放棄SDLC,而直接為所有項目設(shè)計原型的原因。Bea對你所說的話很失望。為了鼓勵她,用一段話向她說明,你認為適用于原型化方法的情形。解答:(1)主要原因:原型僅僅是開發(fā)當中使用的一種手段,它利用得當可以加速開發(fā)的進程,但不能代替軟件開發(fā)中的所有工作。原型開發(fā)最大的缺點就是:成本太高,高的讓人難以接受。所以原型方法只在必要的時候使用原型方法。通常來說,如果用戶需求出現(xiàn)了模糊,不清晰,不完整等具有一定不確定性

41、的特征,就可以考慮使用原型方法。原型方法的復雜性使得它會給項目引入了新的風險。 (2)情形見下表,尤其是其中紅色的部分廢棄型演化型水平型闡明并細化用例和功能性需求識別遺漏功能研究用戶界面方法實現(xiàn)核心用例根據(jù)優(yōu)先級實現(xiàn)其他用例使得系統(tǒng)適應(yīng)快速變化的需要垂直型演示系統(tǒng)可行性實現(xiàn)并擴充核心功能實現(xiàn)并擴充核心算法測試并調(diào)整性能 用戶需求出現(xiàn)了模糊,不清晰,不完整等一定不確定性的特征,就可以使用原型。 如果開始是以缺陷需求為起始點,需要不斷調(diào)整的情況,就可以使用探索式原型開發(fā) 如果開始擁有清晰地用戶需求,但是開發(fā)者對這些需求的實現(xiàn)方法,實現(xiàn)效果和可行性沒有太大的把握,則可以使用實驗式原型的方法 如果開始

42、有清晰的需求也有項目積累下來的原型資產(chǎn),這樣的情況可以使用演化式原型開發(fā)Itall多年來一直擔任Tun-L-Vision公司的系統(tǒng)分析員。在你加入該系統(tǒng)分析團隊以后,建議在目前項目中把原型化方法作為SDLC的一部分,Itall說:“當然可以,但是你不能太在意用戶所說的話。他們也不知道自己需要什么。我會做原型化工作,但是我不會觀察任何用戶?!?在不明確否決Itall的前提下,盡可能巧妙地說明原型化過程中觀察用戶反應(yīng)、用戶建議和用戶創(chuàng)新的重要性的原因。用一段話描述,如果系統(tǒng)的某部分已經(jīng)被原型化,并且在后續(xù)系統(tǒng)中沒有考慮用戶的反饋信息,可能會出現(xiàn)什么情況?解答:(1)通過觀察用戶的反應(yīng)會得到比較多的

43、信息,比如說觀察到用戶總是出錯則說明設(shè)計有問題,用戶在某個界面停留很久這就說明軟件的導航有問題,通過觀察發(fā)現(xiàn)用戶老是從一個位置移到另一個位置,說明界面中按鈕放置的有問題,有的時候用戶使用的方式超出了我們的想象(用戶創(chuàng)新),像這些都要通過觀察得到。在評估中,用戶會對原型系統(tǒng)的人機教會和功能設(shè)置提出建議,這些建議可以幫助開發(fā)者們改進,改變或調(diào)整原型,從來可以是原型更接近于它的目標實現(xiàn)。對于用戶的創(chuàng)新則是用戶潛在的需求,這些可以通過觀察還有用戶的反饋中得到,做到以上,我們可以獲得很多信息,使我們的原型更加完善。 (2)如果系統(tǒng)的某部分已經(jīng)被原型化,但是在后續(xù)系統(tǒng)中沒有考慮用戶的反饋信息,這個原形都不

44、能算是一個符合要求的原型。這樣會導致開出來的原型根本就不符合用戶需求,開發(fā)出來以后用戶不滿意可能會受到用戶的抵制??赡茉诤笃诓疟话l(fā)現(xiàn),開發(fā)方需要做很大的調(diào)整修改,導致項目延期,嚴重者可能會導致項目的失敗。Nordic Designs 是一家專營Scandinavia 當代家具的連鎖企業(yè),它已經(jīng)發(fā)布了一則夸耀其配送信息系統(tǒng)原型的公司簡訊。簡訊報道聲稱:“我們的配送信息系統(tǒng)原型一發(fā)布就投入使用了。絕對沒有任何修改的必要,經(jīng)理們說它是追蹤家具配送的最佳解決方案。不久就可以你們商店中接觸原型了?!边@則報道的作者對原型化方法概念明顯存在什么樣的誤解?用一段話解釋它。如果用戶期望原型“絕對沒有任何修改的必

45、要”的話,列出原型設(shè)計者可能會面臨的問題。解答:(1)這則報道中提到“我們的配送信息系統(tǒng)原型一發(fā)布就投入使用了”可以看出作者誤解了一點:開發(fā)出的原型不是最終的軟件,原型不能直接發(fā)布使用,我們使用原型的目的是獲取需求的內(nèi)容,而不是獲取原型的代碼,原型代碼最終應(yīng)該是會被拋棄的。作者還說“絕對沒有修改的必要”這句話顯然有問題,原型開發(fā)的過程中腰不斷地根據(jù)評估者反饋的不足進行原型的修改,調(diào)整完后還要準備再次原型評估,如果不能通過,則在根據(jù)反饋,觀察進行原型修正,所以不能說“絕對沒有任何修改的必要”。 (2)首先原型是本來就是用來獲取需求的,最終代碼一定要被拋棄,不然開發(fā)出來的軟件質(zhì)量會很差。 如果用戶

46、期望原型“絕對沒有修改的必要”的話,也就是說一次就獲取完需求,顯然這樣的方法是不可行的,不能獲取到完整明確的需求,這樣會導致配送系統(tǒng)漏洞多,不能滿足用戶的需求,不受用戶的歡迎甚至抵制,嚴重的可能影響到業(yè)務(wù) 花費大力氣在原型上,時間花費過大第九章 需求獲取方法之觀察與文檔審查復習題:2. 什么是情景性事件?觀察方法是如何解決情景性事件的?答:情景性是指某些事件只有和他們發(fā)生時的具體環(huán)境聯(lián)系起來,才能得到理解。對于情景性事件,需要將他們呢放在發(fā)生時的情景中進行解釋,才能明確其意圖。而這些情景信息往往是用戶不會有意識提及的,所以他們對情景性事件的描述也往往難以明確。觀察方法將發(fā)現(xiàn)的重點放在問題的上下

47、文環(huán)境之上,稱之為社會因素。通過對上下文環(huán)境的理解,觀察方法可以幫助需求工程師更好的理解問題的發(fā)生情景,進而更透徹的理解情景性問題。當然觀察方法并不能解決所有的情景性問題,尤其是開放的情景性問題。3.采樣觀察有哪兩種方法?比較它們的優(yōu)缺點。采樣方法時間采樣事件采樣優(yōu)點通過隨機的觀察減少誤差對頻繁發(fā)生事件取代表性事件進行觀察允許在行為展開過程中觀察允許對指定的重要事件進行觀察缺點用分段的方式來收集數(shù)據(jù)不能提供全面信息的時間漏掉不經(jīng)常發(fā)生卻很重要的事件消耗大量時間漏掉頻繁發(fā)生事件的代表性樣本適用場景發(fā)現(xiàn)異常流程驗證用戶知識和實際工作的一致性獲取默認知識驗證用戶知識和實際工作的一致性思考題:1.觀察

48、用戶工作總是困難的。它通過使你和用戶都感動不舒服。為了確保由于你的訪問而不至于使用戶的行為發(fā)生改變,你應(yīng)該怎么辦?為了使觀察看起來更自然一些,你應(yīng)該怎么做?二玉哥哥語:書上沒有,屬于日常經(jīng)驗,讓別人感覺到你的訪問不發(fā)生困難的手段參考答案:每次去用戶的工作場所幫助用戶干活,使得用戶感覺自然在特定的觀察之前就經(jīng)常去用戶的工作場所,等到進行觀察時,用戶對需求工程師的到來已經(jīng)習以為常。在去觀察之前做足準備功夫,熟悉客戶的性格特點、個人嗜好、生活習慣和工作風格等,觀察中可以適時與客戶交流,以提高客戶對需求工程師的好感度和熟悉度來降低客戶的不自然觀察客戶的時候不要太明顯,盡量不使客戶察覺到。2.在需求獲取

49、階段,需求工程師收集了大量的硬數(shù)據(jù)樣本,解釋這些樣本的類型以及它們適用于哪種文檔審查方法。二玉哥哥語:書上就有,都可做成復習題,難度不夠-_-參考答案:文檔類型文檔審查方法描述相關(guān)產(chǎn)品的需求規(guī)格說明需求重用分析相關(guān)產(chǎn)品的規(guī)格說明,發(fā)現(xiàn)可以移植到新產(chǎn)品中的需求信息,進行需求的重用:問題與信息用戶界面特征業(yè)務(wù)需求、組織策略、政策法規(guī)硬數(shù)據(jù)文檔分析閱讀研究得到的硬數(shù)據(jù),從中發(fā)現(xiàn)需求信息問題域信息工作流程業(yè)務(wù)細節(jié)客戶的需求文檔需求剝離抽取客戶需求文檔中的需求描述粗粒度需求案例題:2. “我知道你有很多材料。那些材料里到底有什么?”Betty Kant問道,她是MIS特別工作組的負責人。MIS特別工作組

50、是你的系統(tǒng)團隊聯(lián)絡(luò)Sawder家具公司的橋梁。你拖了一大堆材料,正準備離開這棟樓?!芭叮沁^去6個月的一些財政決算、生產(chǎn)報表,還有Sharon給我的一些業(yè)績報表,業(yè)績報表涵蓋了過去6個月的目標和工作業(yè)績?!蹦阍诨卮饡r,有些紙掉到了地上,“你為什么問這個問題呢?”Betty為你拾起紙并把它放到最近的桌子上,回答道:“因為你根本不需要這些垃圾。你來這里要做一件事情,就是和我們這些用戶談話。從這些材料中得不到任何有益的信息?!敝挥懈嬖VBetty你從每份文檔中找到的東西才能使她相信每份文檔都是重要的。用一段文字解釋文檔為需求工程師提供了什么幫助?二玉哥哥語:看看書上 文檔采樣 那部分就知道了參考答案:

51、不同的文檔為需求工程師提供了不同的幫助,譬如:需求規(guī)格說明書:幫助需求工程師發(fā)現(xiàn)需求信息,從而進行需求的重用硬數(shù)據(jù):通過研究和閱讀也可以發(fā)現(xiàn)需求的相關(guān)信息客戶的續(xù)修文檔:可以得到粗粒度的需求通過分析這些文檔,可以獲取組織業(yè)務(wù)的問題域信息、業(yè)務(wù)工作流程的業(yè)務(wù)細節(jié)中存在的問題等。一個有經(jīng)驗的需求工程師會從現(xiàn)有的文檔中獲取事實,理解問題域。在你和Betty談話的時候,意識到實際上也需要其他的定量文檔。列出你缺少的東西。二玉哥哥語:看看定量的和定性的就知道了參考答案:定量硬數(shù)據(jù)缺少:數(shù)據(jù)收集表格:反應(yīng)組織的信息域,收拾正在使用的每張表格,連同填寫和分發(fā)說明一起,與填好的表格進行對比定性硬數(shù)據(jù)缺少:整個

52、組織的描述文檔:Sawder公司的組織結(jié)構(gòu)圖業(yè)務(wù)指導文檔:Sawder公司的工作指南和規(guī)章手冊業(yè)務(wù)備忘:第十章 需求的組織思考題:2. 你認為場景方法可以在需求工程(甚至軟件工程)的哪些方面起到重要作用?在需求工程中:(1) 組織需求獲取得到的信息(2) 幫助進行詳細的需求分析(3) 結(jié)合面向目標的方法,指導需求獲取活動的開展第十一章 需求分析概述復習題:8.比較確定需求優(yōu)先級的各種方法,說明他們的優(yōu)缺點(1)累計投票(得票最多不一定就是最需要去做的;優(yōu)點是實行方便)(2)區(qū)域劃分()(3)Top-N(感覺這是從開發(fā)人員角度來考慮問題,可能不能很好地符合用戶需求;優(yōu)點是開發(fā)起來時間可控性比較強

53、)(4)數(shù)據(jù)量化(分析時比較簡單;但是標準的確定比較困難)補充:面向?qū)ο蠓治鰪拈_始到結(jié)束過程建模技術(shù)的選擇和應(yīng)用面向?qū)ο蠼<夹g(shù)路線:1.從用例描述中識別出對象和類2.分析用例的描述信息,添加類的屬性和類之間的關(guān)聯(lián)3.從用例描述中識別系統(tǒng)行為4.將系統(tǒng)行為分配給類5.綜合考慮類的屬性與行為,細化類的職責,建立完全的對象模型思考題:1. 分析“結(jié)構(gòu)化分析”和“面向?qū)ο蠓治觥钡倪^程,說明它們?yōu)槭裁炊奸_始于系統(tǒng)的邊界定義?二玉哥哥語:和第二章相關(guān):第二章云“軟件要完成用戶的任務(wù)需要和外界協(xié)調(diào)互動“開始于邊界是因為邊界是它們互動的地方。系統(tǒng)分析給自己做個定位的話,是先分析互動的反應(yīng),然后分析系統(tǒng)內(nèi)部的

54、反應(yīng),所以框架中有一些叫系統(tǒng)外部行為等,在需求早期階段都是外部分析,到了后期階段才會進入內(nèi)部分析參考答案:軟件要完成用戶的任務(wù)需要和外界協(xié)調(diào)互動,經(jīng)過問題分析之后一般可以得到高層次的解決方案及系統(tǒng)特性。而一個系統(tǒng)通常會有很多高層次問題,雖然問題分析之后可以得到解系統(tǒng)為了解決某一問題而需要具備的知識片段,卻無法將這些片段自動連接為整個系統(tǒng)的概要全圖,所以很有必要將各個問題的分析結(jié)果進行綜合與處理,已確定整個解系統(tǒng)的功能,建立系統(tǒng)的邊界。之所以把系統(tǒng)邊界作為需求分析的起點,是因為邊界是軟件和外界互動的地方。解系統(tǒng)為自己做定位,首先要分析互動的反應(yīng),然后分析系統(tǒng)內(nèi)部的反應(yīng),所以,框架中有一些系統(tǒng)的外

55、部行為等。一般情況下,在需求分析的早期階段做的都是外部分析,從系統(tǒng)的邊界圖開始,逐一分析和細化系統(tǒng)和外界的交互,以保證最終產(chǎn)品的行為能夠和環(huán)境形成互動,以滿足用戶的需求;然后在需求分析的后期階段,才會逐漸進入內(nèi)部分析。3. 列舉結(jié)構(gòu)化分析的各種技術(shù),說明它們的數(shù)學基礎(chǔ)是什么?二玉哥哥語:有些有基礎(chǔ),而有些是沒有基礎(chǔ)的,結(jié)構(gòu)化、數(shù)據(jù)流圖、ERD、狀態(tài)圖(結(jié)構(gòu)化的一種)都是有基礎(chǔ)的,有些數(shù)據(jù)流圖的細節(jié)方法是沒有基礎(chǔ)的參考答案:結(jié)構(gòu)化分析技術(shù):數(shù)據(jù)流圖、實體聯(lián)系圖、狀態(tài)轉(zhuǎn)移圖、功能實體矩陣、實體生命歷史和事件實體矩陣。以數(shù)據(jù)流動為中心,以DFD為核心技術(shù),以演算為數(shù)學基礎(chǔ)。4列舉面向?qū)ο蠓治龅母鞣N技

56、術(shù),說明它們是對結(jié)構(gòu)化分析技術(shù)的繼承和借鑒嗎?如果是,那么說明它們借鑒了哪些結(jié)構(gòu)化分析技術(shù),如果不是,那么說明它們的數(shù)據(jù)基礎(chǔ)是什么?二玉哥哥語:很明顯是,怎么是的看看發(fā)展歷史的那張表參考答案:是面向?qū)ο蠹夹g(shù):用例圖、類圖、交互圖、活動圖、對象約束語言、狀態(tài)圖和工作流借鑒的結(jié)構(gòu)化分析技術(shù):實體關(guān)系圖、數(shù)據(jù)流圖、狀態(tài)轉(zhuǎn)移圖6“事件”和“事物”一直是進行需求分析的一個重要思路,你對此如何評價?二玉哥哥語:有作用卻也有局限性。事物和事件正好對應(yīng)著結(jié)構(gòu)化方法的兩條路徑,一個是DFD,一個是ERD,可參考書上結(jié)構(gòu)化分析有兩條路徑這塊內(nèi)容,在結(jié)構(gòu)化分析方法那章。但在面向?qū)ο罄锞筒惶糜昧?,因為面向?qū)ο蟮暮诵?/p>

57、是多對象協(xié)同,多對象協(xié)同既不是事件,也不是事物,所以面向?qū)ο箝_始使用場景。事件就是行為,就是DFD;事物就是數(shù)據(jù),就是ERD。參考答案:事件:可以描述、值得記錄的在某一特定時間和地點發(fā)生的事情。通過對事件的分析可以將復雜的系統(tǒng)需求分解成易處理并能更好理解的小單元。事件可分為以下幾類:外部事件、臨時事件、狀態(tài)事件。事物:在面向?qū)ο蟮木幊讨?,這些事物是在系統(tǒng)中相互交互的對象。事物的類型:實物;角色;組織部門;設(shè)備;突發(fā)事件、事件或交互;地點/位置結(jié)構(gòu)化分析:事物和事件正好對應(yīng)著結(jié)構(gòu)化方法的兩條路徑,一個是DFD,一個是ERD面向?qū)ο蠓治觯汉诵氖嵌鄬ο蟮膮f(xié)同,而多對象既不是事件,也不是事物,而是基于

58、場景的。所以,在面向?qū)ο蠓治鲋校录褪切袨?,指的就是DFD;事物就是數(shù)據(jù),指的就是ERD。第12章 過程建模案例題根據(jù)下列敘述性描述,為描述的內(nèi)容繪制一個上下文DFD。校園書店“課本庫存系統(tǒng)”的目的是向?qū)W生提供本地大學課程的課本。大學的教學部門通過一個“課本主清單”向書店提交初始數(shù)據(jù),包括課程、教師、課本和預計注冊人數(shù)。書店生成一個“購買訂單”,“購買訂單”被送到供應(yīng)課本的出版公司。圖書訂單隨著一個“包裝清單”到達書店,它被接收的部門檢查和驗證。學生填寫包含課程信息的“購書要求”,當他們付了書款之后就得到一個“銷售單據(jù)”。建立一個決策表,正確反映下面的課程評分策略一個學生可以得到一個期末課程

59、成績A、B、C、D、F。為了給出學生的期末課程成績,老師首先確定一個學生的初始期末成績,具體按照以下的方式確定:頭三次作業(yè)和測驗中總成績不低于90分,并且第4次作業(yè)成績不低于70分的學生,這門課將得到成績A。頭三次作業(yè)和測驗總成績低于90但不低于80,并且第4次作業(yè)成績不低于70的學生,這門課將得到成績B。頭三次作業(yè)和測驗總成績低于80但不低于70,并且第4次作業(yè)成績不低于70的學生,這門課將得到成績C。頭三次作業(yè)和測驗總成績低于70但不低于60,并且第4次作業(yè)成績不低于70的學生,這門課將得到成績D。頭三次作業(yè)和測驗總成績低于60,或者第4次作業(yè)成績低于70的學生,這門課將得到成績F。一旦老

60、師確定了學生的初始成績,他將決定最后的課程成績。如果學期期間曠課不多于3堂課,這個學生的學生課程成績將同他的初始成績一樣。否則,學生的學期課程成績將比他的初始課程成績低一級。存在某些條件使得老師無法采取行動嗎?如果有,你將如何改正錯誤?你的決策表可以通過消除不可能的規(guī)則或合并規(guī)則進行簡化嗎?解答:1)存在使老師無法采取行動的條件,當初始期末成績?yōu)镕,并且曠課多于3堂時。 2)改正錯誤:添加條件,當初始期末成績?yōu)镕,曠課多于3堂時,不做降級處理 3)這個看自己的圖說,下面給出最終圖條件和行動規(guī)則頭三次作業(yè)和測試總成績=90=90=80并=80并=70并=70并=60并=60并70=0并=70=7

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論