1、東北石油大學計算機與信息技術學院計算機科學系高俊濤高俊濤 副教授副教授軟件工程IBMIBM缺陷放大模型缺陷放大模型需求需求: 1: 1設計設計: 5: 5編碼編碼: 10: 10測試測試: 20-50: 20-50運行與維護運行與維護: 200: 200軟件工程提綱2.12.1軟件需求的概念軟件需求的概念什么是軟件需求什么是軟件需求軟件需求的分類軟件需求的分類需求分析過程需求分析過程2.22.2需求分析技術需求分析技術2.3 2.3 需求規格說明書需求規格說明書2.4 2.4 需求確認需求確認2.5 2.5 需求管理需求管理軟件工程軟件需求定義軟件需求定義(1)用戶解決問題或達到目標所需的條件

2、或能力。 (2)系統或系統部件要滿足合同、標準、規范或其它正式規定文檔所需具有的條件或能力。(3)一種反映上面(1)或(2)所描述的條件或能力的文檔說明。軟件需求的基本任務是準確回答“系統必須做什么”這個問題。 2.1 軟件需求的概念軟件工程按層次劃分軟件需求按層次劃分軟件需求業務需求業務需求( business requirement)反映了組織機構或客戶對系統、產品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明。業務需求描述了企業一組概要性的目標概要性的目標，概要性的目標可能要依靠多個用戶目標來實現。用戶需求用戶需求(user requirement) 文檔描述了用戶使用產品必須要完

3、成的任務，這在使用實例(use case)文檔或方案腳本(scenario)說明中予以說明。用戶需求描述了用戶目標用戶目標，是具體明確的任務，但還不是詳細的細節。 功能需求功能需求(functional requirement)定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求。2.1 軟件需求的概念軟件工程三類需求的關系三類需求的關系業務需求項目視圖與范圍文檔用戶需求使用實例文檔功能需求軟件需求規格說明書非功能需求2.1 軟件需求的概念概要目標層次用戶目標層次功能層次軟件工程軟件需求的非功能性需求軟件需求的非功能性需求非功能需求非功能需求:定義產品必須遵從的標準、

4、規范和合約；外部界面的具體細節；性能要求；設計或實現的約束條件及質量屬性。2.1 軟件需求的概念非功能需求過程需求產品需求外部需求軟件交付互操作性實現方法標準法規成本可用性軟件性能存儲空間可靠性可移植性安全性軟件工程軟軟件需求分析的困件需求分析的困難難(1)(1)客戶說不清楚需求客戶說不清楚需求有些客戶對需求只有朦朧的感覺，當然說不清楚具體的需求。農夫和耕牛的故事有些客戶心里非常清楚想要什么，但卻說不明白。我的鞋是什么樣的？“不懂裝懂”或者“半懂充內行”的客戶令人恐懼2.1 軟件需求的概念軟件工程軟軟件需求的件需求的復雜復雜性性(2)(2)需求自身經常變動需求自身經常變動2.1 軟件需求的概念

5、需求變更原因需求變更原因-客戶方：客戶方：對信息系統的了解不夠對業務需求表達不清對自身業務抽象程度不夠對需求重視程度不夠與開發人員配合不夠業務范圍不斷拓展業務流程不斷變更管理模式不斷創新客戶的能力不足，可以進行適當的培訓，可改善一點。屬于態度問題，需要高層領導協調。不可避免。只能通過合同約束或有限度接受，或通過技術提高軟件適應能力。 軟件工程軟軟件需求的件需求的復雜復雜性性(2)(2)需求自身經常變動需求自身經常變動2.1 軟件需求的概念需求變更原因需求變更原因軟件人員：軟件人員：溝通技巧不高需求工程技術不精需求人員知識儲備不夠不了解客戶方的業務流程調研范圍不確定需求不夠細致、明確項目管理不規

