《軟件需求分析》實驗指導書(共135頁)

《《軟件需求分析》實驗指導書(共135頁)》由會員分享，可在線閱讀，更多相關《《軟件需求分析》實驗指導書(共135頁)（135頁珍藏版）》請在裝配圖網上搜索。

1、精選優(yōu)質文檔-----傾情為你奉上 《軟件需求分析》 實 驗 指 導 書 2013 年 9 月 專心---專注---專業(yè) 中文 軟件需求分析 課 程 編 號 課程 Software Requirement 名稱 英文 適 用 專 業(yè) 軟件工程 Analysis 總學時 32 理論教學學時 28 課 4 內 學 分 2 實踐教學學時 課 8 外 執(zhí)筆者 劉冰 編

2、 寫 日 期 2012 年 3 月 《需求工程—軟件建模與分析》（駱斌主編、丁二 講授 玉編著，高等教育出版社，2009 年 4 月第一版，ISBN 978-7-04--7） 教材 《軟件需求》（第 2 版）（（美）Karl E.Wiegers 著， 參考 劉偉琴、劉洪濤譯，清華大學出版社、2004 年 11 月 第 1 版，ISBN 978-7-302-09834-8） 1 目 錄 一、實驗目的…………………………………………………………….

3、3 二、實驗的軟硬件環(huán)境………………………………………………….3 三、實驗要求與任務…………………………………………………….3 四、實驗步驟…………………………………………………………….3 五、《軟件需求規(guī)格說明書》內容、格式要求………………………..4 六、思考題………………………………………………………………6 【附錄一】軟件需求規(guī)格說明模板…………………………..………..7 【附錄二】 評分標準…………………………..………………………13 【附錄三】前景與范圍文檔寫作范例………………………………..14

4、 【附錄四】需求文檔完整范例…………………………………………20 【附錄五】軟件需求規(guī)格說明書（樣例一）…………………………..40 【附錄六】軟件需求規(guī)格說明書（樣例二）……………………………52 2 實驗名稱：“××管理信息系統(tǒng)”軟件需求規(guī)格說明書的編寫 一、實驗目的 需求開發(fā)的最終成果是：客戶和開發(fā)小組對將要開發(fā)的產品達成一致的協(xié)議。這一協(xié)議 綜合了業(yè)務需求、用戶需求和軟件功能需求。從前面實驗中所得出的一些分析文檔中，我們 可以知道：項目視圖和范圍文檔包含了業(yè)務需求，而使用實例文檔

5、包含了用戶需求。我們還 必須編寫從使用實例派生出的功能需求文檔，還要編寫產品的非功能需求文檔，包括質量屬 性和外部接口需求。至此，我們綜合前面的相關分析結果，來進行需求說明書的編寫，進一 步理解由業(yè)務需求，用戶需求，功能需求三個部分綜合而形成軟件需求說明書的過程。 二、實驗的軟硬件環(huán)境 硬件：微型計算機，打印機； 軟件：Windows XP/7 ，Office 2003/2007，Visual Studio 、Delphi，SQL Server 等 要求實驗環(huán)境為網絡環(huán)境。 三、實驗要求與任務 1、要求： 完成軟件需求規(guī)格說明書的編寫： （1）

6、用好的結構化和自然語言編寫文檔型文檔 （2）建立圖形化模型。 （3） 編寫形式化規(guī)格說明，這可以通過使用數(shù)學上精確的形式化邏輯語言來定義需求。 2、具體任務： 開發(fā)“××管理信息系統(tǒng)”（如人事管理信息系統(tǒng)、財務信息管理系統(tǒng)、酒店信息管理系統(tǒng)、 設備信息管理系統(tǒng)、倉庫管理信息系統(tǒng)、進存銷管理信息系統(tǒng)、學生信息管理系統(tǒng)、圖書館 信息管理系統(tǒng)，圖書銷售信息管理新系統(tǒng)等等）。 通過調查獲取用戶需求，按照需求的內容進行分析，按照內容、格式要求撰寫完整的軟 件需求規(guī)格說明書。 四、實驗步驟 1、 參考相關模板，初步理解軟件需求規(guī)格說明書的結構 2、 結合項目實際，完成軟件需

7、求規(guī)格說明書 3、 進一步檢查、完善相應的需求部分，盡量避免需求遺漏，和定義的不清晰。同時， 3 應確保采用規(guī)范圖例。 4、 重復進行前面幾個步驟，經過小組成員多次討論，并得到客戶的認可，最終達到客 戶和開發(fā)小組對需求的認識一致。 五、《軟件需求規(guī)格說明》內容、格式要求 1、形成軟件需求規(guī)格說明，要包括以下內容： 文檔名稱 文檔版本號 1． 文檔編寫人 文檔編寫記錄 2． 審核人 3． 文檔每次修訂時間，每次修訂人 文檔編寫目的 說明編寫這份軟件需求說明書的目的，指出預期的讀者 a．

8、 待開發(fā)的軟件系統(tǒng)的名稱； b． 本項目的任務提出者、開發(fā)者、用戶及實現(xiàn)該軟件的計算中心或計算 背景描述 機網絡； c． 該軟件系統(tǒng)同其他系統(tǒng)或其他機構的基本的相互來往關系。 定義，縮寫， 列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。 術語 a． 本項目的經核準的計劃任務書或合同、上級機關的批文； b． 屬于本項目的其他已發(fā)表的文件； 參考資料 c． 本文件中各處引用的文件、資料、包括所要用到的軟件開發(fā)標準。 列出這些文件資料的標題、文件編號、發(fā)表日期和出版單位，說明能夠 得到這些文件資料的來源。 敘述該項軟件開發(fā)的意圖、應用目標

