軟件需求講義-第四部分

軟件(ruǎnjiàn)需求（四）共九十二頁需求文檔與需求質(zhì)量(zhìliàng)驗(yàn)證軟件需求規(guī)格(guīgé)說明需求驗(yàn)證需求評(píng)審共九十二頁

第16章.需求規(guī)格(guīgé)說明共九十二頁主要(zhǔyào)內(nèi)容需求規(guī)格說明(shuōmíng)概述需求規(guī)格說明文檔模版的選擇與裁剪文檔寫作技巧優(yōu)秀需求規(guī)格說明文檔的特性需求規(guī)格說明的實(shí)踐調(diào)查共九十二頁需求規(guī)格說明(shuōmíng)概述

——獲取VS分析VS規(guī)格說明需求獲取目標(biāo)是得到用戶需求——收集需求信息需求分析(fēnxī)目標(biāo)是更深刻的理解用戶需求——界定能夠讓用戶滿意的解決方案準(zhǔn)則需求規(guī)格說明目標(biāo)是定義用戶需求——準(zhǔn)確描述需求及其解決方案共九十二頁你可以用三種方法編寫軟件需求規(guī)格說明：?用好的結(jié)構(gòu)化和自然語言編寫文本(wénběn)型文檔。?建立圖形化模型，這些模型可以描繪轉(zhuǎn)換過程、系統(tǒng)狀態(tài)和它們之間的變化、數(shù)據(jù)關(guān)系、邏輯流或?qū)ο箢惡退鼈兊年P(guān)系。?編寫形式化規(guī)格說明，這可以通過使用數(shù)學(xué)上精確的形式化邏輯語言來定義需求。軟件需求(xūqiú)太原理工大學(xué)軟件學(xué)院2015? 共九十二頁第16章軟件(ruǎnjiàn)需求規(guī)格說明

主要內(nèi)容(nèiróng)：需求規(guī)格說明概述需求規(guī)格說明文檔模版的選擇與裁剪文檔寫作技巧優(yōu)秀需求規(guī)格說明文檔的特性需求規(guī)格說明的實(shí)踐調(diào)查共九十二頁SRS（SoftwareRequirementSpecification）是軟件項(xiàng)目初期階段重要的一步，它從問題域的識(shí)別和定義，逐步轉(zhuǎn)移至解決域中。解決域需要用需求模型來描述。SRS提供了容納(róngnà)這些模型的框架。一個(gè)完整的SRS不僅是包括長長的功能性需求列表，還包括外部接口描述和一些諸如質(zhì)量屬性、期望性能等非功能性需求。SRS是初期問題域的識(shí)別和描述；解決域需要用需求模型來描述。SRS需求(xūqiú)規(guī)格說明書軟件需求太原理工大學(xué)軟件學(xué)院2015? 共九十二頁1.需求(xūqiú)規(guī)格說明概述

——需求規(guī)格說明活動(dòng)共九十二頁主要(zhǔyào)內(nèi)容需求規(guī)格說明概述需求規(guī)格說明文檔模版的選擇與裁剪(cáijiǎn)文檔寫作技巧優(yōu)秀需求規(guī)格說明文檔的特性需求規(guī)格說明的實(shí)踐調(diào)查共九十二頁需求規(guī)格(guīgé)說明模版（IEEE/ANSI830-1993）共九十二頁2.需求規(guī)格說明(shuōmíng)文檔

——作用更好的傳遞軟件系統(tǒng)的需求信息和解決方案給所有的開發(fā)者拓展人們的知識(shí)(zhīshi)記憶能力作為合同協(xié)議的重要部分作為項(xiàng)目開發(fā)活動(dòng)的一個(gè)重要依據(jù)發(fā)現(xiàn)和減少可能的需求錯(cuò)誤，減少項(xiàng)目的返工，降低項(xiàng)目的工作量作為有效的智力資產(chǎn)共九十二頁2.需求規(guī)格(guīgé)說明文檔

——忽視的原因交流途徑時(shí)間壓力迭代式開發(fā)(kāifā)敏捷共九十二頁2.需求規(guī)格(guīgé)說明文檔

——類型共九十二頁2.需求規(guī)格(guīgé)說明文檔

——類型共九十二頁2.需求規(guī)格說明(shuōmíng)文檔

——內(nèi)容前景(qiánjǐng)和范圍內(nèi)問題域信息解決方案需求共九十二頁2.需求(xūqiú)規(guī)格說明文檔

——作者項(xiàng)目管理者組織安排(ānpái)、提供條件需求工程師負(fù)責(zé)人、主導(dǎo)人文檔寫作人員有時(shí)會(huì)采用，節(jié)省需求工程師的時(shí)間涉眾（用戶）驗(yàn)證人共九十二頁2.需求(xūqiú)規(guī)格說明文檔

——讀者共九十二頁2.需求規(guī)格說明(shuōmíng)文檔

——手段非形式化自然語言限制性文本半形式化結(jié)構(gòu)化文本偽碼/結(jié)構(gòu)化英語(yīnɡyǔ)模型語言圖、表…形式化形式化語言數(shù)學(xué)語言：BNF，Z…共九十二頁主要(zhǔyào)內(nèi)容需求規(guī)格說明概述需求規(guī)格說明文檔模版的選擇與裁剪(cáijiǎn)文檔寫作技巧優(yōu)秀需求規(guī)格說明文檔的特性需求規(guī)格說明的實(shí)踐調(diào)查共九十二頁3.模版的選擇(xuǎnzé)與裁剪