6、范需求描述存在歧義合同對客戶方約束不夠 個人能力或經驗不足。軟件組織的能力不足軟件工程軟軟件需求分析的基本件需求分析的基本過過程程-需求工程需求工程2.1 軟件需求的概念需求工程需求工程是指應用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題并定義目標系統的所有外部特征的一門學科。需求工程通過合適的工具和記號系統地描述待開發系統及其行為特征和相關約束，形成需求文檔，并對用戶不斷變化的需求演進給予支持。需求工程的活動可分為兩大類：一類屬于需求開發，另一類屬于需求管理。 軟件工程需求工程軟件工程軟軟件需求工程件需求工程2.1 軟件需求的概念需求獲取需求獲取 通過與用戶的交流，

7、對現有系統的觀察及對任務進行分析，從而開發、捕獲和修訂用戶的需求；需求建模需求建模(需求分析需求分析) 為最終用戶所看到的系統建立一個概念模型，作為對需求的抽象描述；形成需求規格形成需求規格 生成需求模型構件的精確的形式化的描述，作為用戶和開發者之間的一個協約；需求驗證需求驗證(需求確認需求確認) 以需求規格說明為輸入，通過符號執行、模擬或快速原型等途徑，分析需求規格的正確性和可行性；需求管理需求管理 支持系統的需求演進，如需求變化和可跟蹤性問題。軟件工程提綱1.11.1軟件需求的概念軟件需求的概念1.21.2需求分析技術需求分析技術功能分析功能分析數據分析數據分析1.4 1.4 需求規格說明

8、書需求規格說明書1.51.5需求確認需求確認軟件工程功能分析工具用例圖 順序圖活動圖 界面定義 原型開發 2.3 需求分析技術：功能分析軟件工程用例圖(UseCase Diagram)用例是從系統的外部對系統進行黑盒視圖描述的一種組織方法。用例是抽象使用系統的一種方式，用戶通過用例與系統交互。用例圖主要的作用有三個：獲取需求在其它環節中起指導作用指導測試參與者（參與者（ActorActor） 用例（用例（Use CaseUse Case） 指系統以外的，在使用系統或與系統交互中所扮演的角色 用例是參與者與系統的一次交互。 2.3 需求分析技術：功能分析軟件工程用例圖用戶發短信打電話查找電話2.

9、3 需求分析技術：功能分析軟件工程如何識別參與者?在系統之外，透過系統邊界與系統進行有意義交互的任何事物都是參與者對于一般規模的軟件系統，參與者不會太多，一般有這樣幾種類型的參與者：與系統交互的用戶與系統交互的外部系統與系統交互的外部硬件特別注意：有時候時間觸發器也可以看成是參與者軟件工程如何識別用例？（Jacobson）：用例實例是在系統中執行的一系列動作，這些動作將生成特定參與者可見的價值結果。一個用例定義一組用例實例。 通俗地，用例是參與者利用系統所要達到的目標用戶打電話軟件工程用例的要點價值結果用例的結果形成有意義的目標執行者可見采用業務語言，從用戶觀點描述一組用例實例用例的實例也稱為

10、場景：是執行者使用系統的一個特定情節或用例的一條執行路徑。例如：通過輸入電話號碼撥打電話的場景通過查找電話號碼簿撥打電話的場景通過查找電話號碼簿撥打電話,電話打到一半電話欠費的場景 軟件工程建立用例模型的參考原則用例是短文用例可以是一個場景，包括動作和交互用例可以是一組場景，描述不同場景下的行為。這種書寫格式可以在任何時候描述有變化的行為，例如黑盒需求，業務流程，系統設計說明。用例里不要有系統設計用例里不要有界面設計用例里不要有測試用例應該描述行為需求用例的主場景最好不要超過9步用例的最大價值不在于主場景，而在于備選行為。軟件工程用例建模的步驟確定系統的范圍和邊界確定執行者確定用例對用例進行描

