品質(zhì)知識(15個 doc)15.doc

第第 9 章章 需求開發(fā)需求開發(fā) 1 9 1 介紹介紹 1 9 2 用戶需求調(diào)查用戶需求調(diào)查 2 9 2 1 目的 2 9 2 2 角色與職責(zé) 2 9 2 3 啟動準(zhǔn)則 2 9 2 4 輸入 2 9 2 5 主要步驟 3 Step1 準(zhǔn)備 3 Step2 調(diào)查與記錄 3 Step3 分析需求信息 3 Step4 撰寫用戶需求說明書 3 后續(xù)活動 需求確認 3 9 2 6 輸出 4 9 2 7 結(jié)束準(zhǔn)則 4 9 2 8 度量 4 9 3 產(chǎn)品需求定義產(chǎn)品需求定義 4 9 3 1 目的 4 9 3 2 角色與職責(zé) 4 9 3 3 啟動準(zhǔn)則 4 9 3 4 輸入 4 9 3 5 主要步驟 5 Step1 細化并分析用戶需求 5 Step2 撰寫產(chǎn)品需求規(guī)格說明書 5 后續(xù)活動 需求確認 5 9 3 6 輸出 5 9 3 7 結(jié)束準(zhǔn)則 5 9 3 8 度量 6 9 4 需求分析方法概述需求分析方法概述 6 9 4 1 問答分析法 6 9 4 2 建模分析法 6 一 結(jié)構(gòu)化分析法 7 二 面向?qū)ο蠓治龇?7 三 恰當(dāng)?shù)厥褂脠D形符號 8 9 5 實施建議實施建議 8 第第 9 章章 需求開發(fā)需求開發(fā) 需求開發(fā) Requirement Development RD 的目的是通過調(diào)查與分析 獲取用戶需求 并定義產(chǎn)品需求 需求開發(fā)過程域是 SPP 模型的重要組成部分 本規(guī)范闡述了需求開發(fā)過程域的兩個主 要規(guī)程 需求調(diào)查 SPP PROC RM SURVEY 需求定義 SPP PROC RM DEFINE 上述每個規(guī)程的 目標(biāo) 角色與職責(zé) 啟動準(zhǔn)則 輸入 主要步驟 輸出 完成準(zhǔn)則 和 度量 均已定義 需求分析是需求開發(fā)過程域的重要活動之一 但是不宜用 規(guī)范 這種形式來論述 本章對需求分析方法作了概括性介紹 請讀者閱讀更加專業(yè)性的需求分析論著 本規(guī)范適用于國內(nèi) IT 企業(yè)的軟件研發(fā)項目 建議用戶根據(jù)自身情況 如商業(yè)目標(biāo) 研 發(fā)實力等 適當(dāng)?shù)匦薷谋疽?guī)范 然后推廣使用 9 1 介紹介紹 需求開發(fā)與需求管理是相輔相成的兩類活動 它們共同構(gòu)成完整的需求工程 需求工 程結(jié)構(gòu)圖如圖 8 1 所示 需求開發(fā)和需求管理的流程如圖 9 1 所示 圖 9 2 需求開發(fā)與需求管理流程圖 需求分析 用戶需求說明書 產(chǎn)品需求規(guī)格說明書 用戶需求調(diào)查 輸出 輸出 產(chǎn)品需求定義 需求 變更 控制 需求確認 需求跟蹤 需求 開發(fā) 過程域 需求 管理 過程域 需求開發(fā)可分為兩個階段 用戶需求調(diào)查階段 和 產(chǎn)品需求定義階段 而 需求 分析 則貫穿于上述兩個階段 需求調(diào)查階段和需求定義階段在邏輯上存在先后關(guān)系 實 際工作中二者通常是迭代進行的 我們把從事需求開發(fā)工作的人員稱為需求分析員 也叫 系統(tǒng)分析員 避免與其它開發(fā)人員混淆 一 需求調(diào)查一 需求調(diào)查 需求調(diào)查的目的是通過各種途徑獲取用戶的需求信息 原始材料 產(chǎn)生 用戶需求說 明書 二 需求分析二 需求分析 需求分析的目的是對各種需求信息進行分析 消除錯誤 刻畫細節(jié)等 常用的需求分 析方法有 問答分析法 結(jié)構(gòu)化分析法 和 面向?qū)ο蠓治龇?三 需求定義三 需求定義 需求定義的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果 進一步定義準(zhǔn)確無誤的產(chǎn)品需求 產(chǎn)生 產(chǎn)品需求規(guī)格說明書 系統(tǒng)設(shè)計人員將依據(jù) 產(chǎn)品需求規(guī)格說明書 開展系統(tǒng)設(shè)計 工作 需求開發(fā)過程域產(chǎn)生的主要文檔有 用戶需求說明書 模板見 SPP TEMP RD UR 產(chǎn)品需求規(guī)格說明書 模板見 SPP TEMP RD PRS 9 2 用戶需求調(diào)查用戶需求調(diào)查 9 2 1 目的目的 獲取用戶 客戶與最終用戶 的需求信息 經(jīng)過分析后產(chǎn)生 用戶需求說明書 9 2 2 角色與職責(zé)角色與職責(zé) 需求分析員調(diào)查 分析用戶的需求 客戶與最終用戶提供必要的需求信息 9 2 3 啟動準(zhǔn)則啟動準(zhǔn)則 需求分析員已經(jīng)確定 9 2 4 輸入輸入 任何與用戶需求相關(guān)的材料 9 2 5 主要步驟主要步驟 Step1 準(zhǔn)備準(zhǔn)備 需求分析員確定需求調(diào)查的方式 例如 與用戶交談 向用戶提問題 參觀用戶的工作流程 觀察用戶的操作 向用戶群體發(fā)調(diào)查問卷 與同行 專家交談 聽取他們的意見 分析已經(jīng)存在的同類軟件產(chǎn)品 提取需求 從行業(yè)標(biāo)準(zhǔn) 規(guī)則中提取需求 從 Internet 上搜查相關(guān)資料 需求分析員準(zhǔn)備調(diào)查問卷 問題表 需求分析員與被調(diào)查者建立聯(lián)系 確定調(diào)查的時間 地點 人員等 Step2 調(diào)查與記錄調(diào)查與記錄 需求分析員調(diào)查用戶需求 隨時記錄調(diào)查過程中所獲取的需求信息 Step3 分析需求信息分析需求信息 需求分析員分析已經(jīng)獲取的需求信息 消除錯誤 歸納與總結(jié)共性的用戶需求 Step4 撰寫用戶需求說明書撰寫用戶需求說明書 需求分析員按照指定的文檔模板撰寫 用戶需求說明書 主要內(nèi)容包括 產(chǎn)品介紹 描述用戶群體的特征 產(chǎn)品應(yīng)當(dāng)遵循的標(biāo)準(zhǔn)或規(guī)范 描述產(chǎn)品的功能性需求 描述產(chǎn)品的非功能性需求 如用戶界面 軟硬件環(huán)境 質(zhì)量等需求 補充說明 調(diào)查過程中獲取的需求信息可以作為 用戶需求說明書 的附件 后續(xù)活動 需求確認后續(xù)活動 需求確認 項目經(jīng)理邀請同行專家和用戶 包括客戶和最終用戶 一起評審 用戶需求說明書 盡最大努力使盡最大努力使 用戶需求說明書用戶需求說明書 能夠正確無誤地反映用戶的真實意愿 能夠正確無誤地反映用戶的真實意愿 需求評審之后 開發(fā)方和客戶方的責(zé)任人對 用戶需求說明書 作書面承諾 補充說明 需求確認 活動屬于需求管理范疇 詳見 SPP PROC RM 9 2 6 輸出輸出 用戶需求說明書 9 2 7 結(jié)束準(zhǔn)則結(jié)束準(zhǔn)則 需求分析員已經(jīng)撰寫完成 用戶需求說明書 并做了內(nèi)部審查 消除拼寫 排版等錯 誤 9 2 8 度量度量 需求分析員統(tǒng)計工作量和上述文檔的規(guī)模 匯報給項目經(jīng)理 9 3 產(chǎn)品需求定義產(chǎn)品需求定義 9 3 1 目的目的 定義準(zhǔn)確無誤的產(chǎn)品需求 產(chǎn)生 產(chǎn)品需求規(guī)格說明書 9 3 2 角色與職責(zé)角色與職責(zé) 需求分析員定義產(chǎn)品需求 客戶與最終用戶提供必要的需求信息 并確認產(chǎn)品需求 9 3 3 啟動準(zhǔn)則啟動準(zhǔn)則 用戶需求說明書 已經(jīng)撰寫完成 9 3 4 輸入輸入 用戶需求說明書 9 3 5 主要步驟主要步驟 Step1 細化并分析用戶需求細化并分析用戶需求 需求分析員對 用戶需求說明書 進行細化 以便產(chǎn)生詳細的產(chǎn)品需求 需求分析員對比較復(fù)雜的用戶需求進行建模分析 以幫助軟件開發(fā)人員更好地理解需 求 建議采用 Rational 的 Rose 工具進行需求的建模分析 建模分析產(chǎn)生的文檔可以 作為 產(chǎn)品需求規(guī)格說明書 的附件 補充說明 建模分析的技術(shù)難度比較高 需求分析員應(yīng)當(dāng)根據(jù)自身水平進行取舍 Step2 撰寫產(chǎn)品需求規(guī)格說明書撰寫產(chǎn)品需求規(guī)格說明書 需求分析員按照指定的文檔模板撰寫 產(chǎn)品需求規(guī)格說明書 如果待開發(fā)的產(chǎn)品分為 軟件和硬件兩部分的話 則應(yīng)當(dāng)分別撰寫 軟件需求規(guī)格說明書 和 硬件需求規(guī)格 說明書 產(chǎn)品需求規(guī)格說明書 的主要內(nèi)容包括 產(chǎn)品介紹 描述用戶群體的特征 定義產(chǎn)品的范圍 闡述產(chǎn)品應(yīng)當(dāng)遵循的標(biāo)準(zhǔn)或規(guī)范 定義產(chǎn)品中的角色 定義產(chǎn)品的功能性需求 定義產(chǎn)品的非功能性需求 如用戶界面 軟硬件環(huán)境 質(zhì)量等需求 后續(xù)活動 需求確認后續(xù)活動 需求確認 項目經(jīng)理邀請同行專家和用戶 包括客戶和最終用戶 一起評審 產(chǎn)品需求規(guī)格說明 書 盡最大努力使盡最大努力使 產(chǎn)品需求規(guī)格說明書產(chǎn)品需求規(guī)格說明書 能夠正確無誤地反映用戶的真實意愿 能夠正確無誤地反映用戶的真實意愿 需求評審之后 開發(fā)方和客戶方的責(zé)任人對 產(chǎn)品需求規(guī)格說明書 作書面承諾 補充說明 需求確認 活動屬于需求管理范疇 詳見 SPP PROC RM 9 3 6 輸出輸出 產(chǎn)品需求規(guī)格說明書 9 3 7 結(jié)束準(zhǔn)則結(jié)束準(zhǔn)則 產(chǎn)品需求規(guī)格說明書 已經(jīng)撰寫完成 已經(jīng)對產(chǎn)品需求進行了評審 并且獲得了開發(fā)方和客戶方對需求的承諾 9 3 8 度量度量 項目經(jīng)理統(tǒng)計工作量和上述文檔的規(guī)模 9 4 需求分析方法概述需求分析方法概述 很多時候用戶說不清楚需求 會說錯需求或者提出一些無法實現(xiàn)的需求 需求分析是指在需求開發(fā)過程中 對所獲取的需求信息進行分析 及時排除錯誤 彌 補不足 確保需求文檔正確地反映用戶的真實意圖 需求分析是需求開發(fā)過程中 最費腦子 的工作 分析方法大體有兩類 問答分析 法 和 建模分析法 后者技術(shù)性比較強 大多數(shù)軟件工程書籍都有論述 前者就是一些 常識而已 雖然寫不成文章 但是簡單易用 很有實用價值 9 4 1 問答分析法問答分析法 問答分析方法很簡單 刨根究底地問 如果解答了這些問題 那么需求也就分析清楚 了 一個人可以 自問自答 地分析需求 幾個人分析需求則稱為 研討 問答分析最重要的問題是 是什么 和 為什么 每個需求都應(yīng)當(dāng)用陳述句說明 是什么 如果 是什么 的內(nèi)涵不夠清晰 則應(yīng)補充 說明 不是什么 如果 是什么 和 不是什么 并不是 理所當(dāng)然 的 那么應(yīng)當(dāng)解釋 為什么 以便加深讀者的理解 追究 是什么 和 為什么 的目的是獲得正確 清楚 的需求 其它常見的問題有 需求存在二義性嗎 需求文檔的上下文有矛盾嗎 需求完備嗎 需求是必要的嗎 需求可實現(xiàn)嗎 需求可驗證嗎 需求的優(yōu)先級確定了嗎 9 4 2 建模分析法建模分析法 人們都有這樣地感受 有些時候用語言描述某個問題特別費勁 而采用圖形則使人一 目了然 所謂 一圖低千言 就是這個道理 在需求開發(fā)過程中 對于某些類型的信息 用圖形表示要比文本表示更加有效 所以 將圖形與文本結(jié)合起來描述需求是很自然的方法 需求建模就是指用圖形符號來表示 刻 畫需求 建模分析方法主要有兩大類 結(jié)構(gòu)化分析法 和 面向?qū)ο蠓治龇?一 結(jié)構(gòu)化分析法一 結(jié)構(gòu)化分析法 軟件的建模分析興起于 20 世紀(jì) 60 年代末期和 70 年代初期 結(jié)構(gòu)化分析方法并不是由 里程碑式的明確地涉及這個主題的一篇文章或者一本著作引入的 它也不是被所有使用者 一致采用的單一方法 相反地 它是幾乎發(fā)展了 20 多年的一個混合物 結(jié)構(gòu)化分析方法在 70 年代和 80 年代非常流行 相關(guān)論著很多 對結(jié)構(gòu)化分析方法有較大貢獻的學(xué)者有 DeMarco Gane Sarsen Yourdon Constantine Ward Mellor Hatly Pirbhai 等人 文獻 Pressmen99 p206 p214 對結(jié)構(gòu)化分析方法作了高度概括 如圖 9 2 所示 我們不妨稱之 為 一個中心三種圖 數(shù)據(jù)字典 是中心 它包含了軟件中所有數(shù)據(jù)對象的描述 實體 關(guān)系圖 是用圖形符號來標(biāo)識數(shù)據(jù)對象以及它們之間的關(guān)系 數(shù)據(jù)流圖 指明了數(shù)據(jù)在系統(tǒng)中移動時如何被變換 狀態(tài) 變遷圖 表示了系統(tǒng)存在的各種狀態(tài)以及它們之間的變遷方式 圖 9 2 結(jié)構(gòu)化分析方法示意圖 二 面向?qū)ο蠓治龇ǘ?面向?qū)ο蠓治龇?面向?qū)ο蠓治鲈O(shè)計 OOAD 方法興起于 20 世紀(jì) 80 年代 從 90 年代起至今它已經(jīng)在 分析設(shè)計領(lǐng)域占據(jù)了無可爭議的主流地位 作者在讀本科 90 年至 94 年 時就充分地感受到了人們對 面向?qū)ο?的狂熱 關(guān) 于 面向?qū)ο?的課堂 學(xué)術(shù)報告常常人滿為患 搞軟件研發(fā)的人都 言必談對象 并引 以為榮 面向?qū)ο蠓治鲈O(shè)計領(lǐng)域有一些比較著名的學(xué)派 如 Coad 和 Yourdon 學(xué)派 其代表作為 Coad91 Booch 學(xué)派 其代表作為 Booch94 Jocobson 學(xué)派 其代表作為 Jacobson92 Rumbaugh 學(xué)派 其代表作為 Rumbaugh91 有趣的是 這些學(xué)派的掌門人就像上帝 真主 如來佛 他們用各自的方式定義了這 個世界 并留下一堆經(jīng)書來解釋這個世界 這種混亂的局面被學(xué)術(shù)界稱為百家爭鳴 每年 誕生了許多論著和教授 叫苦的是軟件企業(yè)和開發(fā)人員 沒有統(tǒng)一的方法 不好干活啊 數(shù)據(jù)字 典 實體 關(guān)系圖數(shù)據(jù)流圖 狀態(tài) 變遷圖 終于等到了那一天 Rational 公司招納了 Booch Jocobson Rumbaugh 這三位 面向 對象 業(yè)界的權(quán)威強強聯(lián)手 制定了 統(tǒng)一建模語言 UML 1997 年 11 月 UML 被國 際對象管理組織 OMG 采納 此后 UML 成為 OOAD 建模語言的國際標(biāo)準(zhǔn) UML 吸取了各種 OOAD 方法的精髓 對于 OOAD 中的語義 圖形表示法和使用規(guī)則 作了完整而詳細的定義 UML 的建模能力超過了以往任何一種 OOAD 方法 當(dāng)然其復(fù)雜 性也隨之膨脹 大多數(shù)軟件開發(fā)人員沒有興趣閱讀枯燥乏味的 UML 文檔 如 Rumbaugh99 真正使 UML 流行的是 Rational 公司基于 UML 的建模工具 Rose Rose 易學(xué)易用 它能交互式地構(gòu)建類圖 用例圖 構(gòu)件圖 部署圖 狀態(tài)圖 活動圖 順序圖 協(xié)作圖等等 深得開發(fā)人員的喜愛 介紹 UML 和 Rose 的書籍非常多 讀者自己選擇 學(xué)習(xí) 這里不再論述 三 恰當(dāng)?shù)厥褂脠D形符號三 恰當(dāng)?shù)厥褂脠D形符號 現(xiàn)代建模工具如 Rose 有非常豐富的圖形符號和文字標(biāo)注 能很好地表達模型的細節(jié) 要注意的是 在建模時使用花樣過多的圖形符號或文字意味著模型表示的復(fù)雜化 將使開 發(fā)人員更難掌握 而且使圖形文檔更加雜亂 世上不存在一個包羅萬象的圖 它能完整