需求規(guī)格說明

第15章.需求規(guī)格說明

主要內(nèi)容第1節(jié)需求規(guī)格說明概述第2節(jié)需求規(guī)格說明文檔第3節(jié)模版的選擇與裁剪第4節(jié)文檔寫作技巧第5節(jié)優(yōu)秀需求規(guī)格說明文檔的特性第6節(jié)需求規(guī)格說明的實踐調(diào)查第1節(jié)需求規(guī)格說明概述需求獲取目標是得到用戶需求——收集需求信息需求分析目標是更深刻的理解用戶需求——界定能夠讓用戶滿意的解決方案準則需求規(guī)格說明目標是定義用戶需求——準確描述需求及其解決方案（1）獲取——分析——規(guī)格說明（2）需求規(guī)格說明活動第2節(jié)需求規(guī)格說明文檔

（1）作用更好的傳遞軟件系統(tǒng)的需求信息和解決方案給所有的開發(fā)者拓展人們的知識記憶能力作為合同協(xié)議的重要部分作為項目開發(fā)活動的一個重要依據(jù)發(fā)現(xiàn)和減少可能的需求錯誤，減少項目的返工，降低項目的工作量作為有效的智力資產(chǎn)（2）忽視的原因交流途徑時間壓力迭代式開發(fā)敏捷（3）類型（4）內(nèi)容前景和范圍內(nèi)容問題域信息解決方案需求（5）作者項目管理者組織安排、提供條件需求工程師負責人、主導人文檔寫作人員有時會采用，節(jié)省需求工程師的時間涉眾（用戶）驗證人（6）讀者（7）手段非形式化自然語言限制性文本半形式化結(jié)構(gòu)化文本偽碼/結(jié)構(gòu)化英語模型語言圖、表…形式化形式化語言數(shù)學語言：BNF，Z…第3節(jié)模版的選擇與裁剪優(yōu)秀的文檔結(jié)構(gòu)組織復(fù)用：模版選擇與裁剪文字寫作字詞、句法寫作技巧（1）動機（2）模板第4節(jié)文檔寫作技巧

（1）原則寫作是一門藝術(shù)沒有什么固定的規(guī)律有一些效用有限的經(jīng)驗原則文檔的組織方式；常見情景的處理；常用的寫作技巧；容易出錯的地方等。文檔化的目標是交流簡潔、易讀VS嚴格、準確不要機械的照搬某些標準和規(guī)則有沒有另外一種更容易理解的表達方式？是否一次性提供了太多信息？對讀者來說什么是重要的，什么是不重要的？是否太抽象了？需不需要舉例說明？是否太專業(yè)了？需不需要解釋原理？會不會引起讀者對內(nèi)容的錯誤解釋？哪些內(nèi)容有益于讀者？有益于哪些讀者？文檔在整體上是不是過于機械、乏味或者松散？文檔枯燥嗎？令人厭煩嗎？（2）結(jié)構(gòu)組織所有內(nèi)容位置得當借鑒和使用標準的文檔模版引用或強化，但不重復(fù)引用而不是復(fù)制強化與重復(fù)引言與冗余元文本（3）表達方式形式依賴于內(nèi)容根據(jù)需要表達的內(nèi)容，選擇合適的表達方式使用系統(tǒng)的表達方式人們傾向于系統(tǒng)的表達方式使用相同的語句格式來描述所有的細節(jié)需求。使用列表或者表格來組織獨立、并列的信息。使用編號來表達繁雜信息之間的關(guān)系，包括順序關(guān)系、嵌套關(guān)系和層次關(guān)系。（4）細節(jié)描述定義術(shù)語表或數(shù)據(jù)字典術(shù)語不一致“方言”問題錯誤術(shù)語和冗余術(shù)語避免干擾文本“這一段的意思是…”“上一句話是指…”避免歧義詞匯表15－1歧義詞匯改進方法可接受的、足夠的具體定義可接受的內(nèi)容，說明系統(tǒng)怎樣判斷“可接受”或“足夠”大概可行的、差不多可行的不要讓開發(fā)人員來判斷“大概”和“差不多”到底是否成立。應(yīng)將其標記為待確定問題并標明解決日期至少、最小、不多于、不超過明確指定能夠接受的最大值和最小值在……之間明確說明兩個端點是否在范圍之內(nèi)依賴描述依賴的原因，數(shù)據(jù)依賴？服務(wù)依賴？還是資源依賴？等等有效的明確“有效”所意味的具體實際情況快的、迅速的明確指定系統(tǒng)在時間或速度上可接受的最小值靈活的描述系統(tǒng)為了響應(yīng)條件變化或需求變化而可能發(fā)生的變更方式改進的、更好的、更快的、優(yōu)越的定量說明在一個專門的功能領(lǐng)域內(nèi)，充分改進的程度和效果包括、包括但不限于、等等、諸如應(yīng)該列舉所有的可能性，否則就無法進行設(shè)計和測試最大化、最小化、最優(yōu)說明對某些參數(shù)所能接受的最大值和最小值一般情況下、理想情況下需要增加描述系統(tǒng)在異常和非理想情況下的行為可選擇地具體說明是系統(tǒng)選擇、用戶選擇還是開發(fā)人員選擇合理的、在必要的時候、在適當?shù)牡胤矫鞔_怎樣判斷合理、必要和適當健壯的顯式定義系統(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)特性，用這些特性說明詞匯所代表的用戶期望的實質(zhì)第5節(jié)

