1、第15章. 需求規(guī)格說明主要內(nèi)容需求規(guī)格說明概述需求規(guī)格說明文檔模版的選擇與裁剪文檔寫作技巧優(yōu)秀需求規(guī)格說明文檔的特性1. 需求規(guī)格說明概述獲取 VS 分析 VS 規(guī)格說明需求獲取目標(biāo)是得到用戶需求收集需求信息需求分析目標(biāo)是更深刻的理解用戶需求界定能夠讓用戶滿意的解決方案準(zhǔn)則需求規(guī)格說明目標(biāo)是定義用戶需求準(zhǔn)確描述需求及其解決方案1. 需求規(guī)格說明概述需求規(guī)格說明活動主要內(nèi)容需求規(guī)格說明概述需求規(guī)格說明文檔模版的選擇與裁剪文檔寫作技巧優(yōu)秀需求規(guī)格說明文檔的特性2. 需求規(guī)格說明文檔作用更好的傳遞軟件系統(tǒng)的需求信息和解決方案給所有的開發(fā)者拓展人們的知識記憶能力作為合同協(xié)議的重要部分作為項目開發(fā)活動

2、的一個重要依據(jù)發(fā)現(xiàn)和減少可能的需求錯誤，減少項目的返工，降低項目的工作量作為有效的智力資產(chǎn)2. 需求規(guī)格說明文檔忽視的原因交流途徑時間壓力迭代式開發(fā)敏捷2. 需求規(guī)格說明文檔類型2. 需求規(guī)格說明文檔類型2. 需求規(guī)格說明文檔內(nèi)容前景和范圍內(nèi)問題域信息解決方案需求2. 需求規(guī)格說明文檔作者項目管理者組織安排、提供條件需求工程師負(fù)責(zé)人、主導(dǎo)人文檔寫作人員有時會采用，節(jié)省需求工程師的時間涉眾（用戶）驗證人2. 需求規(guī)格說明文檔讀者An Industrial Case Study of the Impact of Requirements Engineering on Downstream Deve

3、lopment2003An Industrial Case Study of the Impact of Requirements Engineering on Downstream Development20032. 需求規(guī)格說明文檔 手段非形式化自然語言限制性文本半形式化結(jié)構(gòu)化文本偽碼/結(jié)構(gòu)化英語模型語言圖、表形式化形式化語言數(shù)學(xué)語言：BNF，Z需求規(guī)格說明的實(shí)踐調(diào)查需求規(guī)格說明文檔的描述語言主要內(nèi)容需求規(guī)格說明概述需求規(guī)格說明文檔模版的選擇與裁剪文檔寫作技巧優(yōu)秀需求規(guī)格說明文檔的特性3. 模版的選擇與裁剪動機(jī)優(yōu)秀的文檔結(jié)構(gòu)組織復(fù)用：模版選擇與裁剪文字寫作字詞、句法寫作技巧3. 模版的選擇

4、與裁剪需求規(guī)格說明的實(shí)踐調(diào)查模版和示例的使用3. 模版的選擇與裁剪OO|對外交互操作模式用戶類OO-類圖狀態(tài)圖結(jié)構(gòu)化-DFD補(bǔ)充結(jié)構(gòu)化-實(shí)體關(guān)系圖How Does Requirements Quality Relate to Project Success or Failure?2007How Does Requirements Quality Relate to Project Success or Failure?2007Field Study on Requirements Engineering Artefacts and Patterns2010主要內(nèi)容需求規(guī)格說明概述需求規(guī)格說明文

