第9章 需求開發(fā)
第9章 需求開發(fā) 1 9.1 介紹 1 9.2 用戶需求調(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ù)活動：需求確認(rèn)] 3 9.2.6 輸出 4 9.2.7 結(jié)束準(zhǔn)則 4 9.2.8 度量 4 9.3 產(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ù)活動：需求確認(rèn)] 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ā)（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ā)與需求管理流程圖 需求開發(fā)可分為兩個階段：“用戶需求調(diào)查階段”和“產(chǎn)品需求定義階段”。而“需求分 析”則貫穿于上述兩個階段。需求調(diào)查階段和需求定義階段在邏輯上存在先后關(guān)系，實際 工作中二者通常是迭代進行的。我們把從事需求開發(fā)工作的人員稱為需求分析員（也叫 系統(tǒng)分析員），避免與其它開發(fā)人員混淆。 一、需求調(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)查 9.2.1 目的 o 獲取用戶（客戶與最終用戶）的需求信息，經(jīng)過分析后產(chǎn)生《用戶需求說明書》。 9.2.2 角色與職責(zé) o 需求分析員調(diào)查、分析用戶的需求。 o 客戶與最終用戶提供必要的需求信息。 9.2.3 啟動準(zhǔn)則 o 需求分析員已經(jīng)確定。 9.2.4 輸入 o 任何與用戶需求相關(guān)的材料 9.2.5 主要步驟 [Step1] 準(zhǔn)備 o 需求分析員確定需求調(diào)查的方式，例如： ← 與用戶交談，向用戶提問題。 ← 參觀用戶的工作流程，觀察用戶的操作。 ← 向用戶群體發(fā)調(diào)查問卷。 ← 與同行、專家交談，聽取他們的意見。 ← 分析已經(jīng)存在的同類軟件產(chǎn)品，提取需求。 ← 從行業(yè)標(biāo)準(zhǔn)、規(guī)則中提取需求。 ← 從Internet上搜查相關(guān)資料。 o 需求分析員準(zhǔn)備調(diào)查問卷（問題表）。 o 需求分析員與被調(diào)查者建立聯(lián)系，確定調(diào)查的時間、地點、人員等。 [Step2] 調(diào)查與記錄 o 需求分析員調(diào)查用戶需求，隨時記錄調(diào)查過程中所獲取的需求信息。 [Step3] 分析需求信息 o 需求分析員分析已經(jīng)獲取的需求信息，消除錯誤，歸納與總結(jié)共性的用戶需求。 [Step4] 撰寫用戶需求說明書 o 需求分析員按照指定的文檔模板撰寫《用戶需求說明書》，主要內(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ù)活動：需求確認(rèn)] o 項目經(jīng)理邀請同行專家和用戶（包括客戶和最終用戶）一起評審《用戶需求說明書》，盡 最大努力使《用戶需求說明書》能夠正確無誤地反映用戶的真實意愿。 o 需求評審之后，開發(fā)方和客戶方的責(zé)任人對《用戶需求說明書》作書面承諾。 補充說明：“需求確認(rèn)”活動屬于需求管理范疇，詳見 [SPP-PROC-RM] 。 9.2.6 輸出 o 《用戶需求說明書》 9.2.7 結(jié)束準(zhǔn)則 o 需求分析員已經(jīng)撰寫完成《用戶需求說明書》，并做了內(nèi)部審查（消除拼寫、排版等錯誤 ）。 9.2.8 度量 o 需求分析員統(tǒng)計工作量和上述文檔的規(guī)模，匯報給項目經(jīng)理。 9.3 產(chǎn)品需求定義 9.3.1 目的 o 定義準(zhǔn)確無誤的產(chǎn)品需求，產(chǎn)生《產(chǎn)品需求規(guī)格說明書》。 9.3.2 角色與職責(zé) o 需求分析員定義產(chǎn)品需求。 o 客戶與最終用戶提供必要的需求信息，并確認(rèn)產(chǎn)品需求。 9.3.3 啟動準(zhǔn)則 o 《用戶需求說明書》已經(jīng)撰寫完成。 9.3.4 輸入 o 《用戶需求說明書》 9.3.5 主要步驟 [Step1] 細化并分析用戶需求 o 需求分析員對《用戶需求說明書》進行細化，以便產(chǎn)生詳細的產(chǎn)品需求。 o 需求分析員對比較復(fù)雜的用戶需求進行建模分析，以幫助軟件開發(fā)人員更好地理解需求 。建議采用Rational 的Rose工具進行需求的建模分析，建模分析產(chǎn)生的文檔可以作為《產(chǎn)品需求規(guī)格說明 書》的附件。 補充說明：建模分析的技術(shù)難度比較高，需求分析員應(yīng)當(dāng)根據(jù)自身水平進行取舍。 [Step2] 撰寫產(chǎn)品需求規(guī)格說明書 o 需求分析員按照指定的文檔模板撰寫《產(chǎn)品需求規(guī)格說明書》。如果待開發(fā)的產(chǎn)品分為軟 件和硬件兩部分的話，則應(yīng)當(dāng)分別撰寫《軟件需求規(guī)格說明書》和《硬件需求規(guī)格說明 書》。 o 《產(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ù)活動：需求確認(rèn)] o 項目經(jīng)理邀請同行專家和用戶（包括客戶和最終用戶）一起評審《產(chǎn)品需求規(guī)格說明書 》，盡最大努力使《產(chǎn)品需求規(guī)格說明書》能夠正確無誤地反映用戶的真實意愿。 o 需求評審之后，開發(fā)方和客戶方的責(zé)任人對《產(chǎn)品需求規(guī)格說明書》作書面承諾。 補充說明：“需求確認(rèn)”活動屬于需求管理范疇，詳見 [SPP-PROC-RM] 。 9.3.6 輸出 o 《產(chǎn)品需求規(guī)格說明書》 9.3.7 結(jié)束準(zhǔn)則 o 《產(chǎn)品需求規(guī)格說明書》已經(jīng)撰寫完成。 o 已經(jīng)對產(chǎn)品需求進行了評審，并且獲得了開發(fā)方和客戶方對需求的承諾。 9.3.8 度量 o 項目經(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)化分析法 軟件的建模分析興起于20世紀(jì)60年代末期和70年代初期。結(jié)構(gòu)化分析方法并不是由里程 碑式的明確地涉及這個主題的一篇文章或者一本著作引入的，它也不是被所有使用者一 致采用的單一方法。相反地，它是幾乎發(fā)展了20多年的一個混合物。結(jié)構(gòu)化分析方法在 70年代和80年代非常流行，相關(guān)論著很多。對結(jié)構(gòu)化分析方法有較大貢獻的學(xué)者有DeMa rco, 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ū)ο蠓治鲈O(shè)計（OOAD）方法興起于20世紀(jì)80年代，從90年代起至今它已經(jīng)在分析設(shè) 計領(lǐng)域占據(jù)了無可爭議的主流地位。 作者在讀本科（90年至94年）時就充分地感受到了人們對“面向?qū)ο蟆钡目駸?。關(guān)于“面向 對象”的課堂、學(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)一的方法，不好干活 啊！ 終于等到了那一天，Rational公司招納了Booch, Jocobson, Rumbaugh，這三位“面向?qū)ο蟆睒I(yè)界的權(quán)威強強聯(lián)手，制定了“統(tǒng)一建模語言”（UML）。1 997年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形符號 現(xiàn)代建模工具如Rose有非常豐富的圖形符號和文字標(biāo)注，能很好地表達模型的細節(jié)。要 注意的是：在建模時使用花樣過多的圖形符號或文字意味著模型表示的復(fù)雜化，將使開 發(fā)人員更難掌握，而且使圖形文檔更加雜亂。 世上不存在一個包羅萬象的圖——它能完整地描述需求。需求建模不可能取代文字描述。 在需求規(guī)格說明書中，文字描述是第一重要的，建模主要是起分析、解釋作用。建議將 模型存放在需求規(guī)格說明書的附錄中，便于正文引用。 9.5 實施建議 o 先對需求分析員進行培訓(xùn)，讓他們掌握必要的需求開發(fā)技能。 o 對需求開發(fā)過程域產(chǎn)生的所有有價值的文檔進行配置管理。 o 對于非合同項目，本規(guī)范中有關(guān)客戶的活動可以簡化。 o 需求的建模分析有較高的技術(shù)難度，需求分析員應(yīng)當(dāng)根據(jù)自身水平進行取舍。建議企業(yè) 購買Rational Rose作為需求建模分析的工具。 o 需求分析員...
第9章 需求開發(fā)