11、述定義用例之間的關系審核用例模型 用例是文檔，而非制圖！用例是文檔，而非制圖！軟件工程用例的文字描述應包括以下內容用例的目的（功能）；該用例在什么情況下被哪個參與者啟動執行；用例與參與者之間交互哪些消息來通知對方作出決定；交互的主消息流及因此被使用或修改的實體；用例中可供選擇的異常事件流；用例的結束標志：給參與者返回一個可識別的值舉例：用例名稱：學生選課執行者：學生目的：完成一次學生選課的完整過程類型：主要的，基本的級別：一級軟件工程過程描述：學生輸入學號/密碼，系統識別賬戶的有效性；對學生進行注冊識別；瀏覽本學期預開課程；選擇學生自己要上的課程并確認；退出系統，系統給出所選課程列表及相應學分

12、合計異常事件流：賬戶有效性檢查失敗，允許學生重新輸入（最多次機會）注冊識別失敗，沒有注冊（未交學費）的學生不能選課1. 選擇課程確認失敗，所選幾門課程在時間上發生沖突，系統提示重選軟件工程用例圖用戶發短信輸入電話號碼打電話查找電話包含關系包含關系：用例A的行為包含了用例B的行為。用例B描述在多個用例中都有的公共行為。 擴展關系擴展關系：擴展關系是從擴展用例到基本用例的關系，它說明為擴展用例定義的行為如何插入到為基本用例定義的行為中。在以下幾種情況下，可使用擴展用例：a.表明用例的某一部分是可選的系統行為；b.表明只在特定條件（如例外條件）下才執行的分支流。泛化關系：泛化關系：A指向B，表示A是

13、B的一種。發彩信2.3 需求分析技術：功能分析查看通話時間軟件工程用例間關系-include包含用例的行為插入到基本用例中的一個位置。當遵循基本用例說明的用例實例到達基本用例中定義了包含關系的位置，它就將改而遵循包含用例的說明。一旦執一旦執行完包含用例，用例實行完包含用例，用例實例就將在基本用例中它例就將在基本用例中它先前停止的地方重新開先前停止的地方重新開始。始。軟件工程教師維護學生成績錄入成績修改成績刪除成績軟件工程用例的包含關系的要點1.包含用例本身是不完整的，它必須擁有基本用例以保證完整性。2.包含用例本身并不知道自己何時或是否被包含。因此，它不能依賴任何包含它的用例。3.被包含的用例

14、一定可以被另外的用例包含(即共用性和獨立性)4.從工程角度上，包含關系用于系統分析時共性功能的合并、抽取。5.包含關系通常在用例建模后期而不是前期被發現。軟件工程描述包含關系應在基本用例的行為序列中定義要插入包含用例的位置。要定義該位置，可以引用基本用例事件流中的特定步驟或分支流。軟件工程用例擴展關系的概念一個用例的實例可能增加了一些附加的行為，這些附加的行為在另一個用例中定義，擴展定義了這兩個用例之間的關系。基本用例基本用例可以單獨存在，但是在一定的條件下，它的行為可以被另一個用例的行為擴展。當當一一個個用例有多用例有多個個可選系統行為時時，可以用擴展關系對其進行擴展，使得基本用例的不同子流

15、程能在不同的情形下以擴展用例的形式被激活。通過這種方式，可以把可選行為從必須行為中分離出來。軟件工程用例擴展關系的概念用例擴展關系的概念基本用例基本用例 擴展點擴展點具有條件具有條件擴展用例擴展用例執行執行返回返回軟件工程用例間關系-extends擴展用例可以有基本事件流和備選事件流。用例實例通過擴展到底會采取哪條路徑，這不僅取決于執行擴展前發生的事件，而且還取決于執行擴展時在與主角的交互中發生的事件執行擴展 。用例執行擴展實例一旦用例執行擴展實例一旦執行了擴展，它就會在執行了擴展，它就會在基本用例的中斷點處繼基本用例的中斷點處繼續執行基本用例。續執行基本用例。軟件工程執行擴展一個擴展用例可以