——?jiǎng)訖C(jī)優(yōu)秀的文檔結(jié)構(gòu)組織復(fù)用：模版選擇與裁剪文字(wénzì)寫作字詞、句法寫作技巧共九十二頁共九十二頁主要(zhǔyào)內(nèi)容需求規(guī)格說明概述需求規(guī)格說明文檔模版的選擇(xuǎnzé)與裁剪文檔寫作技巧優(yōu)秀需求規(guī)格說明文檔的特性需求規(guī)格說明的實(shí)踐調(diào)查共九十二頁4.文檔寫作技巧

——原則(yuánzé)寫作是一門藝術(shù)沒有什么固定的規(guī)律有一些效用有限的經(jīng)驗(yàn)原則文檔的組織方式；常見情景的處理；常用的寫作技巧；容易出錯(cuò)的地方等。文檔化的目標(biāo)是交流簡潔、易讀VS嚴(yán)格、準(zhǔn)確不要機(jī)械的照搬某些標(biāo)準(zhǔn)(biāozhǔn)和規(guī)則有沒有另外一種更容易理解的表達(dá)方式？是否一次性提供了太多的信息？對(duì)讀者來說什么是重要的，什么是不重要的？是否太抽象了？需不需要舉例說明？是否太專業(yè)了？需不需要解釋原理？會(huì)不會(huì)引起讀者對(duì)內(nèi)容的錯(cuò)誤解釋？哪些內(nèi)容有益于讀者？有益于哪些讀者？文檔在整體上是不是過于機(jī)械、乏味或者松散？文檔枯燥嗎？令人厭煩嗎？共九十二頁4.文檔寫作技巧

——結(jié)構(gòu)(jiégòu)組織所有內(nèi)容位置得當(dāng)借鑒和使用標(biāo)準(zhǔn)的文檔模版引用或強(qiáng)化(qiánghuà)，但不重復(fù)引用而不是復(fù)制強(qiáng)化與重復(fù)引言與冗余元文本共九十二頁4.文檔寫作技巧

——表達(dá)方式形式依賴于內(nèi)容根據(jù)需要表達(dá)的內(nèi)容，選擇合適的表達(dá)方式使用系統(tǒng)的表達(dá)方式人們傾向于系統(tǒng)的表達(dá)方式使用相同的語句格式來描述所有的細(xì)節(jié)需求。使用列表或者表格來組織獨(dú)立、并列的信息。使用編號(hào)來表達(dá)繁雜信息之間的關(guān)系，包括順序(shùnxù)關(guān)系、嵌套關(guān)系和層次關(guān)系。共九十二頁4.文檔寫作技巧

