需求開發(fā)
第9章 需求開發(fā) 1
9.1 介紹 1
9.2 用戶需求調(diào)查 2
9.2.1 目的 2
9.2.2 角色與職責(zé) 2
9.2.3 啟動(dòng)準(zhǔn)則 2
9.2.4 輸入 2
9.2.5 主要步驟 3
[Step1] 準(zhǔn)備 3
[Step2] 調(diào)查與記錄 3
[Step3] 分析需求信息 3
[Step4] 撰寫用戶需求說明書 3
[后續(xù)活動(dòng)：需求確認(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 啟動(dòng)準(zhǔn)則 4
9.3.4 輸入 4
9.3.5 主要步驟 5
[Step1] 細(xì)化并分析用戶需求 5
[Step2] 撰寫產(chǎn)品需求規(guī)格說明書 5
[后續(xù)活動(dòng)：需求確認(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 實(shí)施建議 8
第9章 需求開發(fā)

需求開發(fā)（Requirement Development, RD）的目的是通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。
需求開發(fā)過程域是SPP模型的重要組成部分。本規(guī)范闡述了需求開發(fā)過程域的兩個(gè)主要規(guī)程：
 需求調(diào)查 [SPP-PROC-RM-SURVEY]
 需求定義 [SPP-PROC-RM-DEFINE]
上述每個(gè)規(guī)程的“目標(biāo)”、“角色與職責(zé)”、“啟動(dòng)準(zhǔn)則”、“輸入”、“主要步驟”、“輸出”、“完成準(zhǔn)則”和“度量”均已定義。
需求分析是需求開發(fā)過程域的重要活動(dòng)之一，但是不宜用“規(guī)范”這種形式來論述。本章對需求分析方法作了概括性介紹，請讀者閱讀更加專業(yè)性的需求分析論著。
本規(guī)范適用于國內(nèi)IT企業(yè)的軟件研發(fā)項(xiàng)目。建議用戶根據(jù)自身情況（如商業(yè)目標(biāo)、研發(fā)實(shí)力等）適當(dāng)?shù)匦薷谋疽?guī)范，然后推廣使用。
9.1 介紹
需求開發(fā)與需求管理是相輔相成的兩類活動(dòng)，它們共同構(gòu)成完整的需求工程。需求工程結(jié)構(gòu)圖如圖8-1所示，需求開發(fā)和需求管理的流程如圖9-1所示。


圖9-2 需求開發(fā)與需求管理流程圖

需求開發(fā)可分為兩個(gè)階段：“用戶需求調(diào)查階段”和“產(chǎn)品需求定義階段”。而“需求分析”則貫穿于上述兩個(gè)階段。需求調(diào)查階段和需求定義階段在邏輯上存在先后關(guān)系，實(shí)際工作中二者通常是迭代進(jìn)行的。我們把從事需求開發(fā)工作的人員稱為需求分析員（也叫系統(tǒng)分析員），避免與其它開發(fā)人員混淆。
一、需求調(diào)查
需求調(diào)查的目的是通過各種途徑獲取用戶的需求信息（原始材料），產(chǎn)生《用戶需求說明書》。
二、需求分析
需求分析的目的是對各種需求信息進(jìn)行分析，消除錯(cuò)誤，刻畫細(xì)節(jié)等。常用的需求分析方法有“問答分析法”、“結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇?rdquo;。
三、需求定義
需求定義的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果，進(jìn)一步定義準(zhǔn)確無誤的產(chǎn)品需求，產(chǎn)生《產(chǎn)品需求規(guī)格說明書》。系統(tǒng)設(shè)計(jì)人員將依據(jù)《產(chǎn)品需求規(guī)格說明書》開展系統(tǒng)設(shè)計(jì)工作。
需求開發(fā)過程域產(chǎn)生的主要文檔有：
 《用戶需求說明書》，模板見 [SPP-TEMP-RD-UR]。
 《產(chǎn)品需求規(guī)格說明書》，模板見 [SPP-TEMP-RD-PRS]。
9.2 用戶需求調(diào)查
9.2.1 目的
 獲取用戶（客戶與最終用戶）的需求信息，經(jīng)過分析后產(chǎn)生《用戶需求說明書》。
9.2.2 角色與職責(zé)
 需求分析員調(diào)查、分析用戶的需求。
 客戶與最終用戶提供必要的需求信息。
9.2.3 啟動(dòng)準(zhǔn)則
 需求分析員已經(jīng)確定。
9.2.4 輸入
 任何與用戶需求相關(guān)的材料
9.2.5 主要步驟
[Step1] 準(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)查的時(shí)間、地點(diǎn)、人員等。
[Step2] 調(diào)查與記錄
 需求分析員調(diào)查用戶需求，隨時(shí)記錄調(diào)查過程中所獲取的需求信息。
[Step3] 分析需求信息
 需求分析員分析已經(jīng)獲取的需求信息，消除錯(cuò)誤，歸納與總結(jié)共性的用戶需求。
[Step4] 撰寫用戶需求說明書
 需求分析員按照指定的文檔模板撰寫《用戶需求說明書》，主要內(nèi)容包括：
 產(chǎn)品介紹；
 描述用戶群體的特征；
 產(chǎn)品應(yīng)當(dāng)遵循的標(biāo)準(zhǔn)或規(guī)范；
 描述產(chǎn)品的功能性需求；
 描述產(chǎn)品的非功能性需求，如用戶界面、軟硬件環(huán)境、質(zhì)量等需求。
補(bǔ)充說明：調(diào)查過程中獲取的需求信息可以作為《用戶需求說明書》的附件。
[后續(xù)活動(dòng)：需求確認(rèn)]
 項(xiàng)目經(jīng)理邀請同行專家和用戶（包括客戶和最終用戶）一起評審《用戶需求說明書》，盡最大努力使《用戶需求說明書》能夠正確無誤地反映用戶的真實(shí)意愿。
 需求評審之后，開發(fā)方和客戶方的責(zé)任人對《用戶需求說明書》作書面承諾。
補(bǔ)充說明：“需求確認(rèn)”活動(dòng)屬于需求管理范疇，詳見 [SPP-PROC-RM] 。
9.2.6 輸出
 《用戶需求說明書》
9.2.7 結(jié)束準(zhǔn)則
 需求分析員已經(jīng)撰寫完成《用戶需求說明書》，并做了內(nèi)部審查（消除拼寫、排版等錯(cuò)誤）。
9.2.8 度量
 需求分析員統(tǒng)計(jì)工作量和上述文檔的規(guī)模，匯報(bào)給項(xiàng)目經(jīng)理。
9.3 產(chǎn)品需求定義
9.3.1 目的
 定義準(zhǔn)確無誤的產(chǎn)品需求，產(chǎn)生《產(chǎn)品需求規(guī)格說明書》。
9.3.2 角色與職責(zé)
 需求分析員定義產(chǎn)品需求。
 客戶與最終用戶提供必要的需求信息，并確認(rèn)產(chǎn)品需求。
9.3.3 啟動(dòng)準(zhǔn)則
 《用戶需求說明書》已經(jīng)撰寫完成。
9.3.4 輸入
 《用戶需求說明書》
9.3.5 主要步驟
[Step1] 細(xì)化并分析用戶需求
 需求分析員對《用戶需求說明書》進(jìn)行細(xì)化，以便產(chǎn)生詳細(xì)的產(chǎn)品需求。
 需求分析員對比較復(fù)雜的用戶需求進(jìn)行建模分析，以幫助軟件開發(fā)人員更好地理解需求。建議采用Rational 的Rose工具進(jìn)行需求的建模分析，建模分析產(chǎn)生的文檔可以作為《產(chǎn)品需求規(guī)格說明書》的附件。
補(bǔ)充說明：建模分析的技術(shù)難度比較高，需求分析員應(yīng)當(dāng)根據(jù)自身水平進(jìn)行取舍。
[Step2] 撰寫產(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ù)活動(dòng)：需求確認(rèn)]
 項(xiàng)目經(jīng)理邀請同行專家和用戶（包括客戶和最終用戶）一起評審《產(chǎn)品需求規(guī)格說明書》，盡最大努力使《產(chǎn)品需求規(guī)格說明書》能夠正確無誤地反映用戶的真實(shí)意愿。
 需求評審之后，開發(fā)方和客戶方的責(zé)任人對《產(chǎn)品需求規(guī)格說明書》作書面承諾。
補(bǔ)充說明：“需求確認(rèn)”活動(dòng)屬于需求管理范疇，詳見 [SPP-PROC-RM] 。
9.3.6 輸出
 《產(chǎn)品需求規(guī)格說明書》
9.3.7 結(jié)束準(zhǔn)則
 《產(chǎn)品需求規(guī)格說明書》已經(jīng)撰寫完成。
 已經(jīng)對產(chǎn)品需求進(jìn)行了評審，并且獲得了開發(fā)方和客戶方對需求的承諾。
9.3.8 度量
 項(xiàng)目經(jīng)理統(tǒng)計(jì)工作量和上述文檔的規(guī)模。
9.4 需求分析方法概述
很多時(shí)候用戶說不清楚需求、會說錯(cuò)需求或者提出一些無法實(shí)現(xiàn)的需求。
需求分析是指在需求開發(fā)過程中，對所獲取的需求信息進(jìn)行分析，及時(shí)排除錯(cuò)誤、彌補(bǔ)不足，確保需求文檔正確地反映用戶的真實(shí)意圖。
需求分析是需求開發(fā)過程中“最費(fèi)腦子”的工作。分析方法大體有兩類：“問答分析法”和“建模分析法”。后者技術(shù)性比較強(qiáng)，大多數(shù)軟件工程書籍都有論述。前者就是一些常識而已，雖然寫不成文章，但是簡單易用，很有實(shí)用價(jià)值。
9.4.1 問答分析法
問答分析方法很簡單：刨根究底地問，如果解答了這些問題，那么需求也就分析清楚了。一個(gè)人可以“自問自答”地分析需求，幾個(gè)人分析需求則稱為“研討”。
問答分析最重要的問題是：“是什么”和“為什么”。
每個(gè)需求都應(yīng)當(dāng)用陳述句說明“是什么”，如果“是什么”的內(nèi)涵不夠清晰，則應(yīng)補(bǔ)充說明“不是什么”。如果“是什么”和“不是什么”并不是“理所當(dāng)然”的，那么應(yīng)當(dāng)解釋“為什么”，以便加深讀者的理解。追究“是什么”和“為什么”的目的是獲得正確、清楚的需求。
其它常見的問題有：
 需求存在二義性嗎？
 需求文檔的上下文有矛盾嗎？
 需求完備嗎？
 需求是必要的嗎？
 需求可實(shí)現(xiàn)嗎？
 需求可驗(yàn)證嗎？
 需求的優(yōu)先級確定了嗎？
9.4.2 建模分析法
人們都有這樣地感受：有些時(shí)候用語言描述某個(gè)問題特別費(fèi)勁，而采用圖形則使人一目了然，所謂“一圖低千言”就是這個(gè)道理。
在需求開發(fā)過程中，對于某些類型的信息，用圖形表示要比文本表示更加有效。所以將圖形與文本結(jié)合起來描述需求是很自然的方法。需求建模就是指用圖形符號來表示、刻畫需求。建模分析方法主要有兩大類：“結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇?rdquo;。
一、結(jié)構(gòu)化分析法
軟件的建模分析興起于20世紀(jì)60年代末期和70年代初期。結(jié)構(gòu)化分析方法并不是由里程碑式的明確地涉及這個(gè)主題的一篇文章或者一本著作引入的，它也不是被所有使用者一致采用的單一方法。相反地，它是幾乎發(fā)展了20多年的一個(gè)混合物。結(jié)構(gòu)化分析方法在70年代和80年代非常流行，相關(guān)論著很多。對結(jié)構(gòu)化分析方法有較大貢獻(xiàn)的學(xué)者有DeMarco, Gane, Sarsen, Yourdon, Constantine, Ward, Mellor, Hatly, Pirbhai等人。文獻(xiàn)[Pressmen99, p206-p214]對結(jié)構(gòu)化分析方法作了高度概括（如圖9-2所示），我們不妨稱之為“一個(gè)中心三種圖”：
 “數(shù)據(jù)字典”是中心，它包含了軟件中所有數(shù)據(jù)對象的描述。
 “實(shí)體－關(guān)系圖”是用圖形符號來標(biāo)識數(shù)據(jù)對象以及它們之間的關(guān)系。
 “數(shù)據(jù)流圖”指明了數(shù)據(jù)在系統(tǒng)中移動(dòng)時(shí)如何被變換。
 “狀態(tài)－變遷圖”表示了系統(tǒng)存在的各種狀態(tài)以及它們之間的變遷方式。

圖9-2 結(jié)構(gòu)化分析方法示意圖
二、面向?qū)ο蠓治龇?
面向?qū)ο蠓治鲈O(shè)計(jì)（OOAD）方法興起于20世紀(jì)80年代，從90年代起至今它已經(jīng)在分析設(shè)計(jì)領(lǐng)域占據(jù)了無可爭議的主流地位。
作者在讀本科（90年至94年）時(shí)就充分地感受到了人們對“面向?qū)ο?rdquo;的狂熱。關(guān)于“面向?qū)ο?rdquo;的課堂、學(xué)術(shù)報(bào)告常常人滿為患。搞軟件研發(fā)的人都“言必談對象”，并引以為榮。
面向?qū)ο蠓治鲈O(shè)計(jì)領(lǐng)域有一些比較著名的學(xué)派，如：
 Coad和Yourdon學(xué)派，其代表作為[Coad91]。
 Booch學(xué)派，其代表作為[Booch94]。
 Jocobson學(xué)派，其代表作為[Jacobson92]。
 Rumbaugh學(xué)派，其代表作為[Rumbaugh91]。