16、有多個插入段，每個插入段都與自己在基本用例中的擴展點相關。用例實例將繼續執行基本用例，并持續到擴展關系中指定的下一個擴展點為止。在此點上，它將執行擴展用例的下一個插入段。這會重復進行，直到執行完最后一個插入段為止。軟件工程教師查詢學生成績導出查詢結果打印查詢結果軟件工程包含關系與擴展關系的區別包含關系包含關系1. 當在兩個或多個獨立用例重復自已并希望避免重復時2. 在基本用例上插入附加行為并具有明確的描述3. 包含用例作為基本用例自身行為的一部分4. 包含關系是無條件的 擴展關系擴展關系1. 當表述關于正常行為的一個變化情況時2. 在基本用例上插入基本用例不能說明的擴展部分3. 擴展用例作為基

17、本用例的增量擴展4. 擴展用例是按條件要求執行的軟件工程包含關系與擴展關系的區別包含關系包含關系1. 包含用例是共用的用例2. 一個基本用例可以有多個包含用例。3. 一個包含用例可以包含在若干基本用例中。4.很難在包含關系上對系統進行維護修改。擴展關系擴展關系1. 擴展用例不是共用的用例2. 把可選行為從必須行為中分離出來3. 有條件地擴展已有用例的行為。4. 基本用例可以獨立于擴展用例單獨存在。5. 適合于功能需求的增加(基本用例的增量擴展)軟件工程注意I業務語言而非技術語言發票，洗衣機，發票，洗衣機，工作業績工作業績C+C+，字，字段，段，.net,AJAX.net,AJAX軟件工程注意用

18、戶觀點而非系統觀點旅行者訂票查看今日航班旅行者處理訂票顯示今日航班軟件工程注意-用例命名：動詞名詞盡量少用弱動詞弱名詞弱動詞：進行使用復制加載重復弱名詞：數據報表表格表單系統會掩蓋真正的業務！軟件工程注意-把步驟當用例用戶輸入用戶名用戶登陸驗證用戶名和密碼軟件工程注意-避免使用CRUD管理員刪除用戶修改用戶查看用戶增加用戶軟件工程注意-一個用例背后可能隱藏很多數據操作減少庫存量減少賬戶金額創建發貨信息結賬軟件工程順序圖順序圖描述了一組交互對象間的交互方式，它表示完成某項行為的對象和這些對象間傳遞消息的時間順序。順序圖將交互關系表示為一個二維圖。縱向是時間軸，時間沿豎線向下延伸。橫向軸代表了在協

19、作中各獨立角色。角色用生命線表示。當角色對象存在時，角色用一條虛線表示，當對象的過程處于激活狀態時，生命線是一個雙道線。 2.3 需求分析技術：功能分析軟件工程活動圖（Activity Diagram）活動圖闡明了業務用例實現的工作流程，由一系列活動組成，它們共同為業務主角完成某些工作。工作流程活動圖用于研究實現業務目標時所要執行的各項任務或活動的順序安排。活動既可以是手動執行的任務，也可以是自動執行的任務。它可完成一個工作單元。 2.3 需求分析技術：功能分析軟件工程活動圖（Activity Diagram）活動活動表示在工作流程中執行某個活動或步驟。轉移轉移：表示活動的控制流動方向，聯接兩

20、個活動，起點活動完成后啟動聯接終點活動。決策判斷：決策判斷：定義了一個判定條件。這些判定條件決定在活動完成后將執行一組備選轉移中的哪一個轉移。您也可以使用判定圖標來表示線程重新合并的位置。決策和警戒條件使您能夠顯示業務用例的工作流程中的備選線程同步條：同步條：同步條用于顯示平行分支流。同步示意條使您能夠顯示業務用例的工作流程中的并行線程 。嵌套活動圖：嵌套活動圖：一個活動狀態可能要引用另一個活動圖，因為后者顯示了前者的內部結構。泳道：泳道：可以使用垂直實線將活動圖劃分為泳道。每條泳道代表整個工作流程的某個部分的職責，泳道最終可以由組織單元或者業務對象模型中的一組類來實施。泳道之間的排序是無意義