9、、作用范圍以及其他應向讀者說 明的有關該軟件開發(fā)的背景材料。解釋被開發(fā)軟件與其他有關軟件之間的 任務 目標 概述 用戶的 特點 關系。如果本軟件產品是一項獨立的軟件，而且全部內容自含，則說明這 一點。如果所定義的產品是一個更大的系統(tǒng)的一個組成部分，則應說明本 產品與該系統(tǒng)中其他各組成部分之間的關系，為此可使用一張方框圖來說 明該系統(tǒng)的組成和本產品同其他各部分的聯(lián)系和接口。 列出本軟件的最終用戶的特點，充分說明操作人員、維護人員的教育 水平和技術專長，以及本軟件的預期使甩頻度。這些是軟件設計工作的重 要約束 4 假

10、定和 列出進行本軟件開發(fā)工作的假定和約束，例如經費限制、開發(fā)期限等。 約束 用列表的方式（例如 IPO 表即輸入、處理、輸出表的形式），逐項定量 和定性地敘述對軟件所提出的功能要求，說明輸入什么量、經怎樣的處理、 得到什么輸出，說明軟件應支持的終端數(shù)和應支持的并行操作的用戶數(shù)。 對功能 的規(guī)定 需求 規(guī)定 例子：  I:原始捕獲的數(shù)據(jù)幀 P：按照既定的數(shù)據(jù)幀存儲格式，存儲到離線文件中 O：數(shù)據(jù)幀文件 1． 1． 精度 對性能 2． 2． 時間特性要求 的規(guī)定 3． 3．

11、靈活性 解釋各輸入輸出數(shù)據(jù)類型，并逐項說明其媒體、格式、數(shù)值范圍、精 輸人輸 度等。對軟件的數(shù)據(jù)輸出及必須標明的控制輸出量進行解釋并舉例，包括 出要求 對硬拷貝報告（正常結果輸出、狀態(tài)輸出及異常輸出）以及圖形或顯示報 告的描述。 數(shù)據(jù)管 說明需要管理的文卷和記錄的個數(shù)、表和文卷的大小規(guī)模，要按可預見的 理能力 增長對數(shù)據(jù)及其份量的存儲要求作出估算。 要求 故障處 列出可能的軟件、硬件故障以及對各項性能而言所產生的后果和對故障處 理要求 理的要求。 其他專 門要求 a． 處理器型號及內存容量；

12、運行 b． 外存容量、聯(lián)機或脫機、媒體及其存儲格式，設備的型號及數(shù)量； 環(huán)境 設備 的規(guī) 定 c． 輸入及輸出設備的型號和數(shù)量，聯(lián)機或脫機； d． 數(shù)據(jù)通信設備的型號和數(shù)量； e． 功能鍵及其他專用硬件 5 支持軟 列出支持軟件,包括要用到的操作系統(tǒng)、編譯（或匯編）程序、測試支 件 持軟件等。 接口 說明該軟件同其他軟件之間的接口、數(shù)據(jù)通信協(xié)議等 控制 說明控制該軟件的運行的方法和控制信號，并說明這些控制信號的來源 2、形成軟件需求規(guī)格說明，格式和編寫體例要依據(jù)【附錄一】模板。 六、思考題 1、軟件

13、需求規(guī)格說明應該包括哪些方面的內容，如果沒有模板，你準備么樣組織材料， 來編寫需求說明？ 2、總結自己撰寫軟件需求規(guī)格說明的心得與收獲。 6 【附錄一】軟件需求規(guī)格說明模板（參見教材 P345-350） 1．引言 引言是對整個軟件需求規(guī)格說明的概覽，以幫助讀者更好地閱讀和理解文檔。包括文檔 的意圖（目的）、主要內容（范圍）、組織方式（文檔組織）、參考文獻（參考文獻）和閱讀

14、時的注意事項（定義、首字母縮寫和縮略語）。 1.1 文檔的意圖（目的） 目的是說明軟件需求規(guī)格說明的主要目標，描述軟件規(guī)格說明所定義的產品或某些產品 部分。限定預期的讀者。 1.2 主要內容（范圍） 在這一節(jié)中： ①根據(jù)名稱確定將被開發(fā)的軟件產品。 ②解釋軟件產品的預期功能，并在必要的時候解釋沒有納人軟件產品預期的功能。 ③描述軟件產品的應用，包括相關的好處、目標和目的。 ④如果在此軟件需求規(guī)格說明之外，還存在著一個更高層次的規(guī)格說明（例如系統(tǒng)需求 規(guī)格說明），那么該部分的描述應該與更高層次文檔的相關段落保持一致。 1.3 閱讀時的注意事項（定義、首字母縮寫

15、和縮略語） 定義了正確理解軟件需求規(guī)格說明所必需的術語、首字母縮寫和縮略語。 這部分內容也可以通過添加附錄或者引用其他文檔來提供。 1.4 參考文獻 在這一節(jié)中： ①提供需求規(guī)格說明文檔引用的全部文檔的清單列表。 ②利用標題、報告編號（如果適用）舊期和出版機構來標識文檔。 ③指出參考文獻的來源，在該來源中可以獲得文獻。 這部分內容也可以通過添加附錄或者引用其他文檔來提供。 1.5 組織方式（文檔組織） 在這一節(jié)中： ①描述軟件需求規(guī)格說明余下部分所包含的內容。 ②解釋軟件需求規(guī)格說明的組織方式。 2．總體描述 從總體上描述影響產品和需求的因素。這部

16、分并不涉及將在文檔第 3 部分（詳細需求描 述）中描述的具體的需求，而是為其提供背景知識，使其更加易于理解。 2．1 產品前景 該節(jié)將所定義的產品和其他相關的產品聯(lián)系起來，在聯(lián)系中描述產品的起源和背景，進 7 而說明對產品的總體預期。 如果產品是一個獨立的、完全自包含的系統(tǒng)，那么就應該在這里進行聲明。 如果像常見的情況那樣，產品僅僅是較大系統(tǒng)的一個組件，那么就應該將較大系統(tǒng)的需 求和軟件的功能聯(lián)系起來進行說明，并標識它們之間的接口。如果能夠開發(fā)一個可以顯示較 大系統(tǒng)的主要組件、內部連接和外部接口的框圖，將會有很大幫助。 這一節(jié)還應