優(yōu)秀需求規(guī)格說明文檔的特性完備性標準描述了用戶的所有有意義的需求，包括功能、性能、約束、質(zhì)量屬性和對外接口。定義了軟件對所有情況的所有實際輸入（無論有效輸入還是無效輸入）的響應(yīng)。為文檔中的所有插圖、圖、表和術(shù)語、度量單位的定義提供了完整的引用和標記。前景和范圍TBD問題一致性標準細節(jié)的需求不能同高層次的需求相沖突，例如系統(tǒng)需求不能和業(yè)務(wù)需求、用戶需求互相矛盾同一層次的不同需求之間也不能互相沖突評審自動化檢查根據(jù)重要性和穩(wěn)定性分級建立需求的優(yōu)先級可修改標準它的結(jié)構(gòu)和風格使得人們可以對其中任一需求進行容易地、完整地、一致地修改，同時還不會影響文檔現(xiàn)有的結(jié)構(gòu)和風格文檔的可修改性要求：有著條理分明并且易于使用的組織方式，包括目錄、索引和顯式的交叉引用。沒有重復(fù)冗余。獨立表達每個需求，而不是和其他需求混在一起?？筛櫤笙蚋櫍˙ackwardtraceability）能找到需求的來源，例如和更早期文檔的顯式關(guān)聯(lián)。前向跟蹤（Forwardtraceability）能找到需求所對應(yīng)的設(shè)計單元、實現(xiàn)源代碼和測試用例等，它要求每個需求都要有唯一的標識或者可供引用的名稱第6節(jié)需求規(guī)格說明的實踐調(diào)查需求規(guī)格說明文檔的編寫和使用時間壓力替代品迭代式開發(fā)需求規(guī)格說明文檔的內(nèi)容問題域描述業(yè)務(wù)過程操作功能用戶行為任務(wù)事件場景術(shù)語首字母縮寫量（Volume）估計值公司背景需求規(guī)格說明文檔的內(nèi)容效果（解系統(tǒng)描述）特征通用標準特征獨特特征事務(wù)更新插入刪除修改信息需求特定報告（Adhocreporting）數(shù)據(jù)采集數(shù)據(jù)流數(shù)據(jù)庫查詢處理報表行為需求困難示例（Cornercase）錯誤示例（Errorcase）事件外部事件狀態(tài)轉(zhuǎn)移轉(zhuǎn)換/轉(zhuǎn)移（Transformation）需求需求規(guī)格說明文檔的內(nèi)容問題接口與其他系統(tǒng)接口系統(tǒng)接口用戶界面變更目的目標可行性分析架構(gòu)約束文檔信息文檔歷史版本和草案簽署日期傳播（Circulation）授權(quán)列表原創(chuàng)作者目錄參考文獻模版和示例的使用需求規(guī)格說明文檔的描述語言實例分析（公司A）我們公司項目的需求規(guī)格說明書，主要存在的問題：模版不是很統(tǒng)一，具有很多個人的特點沒有明確的業(yè)務(wù)需求、用戶需求、系統(tǒng)需求，這三個層次，在需求規(guī)格說明書中或多或少地涵蓋前三項內(nèi)容，但顯得不夠飽滿和清晰鑒于項目的狀況，一般較少考慮硬件需求，倒是一般來說，項目上線選用的都是最新的硬件設(shè)備，成本較高。內(nèi)容的書寫，自然語言居多，出現(xiàn)歧義、省略、模糊的機會較多，質(zhì)量不高從項目的后期來看，性能需求、約束、質(zhì)量需求沒有明確地分門別類地明確列出，導致后期項目中的各個業(yè)務(wù)流程還是基本可行，但是整體系統(tǒng)還是出現(xiàn)總體質(zhì)量不滿足的地方。實例分析（項目報告）需求分析報告中夾雜了很多專業(yè)名詞和行業(yè)名詞，例如橫沖、平衡等等，有些部分客戶看不懂，有些部分程序員看不懂，只有自己心里明白，但這樣就會造成客戶和程序員理解上的問題。另外報告中寫得比較凌亂，沒有把相關(guān)問題歸類整合，編寫目錄，導致程序員零散地一條條對著開發(fā)，很多地方銜接不是很好，另外客戶很多想法尤其一些重要部分在軟件交付的時候會有所改變。