21、的。一個活動狀態都指派了一條泳道，而轉移則可能跨越數條泳道。 2.3 需求分析技術：功能分析軟件工程活動圖（Activity Diagram）表示在工作流程中執行某個活動或步驟。 活動用圓角框表示，標注活動名。條件1條件2初態初態終態終態條件條件1條件條件2判斷判斷同步線同步線轉移描述活動之間的關系，描述由于隱含事件引起的活動變遷。轉移描述活動之間的關系，描述由于隱含事件引起的活動變遷。轉移轉移用帶箭頭的直線表示。用帶箭頭的直線表示。活動名矩形兩端為半圓2.3 需求分析技術：功能分析軟件工程活動圖（Activity Diagram）活動圖中可以出現對象，對象作為活動的輸入輸出。用虛箭頭聯接對象

22、和活動，即對象流。對象用直角矩形表示。輸入電話號碼電話號碼電話呼叫2.3 需求分析技術：功能分析軟件工程活動圖（Activity Diagram） 定義了一個判定條件，用于決定在活動完成后將執行一組備選轉移中的哪一個轉移。 電話存儲方式?打開電話薄顯示電話卡中的電話薄顯示全部電話薄顯示手機中的電話薄電話卡手機全部2.3 需求分析技術：功能分析軟件工程活動圖（Activity Diagram） 同步條用于顯示平行分支流。同步示意條使您能夠顯示業務用例的工作流程中的并行線程 。開機進入短信息進入照相編輯短信選擇收件人發送短信同步條可以是水平的，也可以是垂直的，沒有什么區別。2.3 需求分析技術：功

23、能分析軟件工程活動圖（Activity Diagram） 使用垂直實線將活動圖劃分為多個泳道。每條泳道代表工作流程中某個部分的職責。一個泳道可由一個組織單元或者一個業務對象來承擔。泳道之間的排序是無意義的。活動之間的轉移可以跨越數條泳道。付款確認收到訂單取消訂單發出貨單檢查訂單訂購貨物收到出貨單出貨缺貨有庫存失敗倉庫管理倉庫管理訂單處理訂單處理財務管理財務管理2.3 需求分析技術：功能分析軟件工程狀態圖(Statechart Diagram)狀態圖狀態圖用于顯示對外部事件做出響應的狀態序列，使對象達到這些狀態的事件和條件、以及達到這些狀態時所發生的操作。狀態圖由狀態組成，各狀態由轉移鏈接在一起

24、。狀態狀態是對象執行某項活動或等待某個事件時的條件或狀況。狀態圖中的狀態有3種：初態（即初始狀態）、終態（即最終狀態）和中間狀態。在一張狀態圖中只能有一個初態，而終態和中間狀態可以有0個或多個。 轉移轉移是兩個狀態之間的關系，它由某個事件觸發，然后執行特定的操作或評估并導致特定的結束狀態。 事件事件是在某個特定時刻發生的事情，它是對引起系統做動態或從一個狀態轉換到另一個狀態的外界事件的抽象。例如：用戶移動或點擊鼠標等都是事件。 狀態名稱狀態變量變量名變量值活動表事件名(參數表)/動作表達式初始狀態最終狀態中間狀態圓角矩形2.3 需求分析技術：功能分析軟件工程2.3 需求分析技術：功能分析軟件工

25、程數據流圖（Data Flow Diagram，DFD） 2.3 需求分析技術：數據分析是描述系統中數據流程的圖形工具，它標識了一個系統的邏輯輸入和邏輯輸出，以及把邏輯輸入轉換為邏輯輸出所需的加工處理。數據存儲數據存儲數據源點數據源點或終點或終點加加 工工加工名數據流數據流數據流名文件名實體名箭箭 頭頭圓或橢圓圓或橢圓單或雙杠單或雙杠矩形框矩形框基本圖符數據流是數據在系統內傳播的路徑，數據流應該用名詞或名詞短語命名。 也稱為數據處理，它對數據流進行某些操作或變換。每個加工要有名字，通常是動詞短語，簡明地描述完成什么加工。在分層的數據流圖中，加工還應有編號。指暫時保存數據載體，可以是數據庫、文件