5、檔模版的選擇與裁剪文檔寫作技巧優(yōu)秀需求規(guī)格說明文檔的特性4. 文檔寫作技巧原則寫作是一門藝術(shù)沒有什么固定的規(guī)律有一些效用有限的經(jīng)驗原則文檔的組織方式；常見情景的處理；常用的寫作技巧；容易出錯的地方等。文檔化的目標(biāo)是交流簡潔、易讀 VS 嚴(yán)格、準(zhǔn)確不要機(jī)械的照搬某些標(biāo)準(zhǔn)和規(guī)則4. 文檔寫作技巧結(jié)構(gòu)組織所有內(nèi)容位置得當(dāng)借鑒和使用標(biāo)準(zhǔn)的文檔模版引用或強(qiáng)化，但不重復(fù)引用而不是復(fù)制強(qiáng)化與重復(fù)引言與冗余元文本4. 文檔寫作技巧表達(dá)方式形式依賴于內(nèi)容根據(jù)需要表達(dá)的內(nèi)容，選擇合適的表達(dá)方式使用系統(tǒng)的表達(dá)方式人們傾向于系統(tǒng)的表達(dá)方式使用相同的語句格式來描述所有的細(xì)節(jié)需求。使用列表或者表格來組織獨(dú)立、并列的信息。

6、使用編號來表達(dá)繁雜信息之間的關(guān)系，包括順序關(guān)系、嵌套關(guān)系和層次關(guān)系。4. 文檔寫作技巧細(xì)節(jié)描述定義術(shù)語表或數(shù)據(jù)字典術(shù)語不一致“方言”問題錯誤術(shù)語和冗余術(shù)語避免干擾文本“這一段的意思是”“上一句話是指”避免歧義詞匯表151歧義詞匯改進(jìn)方法可接受的、足夠的具體定義可接受的內(nèi)容，說明系統(tǒng)怎樣判斷“可接受”或“足夠”大概可行的、差不多可行的不要讓開發(fā)人員來判斷“大概”和“差不多”到底是否成立。應(yīng)將其標(biāo)記為待確定問題并標(biāo)明解決日期至少、最小、不多于、不超過明確指定能夠接受的最大值和最小值在之間明確說明兩個端點(diǎn)是否在范圍之內(nèi)依賴描述依賴的原因，數(shù)據(jù)依賴？服務(wù)依賴？還是資源依賴？等等有效的明確“有效”所意味

7、的具體實(shí)際情況快的、迅速的明確指定系統(tǒng)在時間或速度上可接受的最小值靈活的描述系統(tǒng)為了響應(yīng)條件變化或需求變化而可能發(fā)生的變更方式改進(jìn)的、更好的、更快的、優(yōu)越的定量說明在一個專門的功能領(lǐng)域內(nèi)，充分改進(jìn)的程度和效果包括、包括但不限于、等等、諸如應(yīng)該列舉所有的可能性，否則就無法進(jìn)行設(shè)計和測試最大化、最小化、最優(yōu)說明對某些參數(shù)所能接受的最大值和最小值一般情況下、理想情況下需要增加描述系統(tǒng)在異常和非理想情況下的行為可選擇地具體說明是系統(tǒng)選擇、用戶選擇還是開發(fā)人員選擇合理的、在必要的時候、在適當(dāng)?shù)牡胤矫鞔_怎樣判斷合理、必要和適當(dāng)健壯的顯式定義系統(tǒng)如何處理異常和如何響應(yīng)預(yù)料之外的操作無縫的、透明的、優(yōu)雅的將詞

8、匯里面所反映的用戶期望轉(zhuǎn)化成能夠觀察到的產(chǎn)品特性若干聲明具體是多少，或提供某一范圍內(nèi)的最小邊界值和最大邊界值不應(yīng)該試著以肯定的方式陳述需求，描述系統(tǒng)應(yīng)該做什么最新技術(shù)水平的定義其具體含義，即“最新技術(shù)水平”意味什么充分的說明“充分”具體包括哪些內(nèi)容支持、允許精確地定義系統(tǒng)的功能，這些功能組合起來支持某些能力用戶友好的、簡單的、容易的描述系統(tǒng)特性，用這些特性說明詞匯所代表的用戶期望的實(shí)質(zhì)主要內(nèi)容需求規(guī)格說明概述需求規(guī)格說明文檔模版的選擇與裁剪文檔寫作技巧優(yōu)秀需求規(guī)格說明文檔的特性5. 優(yōu)秀需求規(guī)格說明文檔的特性完備性標(biāo)準(zhǔn)描述了用戶的所有有意義的需求，包括功能、性能、約束、質(zhì)量屬性和對外接口。定義

