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