26、等。流向數據存儲的數據流可理解為寫入數據，或查詢請求;從數據存儲流出的數據流可理解為從讀出的數據或查詢結果。是軟件系統外部環境中的實體（包括人員、組織或其他軟件系統），統稱為外部實體。一般只出現在數據流圖的頂層圖中。軟件工程數據流圖（Data Flow Diagram，DFD） 2.3 需求分析技術：數據分析TAB*CTAB*CTAB+CTAB+CB TACATBC 擴展圖符數據A和B同時輸入才能變換成數據C；數據A變換成B和C。數據A或B，或A和B同時輸入變換成C；數據A變換成B或C，或B和C。只有數據A或只有數據B(但不能A、B同時)輸入時變換成C；數據A變換成B或C，但不能變換成B和C。

27、軟件工程數據流圖（Data Flow Diagram，DFD） 2.3 需求分析技術：數據分析顧客出版社驗證驗證訂單訂單匯總匯總訂單訂單訂單圖書目錄文件顧客檔案待處理訂單文件正確訂單一批訂單出版社檔案文件出版社 訂單訂貨存根文件畫圖步驟 ： 1、確定外部實體（顧客、出版社）及輸入、輸出數據流（訂單、出版社訂單）。 2、確定分解頂層的加工（驗證訂單、匯總訂單）。 3、確定使用的文件（圖書目錄文件、顧客檔案等5個文件）。 4、用數據流將各部分連接起來，形成數據封閉。加工和文件還有 其他一些圖例：加 工加工名編號加工名編號文件名文件名文 件軟件工程數據流圖的例子假設一家工廠的采購部每天需要一張定貨報

28、表，報表按零件編號排序，表中列出所有需要再次定貨的零件。對于每個需要再次定貨的零件應該列出下述數據：零件編號、零件名稱、定貨數量、目前價格、主要供應商、次要供應商。零件入庫或出庫的操作稱為事務，通過放在倉庫中的CRT終端把事務報告給定貨系統。當某種零件的庫存數量小于庫存量臨界值時就該再次定貨。軟件工程數據流圖（Data Flow Diagram，DFD） 2.3 需求分析技術：數據分析倉庫管理員采購員事務定貨報表1處理事務2產生報表定貨信息定貨信息D2定貨信息D1庫存清單庫存清單軟件工程數據流圖（Data Flow Diagram，DFD） 2.3 需求分析技術：數據分析X1321.11.21

29、.....1頂頂層層中中 間間 層層底底 層層0圖1圖2圖先全局后局部,先整體后細節,先抽象后具體。通常可將這種分層的DFD圖,分為頂層、中間層、底層。具體步驟： 1、先確定系統范圍，畫出頂層的DFD圖。 2、逐層分解頂層DFD圖，獲得若干中間層DFD圖。中間層的數據流圖描述了某個加工的分解，而它的組成部分又要進一步分解。 3、畫出底層的DFD圖。底層圖由一些不能再分解的加工組成，這些加工都非常簡單，稱為基本加工。軟件工程數據字典 2.3 需求分析技術：數據分析數據流條目：數據流條目：給出了DFD圖中數據

30、流的定義，通常列出該數據流的各組成數據項。乘客名單乘客姓名單位名等級報名單姓名單位名年齡性別課程名文件條目：文件條目：給出某個文件的定義，文件的定義通常是列出文件記錄的組成數據流。訂單文件訂單編號顧客名稱產品名稱訂貨數量交貨日期數據項條目：數據項條目：給出某個數據單項的定義，通常是該數據項的值類型、允許值等。賬號= 00000 99999 ； 存款期= 1 | 3 | 5 （單位：年）加工條目：加工條目：加工條目就是“加工小說明”。一般應單獨列出。數據詞典數據詞典是數據流圖中包含的所有元素的定義的集合。它有四類條目：數據流、數據項、文件及基本加工。在定義數據流或文件時，使用規定的符號。將這些條