——細(xì)節(jié)(xìjié)描述定義術(shù)語表或數(shù)據(jù)字典術(shù)語不一致“方言”問題錯(cuò)誤術(shù)語和冗余術(shù)語避免干擾(gānrǎo)文本“這一段的意思是…”“上一句話是指…”避免歧義詞匯表15－1共九十二頁歧義詞匯改進(jìn)方法可接受的、足夠的具體定義可接受的內(nèi)容，說明系統(tǒng)怎樣判斷“可接受”或“足夠”大概可行的、差不多可行的不要讓開發(fā)人員來判斷“大概”和“差不多”到底是否成立。應(yīng)將其標(biāo)記為待確定問題并標(biāo)明解決日期至少、最小、不多于、不超過明確指定能夠接受的最大值和最小值在……之間明確說明兩個(gè)端點(diǎn)是否在范圍之內(nèi)依賴描述依賴的原因，數(shù)據(jù)依賴？服務(wù)依賴？還是資源依賴？等等有效的明確“有效”所意味的具體實(shí)際情況快的、迅速的明確指定系統(tǒng)在時(shí)間或速度上可接受的最小值靈活的描述系統(tǒng)為了響應(yīng)條件變化或需求變化而可能發(fā)生的變更方式改進(jìn)的、更好的、更快的、優(yōu)越的定量說明在一個(gè)專門的功能領(lǐng)域內(nèi)，充分改進(jìn)的程度和效果包括、包括但不限于、等等、諸如應(yīng)該列舉所有的可能性，否則就無法進(jìn)行設(shè)計(jì)和測試最大化、最小化、最優(yōu)說明對(duì)某些參數(shù)所能接受的最大值和最小值一般情況下、理想情況下需要增加描述系統(tǒng)在異常和非理想情況下的行為可選擇地具體說明是系統(tǒng)選擇、用戶選擇還是開發(fā)人員選擇合理的、在必要的時(shí)候、在適當(dāng)?shù)牡胤矫鞔_怎樣判斷合理、必要和適當(dāng)健壯的顯式定義系統(tǒng)如何處理異常和如何響應(yīng)預(yù)料之外的操作無縫的、透明的、優(yōu)雅的將詞匯里面所反映的用戶期望轉(zhuǎn)化成能夠觀察到的產(chǎn)品特性若干聲明具體是多少，或提供某一范圍內(nèi)的最小邊界值和最大邊界值不應(yīng)該試著以肯定的方式陳述需求，描述系統(tǒng)應(yīng)該做什么最新技術(shù)水平的定義其具體含義，即“最新技術(shù)水平”意味什么充分的說明“充分”具體包括哪些內(nèi)容支持、允許精確地定義系統(tǒng)的功能，這些功能組合起來支持某些能力用戶友好的、簡單的、容易的描述系統(tǒng)特性，用這些特性說明詞匯所代表的用戶期望的實(shí)質(zhì)共九十二頁主要(zhǔyào)內(nèi)容需求規(guī)格(guīgé)說明概述需求規(guī)格說明文檔模版的選擇與裁剪文檔寫作技巧優(yōu)秀需求規(guī)格說明文檔的特性需求規(guī)格說明的實(shí)踐調(diào)查共九十二頁5.優(yōu)秀需求(xūqiú)規(guī)格說明文檔的特性完備性標(biāo)準(zhǔn)描述了用戶的所有有意義的需求，包括功能、性能、約束、質(zhì)量屬性和對(duì)外接口。定義(dìngyì)了軟件對(duì)所有情況的所有實(shí)際輸入（無論有效輸入還是無效輸入）的響應(yīng)。為文檔中的所有插圖、圖、表和術(shù)語、度量單位的定義提供了完整的引用和標(biāo)記。前景和范圍TBD問題共九十二頁5.優(yōu)秀需求(xūqiú)規(guī)格說明文檔的特性一致性標(biāo)準(zhǔn)細(xì)節(jié)的需求不能同高層次的需求相沖突，例如系統(tǒng)需求不能和業(yè)務(wù)(yèwù)需求、用戶需求互相矛盾同一層次的不同需求之間也不能互相沖突評(píng)審自動(dòng)化檢查共九十二頁5.優(yōu)秀需求規(guī)格(guīgé)說明文檔的特性根據(jù)重要性和穩(wěn)定性分級(jí)建立需求的優(yōu)先級(jí)可修改標(biāo)準(zhǔn)它的結(jié)構(gòu)和風(fēng)格使得人們可以對(duì)其中任一需求進(jìn)行容易地、完整地、一致地修改，同時(shí)還不會(huì)影響文檔現(xiàn)有的結(jié)構(gòu)和風(fēng)格文檔的可修改性要求(yāoqiú)：有著條理分明并且易于使用的組織方式，包括目錄、索引和顯式的交叉引用。沒有重復(fù)冗余。獨(dú)立表達(dá)每個(gè)需求，而不是和其他需求混在一起。共九十二頁5.優(yōu)秀需求(xūqiú)規(guī)格說明文檔的特性可跟蹤后向跟蹤（Backwardtraceability）能找到需求的來源，例如和更早期文檔的顯式關(guān)聯(lián)。前向跟蹤（Forwardtraceability）能找到需求所對(duì)應(yīng)的設(shè)計(jì)單元、實(shí)現(xiàn)源代碼和測試用例等，它要求每個(gè)需求都要有唯一的標(biāo)識(shí)(biāozhì)或者可供引用的名稱共九十二頁主要(zhǔyào)內(nèi)容需求規(guī)格說明概述需求規(guī)格說明文檔模版的選擇與裁剪文檔寫作技巧優(yōu)秀(yōuxiù)需求規(guī)格說明文檔的特性需求規(guī)格說明的實(shí)踐調(diào)查共九十二頁6.需求規(guī)格(guīgé)說明的實(shí)踐調(diào)查需求規(guī)格(guīgé)說明文檔的編寫和使用時(shí)間壓力替代品迭代式開發(fā)共九十二頁6.需求規(guī)格說明的實(shí)踐(shíjiàn)調(diào)查需求規(guī)格說明(shuōmíng)文檔的內(nèi)容問題域描述業(yè)務(wù)過程操作功能用戶行為任務(wù)事件場景術(shù)語首字母縮寫量（Volume）估計(jì)值公司背景共九十二頁6.需求(xūqiú)規(guī)格說明的實(shí)踐調(diào)查需求規(guī)格(guīgé)說明文檔的內(nèi)容效果（解系統(tǒng)描述）特征通用標(biāo)準(zhǔn)特征獨(dú)特特征事務(wù)更新插入刪除修改信息需求特定報(bào)告（Adhocreporting）數(shù)據(jù)采集數(shù)據(jù)流數(shù)據(jù)庫查詢處理報(bào)表行為需求困難示例（Cornercase）錯(cuò)誤示例（Errorcase）事件外部事件狀態(tài)轉(zhuǎn)移轉(zhuǎn)換/轉(zhuǎn)移（Transformation）需求共九十二頁6.需求規(guī)格(guīgé)說明的實(shí)踐調(diào)查需求規(guī)格(guīgé)說明文檔的內(nèi)容問題接口與其他系統(tǒng)接口系統(tǒng)接口用戶界面變更目的目標(biāo)可行性分析架構(gòu)約束文檔信息文檔歷史版本和草案簽署日期傳播（Circulation）授權(quán)列表原創(chuàng)作者目錄參考文獻(xiàn)共九十二頁6.需求規(guī)格說明的實(shí)踐(shíjiàn)調(diào)查模版和示例(shìlì)的使用共九十二頁6.需求規(guī)格說明(shuōmíng)的實(shí)踐調(diào)查需求(xūqiú)規(guī)格說明文檔的描述語言共九十二頁實(shí)例分析(fēnxī)(wiki的使用)由于時(shí)間壓力以及采取迭代開發(fā)的方式，造成了該項(xiàng)目沒有編寫需求規(guī)格說明書。但是可以采用(cǎiyòng)更為靈活的方式編寫，例如wiki。我曾在某一預(yù)研性質(zhì)的項(xiàng)目中使用wiki來完成各類文檔。結(jié)果證明它非常好用。wiki非常適合用在迭代開發(fā)以及預(yù)研性質(zhì)的項(xiàng)目中編寫文檔。共九十二頁實(shí)例分析(fēnxī)（公司A）我們公司項(xiàng)目的需求規(guī)格說明書，主要存在以下幾點(diǎn)問題模版不是很統(tǒng)一，具有很多個(gè)人的特點(diǎn)沒有明確的業(yè)務(wù)需求、用戶需求、系統(tǒng)需求，這三個(gè)層次，在需求規(guī)格說明書中或多或少地涵蓋前三項(xiàng)內(nèi)容，但顯得不夠飽滿和清晰鑒于項(xiàng)目的狀況，一般較少考慮(kǎolǜ)硬件需求，倒是一般來說，項(xiàng)目上線選用的都是最新的硬件設(shè)備，成本較高。內(nèi)容的書寫，自然語言居多，出現(xiàn)歧義、省略、模糊的機(jī)會(huì)較多，質(zhì)量不高從項(xiàng)目的后期來看，性能需求、約束、質(zhì)量需求沒有明確地分門別類地明確列出，導(dǎo)致后期項(xiàng)目中的各個(gè)業(yè)務(wù)流程還是基本可行，但是整體系統(tǒng)還是出現(xiàn)總體質(zhì)量不滿足的地方。共九十二頁實(shí)例分析(fēnxī)（項(xiàng)目報(bào)告）需求分析報(bào)告中夾雜了很多專業(yè)名詞和行業(yè)名詞，例如橫沖、平衡等等，有些部分客戶看不懂，有些部分程序員看不懂，只有自己心里明白，但這樣就會(huì)造成客戶和程序員理解上的問題。另外報(bào)告中寫得比較凌亂，沒有把相關(guān)問題歸類整合，編寫目錄，導(dǎo)致程序員零散地一條條對(duì)著開發(fā)，很多地方銜接不是很好，另外客戶很多想法(xiǎngfǎ)尤其一些重要部分在軟件交付的時(shí)候會(huì)有所改變。共九十二頁需求文檔的編寫(biānxiě)原則句子和段落要短。要檢查需求是否(shìfǒu)被有效地定義。需求編寫者還要努力正確地把握細(xì)化程度。密切關(guān)注合成了多個(gè)需求的單個(gè)需求。通篇文檔細(xì)節(jié)上要保持一致。共九十二頁高質(zhì)量的SRS的一些(yīxiē)特性完整性一致性可修改性可追蹤書上P169