17、該描述較大系統(tǒng)的其他部分對軟件產品的操作預期。這些部分包括： ①系統(tǒng)接口：系統(tǒng)接口對軟件產品的功能要求。 ②用戶界面：軟件產品和用戶之間接口的邏輯特征和優(yōu)化要求。 ③硬件接口：軟件產品和較大系統(tǒng)中硬件組件之間接口的邏輯特征。 ④軟件接口：其他軟件系統(tǒng)對軟件產品的要求。： ⑤交流接口：本地網絡協(xié)議之類的交流接口要求?！? ⑥內存：軟件產品在主存儲器和輔助存儲器上的局限性和可適用特性。 ⑦操作：用戶要求的正常和特殊操作。 ⑧地點改變需求：對指定地點、任務或者操作模式的需求，調整軟件裝置而需要改變的 地點或者任務的相關特征。 2.2 產品功能－ 概述軟件將要執(zhí)行的主要功能

18、。此處只需要概略的總結，其詳細內容將在第 3 部分（詳 細需求描述）中描述。例如，一個賬目管理程序的軟件需求規(guī)格說明會在本節(jié)中描述顧客賬 目維護、顧客描述和發(fā)票處理等功能，但不會提及上述功能的大量細節(jié)。如果存在為軟件產 品分配功能更高一層的規(guī)格說明，那么這個部分的功能概述應該直接從更高層次規(guī)格說明的 相關部分提取。 為了清晰起見：－ ①功能的組織應該能夠讓第一次看到文檔的顧客或者其他人理解功能列表。 ②可以使用文本或者圖形化的方法顯示不同功能及其聯(lián)系。 2.3 用戶特征 描述產品預期用戶的一般特征，包括受教育水平、經驗和技術能力等。這些描述信息可 以用來解釋第 3

19、部分（詳細需求描述）中特定需求出現(xiàn)的原因，但是本節(jié)并不涉及這些特定 的需求。 2.4 約束 對限制開發(fā)人員開發(fā)方案選擇的事項進行一般性描述。這些事項包括： ①規(guī)章政策。 ②硬件限制。 ③和其他應用的接口。 ④并發(fā)操作。 8 ⑤審計功能。 ⑥控制功能 ⑦高階語言要求（即程序開發(fā)語言）。 ⑧信號握手協(xié)議（即信息交流的可靠性要求）。 ⑨應用的臨界狀態(tài)。 ⑩安全性考慮。 2.5 假設和依賴 列舉并描述了那些會對文檔中所述需求產生影響的因素。這些因素并不是軟件的設計限 制，但是這些因素的任何變化都會影響到文檔中的需求。例如，有這樣

20、一個假設：軟件產品 的目標硬件上會有某個特定的操作系統(tǒng)。而在實際情況中，如果這樣的情況并不存在，那么 文檔中的需求將不得不進行相應的改變。 3.詳細需求描述 這通常是軟件需求規(guī)格說明中最多和最重要的部分。它要對所有的軟件需求進行充分的 描述。這部分的內容應該包括設計人員進行設計時所需要的所有細節(jié)，足以讓設計人員設計 出一個滿足需求的系統(tǒng)。它還需要清楚地告訴測試人員需要怎么樣的測試才能保證得到一個 滿足需求的系統(tǒng)。 在這一部分： ①細節(jié)需求的描述要符合優(yōu)秀需求的特性要求（參見 2. 5 節(jié)），文檔的組織和內容整合 要符合優(yōu)秀軟件需求規(guī)格說明文檔的特性要求（參見 15.5 節(jié)）。