31、目按照一定的規則組織起來，構成數據詞典。軟件工程數據字典 2.3 需求分析技術：數據分析X=1 8 表示X可取1到8中的任意一個值連接符 X=“a” 表示X是取值為字符a 的數據元素基本數據元素“”X=(a) 表示 a 可在X中出現，也可不出現可選()X=2a6 或 x=a62 表示重復26次 a 重復mn或或X=a 表示X由 0個或多個 a 組成重復X=a | b 表示X由 a或 b組成或|X=a + b 表示X由a 和 b 組成與+被定義為=例及例及說說明明含含 義義符符 號號Nm軟件工程數據字典 2.3 需求分析技術：數據分析名字名字: :定貨報表別名別名: :定貨信息描述描述: :每天

32、一次送給采購員的需要定貨的零件表定義定義: :定貨報表=零件編號零件名稱定貨數量目前價格主要供應者次要供應者位置位置: :輸出到打印機名字名字:零件編號別名別名:描述描述:唯一地標識庫存清單中一個特定零件的關鍵域定義定義:零件編號=8字符8位置位置:定貨報表 定貨信息 庫存清單 軟件工程需求分析中的軟件體系結構 2.3 需求分析技術：數據分析盡管軟件的體系結構確定是到設計階段的任務，但在需求階段無法回避對軟件體系結構的思考。 (1)需求中問題的分解并不是漫無目的和無組織的，而是分門別類，按層次進行的，這種組織層次也是一種軟件體系結構。(2)對用例和數據的定義也不是雜亂無章的，需要對它們進行組織

33、和管理，這也要采用軟件體系結構。在幾種基于UML的需求描述方法中，“包（package)”的結構通常體現了需求中的軟件體系結構。軟件工程提綱1.11.1軟件需求的概念軟件需求的概念1.21.2需求獲取技術需求獲取技術1.3 1.3 需求分析技術需求分析技術1.4 1.4 需求規格說明書需求規格說明書1.51.5需求確認需求確認軟件工程2.4 規格說明書1. 引言 提出了對需求規格說明的縱覽，這有助于讀者理解文檔如何編寫并且如何閱讀和解釋。 1.1 目的 1.2 文檔約定 描述編寫文檔時所采用的標準或排版約定，包括正文風格、提示區或重要符號。1.3 預期的讀者和閱讀建議 列舉了軟件需求規格說明所

34、針對的不同讀者，列如開發人員、項目經理、營銷人員、用戶、測試人員或文檔的編寫人員。1.4 產品的范圍 提供了對指定的軟件及其目的的簡短描述，包括利益和目標。把軟件與企業目標或業務策略相聯系。可以參考項目視圖和范圍文檔而不是將其內容復制到這里。1.5 參考文獻 作者1,作者1,作者1.文獻名稱.出版社或期刊名稱,出版時間或期刊號:頁碼范圍.需求規格說明書模板軟件工程2.4 規格說明書2.綜合描述概述產品以及它所運行的環境、使用產品的用戶和已制知的限制、假設和依賴。2.1 產品的背景描述了產品的背景和起源。說明了該產品與其它產品或項目的關系。2.2 產品的功能概述了產品所具有的主要功能。其詳細內容

35、將在第4部分中描述。概述方式是圖或列表。2.3 用戶類和特征 描述可能使用該產品的用戶類型，并描述它們相關的特征。2.4 運行環境描述了軟件的運行環境，包括硬件平臺、操作系統和版本，及其它的軟件組件。2.5 設計和實現上的限制 確定影響開發人員自由選擇的問題，并說明這些問題為什么成為一種限制。如必須使用或者避免的特定技術、工具、標準、策略等。2.6 假設和依賴 列舉出在對軟件需求規格說明中影響需求陳述的假設因素。如果這些假設不正確、不一致或被更改，就會使項目受到影響。 需求規格說明書模板軟件工程2.4 規格說明書3. 外部接口需求 描述新產品與外部組件正確連接的需求。 3.1 用戶界面 陳述所