共九十二頁評(píng)審需求(xūqiú)規(guī)格說明書的常見問題

敘述的軟件目標(biāo)和系統(tǒng)的目標(biāo)是否保持一致？所有系統(tǒng)元素的重要(zhòngyào)接口都已描述了嗎？問題域的信息流和結(jié)構(gòu)都已被恰當(dāng)?shù)囟x了嗎？圖示是否清楚？每個(gè)圖都可以不需要文字補(bǔ)充了嗎？是否包括了所有主要的功能，它們都已描述清楚了嗎？系統(tǒng)的功能和用戶需求一致了嗎？設(shè)計(jì)約束是現(xiàn)實(shí)可行的嗎？是否考慮過開發(fā)的技術(shù)風(fēng)險(xiǎn)？是否考慮過其他可選的軟件需求？檢驗(yàn)標(biāo)準(zhǔn)是否被詳細(xì)地陳述？它們能有效地檢驗(yàn)系統(tǒng)是否成功嗎？是否存在不一致性、是否信息被忽略或冗余？和客戶全面接觸過嗎？客戶的主要意見都已被考慮了嗎？用戶是否評(píng)審過初步的原型？計(jì)劃的估算受到什么樣的影響？共九十二頁發(fā)現(xiàn)需求規(guī)格說明書中問題(wèntí)的一些方法