21、 ②細節(jié)需求要能夠回溯到相關的前期文檔，形成前后參照。 ③所有的需求都要被唯一的標識。 ④需求的組織應該盡可能的提高可讀性。 該部分內容的最佳組織方式要依賴于軟件產品的應用領域和特性?！睮EEE 830-19981 為該部分的文檔組織提供了 8 種不同的模板方式，圖 15 一 5 所示的模板為其中之一。 圖 15 -6 所示的模板是按照系統(tǒng)特性來進行需求組織的，除此之外也可以按照操作模式、 類／對象、刺激／響應、功能分解、用戶類別等方式進行組織。關于其他幾種組織方式可參 見教材的附錄一（P423-428）。 [IEEE 830-1998」將需求分成了 5 種類別，并據(jù)此進行內

22、容的組織。這 5 種內容是： ①功能需求。 ②性能需求。 ③約束。 ④質量屬性。 ⑤對外接口。 軟件需求規(guī)格說明模板中第 2 章已經詳細解釋了 5 種類型需求的區(qū)別，本章將僅僅對文 9 檔內容的組織進行介紹。 3.1 對外接口需求 描述了設計人員正確開發(fā)與軟件外部實體的接口所需要的所有信息。 對軟件產品對外接口中的輸人／輸出項，可以參照下列方式進行描述： （1）名稱。 （2）目的描述。 （3）輸人源／輸出目標。 （4）有效范圍，精確度和誤差范圍。 （5）度量單位。 （6）時間要求。 （7）和其他輸人／輸

23、出項的關系。、 （8）屏幕布局／組織。 （9）窗口布局／組織。 （10）數(shù)據(jù)格式。 （11）命令格式。 （12）結束消息。 3.1.1 用戶界面 描述系統(tǒng)所需的每個用戶界面的邏輯特征。本節(jié)可能包括下列內容： ①對圖形用戶界面(GUI)標準的引用或者將要采用的產品系列的樣式指南。 ②有關字體、圖標、按鈕標簽、圖像、顏色選擇方案、組件的 tab 順序、常用控件等的 標準。 ③屏幕布局或解決方案的約束。 ④每個屏幕中將出現(xiàn)的標準按鈕、功能或者導航鏈接。 ⑤快捷鍵。． ⑥消息顯示約定。 ⑦便于軟件定位的布局標準。 ⑧滿足視力有問題的用戶的要求．， 3

24、.1.2 硬件接口 描述系統(tǒng)中軟件和硬件每一接口的特征。這種描述可能包括支持的硬件類型、軟硬件之 間交流的數(shù)據(jù)和控制信息的性質以及所使用的通信協(xié)議等。 3.1.3 軟件接口 描述該產品與其他外部組件（由名字和版本識別）的連接，包括數(shù)據(jù)庫、操作系統(tǒng)、工 具、程序庫和集成的商業(yè)組件等。聲明在軟件組件之間交換數(shù)據(jù)、消息和控制命令的目的。 描述其他外部組件所需要的服務以及組件間通信的性質。確定將在組件之間共享的數(shù)據(jù)。 10 3.1.4 通信接口 描述與產品所使用的通信功能相關的需求，包括電子郵件,Web 瀏覽器、網絡通信標準 或協(xié)議及電子表格

25、等。定義了相關的消息格式。規(guī)定通信安全或力。密問題、數(shù)據(jù)傳輸速率 和同步通 信機制等。 3.2 功能需求 描述了軟件產品在接收和處理外部輸入（或者處理和產生對外輸出）中發(fā)生的基本行為。 需要描述的內容有： z 對輸人的驗證 z 操作的順序 z 對異常的響應，例如 ? 數(shù)值越界 ? 通信間題 ? 錯誤處理與恢復 z 參數(shù)的說明 z 輸出和輸人的關系 ? 輸人／輸出序列 ? 將輸人轉換為輸出的公式和規(guī)則 3.2.x 系統(tǒng)特性 系統(tǒng)特性是外部期望的系統(tǒng)服務，它接收一系列的輸入，并產生外界預期的輸出。 3.2

26、.x.1 特性描述 提出了對該系統(tǒng)特性的簡短說明。 3.2.x.2 刺激／響應序列 列出輸入刺激序列（用戶動作、來自外部設備的信號或其他觸發(fā)器）和系統(tǒng)的響應 序列。 3.2.x.3 相關功能需求 詳細列出與該特性相關的功能需求。這些是必須提交給用戶的軟件功能，使用戶可以 使用所提供的特性執(zhí)行服務或者使用所指定的使用實例執(zhí)行任務。描述產品如何響應可預知 的出錯條件或者非法輸人或動作。 3. 2.x.3.n 功能需求 x.n 對單個需求（功能的某個步驟或者某個方面）的清晰描述，常見形式為“RID：系 統(tǒng)應該…”。 3.3 性能需求

27、闡述了不同的應用領域對產品性能的需求，并解釋它們的原理以幫助開發(fā)人員做出合理 的設計選擇。確定相互合作的用戶數(shù)、所支持的操作、響應時間以及與實時系統(tǒng)的時間關系。 11 還可以定義容量需求，例如存儲器和磁盤空間的需求或者存儲在數(shù)據(jù)庫中表的最大行數(shù)。盡 可能詳細地確定性能需求?？赡苄枰槍γ總€功能需求或特性分別陳述其性能需求，而不是 把它們都集中在一起陳述。 性能需求描述的詳細內容和形式示例可參見 2.3.3。 3.4 約束 描述可能由法律法規(guī)、標準、規(guī)范或者硬件限制等因素帶來的設計約束。 約束描述的詳細內容可參見 2.3.6. 3.5 質量屬性

28、 詳盡陳述對客戶或開發(fā)人員至關重要的產品質量屬性。這些特性必須是確定、定量的而 且在可能時是可驗證的。 關于質量屬性的詳細內容可參見 2.3.4. 3.6 其他需求 定義在軟件需求規(guī)格說明的其他部分未出現(xiàn)的需求，例如國際化需求或法律上的需求。 你還可以增加有關操作、管理和維護部分來完善產品安裝、配置、啟動和關閉、修復和容錯， 以及登錄和監(jiān)控操作等方面的需求。 附錄 附錄是對軟件需求規(guī)格說明正文信息的補充。雖然它并不總是必需的，但是必要的附錄 可以增加文檔對需求的描述能力。 常見的附錄內容包括： ①I/O 格式示例、成本分析研究、用戶調查結果。 ②有助于閱讀

29、軟件需求規(guī)格說明的背景信息，常見的有術語表、數(shù)據(jù)字典和分析模型 圖示。 ③需要解決但是目前還懸而未決的問題列表。 ④為了滿足安全、導出、初始加載或者其他需求而對代碼和數(shù)據(jù)媒體進行特殊打包處理 的說明。 索引 對文檔重要內容的位置引用，可以利用文檔編輯工具自動生成。 需求規(guī)格說明文檔的寫作原則與技巧參見教材 P350“需求規(guī)格說 文檔寫作”。 12 【附錄二】 評分標準 1、優(yōu)（90 以上）：文檔非常規(guī)范、思路很清晰，能較好反映、概括當前項 目內容以及客戶各個方面的需求。 2、良（80 以上 ）：文檔比較

30、規(guī)范、思路比較清晰，能較好反映、概括當前 項目內容以及客戶各個方面的需求。 3、中（70 以上）：文檔基本規(guī)范、思路清晰，能反映、概括當前項目內容 以及客戶各個方面的需求。 4、及格（60 以上）：文檔組織基本合理，思路基本清楚，能基本反映、概 括當前項目內容以及客戶各個方面的需求。 5、不及格（60 下）：文檔組織混亂，思路含混，不能反映、概括當前項目 內容以及客戶各個方面的需求。 13

31、 【附錄三】前景與范圍文檔寫作范例 ——自助餐廳在線訂餐系統(tǒng) 業(yè)務需求、高層次解決方案和系統(tǒng)特性都應該被定義到項目前景與范圍文檔 之中，以為后續(xù)的開發(fā)工作打好基礎。 前景與范圍文檔目錄如下： 1 業(yè)務需求 1.1 應用背景 1.2 業(yè)務機遇 1.3 業(yè)務目標 1.4 業(yè)務風險 2 項目前景 2.1 前景概述 2.2 主要特性 2.3 假設與依賴 3 項目范圍 3.1 第一版范圍 3.2 后續(xù)版本范圍 3.3 限制與排除 4 項目環(huán)境 4.1

32、操作環(huán)境 4.2 涉眾 4.3 項目屬性 詞匯表 參考資料 附錄 1、業(yè)務需求 （要求說明：該項內容主要目的是清晰地解釋系統(tǒng)的業(yè)務需求。業(yè)務需求描述了新系統(tǒng) 將帶給投資人、購買者和用戶的主要利益，說明了項目的最終目標。） 1.1 應用背景 （要求說明：概述系統(tǒng)開發(fā)的應用背景，描述原有的應用狀況，說明新系統(tǒng)開發(fā)的動 機。必要的情況下，還需要說明應用的歷史延續(xù)過程。） 目前，Process Impact 公司的大多數(shù)員工平均每天要花費 60 分鐘去白助餐廳 用午餐，其中大約有 20 分鐘要花在公司和自助餐廳之間的往返、選擇午餐和以 1

33、4 現(xiàn)金或信用卡方式結賬上。當員工到自助餐廳之外去用午餐時，他們平均有 90 分鐘時間不在崗。有些員工提前給自助食堂打電話預訂午餐，請自助餐廳準備好 他們選擇的午餐。但是，員工并不總是能夠如愿以償，因為自助餐廳有些食物已 賣完。而與此同時，自助餐廳又在浪費大量的食物，因為有些食物沒有賣掉而只 好倒掉。早餐和午餐同樣面臨著這樣的問題，只是到餐廳用餐的員工人數(shù)比午餐 要少得多。 1.2 業(yè)務機遇 （要求說明：如果開發(fā)的是商業(yè)產品，這部分描述的是存在的市場機遇以及產品要參與 競爭的市場。如果是企業(yè)信息系統(tǒng)，則應描述要解決的業(yè)務問題或需要改進的業(yè)務流程，

34、以 及系統(tǒng)的應用環(huán)境。 這部分內容還應對已有的產品和可能的解決方案進行比較評估，指出新產品的優(yōu)點。 說明有哪些問題因為沒有該產品而在當前無法解決。還要說明該產品怎樣符合市場潮流、技 術發(fā)展趨勢或企業(yè)的戰(zhàn)略方向。另外，還應有一段簡短的說明描述如果需要為客戶提供一個 完整的解決方案，還需要哪些其他的技術、過程和資源。） 許多員工都通過自助餐廳的一個在線訂餐系統(tǒng)提出訂餐請求，要求在指定的 日期和時間內將所訂的午餐送到公司的指定地點。通過這樣一個系統(tǒng)，使用這一 服務的員工可以節(jié)約相當可觀的時間，而且訂到自己喜歡食物的機會也增大了。 這既提高了他們的工作生活質量，也提高了他們的生產率。自助

35、餐廳提前了解到 客戶需要哪些食物，就可以減少浪費，并提高高員工的工作效率。要求送貨上門 的訂餐員工將來還可以從本地的其他飯店來訂餐，這就大大擴大了員工對食物的 選擇范圍，并通過與其他飯店的大量購餐協(xié)議而有可能節(jié)約費用。Process Impact 公司也可以只在自助餐廳訂午餐，而在其他飯店訂早餐、晚餐、特定事件的用餐 和周末會餐。 1.3 業(yè)務目標與成功標準 （要求說明：用量化和可衡量的方式概述產品提供了哪些重要的業(yè)務利益。如果其他 文檔（如業(yè)務用例文檔）中已包含了這些信息，此處指明參考文檔即可，不必重復其內容。 這一部分還應明確涉眾如何定義和判斷項目的成功。說明哪

36、些因素對項目獲得成功的影響最 大，無論這些因素是否處于組織的控制范圍內。還要定義可衡量的標準，用于評估各項業(yè)務 目標是否已實現(xiàn)。） 15 BO -1：在第一版應用之后的 6 個月內，減少食物的浪費。 度量標準（Scale）：每周被自助餐廳工作人員扔掉的食物的價值。 SC -1：在第一版應用之后的 s 個月內，目前在自助餐廳用午餐的員工中，75 ％的人使用在線訂餐系統(tǒng)。 SC -2：在第一版應用之后的 3 個月內，對自助餐廳滿意度的季度調查評價 要提高 0.5，而在第一版應用之后的 12 個月內，這種滿意度要提高 1.0。 1

37、.4 業(yè)務風險 （要求說明：概述與產品開發(fā)相關的主要風險。風險類別包括市場競爭、時間安排、 用戶認可、實現(xiàn)技術以及可能對業(yè)務造成的負面影響。．要評估每一項風險可能造成的損失、 發(fā)生的幾率以及對它的控制能力。找出所有可能降低風險的必要措施。如果在業(yè)務用例分析 或類似文檔中已經給出了這些信息，此處只需指明出處而不必重復該信息。） RI -1：使用該系統(tǒng)的員工太少，減少了對系統(tǒng)開發(fā)和變更自助餐廳經營過程 的投資回報。 可能性 0.3，影響為 9。 RI -2：其他本地飯店可能并不認何減價是員工使月這一系統(tǒng)的正當理由，這 會減低員工對該系統(tǒng)的滿意度，并可能會減少他們對這一系統(tǒng)的

38、使 月。 可能性為 0.4，影響為 3。 2 項目前景 （要求說明：這一部分建立系統(tǒng)的戰(zhàn)略前景，該系統(tǒng)將實現(xiàn)業(yè)務目標。前景為產品生 命周期中所有的決策提供了背景。詳細的功能需求或項目計劃信息不應包括在這一部分內。) 2.1 前景概述 （要求說明：用一個簡潔的聲明概括系統(tǒng)的長期目標和意圖。聲明應當反映能夠滿足不 同涉眾需求的平衡的觀點。前景聲明可以理想化，但應當以當前或預期的市場現(xiàn)狀、企業(yè)結 構、團體戰(zhàn)略和資源限制為依據(jù)。） 對那些希望通過公司自助餐廳或其他本地飯店在線訂餐的員工來說，“自助 餐廳訂餐系統(tǒng)”是一個基于 Internet 的應月程序，

