[互聯(lián)網(wǎng)]ch5-系統(tǒng)分析-資料下載頁
2025-04-13 22:19本頁面
【正文】 理 ?（ 1）需求驗(yàn)證 ?系統(tǒng)分析員往往認(rèn)為他們了解與掌握了用戶的需求，然而卻沒有真正把握商業(yè)過程的最精妙之處。在項(xiàng)目早期發(fā)現(xiàn)和解決這方面的問題，比到了開發(fā)與實(shí)現(xiàn)階段解決的代價(jià)要小百倍。發(fā)現(xiàn)和解決需求分析問題的手段是需求驗(yàn)證。 ?類似于房屋建造，需求分析相當(dāng)于設(shè)計(jì)藍(lán)圖，在進(jìn)行設(shè)計(jì)時(shí)可能會(huì)存在問題，如果在正式建造前不加以解決可能導(dǎo)致完全的失敗，在建造之前首先要驗(yàn)證圖紙的正確性。 ?1）需求驗(yàn)證過程 ?需求確認(rèn)是指開發(fā)方和客戶方共同對(duì) 《產(chǎn)品需求規(guī)格說明書 》 進(jìn)行評(píng)審，雙方對(duì)需求達(dá)成共識(shí)后作出承諾。需求確認(rèn)包含兩個(gè)重要工作：“需求評(píng)審”和“需求承諾”。 ? 2）需求評(píng)審 ： ? 需求評(píng)審的一個(gè)通病是“虎頭蛇尾”。需求評(píng)審的確乏味，也比較費(fèi)腦子。剛開始評(píng)審時(shí)，大家都比較認(rèn)真，越到后頭越馬虎。主持人應(yīng)當(dāng)控制節(jié)奏，將重要內(nèi)容放在前面。 ? 需求評(píng)審涉及的人員可能比較多，有些時(shí)候讓這么多人聚在一起花費(fèi)比較長(zhǎng)的時(shí)間開會(huì)并不容易（例如有些人可能出差在外，有些人可能事務(wù)纏身）。沒有必要把所有事情擠在一塊做，需求開發(fā)是循序漸進(jìn)的過程，需求評(píng)審也可以分段進(jìn)行。這樣每次評(píng)審的時(shí)間比較短，參加評(píng)審的人員也少一些，組織會(huì)議就比較容易 ? 開評(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)議有利于澄清問題，比什么東西都一致贊成要好。控制爭(zhēng)議不變?yōu)闋?zhēng)吵，爭(zhēng)吵不僅對(duì)評(píng)審工作沒有好處，而且會(huì)無意中傷害同事間及與客戶的關(guān)系，影響項(xiàng)目組下一步的工作。 ? 人們?cè)诤芏鄷r(shí)候分不清楚自己究竟是“堅(jiān)持真理”還是“固執(zhí)己見”。毫不妥協(xié)或者輕易妥協(xié)都不是好辦法。我們應(yīng)當(dāng)養(yǎng)成良好的習(xí)慣：不要一棍子打死異己的觀點(diǎn)，嘗試著讓自己站在他人的立場(chǎng)思考問題，這樣你會(huì)找到比較滿意的答案。 ?3）需求承諾 ?需求承諾是指開發(fā)方和客戶方的責(zé)任人對(duì)通過了正式技術(shù)評(píng)審的 《 產(chǎn)品需求規(guī)格說明書 》 作出承諾，該承諾具有商業(yè)合同的效果。 本 《 產(chǎn)品需求規(guī)格說明書 》 建立在雙方對(duì)需求的共同理解基礎(chǔ)之上，我同意后續(xù)的開發(fā)工作根據(jù)該 《 產(chǎn)品需求規(guī)格說明書 》 開展。如果需求發(fā)生變化，我們將按照“變更控制規(guī)程”執(zhí)行。我明白需求的變更將導(dǎo)致雙方重新協(xié)商成本、資源和進(jìn)度等。 甲方簽字 乙方簽字 ?人們?cè)谧鞒龀兄Z之前務(wù)必要認(rèn)真閱讀文檔，一定要明白簽字意味著什么。 ?（ 2）需求跟蹤 ? 需求跟蹤的目的是建立與維護(hù)“需求－設(shè)計(jì)－編程－測(cè)試”之間的一致性，確保所有的工作成果符合用戶需求。 ? 需求跟蹤有兩種方式： ? –正向跟蹤。檢查 《 產(chǎn)品需求規(guī)格說明書 》 中的每個(gè)需求是否都能在后繼工作成果中找到對(duì)應(yīng)點(diǎn)。 ? –逆向跟蹤。檢查設(shè)計(jì)文檔、代碼、測(cè)試用例等工作成果是否都能在 《 產(chǎn)品需求規(guī)格說明書 》 中找到出處。 ? –正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采用何種跟蹤方式，都要建立與維護(hù)需求跟蹤矩陣（即表格）。需求跟蹤矩陣保存了需求與后繼工作成果的對(duì)應(yīng)關(guān)系。 ?（ 3）需求變更管理 ?1)需求發(fā)生變更的起因： ? –隨著項(xiàng)目的進(jìn)展，人們（包括開發(fā)方和客戶方）對(duì)需求的了解越來越深入。原先的需求文檔可能存在這樣那樣的錯(cuò)誤或不足，因此要變更需求。 ? –市場(chǎng)發(fā)生了變化，原先的需求文檔可能跟不上當(dāng)前的市場(chǎng)需求，因此要變更需求。 ?“沒有軟件系統(tǒng)開發(fā)中用戶需求的變化不超過 3次” ? ? 2)需求變更管理： ? 提出需求變更的動(dòng)機(jī)是好的，目的是希望產(chǎn)品更加符合用戶的需求。對(duì)項(xiàng)目開發(fā)小組而言，變更需求意味著要調(diào)整資源、重新分配任務(wù)、修改前期工作成果等，開發(fā)小組要為此付出較重的代價(jià)。如果每次需求變更請(qǐng)求都被采納的話，這個(gè)項(xiàng)目也許永遠(yuǎn)不能按時(shí)完成。 ? 需求變更控制的目的： 如果需求變更帶來的好處大于壞處，那么允許變更，但必須按照已定義的變更規(guī)程執(zhí)行，以免變更失去控制。 如果需求變更帶來的壞處大于好處，那么拒絕變更。 ? 需求變更控制過程中最難辦的事情是莫過于“拒絕客戶提出的需求變更請(qǐng)求”。通常情況下開發(fā)方是不敢得罪客戶的，但是無原則地退讓將使開發(fā)小組陷入困境。解決這個(gè)問題最好的辦法是事先建立“游戲規(guī)則”： ? 開發(fā)方與客戶方達(dá)成“事不過三”的約定（符合中國(guó)人的習(xí)慣），即允許客戶變更三次需求；如果客戶第四此變更需求，開發(fā)方有權(quán)拒絕，除非客戶愿意補(bǔ)償開發(fā)方的損失。 ? 如果事先沒有“游戲規(guī)則”的話，開發(fā)方需要一些社交技巧來減緩矛盾。例如建議在開發(fā)該產(chǎn)品新版本時(shí)修改需求。 實(shí)驗(yàn) 6 數(shù)據(jù)流分析與定義 ?根據(jù)小組項(xiàng)目的業(yè)務(wù)流程圖和系統(tǒng)關(guān)聯(lián)圖，對(duì)數(shù)據(jù)流進(jìn)行分析，對(duì)系統(tǒng)關(guān)聯(lián)圖逐步分解，畫出足夠描述數(shù)據(jù)流與信息處理過程的數(shù)據(jù)流圖 ?對(duì)數(shù)據(jù)流中的數(shù)據(jù)存儲(chǔ)，對(duì)照事物表，結(jié)合 ER分析，確定系統(tǒng)的數(shù)據(jù)庫(kù)關(guān)系模型，并對(duì)數(shù)據(jù)表中的字段進(jìn)行定義 ?結(jié)合事物表，對(duì)數(shù)據(jù)流圖中的數(shù)據(jù)流進(jìn)行分析定義 ?結(jié)合事件表，對(duì)數(shù)據(jù)流圖中的加工進(jìn)行說明 ?必要的話，對(duì)外部項(xiàng)進(jìn)行說明 ?參考標(biāo)準(zhǔn)模板撰定需求分析說明書，并將業(yè)務(wù)流程圖，數(shù)據(jù)流圖等模型及說明作為附件。 例：網(wǎng)上書店的數(shù)據(jù)流分析 ?管理員：圖書管理 ?顧客：查詢、訂購(gòu)、個(gè)人信息管理
教學(xué)課件相關(guān)推薦
鄂ICP備17016276號(hào)-1