搜尋說服性的連接詞(例如，當(dāng)然、因此、明確地、顯然)，并問“為什么”。觀察含糊的術(shù)語(例如，一些、有時(shí)、經(jīng)常、通常、一般地、大多數(shù))，并進(jìn)行澄清。當(dāng)給出了不完整的列表時(shí)，確定已理解了所有的項(xiàng)。關(guān)鍵是查找“等等、如此這樣”。確定陳述的范圍內(nèi)條件清晰。(例如，從10到100的校驗(yàn)代碼范圍究竟是整數(shù)？實(shí)數(shù)？還是復(fù)數(shù)？)避免含糊的動(dòng)詞，如“處理、拒絕、處制、跳過、限制”等，它們可以有很多方式來解釋。避免含糊的代詞(dàicí)(例如，I/O模塊與數(shù)據(jù)校驗(yàn)?zāi)K通信，且設(shè)置它的控制標(biāo)志，那么標(biāo)志是誰的？)查找蘊(yùn)含了確定性判斷的語句(例如，總是、每次、所有、無、永不)，證明它們是合理的。某個(gè)術(shù)語一旦被明確地定義，就要在文中前后一致地使用。用圖示的方法可以幫助理解。共九十二頁本章(běnzhānɡ)小結(jié)需求規(guī)格說明定義解決方案和需求，承載需求分析的成果需求規(guī)格說明是一項(xiàng)復(fù)雜的活動(dòng)，正確的文檔寫作要求準(zhǔn)確的界定文檔的特性掌握文檔模版的裁剪技巧和文檔的寫作技巧，可以幫助(bāngzhù)提高需求規(guī)格說明文檔寫作的能力優(yōu)秀的需求規(guī)格說明文檔需要達(dá)到一定的要求共九十二頁思考題什么時(shí)候建立術(shù)語表？在需求獲取和需求分析當(dāng)中(dāngzhōng)采用哪些手段可以保證最終需求集的完備性、一致性和正確性？共九十二頁

第17章.需求(xūqiú)驗(yàn)證與

第18章需求評(píng)審

共九十二頁主要(zhǔyào)內(nèi)容驗(yàn)證與確認(rèn)(quèrèn)需求驗(yàn)證需求驗(yàn)證方法問題修正需求驗(yàn)證的實(shí)踐調(diào)查共九十二頁1.驗(yàn)證與確認(rèn)(quèrèn)

——概念需求驗(yàn)證：以正確的方式建立需求需求集是正確的、完備的和一致的；技術(shù)(jìshù)上是可解決的；它們?cè)诂F(xiàn)實(shí)世界中的滿足是可行的和可驗(yàn)證的。需求確認(rèn)：建立的需求是正確的每一條需求都是符合用戶原意的系統(tǒng)驗(yàn)證：正確的建立系統(tǒng)系統(tǒng)能夠在預(yù)期的環(huán)境中正確的執(zhí)行設(shè)定的功能。系統(tǒng)確認(rèn)：建立的系統(tǒng)是正確的建立的系統(tǒng)是符合系統(tǒng)需求和系統(tǒng)設(shè)計(jì)的共九十二頁第17章需求(xūqiú)驗(yàn)證需求驗(yàn)證所包括的活動(dòng)是為了確定以下(yǐxià)幾方面的內(nèi)容：軟件需求規(guī)格說明正確描述了預(yù)期的系統(tǒng)行為和特征。從系統(tǒng)需求或其它來源中得到軟件需求。需求是完整的和高質(zhì)量的。所有對(duì)需求的看法是一致的。需求為繼續(xù)進(jìn)行產(chǎn)品設(shè)計(jì)、構(gòu)造和測試提供了足夠的基礎(chǔ)。需求驗(yàn)證確保了需求符合良好特征并且符合需求規(guī)格說明的良好特性。共九十二頁需求(xūqiú)驗(yàn)證的意義

需求驗(yàn)證并不僅僅是一個(gè)獨(dú)立的階段。一些驗(yàn)證活動(dòng)，例如對(duì)迭代增量型軟件需求規(guī)格(guīgé)說明的反復(fù)評(píng)審，將貫穿著反復(fù)獲取需求、分析和編寫規(guī)格(guīgé)說明的整個(gè)過程。當(dāng)你的項(xiàng)目計(jì)劃或?qū)嶋H工作中的獨(dú)立任務(wù)破壞了結(jié)構(gòu)性時(shí)，就要結(jié)合進(jìn)行需求驗(yàn)證活動(dòng)。為防止錯(cuò)誤而花費(fèi)1美元將可以為你修補(bǔ)錯(cuò)誤節(jié)省3~10美元。**[Jones1994]共九十二頁1.驗(yàn)證(yànzhèng)與確認(rèn)

——軟件工程的驗(yàn)證與確認(rèn)共九十二頁主要(zhǔyào)內(nèi)容驗(yàn)證與確認(rèn)(quèrèn)需求驗(yàn)證需求驗(yàn)證方法問題修正需求驗(yàn)證的實(shí)踐調(diào)查共九十二頁2.需求驗(yàn)證(yànzhèng)

——概念驗(yàn)證普遍存在獲得的用戶需求是否正確和充分的支持業(yè)務(wù)需求？建立的分析模型是否正確的反映了問題域特性和需求？細(xì)化的系統(tǒng)需求是否充分和正確的支持用戶需求？需求規(guī)格說明文檔是否組織良好、書寫(shūxiě)正確？需求規(guī)格說明文檔內(nèi)的需求是否充分和正確的反映了涉眾的意圖？需求規(guī)格說明文檔是否可以作為后續(xù)開發(fā)工作（設(shè)計(jì)、實(shí)現(xiàn)、測試等等）的基礎(chǔ)？需求驗(yàn)證是專指在需求規(guī)格說明完成之后，對(duì)需求規(guī)格說明文檔進(jìn)行的驗(yàn)證活動(dòng)共九十二頁2.需求驗(yàn)證(yànzhèng)