39、它可以接受個人訂餐或團體訂 餐，結算用餐費用，并觸發(fā)將預訂餐送到 Process Impact 公司內指定位置的事件。 16 與當前的電話訂餐和人工訂餐不同，使用“自助餐廳訂餐系統(tǒng)”的雇員并不需要到 食堂內去用餐，這既可以節(jié)約他灼的時間，又可以擴大他們對食物的選擇范周。 2.2 主要特性 （要求說明：為新產品的每一項主要特性或用戶功能進行固定的、唯一的命名或編號， 突出其超越原有產品或競爭產品的特性。給每項特性一個唯一的標號，這樣可以追蹤其去向 —用戶需求、功能需求和其他系統(tǒng)元素。） FE- 1：根據(jù)自助餐廳提供的菜單來訂餐。 FE-

40、2：根據(jù)真他本地飯店的送貨菜單來訂餐。 FE-3：請求送餐。 FE-4：創(chuàng)建、瀏覽、修改、刪除用餐預訂。 FE-5：通過公司的內聯(lián)網訪問系統(tǒng)，或者授權員工通過外部 Internet 訪問系 統(tǒng)。 2.3 假設與依賴 （要求說明：記錄構思項目和編寫前景與范圍文檔過程中涉眾所提出的每一項假設。 由于一方所做的假設往往不為其他各方所知，因此通過將所有的假設記錄下來并進行檢查， 各方就能對項目潛在的基本假設達成一致。這樣便能夠避免可能的混亂以及這種混亂會在將 來造成的影響。 這一部分還記錄項目對不在自身控制范圍內的外部因素的主要依賴關系。這類外部因素 包括懸而未決的行業(yè)

