《軟件需求分析》教學PPT

《軟件需求分析》教學PPT,軟件需求分析,軟件,需求,分析,教學,PPT 第15章.需求規(guī)格說明主要內(nèi)容1.需求規(guī)格說明概述2.需求規(guī)格說明文檔3.模版的選擇與裁剪4.文檔寫作技巧5.優(yōu)秀需求規(guī)格說明文檔的特性6.需求規(guī)格說明的實踐調查1.需求規(guī)格說明概述獲取 VS 分析 VS 規(guī)格說明n需求獲取q目標是得到用戶需求收集需求信息n需求分析q目標是更深刻的理解用戶需求界定能夠讓用戶滿意的解決方案準則n需求規(guī)格說明q目標是定義用戶需求準確描述需求及其解決方案1.需求規(guī)格說明概述需求規(guī)格說明活動主要內(nèi)容1.需求規(guī)格說明概述2.需求規(guī)格說明文檔3.模版的選擇與裁剪4.文檔寫作技巧5.優(yōu)秀需求規(guī)格說明文檔的特性6.需求規(guī)格說明的實踐調查2.需求規(guī)格說明文檔作用n更好的傳遞軟件系統(tǒng)的需求信息和解決方案給所有的開發(fā)者n拓展人們的知識記憶能力n作為合同協(xié)議的重要部分n作為項目開發(fā)活動的一個重要依據(jù)n發(fā)現(xiàn)和減少可能的需求錯誤，減少項目的返工，降低項目的工作量n作為有效的智力資產(chǎn)2.需求規(guī)格說明文檔忽視的原因n交流途徑n時間壓力n迭代式開發(fā)q敏捷2.需求規(guī)格說明文檔類型2.需求規(guī)格說明文檔類型2.需求規(guī)格說明文檔內(nèi)容n前景和范圍內(nèi)q問題域信息q解決方案q需求2.需求規(guī)格說明文檔作者n項目管理者q組織安排、提供條件n需求工程師q負責人、主導人n文檔寫作人員q有時會采用，節(jié)省需求工程師的時間n涉眾（用戶）q驗證人2.需求規(guī)格說明文檔讀者2.需求規(guī)格說明文檔 手段n非形式化q自然語言q限制性文本n半形式化q結構化文本n偽碼/結構化英語q模型語言n圖、表n形式化q形式化語言n數(shù)學語言：BNF，Z主要內(nèi)容1.需求規(guī)格說明概述2.需求規(guī)格說明文檔3.模版的選擇與裁剪4.文檔寫作技巧5.優(yōu)秀需求規(guī)格說明文檔的特性6.需求規(guī)格說明的實踐調查3.模版的選擇與裁剪動機n優(yōu)秀的文檔q結構組織n復用：模版q選擇與裁剪q文字寫作n字詞、句法q寫作技巧3.模版的選擇與裁剪3.模版的選擇與裁剪主要內(nèi)容1.需求規(guī)格說明概述2.需求規(guī)格說明文檔3.模版的選擇與裁剪4.文檔寫作技巧5.優(yōu)秀需求規(guī)格說明文檔的特性6.需求規(guī)格說明的實踐調查4.文檔寫作技巧原則n寫作是一門藝術q沒有什么固定的規(guī)律q有一些效用有限的經(jīng)驗原則n文檔的組織方式；n常見情景的處理；n常用的寫作技巧；n容易出錯的地方等。n文檔化的目標是交流文檔化的目標是交流q簡潔、易讀 VS 嚴格、準確q不要機械的照搬某些標準和規(guī)則有沒有另外一種更容易理解的表達方式？是否一次性提供了太多的信息？對讀者來說什么是重要的，什么是不重要的？是否太抽象了？需不需要舉例說明？是否太專業(yè)了？需不需要解釋原理？會不會引起讀者對內(nèi)容的錯誤解釋？哪些內(nèi)容有益于讀者？有益于哪些讀者？文檔在整體上是不是過于機械、乏味或者松散？文檔枯燥嗎？令人厭煩嗎？4.文檔寫作技巧結構組織n所有內(nèi)容位置得當q借鑒和使用標準的文檔模版n引用或強化，但不重復q引用而不是復制q強化與重復q引言與冗余元文本4.文檔寫作技巧表達方式n形式依賴于內(nèi)容q根據(jù)需要表達的內(nèi)容，選擇合適的表達方式n使用系統(tǒng)的表達方式q人們傾向于系統(tǒng)的表達方式n使用相同的語句格式來描述所有的細節(jié)需求。n使用列表或者表格來組織獨立、并列的信息。n使用編號來表達繁雜信息之間的關系，包括順序關系、嵌套關系和層次關系。4.文檔寫作技巧細節(jié)描述n定義術語表或數(shù)據(jù)字典q術語不一致q“方言”問題q錯誤術語和冗余術語n避免干擾文本q“這一段的意思是”q“上一句話是指”n避免歧義詞匯q表151歧義詞匯改進方法可接受的、足夠的具體定義可接受的內(nèi)容，說明系統(tǒng)怎樣判斷“可接受”或“足夠”大概可行的、差不多可行的不要讓開發(fā)人員來判斷“大概”和“差不多”到底是否成立。應將其標記為待確定問題并標明解決日期至少、最小、不多于、不超過明確指定能夠接受的最大值和最小值在之間明確說明兩個端點是否在范圍之內(nèi)依賴描述依賴的原因，數(shù)據(jù)依賴？服務依賴？還是資源依賴？等等有效的明確“有效”所意味的具體實際情況快的、迅速的明確指定系統(tǒng)在時間或速度上可接受的最小值靈活的描述系統(tǒng)為了響應條件變化或需求變化而可能發(fā)生的變更方式改進的、更好的、更快的、優(yōu)越的定量說明在一個專門的功能領域內(nèi)，充分改進的程度和效果包括、包括但不限于、等等、諸如應該列舉所有的可能性，否則就無法進行設計和測試最大化、最小化、最優(yōu)說明對某些參數(shù)所能接受的最大值和最小值一般情況下、理想情況下需要增加描述系統(tǒng)在異常和非理想情況下的行為可選擇地具體說明是系統(tǒng)選擇、用戶選擇還是開發(fā)人員選擇合理的、在必要的時候、在適當?shù)牡胤矫鞔_怎樣判斷合理、必要和適當健壯的顯式定義系統(tǒng)如何處理異常和如何響應預料之外的操作無縫的、透明的、優(yōu)雅的將詞匯里面所反映的用戶期望轉化成能夠觀察到的產(chǎn)品特性若干聲明具體是多少，或提供某一范圍內(nèi)的最小邊界值和最大邊界值不應該試著以肯定的方式陳述需求，描述系統(tǒng)應該做什么最新技術水平的定義其具體含義，即“最新技術水平”意味什么充分的說明“充分”具體包括哪些內(nèi)容支持、允許精確地定義系統(tǒng)的功能，這些功能組合起來支持某些能力用戶友好的、簡單的、容易的描述系統(tǒng)特性，用這些特性說明詞匯所代表的用戶期望的實質主要內(nèi)容1.需求規(guī)格說明概述2.需求規(guī)格說明文檔3.模版的選擇與裁剪4.文檔寫作技巧5.優(yōu)秀需求規(guī)格說明文檔的特性6.需求規(guī)格說明的實踐調查5.優(yōu)秀需求規(guī)格說明文檔的特性n完備性完備性q標準n描述了用戶的所有有意義的需求，包括功能、性能、約束、質量屬性和對外接口。n定義了軟件對所有情況的所有實際輸入（無論有效輸入還是無效輸入）的響應。n為文檔中的所有插圖、圖、表和術語、度量單位的定義提供了完整的引用和標記。q前景和范圍qTBD問題5.優(yōu)秀需求規(guī)格說明文檔的特性n一致性一致性q標準n細節(jié)的需求不能同高層次的需求相沖突，例如系統(tǒng)需求不能和業(yè)務需求、用戶需求互相矛盾n同一層次的不同需求之間也不能互相沖突q評審q自動化檢查5.優(yōu)秀需求規(guī)格說明文檔的特性n根據(jù)重要性和穩(wěn)定性分級根據(jù)重要性和穩(wěn)定性分級q建立需求的優(yōu)先級n可修改可修改q標準n它的結構和風格使得人們可以對其中任一需求進行容易地、完整地、一致地修改，同時還不會影響文檔現(xiàn)有的結構和風格q文檔的可修改性要求：n有著條理分明并且易于使用的組織方式，包括目錄、索引和顯式的交叉引用。n沒有重復冗余。n獨立表達每個需求，而不是和其他需求混在一起。5.優(yōu)秀需求規(guī)格說明文檔的特性n可跟蹤可跟蹤q后向跟蹤（Backward traceability）n能找到需求的來源，例如和更早期文檔的顯式關聯(lián)。q前向跟蹤（Forward traceability）n能找到需求所對應的設計單元、實現(xiàn)源代碼和測試用例等，它要求每個需求都要有唯一的標識或者可供引用的名稱主要內(nèi)容1.需求規(guī)格說明概述2.需求規(guī)格說明文檔3.模版的選擇與裁剪4.文檔寫作技巧5.優(yōu)秀需求規(guī)格說明文檔的特性6.需求規(guī)格說明的實踐調查6.需求規(guī)格說明的實踐調查n需求規(guī)格說明文檔的編寫和使用q時間壓力q替代品q迭代式開發(fā)6.需求規(guī)格說明的實踐調查n需求規(guī)格說明文檔的內(nèi)容問題域描述業(yè)務過程操作功能用戶行為任務事件場景術語首字母縮寫量（Volume）估計值公司背景6.需求規(guī)格說明的實踐調查n需求規(guī)格說明文檔的內(nèi)容效果（解系統(tǒng)描述）特征通用標準特征獨特特征事務更新插入刪除修改信息需求特定報告（Ad hoc reporting）數(shù)據(jù)采集數(shù)據(jù)流數(shù)據(jù)庫查詢處理報表行為需求困難示例（Corner case）錯誤示例（Error case）事件外部事件狀態(tài)轉移轉換/轉移（Transformation）需求6.需求規(guī)格說明的實踐調查n需求規(guī)格說明文檔的內(nèi)容問題接口與其他系統(tǒng)接口系統(tǒng)接口用戶界面變更目的目標可行性分析架構約束文檔信息文檔歷史版本和草案簽署日期傳播（Circulation）授權列表原創(chuàng)作者目錄參考文獻6.需求規(guī)格說明的實踐調查n模版和示例的使用6.需求規(guī)格說明的實踐調查n需求規(guī)格說明文檔的描述語言實例分析(wiki的使用)n由于時間壓力以及采取迭代開發(fā)的方式，造成了該項目沒有編寫需求規(guī)格說明書。但是可以采用更為靈活的方式編寫，例如wiki。我曾在某一預研性質的項目中使用wiki來完成各類文檔。結果證明它非常好用。n個人認為wiki非常適合用在迭代開發(fā)以及預研性質的項目中編寫文檔。實例分析（公司A）n我們公司項目的需求規(guī)格說明書，主要存在以下幾點問題q模版不是很統(tǒng)一，具有很多個人的特點q沒有明確的業(yè)務需求、用戶需求、系統(tǒng)需求，這三個層次，在需求規(guī)格說明書中或多或少地涵蓋前三項內(nèi)容，但顯得不夠飽滿和清晰q鑒于項目的狀況，一般較少考慮硬件需求，倒是一般來說，項目上線選用的都是最新的硬件設備，成本較高。q內(nèi)容的書寫，自然語言居多，出現(xiàn)歧義、省略、模糊的機會較多，質量不高q從項目的后期來看，性能需求、約束、質量需求沒有明確地分門別類地明確列出，導致后期項目中的各個業(yè)務流程還是基本可行，但是整體系統(tǒng)還是出現(xiàn)總體質量不滿足的地方。實例分析（項目報告）n需求分析報告中夾雜了很多專業(yè)名詞和行業(yè)名詞，例如橫沖、平衡等等，有些部分客戶看不懂，有些部分程序員看不懂，只有自己心里明白，但這樣就會造成客戶和程序員理解上的問題。n另外報告中寫得比較凌亂，沒有把相關問題歸類整合，編寫目錄，導致程序員零散地一條條對著開發(fā)，很多地方銜接不是很好，另外客戶很多想法尤其一些重要部分在軟件交付的時候會有所改變。本章小結n需求規(guī)格說明定義解決方案和需求，承載需求分析的成果n需求規(guī)格說明是一項復雜的活動，正確的文檔寫作要求準確的界定文檔的特性n掌握文檔模版的裁剪技巧和文檔的寫作技巧，可以幫助提高需求規(guī)格說明文檔寫作的能力n優(yōu)秀的需求規(guī)格說明文檔需要達到一定的要求思考題n什么時候建立術語表？n在需求獲取和需求分析當中采用哪些手段可以保證最終需求集的完備性、一致性和正確性？