——活動(dòng)共九十二頁測試與開發(fā)平行，驗(yàn)收測試以用戶需求為基礎(chǔ)(jīchǔ)，系統(tǒng)測試以功能需求為基礎(chǔ)(jīchǔ)，集成測試以系統(tǒng)體系結(jié)構(gòu)為基礎(chǔ)(jīchǔ)。軟件開發(fā)的V字模型(móxíng)軟件需求太原理工大學(xué)軟件學(xué)院2015? 共九十二頁主要(zhǔyào)內(nèi)容驗(yàn)證與確認(rèn)需求驗(yàn)證需求驗(yàn)證方法評(píng)審原型與模擬開發(fā)測試用例用戶手冊(cè)編制利用跟蹤關(guān)系自動(dòng)化分析問題(wèntí)修正需求驗(yàn)證的實(shí)踐調(diào)查共九十二頁3.1評(píng)審(pínɡshěn)由作者之外的其他人來檢查產(chǎn)品問題的方法是主要的靜態(tài)分析手段原則上，每一條(yītiáo)需求都應(yīng)該進(jìn)行評(píng)審共九十二頁3.1評(píng)審(pínɡshěn)

——參與人員共九十二頁3.1評(píng)審(pínɡshěn)

——過程共九十二頁3.1評(píng)審(pínɡshěn)

——檢查方法檢查方法描述自由方法（Ad-hoc）沒有為檢查人員提供系統(tǒng)化的引導(dǎo)檢查清單（Checklist-Based）以通用的檢查清單來引導(dǎo)檢查過程缺陷（Defect-Based）用于需求文檔，根據(jù)缺陷的分類來組織和檢查場景功能點(diǎn)（FunctionPoint-Based）按照功能點(diǎn)來組織和檢查場景視角（Perspective-Based）按照不同涉眾類型的視角來組織和檢查場景場景（Scenario-Based）對(duì)每一個(gè)場景，都利用一系列的問題或者細(xì)節(jié)要求，來引導(dǎo)檢查過程。缺陷、功能點(diǎn)、視角都是場景方法的一個(gè)特例。逐步提升（StepwiseAbstraction）凈室軟件開發(fā)中的一種方法。閱讀者描述一些獨(dú)立代碼段的功能，然后將描述的范圍逐步擴(kuò)大，描述的功能抽象逐步提高，直至閱讀人員描述了整個(gè)評(píng)審物件共九十二頁3.1評(píng)審(pínɡshěn)

——類型共九十二頁3.2原型(yuánxíng)與模擬涉及到復(fù)雜的動(dòng)態(tài)行為(xíngwéi)時(shí)成本較高共九十二頁3.3開發(fā)(kāifā)測試用例如果無法(wúfǎ)為某條需求定義完備的測試用例，那么它可能就存在著模糊、信息遺漏、不正確等缺陷例外排斥性需求（ExclusiveRequirements）這種需求要求特定的行為絕對(duì)不會(huì)發(fā)生，例如需求可能會(huì)要求系統(tǒng)故障不能導(dǎo)致數(shù)據(jù)庫的崩潰全局性非功能性需求（GlobalNon-FunctionalRequirements）例如可靠性、可用性等，對(duì)這些需求的測試往往都是大數(shù)據(jù)集的處理共九十二頁3.4用戶手冊(cè)編制(biānzhì)驗(yàn)證功能需求對(duì)軟件系統(tǒng)功能和實(shí)現(xiàn)的描述驗(yàn)證項(xiàng)目范圍對(duì)系統(tǒng)沒有實(shí)現(xiàn)的功能的描述驗(yàn)證異常流程需求問題和故障的解決驗(yàn)證環(huán)境與約束需求系統(tǒng)的安裝(ānzhuāng)和啟動(dòng)共九十二頁3.5利用(lìyòng)跟蹤關(guān)系業(yè)務(wù)需求

用戶需求

系統(tǒng)需求如果業(yè)務(wù)需求和用戶需求沒有得到后項(xiàng)需求（用戶需求和系統(tǒng)需求）的充分支持，那么軟件需求規(guī)格說明(shuōmíng)文檔就存在不完備的缺陷。系統(tǒng)需求

用戶需求