41、標準或政府法規(guī)、其他項目、第三方廠商及開發(fā)伙伴等。） AS-1：自助餐廳內有可以訪問公司內網的計算機和打印機。 AS-2：自助餐廳有送貨人員和送貨車輛，最多比請求的送貨時間晚 15 分鐘。 DE-1：如果某飯店有自己的聯(lián)機訂餐系統(tǒng)，那么“自助餐廳訂餐系統(tǒng)”必須能 與這一系統(tǒng)進行雙向通信。 3 項目范圍 （要求說明：項目的范圍定義了解決方案的概念和范圍，同時也要表明系統(tǒng)不能提供 哪些功能，它可以幫助涉眾建立現(xiàn)實的期望。） 3.1 第一版范圍 （要求說明：概述計劃在產品的第一個版本中實現(xiàn)的主要特性。描述產品的質量特性， 17

42、 產品依靠這些特性為不同類別的用戶提供預期利益。 如果目標是集中開發(fā)力量和維持合理的項目進度，就不要企圖在 1.0 版本中包含所有可 能的需求。那樣會導致項目范圍在不知不覺中增大，使得進度延誤。應該把注意力集中在那 些能夠在最短時間內，以最適宜的成本，為最大多數(shù)用戶提供最大價值的特性上。） 3.2 后續(xù)版本范圍 （要求說明：如果要采取階段性的開發(fā)方式，需要決定推遲實現(xiàn)哪些特性，并為后續(xù) 的版本做出時間安排。后續(xù)版本能夠實現(xiàn)更多的需求和特性，并可完善最初的功能。隨著產 品的不斷成熟，系統(tǒng)的性能、可靠性和其他質量特征也將得到改進。） 表 1 版本范圍

43、 3.3 限制與排除 (要求說明：管理范圍蔓延的方法之一是，定義項目包含的需求與不包含的需求之間的 界線。此處應列出涉眾可能希望得到、但不在產品或其某個特定版本計劃之內的功能和特 性。) LI-1：自助餐廳的有些食物不適宜送貨，因此“自助餐廳訂餐索統(tǒng)”的顧客使 用的送貨菜單是食堂整個菜單的一個子集。 LI -2“自助餐廳訂餐系統(tǒng)”只能用子 Process Impact 公司總部內的自助餐廳。 4 項目環(huán)境 4.1 操作環(huán)境 （要求說明：描述系統(tǒng)將用于什么樣的環(huán)境，定義關鍵的可用性、可靠性、性能等質 量屬性要求。這些信

44、息對系統(tǒng)的結構定義有著重要的影響。 與操作環(huán)境相關的問題包括： ①用戶是地理分散的還是集中的？ 18 ②不同的用戶會在什么時間訪問系統(tǒng)？ ③數(shù)據(jù)在何處生成，用于何處？ ④訪問數(shù)據(jù)時的最大響應時間是否已知？ ⑤用戶能否容忍服務中斷？ ⑥是否需要提供訪問安全控制和數(shù)據(jù)保護？） 4.2 涉眾 （要求說明：描述項目涉眾的相關信息，重點介紹不同類型的客戶、目標市場和目標 市場中的用戶類別，說明他們和系統(tǒng)密切相關的一些特征。） 4.3 項目屬性 （要求說明：要想更有效地進行決策，涉眾就必須就項目的相關屬性及其優(yōu)先級達成 一致。這

45、些屬性包歌括：特性（功能、范圍）、質量、成本、進度和人員。 對任何一個特定的項目而言，上述每個屬性都有三種影響因素： ①驅動因素(Driver)：重要的成功目標。 ②約束因素（Constraint）：項目必須在一定的限制下展開工作。 ③可調整因素(Degree of Freedom)：可以根據(jù)其他方面進行平衡和調整的因素。 項目經理的目標是：在約束因素施加的限制內，合理安排可調整因素，獲得最大的驅 動因素。 在項目屬性之間不可調和時，屬性間的優(yōu)先級順序指導項目管理者采取正確的行動。 例如，對于急需面市的系統(tǒng)，其進度是第一優(yōu)先級，這樣在項目無法按照預定計劃前進時， 就