9、了軟件對所有情況的所有實(shí)際輸入（無論有效輸入還是無效輸入）的響應(yīng)。為文檔中的所有插圖、圖、表和術(shù)語、度量單位的定義提供了完整的引用和標(biāo)記。前景和范圍TBD問題5. 優(yōu)秀需求規(guī)格說明文檔的特性一致性標(biāo)準(zhǔn)細(xì)節(jié)的需求不能同高層次的需求相沖突，例如系統(tǒng)需求不能和業(yè)務(wù)需求、用戶需求互相矛盾同一層次的不同需求之間也不能互相沖突評審自動化檢查5. 優(yōu)秀需求規(guī)格說明文檔的特性根據(jù)重要性和穩(wěn)定性分級建立需求的優(yōu)先級可修改標(biāo)準(zhǔn)它的結(jié)構(gòu)和風(fēng)格使得人們可以對其中任一需求進(jìn)行容易地、完整地、一致地修改，同時還不會影響文檔現(xiàn)有的結(jié)構(gòu)和風(fēng)格文檔的可修改性要求：有著條理分明并且易于使用的組織方式，包括目錄、索引和顯式的交叉引

10、用。沒有重復(fù)冗余。獨(dú)立表達(dá)每個需求，而不是和其他需求混在一起。5. 優(yōu)秀需求規(guī)格說明文檔的特性可跟蹤前向跟蹤（Pre-traceability）能找到需求的來源，例如和更早期文檔的顯式關(guān)聯(lián)。后向跟蹤（Post-traceability）能找到需求所對應(yīng)的設(shè)計單元、實(shí)現(xiàn)源代碼和測試用例等，它要求每個需求都要有唯一的標(biāo)識或者可供引用的名稱實(shí)例分析由于時間壓力以及采取迭代開發(fā)的方式，造成了該項目沒有編寫需求規(guī)格說明書。但是可以采用更為靈活的方式編寫，例如wiki。我曾在某一預(yù)研性質(zhì)的項目中使用wiki來完成各類文檔。結(jié)果證明它非常好用。個人認(rèn)為wiki非常適合用在迭代開發(fā)以及預(yù)研性質(zhì)的項目中編寫文檔

11、。實(shí)例分析我們公司項目的需求規(guī)格說明書，主要存在以下幾點(diǎn)問題：模版不是很統(tǒng)一，具有很多個人的特點(diǎn)沒有明確的業(yè)務(wù)需求、用戶需求、系統(tǒng)需求，這三個層次，在需求規(guī)格說明書中或多或少地涵蓋前三項內(nèi)容，但顯得不夠飽滿和清晰。鑒于項目的狀況，一般較少考慮硬件需求，倒是一般來說，項目上線選用的都是最新的硬件設(shè)備，成本較高。內(nèi)容的書寫，自然語言居多，出現(xiàn)歧義、省略、模糊的機(jī)會較多，質(zhì)量不高從項目的后期來看，性能需求、約束、質(zhì)量需求沒有明確地分門別類地明確列出，導(dǎo)致后期項目中的各個業(yè)務(wù)流程還是基本可行，但是整體系統(tǒng)還是出現(xiàn)不滿足需求的地方。實(shí)例分析需求分析報告中夾雜了很多專業(yè)名詞和行業(yè)名詞，例如橫沖、平衡等等，部分客戶看不懂，部分程序員看不懂，只有自己心里明白，但這樣就會造成客戶和程序員理解上的問題，應(yīng)該加些注釋盡量寫得比較白話。另外報告中寫得比較凌亂，沒有把相關(guān)問題歸類整合，編寫目錄，并得到客戶的簽字確認(rèn)，導(dǎo)致程序員零散地一條條對著開發(fā)，很多地方銜接不是很好，另外客戶很多想法尤其一些重要部分在軟件交付的時候會有所改變，沒有簽字確認(rèn)