業(yè)務(wù)需求如果不能依據(jù)跟蹤關(guān)系找到一條系統(tǒng)需求的前項(xiàng)用戶需求和前項(xiàng)業(yè)務(wù)需求，那么該需求就屬于非必要的需求。共九十二頁3.6自動(dòng)化分析(fēnxī)共九十二頁主要(zhǔyào)內(nèi)容驗(yàn)證(yànzhèng)與確認(rèn)需求驗(yàn)證需求驗(yàn)證方法問題修正需求驗(yàn)證的實(shí)踐調(diào)查共九十二頁4.問題(wèntí)修正需求澄清（RequirementsClarification）理解偏差：重新進(jìn)行分析工作分析遺漏：重新分析和文檔化這部分信息表達(dá)不當(dāng)：重新以合適的方式表達(dá)缺失需求重新執(zhí)行需求獲取等一系列工作需求沖突協(xié)商(xiéshāng)解決不切實(shí)際的期望項(xiàng)目調(diào)整與需求協(xié)商共九十二頁主要(zhǔyào)內(nèi)容驗(yàn)證與確認(rèn)需求驗(yàn)證需求驗(yàn)證方法(fāngfǎ)問題修正需求驗(yàn)證的實(shí)踐調(diào)查共九十二頁5.需求驗(yàn)證(yànzhèng)的實(shí)踐調(diào)查需求驗(yàn)證是重要的需求驗(yàn)證是容易被忽視的需求驗(yàn)證的方法是多樣的評(píng)審(pínɡshěn)和原型最為廣泛客戶對(duì)線索（Threads）和場景（Scenarios）表現(xiàn)出了最大的興趣技術(shù)人員、領(lǐng)域?qū)＜?、客戶以及用戶是最合適的評(píng)審者共九十二頁實(shí)例(shílì)分析(一個(gè)公司的業(yè)務(wù)管理系統(tǒng))問題需求雖然寫好了也定稿了，但是并沒有得到最終確認(rèn)就開始了軟件開發(fā)工作。這種現(xiàn)象主要是由于業(yè)務(wù)小組和技術(shù)小組溝通不全面造成的，在雙方(shuāngfāng)就某一問題產(chǎn)生分歧的情況下，沒有一個(gè)能出來拍板的人決定（有權(quán)利決定的領(lǐng)導(dǎo)不參與開發(fā)和需求編寫）。所以整個(gè)項(xiàng)目的開發(fā)是在業(yè)務(wù)小組和技術(shù)小組的爭論中走過的。經(jīng)常出現(xiàn)業(yè)務(wù)小組提出的方案技術(shù)小組難以落實(shí)，等到后期變通修改造成功能損失的情況。因?yàn)樾枨蟮貌坏阶罱K確認(rèn)，一直在修改中，造成技術(shù)小組不停的修改已經(jīng)編寫完畢的模塊，有些改動(dòng)甚至涉及到公共基類的修改和各模塊之間的關(guān)聯(lián)，造成很大的浪費(fèi)。解決驗(yàn)證與確認(rèn)+需求管理共九十二頁實(shí)例(shílì)分析（地稅系統(tǒng)）問題系統(tǒng)開發(fā)過程中，沒有好的辦法檢測需求落實(shí)的情況。最后驗(yàn)收(yànshōu)的時(shí)候功能是否實(shí)現(xiàn)由技術(shù)小組說了算。解決需求規(guī)格說明+需求驗(yàn)證與確認(rèn)用戶為中心共九十二頁本章(běnzhānɡ)小結(jié)驗(yàn)證與確認(rèn)是軟件工程(gōngchéng)當(dāng)中一項(xiàng)重要的活動(dòng)。需求驗(yàn)證是需求工程(gōngchéng)中發(fā)生的對(duì)需求規(guī)格說明文檔進(jìn)行的驗(yàn)證與確認(rèn)活動(dòng)需求驗(yàn)證有多種有效的方法，實(shí)踐中最為重要和廣泛應(yīng)用是的評(píng)審方法和原型方法需求驗(yàn)證不僅要發(fā)現(xiàn)問題，而且要監(jiān)督問題的解決共九十二頁思考題用于需求獲取的原型與用于需求驗(yàn)證的原型有何異同？多種需求驗(yàn)證的方法應(yīng)該(yīnggāi)如何結(jié)合運(yùn)用？共九十二頁第18章需求(xūqiú)評(píng)審需求評(píng)審為涉眾們提供(tígōng)了在特定問題上達(dá)成共識(shí)的方法。評(píng)審類型：評(píng)審、檢察、走查。進(jìn)行成功的評(píng)審有幾個(gè)關(guān)鍵要素：理解評(píng)審流程；確保評(píng)審員理解自己的角色；指定協(xié)調(diào)員；使評(píng)審保持簡短，嚴(yán)格按照議程進(jìn)行；確定問題，而不要解決問題。評(píng)審過程。需求評(píng)審中常見的問題。軟件需求規(guī)格說明書的評(píng)審清單。

共九十二頁非正式評(píng)審(pínɡshěn)

非正式評(píng)審的方法可以是把工作產(chǎn)品分發(fā)給許多其它的開發(fā)人員粗略看一看和走過場似地檢查一遍(walkthrough)，或是由產(chǎn)品開發(fā)者描述產(chǎn)品，征求大家的意見。非正式評(píng)審對(duì)于獲得分散而隨機(jī)的反饋是有效的，但非正式評(píng)審是非(shìfēi)系統(tǒng)化的，不徹底的，它在實(shí)施過程中具有不一致性。共九十二頁正式(zhèngshì)評(píng)審正式評(píng)審則遵循預(yù)先定義好的一系列步驟過程。正式評(píng)審內(nèi)容需要記錄在案，它包括確定材料、評(píng)審員、評(píng)審小組對(duì)產(chǎn)品是否完整或是否需要進(jìn)一步工作的判定，以及對(duì)所發(fā)現(xiàn)的錯(cuò)誤和所提出的問題(wèntí)的總結(jié)。正式評(píng)審小組的成員對(duì)評(píng)審的質(zhì)量負(fù)責(zé)，而開發(fā)者則最終對(duì)他們所開發(fā)的產(chǎn)品的質(zhì)量負(fù)責(zé)。共九十二頁評(píng)審(pínɡshěn)類型