46、可能會推遲特定功能的實現(xiàn)，或者增加人員和投資。再例如，對于人員（或費用）受限的 系統(tǒng)，人員（費用）是第一優(yōu)先級，在項目出現(xiàn)偏離時就可能延遲系統(tǒng)的完成期限，或者推 遲部分功能的實現(xiàn)。除特例情況之外，質量都是一個不應該被犧牲的項目屬性。） 表 2 項目屬性的示例 19 【附錄四】 需求文檔完整范例 本附錄通過“自助食堂訂餐系統(tǒng)(Cafeteria Ordering System COS)”這樣一個假想的小型 項目，闡述了本書所描述的某些需求文檔和圖。

47、這里包括如下這些內容： ● 前景和范圍文檔。 ● 用例列表和若干用例描述。 ● 部分軟件需求規(guī)格說明。 ● 某些分析模型。 ● 部分數(shù)據(jù)字典。 ● 若干業(yè)務規(guī)則。 因為這僅僅是一個范例，所以我們并不打算完善這些需求元素。我們的目標只是提供一 種思想，各種類型的需求信息之間彼此是如何關聯(lián)的，并演示我們可能如何編寫文檔每一部 分的內容。在一個小型項目中，將不同的需求信息綜合到單一的文檔中，常常是有意義的， 因此我們可能沒有單獨的前景和范圍文檔、用例文檔和軟件需求規(guī)格說明。這些文檔中的信 息能夠以多種其他合理的方式來組織?；镜哪繕耸谴_保需求文檔清晰明了、完整和易使用。

48、 這些文檔總的來說都遵照前面章節(jié)所描述的模板，但是，因為這只是一個小型項目， 所以對這些模板稍微作了一些簡化。有時，會將幾個部分合并起來，這是為了避免信息重復。 每一個項目都應該考慮如何適應組織的標準模板，以盡量適合于項目的規(guī)模和本質。 1 前景和范圍文檔 1.1 業(yè)務需求 1．背景、業(yè)務機會和客戶需要 目前，Process Impact 公司的大多數(shù)員工平均每天要花費 60 分鐘去自助食堂選擇、購買 并用午餐，其中大約有 20 分鐘要花在公司和自助食堂之間的往返路程、選擇自己喜歡的午 餐、以及以現(xiàn)金方式或以信用卡方式結算餐費上。當員工出去用午餐時，他們平均有

49、 90 分 鐘時間不在崗。有些員工提前給自助食堂打電話預訂午餐，請自助食堂準備好他們所選擇的 午餐。但是，員工并不是總能如愿以償，因為自助食堂有些食物已賣完，而與此同時，自助 食堂又不可避免地會浪費大量的食物，因為有些食物沒有賣出去而只好倒掉。早餐和晚餐同 樣面臨著這樣的問題，只是到自助食堂用餐的員工人數(shù)比午餐要少得多。 許多員工都通過允許自助食堂用戶在線訂餐的一個系統(tǒng)而提出訂餐請求，要求在指定的 日期和時間內將所訂的午餐送到公司的指定地點。通過這樣一個系統(tǒng)，使用這一服務的員工 可以節(jié)約相當可觀的時間，而且訂到自己所喜歡的食物的機會也增大了。這既提高了他們的 工作生活質量，也提高了

50、他們的生產率。自助食堂提前了解到客戶需要哪些食物，就可以減 少浪費，并提高自助食堂員工的工作效率。要求送貨上門的訂餐員工將來還可以從本地的飯 店來訂餐，這就大大擴大了員工對食物的選擇范圍，并通過與飯店的大量購餐協(xié)議而有可能 節(jié)約費用。Process Impact 公司也可以只在自助食堂訂午餐，而在飯店訂早餐、晚餐、特定 事件的用餐以及周末會餐。 2．業(yè)務目標（Business Objective. BO）和成功標準（Success Criteria SC) BO-l：初始版本發(fā)布之后的 6 個月內，自助食堂的食物浪費減少 50%。 度量單位（scale）：自助食堂的工作人員每星期所倒掉

51、的食物的價值。 20 計量(meter)檢查“自助食堂存貨系統(tǒng)（Cafeteria Inventory System）”的日志。 過去情況（past）[2002，初步調研］：30% 一般標準（plan）：小于 15% 最低標準（must）：小于 20% BO-2：初始版本發(fā)布之后的 12 個月內，自助食堂的運作費用減少 50％。 BO-3：初始版本發(fā)布之后的 3 個月內，每個雇員每天的平均有效工作時間增加 20 分鐘。 SC-1：目前通過自助食堂解決午餐問題的那些員工，在初始版本發(fā)布之后的 6 個月內， 他們中有 75%的人使用“自助食堂

52、訂餐系統(tǒng)”。 SC-2：初始版本發(fā)布之后的 3 個月內，對自助食堂滿意度的季度調查評價要提高 0.5, 而在初始版本發(fā)布之后的 12 個月內，這種滿意度要提高 1.0. 3．業(yè)務風險（RIsk) RI-1：“自助食堂雇員聯(lián)合會(Cafeteria Employees Union)”可能要求與雇員重新簽訂合 同，以反映新的雇員角色和自助食堂營業(yè)時間。（可能性為 0.6.影響為 3） RI-2：使用該系統(tǒng)的雇員太少，減少了對系統(tǒng)開發(fā)和變更自助食堂經營過程的投資回報。 （可能性為 0.3，影響為 9) RI-3：本地飯店可能并不認同減價是雇員使用這一系統(tǒng)的正當理由，這會減