36、需要的用戶界面的軟件組件。描述每個用戶界面的邏輯特征。 對于用戶界面的細節，例如特定對話的布局，應該寫入一個獨立的用戶界面規格說明中，而不能寫入軟件需求規格說明中。 3.2 硬件接口 描述系統中軟件和硬件每一接口的特征。這種描述可能包括支持的硬件類型、軟硬件之間的交流的數據和控制信息的性質以及使用的通信協議。 3.3 軟件接口 描述該產品與其他外部組件（由名字和版本識別）的連接，包括數據庫、操作系統、工具、組件，明確并描述在軟件組件之間交換數據或消息的目的和格式。3.4 通信接口描述與產品所使用的通信功能相關的，包括電子、Web瀏覽器、網絡通信標準或協議及電子表格等等。定義了相關的消息格式、通

37、信安全、數據傳輸速率和同步通信機制。需求規格說明書模板軟件工程2.4 規格說明書4.系統特性 4.1 說明和優先級 提出了對該系統特性的簡短說明并指出該特性的優先級是高、中，還是低。4.2 激勵/響應序列 列出輸入激勵（用戶動作、來自外部設備的信號或其它觸發器）和定義這一特性行為的系統響應序列。4.3 功能需求 列出與該特性相關的詳細功能。這些是必須提交給用戶的軟件功能，使用戶可以使用所提供的特性執行服務或者使用所指定的使用實例執行任務。 5.其它非功能需求 這部分列舉出了所有非功能需求，而不是外部接口需求和限制。 5.1 性能需求 闡述不同應用領域對產品性能的需求，并解釋它們的原理以幫助開發

38、人員作出合理的設計選擇。如：最大用戶數或者所支持的操作、響應時間以及與實時系統的時間關系。5.2 安全設施需求 詳盡陳述與產品使用過程中可能發生的損失、破壞或危害相關的需求。需求規格說明書模板軟件工程2.4 規格說明書5.3 安全性需求 詳盡陳述與系統安全性、完整性或與私人問題相關的需求，這些問題將會影響到產品的使用和產品所創建或使用的數據的保護。5.4 軟件質量標準屬性 詳盡陳述與客戶或開發人員至關重要的其產品質量特性。5.5 業務規則 列舉出有關產品的所有操作規則。這些本身不是功能需求，但它們可以暗示某些功能需求執行這些規則。5.6 用戶文檔 列舉出將與軟件一同發行的用戶文檔部分，例如，用

39、戶手冊、在線幫助和教程。明確所有已知的用戶文檔的交付格式和標準。 6. 其它需求 附錄A：詞匯表 附錄B：分析模型 附錄C：待確定問題的列表 需求規格說明書模板軟件工程提綱1.11.1軟件需求的概念軟件需求的概念1.21.2需求獲取技術需求獲取技術1.3 1.3 需求分析技術需求分析技術1.4 1.4 需求規格說明書需求規格說明書1.51.5需求確認需求確認軟件工程需求分析階段的最一個步驟就是需求確認需求確認，或需求驗證，即驗證需求是正確的。需求確認 需求確認一般從以下4個方面進行：一致性：所有需求需求必須是一致的，任何一條需求不能和其它需求相互矛盾。完整性：需求必須是完整的，規格說明書應該包

40、括用戶需要的每一個功能和性能。首先要保證系統的每一個目標都實現了。可行性：需求中要求的硬件和軟件技術必須是可實現的。有效性：必須證明需求是正確有效的，確實能解決用戶面對的問題 軟件工程需求確認 需求確認的主要方法：需求確認的主要方法：審查需求文檔：對需求文檔進行正式審查是保證軟件質量的很有效的方法。組織一個由不同代表（如分析人員，客戶，設計人員，測試人員）組成的小組，對需求規格說明書及相關模型進行仔細的檢查。另外在需求開發期間所做的非正式評審也是有所裨益的。依據需求編寫測試用例：根據用戶需求所要求的產品特性寫出黑盒功能測試用例。客戶通過使用測試用例以確認是否達到了期望的要求。還要從測試用例追溯回功能需求以確保沒有需求被疏忽，并且確保所有測試結果與測試用例相一致。同時，要使用測試