[IEEE]評(píng)審：一次正式的會(huì)議。在會(huì)議上向用戶、客戶或其他相關(guān)各方介紹一個(gè)或一組工件，以征求對(duì)方的意見和批準(zhǔn)。檢查：一種正式的評(píng)估方法，將由非制作者本人的個(gè)人或小組詳細(xì)檢查工件，以查明是否有錯(cuò)誤、是否違反開發(fā)標(biāo)準(zhǔn)、是否存在其他問題。走查：一個(gè)評(píng)審過程，由某個(gè)開發(fā)人員領(lǐng)導(dǎo)一個(gè)或多個(gè)開發(fā)團(tuán)隊(duì)成員對(duì)他（或她）所編寫的一段工件進(jìn)行檢查；同時(shí)，由其他成員針對(duì)技術(shù)、風(fēng)格(fēnggé)、可能的錯(cuò)誤、是否違反開發(fā)標(biāo)準(zhǔn)和其他問題提出問題并發(fā)表意見。共九十二頁評(píng)審(pínɡshěn)流程評(píng)審流程是一個(gè)重復(fù)進(jìn)行的循環(huán)過程：評(píng)審員提出問題—〉討論問題—〉對(duì)問題進(jìn)行確認(rèn)—〉確定缺陷（確定需要解決的地方(dìfāng)），直到?jīng)]有確定的問題時(shí)再繼續(xù)下一步。RUP強(qiáng)調(diào)確保質(zhì)量的主要因素：同事檢查。共九十二頁需求評(píng)審(pínɡshěn)中常見的問題需求報(bào)告很長，短時(shí)間內(nèi)評(píng)審者根本就不能把需求報(bào)告讀懂、想清楚。沒有作好(zuòhǎo)前期準(zhǔn)備工作，需求評(píng)審的效率很低。需求評(píng)審的節(jié)奏無法控制。找不到合格的評(píng)審員，與會(huì)的評(píng)審員無法提出深入的問題。共九十二頁需求評(píng)審(pínɡshěn)技術(shù)細(xì)節(jié)上的常見錯(cuò)誤

根本不進(jìn)行需求評(píng)審，而是讓程序員隨心所欲地寫程序。用例不能符合所需的系統(tǒng)行為(xíngwéi)。不使用任何GUI原型來幫助驗(yàn)證系統(tǒng)行為。用例高度抽象，讓不懂技術(shù)的客戶如墜迷霧中。概念模型不能準(zhǔn)確地反映真實(shí)世界的概念性對(duì)象。用例建模沒有參考概念模型。對(duì)不包含任何分支流程的用例不提出疑義。共九十二頁分層次評(píng)審用戶需求(xūqiú)分為：目標(biāo)性需求，系統(tǒng)目標(biāo)功能性需求，系統(tǒng)任務(wù)操作性需求，人機(jī)交互正式結(jié)合非正式評(píng)審分階段評(píng)審充分利用需求評(píng)審檢查單，如下表軟件質(zhì)量因素。如何(rúhé)做好需求評(píng)審

軟件需求太原理工大學(xué)軟件學(xué)院2015? 共九十二頁對(duì)需求定義(dìngyì)進(jìn)行靜態(tài)測試的對(duì)照條例

兼容性：界面需求是否使軟硬件系統(tǒng)具有兼容性？完備性：需求定義是否包含了有關(guān)文件（指質(zhì)量手冊(cè)、質(zhì)量計(jì)劃以及其他有關(guān)文件）中所規(guī)定的需求定義所應(yīng)該包含的所有內(nèi)容？需求定義是否包含了有關(guān)功能、性能、限制、目標(biāo)、質(zhì)量等方面的所有需求？功能性需求是否覆蓋了所有非正常情況的處理？是否已對(duì)各種操作模式（如正常、非正常、有干擾等）下的環(huán)境條件都作規(guī)定？是否識(shí)別出了所有與時(shí)間因素有關(guān)的功能？它們的時(shí)間準(zhǔn)則是否都明了？時(shí)間準(zhǔn)則的最大、最小執(zhí)行時(shí)間是否都定義了？是否識(shí)別定義了在將來可能會(huì)變化的需求？是否定義了系統(tǒng)的所有輸入？是否標(biāo)識(shí)清楚了系統(tǒng)輸入的來源？是否識(shí)別了系統(tǒng)的輸出？是否說明了系統(tǒng)輸入、輸出的類型？是否說明了系統(tǒng)輸入、輸出的值域、單位、格式等？是否說明了如何進(jìn)行系統(tǒng)輸入的合法性檢查？是否定義了系統(tǒng)輸入、輸出的精度？在不同負(fù)載情況下，系統(tǒng)的生產(chǎn)率如何？在不同的情況下，系統(tǒng)的響應(yīng)時(shí)間如何？系統(tǒng)對(duì)軟件、硬件或電源故障必須作什么樣的反應(yīng)？是否充分定義了關(guān)于人機(jī)界面的需求？一致性：各個(gè)需求之間是否一致？是否有沖突和矛盾？所規(guī)定的模型、算法和數(shù)值