53、低雇員對該 系統(tǒng)的滿意度，并可能會減少他們對這一系統(tǒng)的使用。（可能性為 0.4，影響為 3） 1.2 解決方案的前景 1．前景陳述 對那些希望通過公司自助食堂或本地飯店在線訂餐的員工來說，“自助食堂訂餐系統(tǒng)” 是一個基于 Internet 的應用程序，它可以接受個人訂餐或團體訂餐，結算用餐費用，并觸發(fā) 將預訂餐送到 Process Impact 公司內的指定位置。與當前的電話訂餐和人工訂餐不同，使用 “自助食堂訂餐系統(tǒng)”的雇員并不需要到食堂內去用餐，這既可以節(jié)約他們的時間，又可以 增加他們對食物的選擇范圍。 2．主要特性（FEature) FE-1：根據(jù)自助食堂提供的選擇

54、菜單或送貨菜單來訂餐。 FE-2：根據(jù)本地飯店的送貨菜單來訂餐。 FE-3：創(chuàng)建、瀏覽、修改和刪除用餐預訂服務。 FE-4：注冊用餐的付費方式。 FE-5：請求送餐。 FE-6：創(chuàng)建、瀏覽、修改和刪除自助食堂菜單。 FE-7：預訂自助食堂菜單上所沒有的定做菜。 FE-8：生成自助食堂定做菜的食譜和配料列表。 FE-9：通過公司的內聯(lián)網可以訪問系統(tǒng)，或者授權的員工通過外部 Internet 訪問系統(tǒng)。 3．假設(ASsumption)和依賴(DEpendency) AS-1：自助食堂內有可以訪問公司內聯(lián)網的計算機和打印機，這樣自助食堂的雇員就 可以處理期望的訂單量，不會遺

55、漏任何送貨時間。 AS-2：最多比請求的送貨時間晚 15 分鐘，自助食堂有送貨人員和送貨車輛，這樣就能 滿足所有訂單的送貨要求。 DE-1：如果某飯店有自己的聯(lián)機訂餐系統(tǒng)，那么“自助食堂訂餐系統(tǒng)”必須能與這一 系統(tǒng)進行雙向通信。 1.3 范圍和局限性 21 LI-2： 1．初始版本和后續(xù)版本的范圍 2．局限性（Limitation）和排斥性 LI-1：自助食堂的有些食物不適宜于送貨，因此“自助食堂訂餐系統(tǒng)”的顧客所用的菜單 是

56、食堂整個菜單的一個子集。 “自助食堂訂餐系統(tǒng)”只能用于俄勒岡州 Clackamas 的 Process Impact 公司總部內 的自助食堂。 1.4 業(yè)務上下文 1．涉眾概覽 22

57、 23 24

58、 25 26

59、 27 28

60、 29 30

61、 31 3 軟件需求規(guī)格說明 3.1 介紹 1．目標 軟件需求規(guī)格說明描述了“自助食堂訂餐系統(tǒng)(Cafeteria Ordering System, COS)"1.0 版本 的軟件功能性需求和非功能性需求。這一文檔計劃由實現(xiàn)和驗證系統(tǒng)正確功能的項目團隊成 員來使用。除非在其他地方另有說明，這里指定的所有需求都具有高優(yōu)先級，而且都要在版 本 1.0 中加以實現(xiàn)。 2．項目范圍和產品特性 “自助食堂訂餐系統(tǒng)”允許 Process Impact 公司雇員向公司的自助食堂在線訂餐

62、，并送 餐到公司內的指定地點。詳細的項目描述請參見 Cafeteria Ordering 枷 tem Visionand Scope Document(自助食堂訂餐系統(tǒng)前景和范圍文檔）【1】。文檔中這一部分的標題為“初始版本和 后續(xù)版本的范圍”，列出了按照進度計劃在這一版本中實現(xiàn)的全部或部分特性。 3．參考文獻 （1） Karl Wiegers 所著的 Cafeteria Ordering System Vision and Scope Document，其 網址是 vision and scope.doc （2）Karl Widgers 所著的 Process Impact I

63、ntranet Development Standard 版本 1.3，其 網址是 intranet dev-std.doc （ 3 ） Christine Zambito 所 著 的 Process Impact Business Rules Catalog, 其 網 址 是 rules.doc （ 4 ） Christine Zambito 所 著 的 Process Impact Internet Application User Interface Standard 版本 2.0,其網址是 internet ui std.doc

64、 3.2 總體描述 1．產品遠景規(guī)劃 “自助食堂訂餐系統(tǒng)”是一個新系統(tǒng)，它取代了當前在 Process Impact 公司自助食堂內 以手工方式和電話方式預定和選擇午餐的過程。圖 D.1 是一幅關聯(lián)圖，它演示了 1.0 版本的 外部實體和系統(tǒng)接口。期望系統(tǒng)演化若干個版本，最終與本地若干飯店的 Internet 訂餐服務 相連接，并提供信用卡和借記卡授權服務。 32

65、 33 OE-1： OE-2： OE-3： 3．運行環(huán)境(Operating Environment，OE) “自助食堂訂餐系統(tǒng)”的操作將通過如下的 Web 瀏覽器來完成：Microsoft Internet Explorer 版本 5.0 和 6.0，Netscape Communicator 版本 4.7 和 Netscape 版本 6 和版本 7。 “自助食堂訂餐系統(tǒng)”將運行在一個服務器中，該服務器運行當前由公司批準的 Red Ha

66、t Linux 版本和 Apache HTTP Server。 “自助食堂訂餐系統(tǒng)”將允許用戶通過公司內聯(lián)網來訪問，如果用戶被授權在公 司的外部穿過防火墻來訪問，那么用戶也可以在家里通過 Internet 來訪問該系統(tǒng)。 4．設計和實現(xiàn)的約束條件（constraint） CO-1：系統(tǒng)的設計、編碼和維護文檔將遵照 Pruccss Impact Intranet Development Standard （Process Impact 公司內聯(lián)網開發(fā)標準）版本 1.3 【2】。 CO-2：系統(tǒng)將采用公司標準的當前 Oracle 數(shù)據(jù)庫引擎。 CO-3：所有 HTML 代碼將遵照 HTML 4.0 標準。 CO-4：所有