需求開發(fā)與需求管理-消除軟件開發(fā)百病之源培訓教材漫索軟-資料下載頁
2025-05-24 15:25本頁面
【導讀】寬泛地講，需求來源于用戶的一些“需要”，這些“需要”被分析、確認后形成完整的文檔，該。文檔詳細地說明了產(chǎn)品“必須或應當”做什么。FrederickBrooks在他1987年經(jīng)典文章“NoSilverBullet‖中闡述了需求的重要性：。最困難的概念性工作是編寫出詳細的。需求，包括所有面向用戶、面向機器和其它軟件系統(tǒng)的接口。此工作一旦做錯，將會給系。統(tǒng)帶來極大的損害，并且以后對它修改也極為困難。需求是產(chǎn)品的根源，需求工作的優(yōu)劣對產(chǎn)品影響最大。整條河流也就被污染了。上海貝爾某事業(yè)部一群高智商的開發(fā)人員集體犯需求觀念錯誤的案例。需求確認是指開發(fā)方和客戶共同對需求文檔進行評審，雙方對需求達成共識后作出書面承諾，使。變更失去控制而導致項目發(fā)生混亂。開發(fā)者對待需求工程的態(tài)度可分“被動型”、“主動型”和“領先型”三種，只有后。–“主動型”是指開發(fā)者積極地開展需求工程中的各項活動。俗話說“良好的開端是成功的一半”，“主動型”需求工程是開發(fā)成功產(chǎn)品的必備條
【正文】 ，什么都要做，可是做著做著，人們常常會面臨 “ 進度延誤、費用超支、人員不足 ” 等問題，這時就亂套了。 – 人們想出了 “ 取舍 ” 辦法：先做優(yōu)先級高的需求，后做（甚至放棄）優(yōu)先級低的需求，這樣可以將風險降到最低。 ? 需求的優(yōu)先級其實就是需求 “ 輕重緩急 ” 的分級表述，例如劃分為 “ 高、中、低 ” 三級。一般地，由用戶和開發(fā)方共同確定需求的優(yōu)先級。 闡述 “ 做什么 ” 而不是 “ 怎么做 ” ? 《 產(chǎn)品需求規(guī)格說明書 》 的重點是闡述 “ 做什么 ” ， 而不是闡述 “ 怎么做 ” 。 “ 怎么做 ” 是系統(tǒng)設計和實現(xiàn)階段的事情 。 ? 國內(nèi)的很多軟件公司里 ， 開發(fā)人員常常身兼數(shù)職 ， 可能把需求開發(fā) 、 系統(tǒng)設計 、 編程等工作從頭做到尾 。 所以他們在調(diào)查 、 分析 、 定義需求時 ， 自然會想到 “ 怎么做 ” ， 這并沒有什么過錯 。 如果在調(diào)查 、 定義需求時想好了 “ 怎么做 ” ， 當然應該寫下來 ， 否則豈不浪費 ！ 關鍵是不要將 “ 怎么做 ” 寫到需求規(guī)格說明書里面 ， 記錄在其它文檔里就行了 。 Page 30 8. 如何定義產(chǎn)品需求 規(guī)程 ? 第一步：細化并分析用戶需求 – 需求分析員首先對《用戶需求說明書》進行細化，對比較復雜的用戶需求進行建模分析，以幫助軟件開發(fā)人員更好地理解需求。例如采用 Rational 的 Rose工具進行需求的建模分析，建模分析產(chǎn)生的文檔可以作為《產(chǎn)品需求規(guī)格說明書》的附件。補充說明：建模分析的技術難度比較高，需求分析員應當根據(jù)自身水平進行取舍。 ? 第二步：撰寫產(chǎn)品需求規(guī)格說明書 – 需求分析員按照指定的文檔模板撰寫《產(chǎn)品需求規(guī)格說明書》。如果待開發(fā)的產(chǎn)品分為軟件和硬件兩部分的話，則應當撰寫《軟件需求規(guī)格說明書》和《硬件需求規(guī)格說明書》。 ? 第三步：進行需求確認 – 項目經(jīng)理邀請同行專家和用戶（包括客戶和最終用戶）一起評審《產(chǎn)品需求規(guī)格說明書》，盡最大努力使《產(chǎn)品需求規(guī)格說明書》能夠正確無誤地反映用戶的真實意愿。 – 需求評審之后，開發(fā)方和客戶方的責任人對《產(chǎn)品需求規(guī)格說明書》作書面承諾。 軟件需求規(guī)格說明書的參考模板 Page 31 軟件需求說明書的參考模板 Page 32 9. 需求管理：確認、跟蹤、變更控制 需求 確認（評審和承諾） ? 需求確認是指開發(fā)方和客戶方共同對《產(chǎn)品需求規(guī)格說明書》進行評審，雙方對需求達成共識后作出承諾。需求確認包含兩個重要工作： “ 需求評審 ” 和 “ 需求承諾 ” 。 需求評審面臨的困難 ? 需求評審的一個通病是 “ 虎頭蛇尾 ” 。 需求評審的確乏味 ， 也比較費腦子 。 剛開始評審時 ， 大家都比較認真 ， 越到后頭越馬虎 。 ? 需求評審涉及的人員可能比較多，有些時候讓這么多人聚在一起花費比較長的時間開會并不容易（例如有些人可能出差在外，有些人可能事務纏身）。沒有必要把所有事情擠在一塊做，需求開發(fā)是循序漸進的過程，需求評審也可以分段進行。這樣每次評審的時間比較短，參加評審的人員也少一些，組織會議就比較容易。 ? 開評審會議時經(jīng)常會 “ 跑題 ” ，導致評審效率很低。有時話匣子一打開后關不上，大家越扯越遠，結果評審會議變成了聊天會議。主持人應當控制話題，避免大家討論與主題無關的東西。 ? 開評審會議時經(jīng)常會發(fā)生爭議。適當?shù)臓幾h有利于澄清問題，比什么東西都一致贊成要好。然而當爭議變?yōu)闋幊硶r就壞事了， 爭吵不僅對評審工作沒有好處，而且會無意中傷害同事們的感情。 ? 人們在很多時候分不清楚自己究竟是 “ 堅持真理 ” 還是 “ 固執(zhí)己見 ” 。毫不妥協(xié)或者輕易妥協(xié)都不是好辦法。我們應當養(yǎng)成良好的習慣：不要一棍子打死異己的觀點，嘗試著讓自己站在他人的立場思考問題，這樣你會找到比較滿意的答案。 Page 33 9. 需求管理：確認、跟蹤、變更控制 需求 承諾 ? 需求承諾是指開發(fā)方和客戶方的責任人對通過了正式技術評審的《產(chǎn)品需求規(guī)格說明書》作出承諾，該承諾具有商業(yè)合同的效果。 ? 需求承諾的 “ 八股文 ” 如下： – 本 《 產(chǎn)品需求規(guī)格說明書 》 建立在雙方對需求的共同理解基礎之上 ， 我同意后續(xù)的開發(fā)工作根據(jù)該 《 產(chǎn)品需求規(guī)格說明書 》 開展 。 如果需求發(fā)生變化 ， 我們將按照 “ 變更控制規(guī)程” 執(zhí)行 。 我明白需求的變更將導致雙方重新協(xié)商成本 、 資源和進度等 。 – 甲方簽字 乙方簽字 ? 人們在作出承諾之前務必要認真閱讀文檔 ， 一定要明白簽字意味著什么 。 Page 34 9. 需求管理：確認、跟蹤、變更控制 需求 跟蹤 ? 需求跟蹤的目的是建立與維護“需求－設計－編程－測試”之間的一致性，確保所有的工作成果符合用戶需求。 ? 需求跟蹤有兩種方式： – 正向跟蹤。檢查《產(chǎn)品需求規(guī)格說明書》中的每個需求是否都能在后繼工作成果中找到對應點。 – 逆向跟蹤。檢查設計文檔、代碼、測試用例等工作成果是否都能在《產(chǎn)品需求規(guī)格說明書》中找到出處。 ? 正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采用何種跟蹤方式，都要建立與維護需求跟蹤矩陣（即表格）。需求跟蹤矩陣保存了需求與后繼工作成果的對應關系。 Page 35 9. 需求管理：確認、跟蹤、變更控制 需求變更控制 ? 需求發(fā)生變更的起因主要有： – 隨著項目的進展，人們（包括開發(fā)方和客戶方）對需求的了解越來越深入。原先的需求文檔可能存在這樣那樣的錯誤或不足，因此要變更需求。 – 市場發(fā)生了變化，原先的需求文檔可能跟不上當前的市場需求，因此要變更需求。 ? 提出需求變更的動機是好的，目的是希望產(chǎn)品更加符合用戶的需求。對項目開發(fā)小組而言， 變更需求意味著要調(diào)整資源、重新分配任務、修改前期工作成果等，開發(fā)小組要為此付出較重的代價。如果每次需求變更請求都被采納的話，這個項目也許永遠不能按時完成。 ? 需求變更控制的目的： 如果需求變更帶來的好處大于壞處，那么允許變更，但必須按照已定義的變更規(guī)程執(zhí)行，以免變更失去控制。 如果需求變更帶來的壞處大于好處，那么拒絕變更。 ? 需求變更控制過程中最難辦的事情是莫過于“拒絕客戶提出的需求變更請求”。通常情況下開發(fā)方是不敢得罪客戶的，但是無原則地退讓將使開發(fā)小組陷入困境。解決這個問題最好的辦法是事先建立“游戲規(guī)則”： – 開發(fā)方與客戶方達成“事不過三”的約定（符合中國人的習慣），即允許客戶變更三次需求；如果客戶第四此變更需求，開發(fā)方有權拒絕，除非客戶愿意補償開發(fā)方的損失。 ? 如果事先沒有“游戲規(guī)則”的話，開發(fā)方需要一些社交技巧來減緩矛盾。例如建議在開發(fā)該產(chǎn)品新版本時修改需求。
教學課件相關推薦
鄂ICP備17016276號-1