有趣的是，這些學(xué)派的掌門人就像上帝、真主、如來佛，他們用各自的方式定義了這個(gè)世界，并留下一堆經(jīng)書來解釋這個(gè)世界。這種混亂的局面被學(xué)術(shù)界稱為百家爭鳴，每年誕生了許多論著和教授。叫苦的是軟件企業(yè)和開發(fā)人員：沒有統(tǒng)一的方法，不好干活?。?
終于等到了那一天，Rational公司招納了Booch, Jocobson, Rumbaugh，這三位“面向?qū)ο?rdquo;業(yè)界的權(quán)威強(qiáng)強(qiáng)聯(lián)手，制定了“統(tǒng)一建模語言”（UML）。1997年11月，UML被國際對象管理組織（OMG）采納，此后UML成為OOAD建模語言的國際標(biāo)準(zhǔn)。
UML吸取了各種OOAD方法的精髓，對于OOAD中的語義、圖形表示法和使用規(guī)則作了完整而詳細(xì)的定義。UML的建模能力超過了以往任何一種OOAD方法，當(dāng)然其復(fù)雜性也隨之膨脹。大多數(shù)軟件開發(fā)人員沒有興趣閱讀枯燥乏味的UML文檔（如[Rumbaugh99]）。真正使UML流行的是Rational公司基于UML的建模工具Rose。Rose易學(xué)易用，它能交互式地構(gòu)建類圖、用例圖、構(gòu)件圖、部署圖、狀態(tài)圖、活動(dòng)圖、順序圖、協(xié)作圖等等，深得開發(fā)人員的喜愛。
介紹UML和Rose的書籍非常多，讀者自己選擇、學(xué)習(xí)，這里不再論述。
三、恰當(dāng)?shù)厥褂脠D形符號
現(xiàn)代建模工具如Rose有非常豐富的圖形符號和文字標(biāo)注，能很好地表達(dá)模型的細(xì)節(jié)。要注意的是：在建模時(shí)使用花樣過多的圖形符號或文字意味著模型表示的復(fù)雜化，將使開發(fā)人員更難掌握，而且使圖形文檔更加雜亂。
世上不存在一個(gè)包羅萬象的圖——它能完整地描述需求。需求建模不可能取代文字描述。在需求規(guī)格說明書中，文字描述是第一重要的，建模主要是起分析、解釋作用。建議將模型存放在需求規(guī)格說明書的附錄中，便于正文引用。
9.5 實(shí)施建議
 先對需求分析員進(jìn)行培訓(xùn)，讓他們掌握必要的需求開發(fā)技能。
 對需求開發(fā)過程域產(chǎn)生的所有有價(jià)值的文檔進(jìn)行配置管理。
 對于非合同項(xiàng)目，本規(guī)范中有關(guān)客戶的活動(dòng)可以簡化。
 需求的建模分析有較高的技術(shù)難度，需求分析員應(yīng)當(dāng)根據(jù)自身水平進(jìn)行取舍。建議企業(yè)購買Rational Rose作為需求建模分析的工具。
 需求分析員根據(jù)產(chǎn)品的特征，適當(dāng)?shù)匦薷摹队脩粜枨笳f明書》和《產(chǎn)品需求規(guī)格說明書》的模板。
需求開發(fā)