1、軟件需求分析 實(shí) 驗(yàn) 指 導(dǎo) 書 2013 年 9 月 中文軟件需求分析課 程 編 號課程 Software Requirement 名稱英文適 用 專 業(yè)軟件工程Analysis 總學(xué)時32理論教學(xué)學(xué)時28課 4 內(nèi) 學(xué) 分2實(shí)踐教學(xué)學(xué)時課 8 外 執(zhí)筆者劉冰編 寫 日 期2012 年 3 月需求工程軟件建模與分析（駱斌主編、丁二 講授 玉編著，高等教育出版社，2009 年 4 月第一版，ISBN 978-7-04-7） 教材 軟件需求（第 2 版）（美）Karl E.Wiegers 著， 參考 劉偉琴、劉洪濤譯，清華大學(xué)出版社、2004 年 11 月 第 1 版，ISBN 978-7-30

2、2-09834-8） 1 目 錄 一、實(shí)驗(yàn)?zāi)康?3 二、實(shí)驗(yàn)的軟硬件環(huán)境.3 三、實(shí)驗(yàn)要求與任務(wù).3 四、實(shí)驗(yàn)步驟.3 五、軟件需求規(guī)格說明書內(nèi)容、格式要求.4 六、思考題6 【附錄一】軟件需求規(guī)格說明模板.7 【附錄二】 評分標(biāo)準(zhǔn).13 【附錄三】前景與范圍文檔寫作范例.14 【附錄四】需求文檔完整范例20 【附錄五】軟件需求規(guī)格說明書（樣例一）.40 【附錄六】軟件需求規(guī)格說明書（樣例二）52 2 實(shí)驗(yàn)名稱：“管理信息系統(tǒng)”軟件需求規(guī)格說明書的編寫 一、實(shí)驗(yàn)?zāi)康?需求開發(fā)的最終成果是：客戶和開發(fā)小組對將要開發(fā)的產(chǎn)品達(dá)成一致的協(xié)議。這一協(xié)議 綜合了業(yè)務(wù)需求、用戶需求和軟件功能需求。從前面實(shí)驗(yàn)

3、中所得出的一些分析文檔中，我們 可以知道：項(xiàng)目視圖和范圍文檔包含了業(yè)務(wù)需求，而使用實(shí)例文檔包含了用戶需求。我們還 必須編寫從使用實(shí)例派生出的功能需求文檔，還要編寫產(chǎn)品的非功能需求文檔，包括質(zhì)量屬 性和外部接口需求。至此，我們綜合前面的相關(guān)分析結(jié)果，來進(jìn)行需求說明書的編寫，進(jìn)一 步理解由業(yè)務(wù)需求，用戶需求，功能需求三個部分綜合而形成軟件需求說明書的過程。 二、實(shí)驗(yàn)的軟硬件環(huán)境 硬件：微型計算機(jī)，打印機(jī)； 軟件：Windows XP/7 ，Office 2003/2007，Visual Studio 、Delphi，SQL Server 等 要求實(shí)驗(yàn)環(huán)境為網(wǎng)絡(luò)環(huán)境。 三、實(shí)驗(yàn)要求與任務(wù) 1、要求：

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

5、件需求規(guī)格說明書 3、 進(jìn)一步檢查、完善相應(yīng)的需求部分，盡量避免需求遺漏，和定義的不清晰。同時， 3 應(yīng)確保采用規(guī)范圖例。 4、 重復(fù)進(jìn)行前面幾個步驟，經(jīng)過小組成員多次討論，并得到客戶的認(rèn)可，最終達(dá)到客 戶和開發(fā)小組對需求的認(rèn)識一致。 五、軟件需求規(guī)格說明內(nèi)容、格式要求 1、形成軟件需求規(guī)格說明，要包括以下內(nèi)容： 文檔名稱 文檔版本號 1 文檔編寫人 文檔編寫記錄2 審核人3 文檔每次修訂時間，每次修訂人 文檔編寫目的 說明編寫這份軟件需求說明書的目的，指出預(yù)期的讀者 a 待開發(fā)的軟件系統(tǒng)的名稱；b 本項(xiàng)目的任務(wù)提出者、開發(fā)者、用戶及實(shí)現(xiàn)該軟件的計算中心或計算背景描述機(jī)網(wǎng)絡(luò)；c 該軟件系統(tǒng)同其

6、他系統(tǒng)或其他機(jī)構(gòu)的基本的相互來往關(guān)系。定義，縮寫，列出本文件中用到的專門術(shù)語的定義和外文首字母組詞的原詞組。術(shù)語a 本項(xiàng)目的經(jīng)核準(zhǔn)的計劃任務(wù)書或合同、上級機(jī)關(guān)的批文； b 屬于本項(xiàng)目的其他已發(fā)表的文件； 參考資料c 本文件中各處引用的文件、資料、包括所要用到的軟件開發(fā)標(biāo)準(zhǔn)。列出這些文件資料的標(biāo)題、文件編號、發(fā)表日期和出版單位，說明能夠 得到這些文件資料的來源。 敘述該項(xiàng)軟件開發(fā)的意圖、應(yīng)用目標(biāo)、作用范圍以及其他應(yīng)向讀者說 明的有關(guān)該軟件開發(fā)的背景材料。解釋被開發(fā)軟件與其他有關(guān)軟件之間的任務(wù)目標(biāo)概述用戶的特點(diǎn)關(guān)系。如果本軟件產(chǎn)品是一項(xiàng)獨(dú)立的軟件，而且全部內(nèi)容自含，則說明這一點(diǎn)。如果所定義的產(chǎn)品是

7、一個更大的系統(tǒng)的一個組成部分，則應(yīng)說明本 產(chǎn)品與該系統(tǒng)中其他各組成部分之間的關(guān)系，為此可使用一張方框圖來說 明該系統(tǒng)的組成和本產(chǎn)品同其他各部分的聯(lián)系和接口。列出本軟件的最終用戶的特點(diǎn)，充分說明操作人員、維護(hù)人員的教育 水平和技術(shù)專長，以及本軟件的預(yù)期使甩頻度。這些是軟件設(shè)計工作的重 要約束4 假定和 列出進(jìn)行本軟件開發(fā)工作的假定和約束，例如經(jīng)費(fèi)限制、開發(fā)期限等。約束用列表的方式（例如 IPO 表即輸入、處理、輸出表的形式），逐項(xiàng)定量 和定性地敘述對軟件所提出的功能要求，說明輸入什么量、經(jīng)怎樣的處理、 得到什么輸出，說明軟件應(yīng)支持的終端數(shù)和應(yīng)支持的并行操作的用戶數(shù)。對功能的規(guī)定需求規(guī)定 例子：I

8、:原始捕獲的數(shù)據(jù)幀P：按照既定的數(shù)據(jù)幀存儲格式，存儲到離線文件中O：數(shù)據(jù)幀文件 1 1 精度對性能2 2 時間特性要求的規(guī)定3 3 靈活性解釋各輸入輸出數(shù)據(jù)類型，并逐項(xiàng)說明其媒體、格式、數(shù)值范圍、精輸人輸度等。對軟件的數(shù)據(jù)輸出及必須標(biāo)明的控制輸出量進(jìn)行解釋并舉例，包括出要求對硬拷貝報告（正常結(jié)果輸出、狀態(tài)輸出及異常輸出）以及圖形或顯示報告的描述。數(shù)據(jù)管說明需要管理的文卷和記錄的個數(shù)、表和文卷的大小規(guī)模，要按可預(yù)見的理能力增長對數(shù)據(jù)及其份量的存儲要求作出估算。要求故障處列出可能的軟件、硬件故障以及對各項(xiàng)性能而言所產(chǎn)生的后果和對故障處理要求理的要求。其他專門要求a 處理器型號及內(nèi)存容量；運(yùn)行b 外

9、存容量、聯(lián)機(jī)或脫機(jī)、媒體及其存儲格式，設(shè)備的型號及數(shù)量；環(huán)境設(shè)備的規(guī)定c 輸入及輸出設(shè)備的型號和數(shù)量，聯(lián)機(jī)或脫機(jī)；d 數(shù)據(jù)通信設(shè)備的型號和數(shù)量；e 功能鍵及其他專用硬件5 支持軟列出支持軟件,包括要用到的操作系統(tǒng)、編譯（或匯編）程序、測試支件持軟件等。接口說明該軟件同其他軟件之間的接口、數(shù)據(jù)通信協(xié)議等控制說明控制該軟件的運(yùn)行的方法和控制信號，并說明這些控制信號的來源2、形成軟件需求規(guī)格說明，格式和編寫體例要依據(jù)【附錄一】模板。 六、思考題 1、軟件需求規(guī)格說明應(yīng)該包括哪些方面的內(nèi)容，如果沒有模板，你準(zhǔn)備么樣組織材料， 來編寫需求說明？ 2、總結(jié)自己撰寫軟件需求規(guī)格說明的心得與收獲。 6 【附錄

10、一】軟件需求規(guī)格說明模板（參見教材 P345-350） 1引言 引言是對整個軟件需求規(guī)格說明的概覽，以幫助讀者更好地閱讀和理解文檔。包括文檔 的意圖（目的）、主要內(nèi)容（范圍）、組織方式（文檔組織）、參考文獻(xiàn)（參考文獻(xiàn)）和閱讀 時的注意事項(xiàng)（定義、首字母縮寫和縮略語）。 1.1 文檔的意圖（目的） 目的是說明軟件需求規(guī)格說明的主要目標(biāo)，描述軟件規(guī)格說明所定義的產(chǎn)品或某些產(chǎn)品 部分。限定預(yù)期的讀者。 1.2 主要內(nèi)容（范圍） 在這一節(jié)中： 根據(jù)名稱確定將被開發(fā)的軟件產(chǎn)品。 解釋軟件產(chǎn)品的預(yù)期功能，并在必要的時候解釋沒有納人軟件產(chǎn)品預(yù)期的功能。 描述軟件產(chǎn)品的應(yīng)用，包括相關(guān)的好處、目標(biāo)和目的。 如果

11、在此軟件需求規(guī)格說明之外，還存在著一個更高層次的規(guī)格說明（例如系統(tǒng)需求 規(guī)格說明），那么該部分的描述應(yīng)該與更高層次文檔的相關(guān)段落保持一致。 1.3 閱讀時的注意事項(xiàng)（定義、首字母縮寫和縮略語） 定義了正確理解軟件需求規(guī)格說明所必需的術(shù)語、首字母縮寫和縮略語。 這部分內(nèi)容也可以通過添加附錄或者引用其他文檔來提供。 1.4 參考文獻(xiàn) 在這一節(jié)中： 提供需求規(guī)格說明文檔引用的全部文檔的清單列表。 利用標(biāo)題、報告編號（如果適用）舊期和出版機(jī)構(gòu)來標(biāo)識文檔。 指出參考文獻(xiàn)的來源，在該來源中可以獲得文獻(xiàn)。 這部分內(nèi)容也可以通過添加附錄或者引用其他文檔來提供。 1.5 組織方式（文檔組織） 在這一節(jié)中： 描述

12、軟件需求規(guī)格說明余下部分所包含的內(nèi)容。 解釋軟件需求規(guī)格說明的組織方式。 2總體描述 從總體上描述影響產(chǎn)品和需求的因素。這部分并不涉及將在文檔第 3 部分（詳細(xì)需求描 述）中描述的具體的需求，而是為其提供背景知識，使其更加易于理解。 21 產(chǎn)品前景 該節(jié)將所定義的產(chǎn)品和其他相關(guān)的產(chǎn)品聯(lián)系起來，在聯(lián)系中描述產(chǎn)品的起源和背景，進(jìn) 7 而說明對產(chǎn)品的總體預(yù)期。 如果產(chǎn)品是一個獨(dú)立的、完全自包含的系統(tǒng)，那么就應(yīng)該在這里進(jìn)行聲明。 如果像常見的情況那樣，產(chǎn)品僅僅是較大系統(tǒng)的一個組件，那么就應(yīng)該將較大系統(tǒng)的需 求和軟件的功能聯(lián)系起來進(jìn)行說明，并標(biāo)識它們之間的接口。如果能夠開發(fā)一個可以顯示較 大系統(tǒng)的主要組

13、件、內(nèi)部連接和外部接口的框圖，將會有很大幫助。 這一節(jié)還應(yīng)該描述較大系統(tǒng)的其他部分對軟件產(chǎn)品的操作預(yù)期。這些部分包括： 系統(tǒng)接口：系統(tǒng)接口對軟件產(chǎn)品的功能要求。 用戶界面：軟件產(chǎn)品和用戶之間接口的邏輯特征和優(yōu)化要求。 硬件接口：軟件產(chǎn)品和較大系統(tǒng)中硬件組件之間接口的邏輯特征。 軟件接口：其他軟件系統(tǒng)對軟件產(chǎn)品的要求。： 交流接口：本地網(wǎng)絡(luò)協(xié)議之類的交流接口要求。 內(nèi)存：軟件產(chǎn)品在主存儲器和輔助存儲器上的局限性和可適用特性。 操作：用戶要求的正常和特殊操作。 地點(diǎn)改變需求：對指定地點(diǎn)、任務(wù)或者操作模式的需求，調(diào)整軟件裝置而需要改變的 地點(diǎn)或者任務(wù)的相關(guān)特征。 2.2 產(chǎn)品功能 概述軟件將要執(zhí)行的

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

15、需求出現(xiàn)的原因，但是本節(jié)并不涉及這些特定 的需求。 2.4 約束 對限制開發(fā)人員開發(fā)方案選擇的事項(xiàng)進(jìn)行一般性描述。這些事項(xiàng)包括： 規(guī)章政策。 硬件限制。 和其他應(yīng)用的接口。 并發(fā)操作。 8 審計功能。 控制功能 高階語言要求（即程序開發(fā)語言）。 信號握手協(xié)議（即信息交流的可靠性要求）。 應(yīng)用的臨界狀態(tài)。 安全性考慮。 2.5 假設(shè)和依賴 列舉并描述了那些會對文檔中所述需求產(chǎn)生影響的因素。這些因素并不是軟件的設(shè)計限 制，但是這些因素的任何變化都會影響到文檔中的需求。例如，有這樣一個假設(shè)：軟件產(chǎn)品 的目標(biāo)硬件上會有某個特定的操作系統(tǒng)。而在實(shí)際情況中，如果這樣的情況并不存在，那么 文檔中的需求將不得

16、不進(jìn)行相應(yīng)的改變。 3.詳細(xì)需求描述 這通常是軟件需求規(guī)格說明中最多和最重要的部分。它要對所有的軟件需求進(jìn)行充分的 描述。這部分的內(nèi)容應(yīng)該包括設(shè)計人員進(jìn)行設(shè)計時所需要的所有細(xì)節(jié)，足以讓設(shè)計人員設(shè)計 出一個滿足需求的系統(tǒng)。它還需要清楚地告訴測試人員需要怎么樣的測試才能保證得到一個 滿足需求的系統(tǒng)。 在這一部分： 細(xì)節(jié)需求的描述要符合優(yōu)秀需求的特性要求（參見 2. 5 節(jié)），文檔的組織和內(nèi)容整合 要符合優(yōu)秀軟件需求規(guī)格說明文檔的特性要求（參見 15.5 節(jié)）。 細(xì)節(jié)需求要能夠回溯到相關(guān)的前期文檔，形成前后參照。 所有的需求都要被唯一的標(biāo)識。 需求的組織應(yīng)該盡可能的提高可讀性。 該部分內(nèi)容的最佳組織

17、方式要依賴于軟件產(chǎn)品的應(yīng)用領(lǐng)域和特性。IEEE 830-19981 為該部分的文檔組織提供了 8 種不同的模板方式，圖 15 一 5 所示的模板為其中之一。 圖 15 -6 所示的模板是按照系統(tǒng)特性來進(jìn)行需求組織的，除此之外也可以按照操作模式、 類對象、刺激響應(yīng)、功能分解、用戶類別等方式進(jìn)行組織。關(guān)于其他幾種組織方式可參 見教材的附錄一（P423-428）。 IEEE 830-1998將需求分成了 5 種類別，并據(jù)此進(jìn)行內(nèi)容的組織。這 5 種內(nèi)容是： 功能需求。 性能需求。 約束。 質(zhì)量屬性。 對外接口。 軟件需求規(guī)格說明模板中第 2 章已經(jīng)詳細(xì)解釋了 5 種類型需求的區(qū)別，本章將僅僅對文 9

18、 檔內(nèi)容的組織進(jìn)行介紹。 3.1 對外接口需求 描述了設(shè)計人員正確開發(fā)與軟件外部實(shí)體的接口所需要的所有信息。 對軟件產(chǎn)品對外接口中的輸人輸出項(xiàng)，可以參照下列方式進(jìn)行描述： （1）名稱。 （2）目的描述。 （3）輸人源輸出目標(biāo)。 （4）有效范圍，精確度和誤差范圍。 （5）度量單位。 （6）時間要求。 （7）和其他輸人輸出項(xiàng)的關(guān)系。、 （8）屏幕布局組織。 （9）窗口布局組織。 （10）數(shù)據(jù)格式。 （11）命令格式。 （12）結(jié)束消息。 3.1.1 用戶界面 描述系統(tǒng)所需的每個用戶界面的邏輯特征。本節(jié)可能包括下列內(nèi)容： 對圖形用戶界面(GUI)標(biāo)準(zhǔn)的引用或者將要采用的產(chǎn)品系列的樣式指南。 有關(guān)字體

19、、圖標(biāo)、按鈕標(biāo)簽、圖像、顏色選擇方案、組件的 tab 順序、常用控件等的 標(biāo)準(zhǔn)。 屏幕布局或解決方案的約束。 每個屏幕中將出現(xiàn)的標(biāo)準(zhǔn)按鈕、功能或者導(dǎo)航鏈接。 快捷鍵。 消息顯示約定。 便于軟件定位的布局標(biāo)準(zhǔn)。 滿足視力有問題的用戶的要求， 3.1.2 硬件接口 描述系統(tǒng)中軟件和硬件每一接口的特征。這種描述可能包括支持的硬件類型、軟硬件之 間交流的數(shù)據(jù)和控制信息的性質(zhì)以及所使用的通信協(xié)議等。 3.1.3 軟件接口 描述該產(chǎn)品與其他外部組件（由名字和版本識別）的連接，包括數(shù)據(jù)庫、操作系統(tǒng)、工 具、程序庫和集成的商業(yè)組件等。聲明在軟件組件之間交換數(shù)據(jù)、消息和控制命令的目的。 描述其他外部組件所需要的

20、服務(wù)以及組件間通信的性質(zhì)。確定將在組件之間共享的數(shù)據(jù)。 10 3.1.4 通信接口 描述與產(chǎn)品所使用的通信功能相關(guān)的需求，包括電子郵件,Web 瀏覽器、網(wǎng)絡(luò)通信標(biāo)準(zhǔn) 或協(xié)議及電子表格等。定義了相關(guān)的消息格式。規(guī)定通信安全或力。密問題、數(shù)據(jù)傳輸速率 和同步通 信機(jī)制等。 3.2 功能需求 描述了軟件產(chǎn)品在接收和處理外部輸入（或者處理和產(chǎn)生對外輸出）中發(fā)生的基本行為。 需要描述的內(nèi)容有： z 對輸人的驗(yàn)證 z 操作的順序 z 對異常的響應(yīng)，例如 數(shù)值越界 通信間題 錯誤處理與恢復(fù) z 參數(shù)的說明 z 輸出和輸人的關(guān)系 輸人輸出序列 將輸人轉(zhuǎn)換為輸出的公式和規(guī)則 3.2.x 系統(tǒng)特性 系統(tǒng)特性是外部

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

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

23、性必須是確定、定量的而 且在可能時是可驗(yàn)證的。 關(guān)于質(zhì)量屬性的詳細(xì)內(nèi)容可參見 2.3.4. 3.6 其他需求 定義在軟件需求規(guī)格說明的其他部分未出現(xiàn)的需求，例如國際化需求或法律上的需求。 你還可以增加有關(guān)操作、管理和維護(hù)部分來完善產(chǎn)品安裝、配置、啟動和關(guān)閉、修復(fù)和容錯， 以及登錄和監(jiān)控操作等方面的需求。 附錄 附錄是對軟件需求規(guī)格說明正文信息的補(bǔ)充。雖然它并不總是必需的，但是必要的附錄 可以增加文檔對需求的描述能力。 常見的附錄內(nèi)容包括： I/O 格式示例、成本分析研究、用戶調(diào)查結(jié)果。 有助于閱讀軟件需求規(guī)格說明的背景信息，常見的有術(shù)語表、數(shù)據(jù)字典和分析模型 圖示。 需要解決但是目前還懸而未決

24、的問題列表。 為了滿足安全、導(dǎo)出、初始加載或者其他需求而對代碼和數(shù)據(jù)媒體進(jìn)行特殊打包處理 的說明。 索引 對文檔重要內(nèi)容的位置引用，可以利用文檔編輯工具自動生成。 需求規(guī)格說明文檔的寫作原則與技巧參見教材 P350“需求規(guī)格說 文檔寫作”。 12 【附錄二】 評分標(biāo)準(zhǔn) 1、優(yōu)（90 以上）：文檔非常規(guī)范、思路很清晰，能較好反映、概括當(dāng)前項(xiàng) 目內(nèi)容以及客戶各個方面的需求。 2、良（80 以上 ）：文檔比較規(guī)范、思路比較清晰，能較好反映、概括當(dāng)前 項(xiàng)目內(nèi)容以及客戶各個方面的需求。 3、中（70 以上）：文檔基本規(guī)范、思路清晰，能反映、概括當(dāng)前項(xiàng)目內(nèi)容 以及客戶各個方面的需求。 4、及格（60 以上

25、）：文檔組織基本合理，思路基本清楚，能基本反映、概 括當(dāng)前項(xiàng)目內(nèi)容以及客戶各個方面的需求。 5、不及格（60 下）：文檔組織混亂，思路含混，不能反映、概括當(dāng)前項(xiàng)目 內(nèi)容以及客戶各個方面的需求。 13 【附錄三】前景與范圍文檔寫作范例 自助餐廳在線訂餐系統(tǒng) 業(yè)務(wù)需求、高層次解決方案和系統(tǒng)特性都應(yīng)該被定義到項(xiàng)目前景與范圍文檔 之中，以為后續(xù)的開發(fā)工作打好基礎(chǔ)。 前景與范圍文檔目錄如下： 1 業(yè)務(wù)需求 1.1 應(yīng)用背景 1.2 業(yè)務(wù)機(jī)遇 1.3 業(yè)務(wù)目標(biāo) 1.4 業(yè)務(wù)風(fēng)險 2 項(xiàng)目前景 2.1 前景概述 2.2 主要特性 2.3 假設(shè)與依賴 3 項(xiàng)目范圍 3.1 第一版范圍 3.2 后續(xù)版本范圍 3

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

27、上。當(dāng)員工到自助餐廳之外去用午餐時，他們平均有 90 分鐘時間不在崗。有些員工提前給自助食堂打電話預(yù)訂午餐，請自助餐廳準(zhǔn)備好 他們選擇的午餐。但是，員工并不總是能夠如愿以償，因?yàn)樽灾蛷d有些食物已 賣完。而與此同時，自助餐廳又在浪費(fèi)大量的食物，因?yàn)橛行┦澄餂]有賣掉而只 好倒掉。早餐和午餐同樣面臨著這樣的問題，只是到餐廳用餐的員工人數(shù)比午餐 要少得多。 1.2 業(yè)務(wù)機(jī)遇 （要求說明：如果開發(fā)的是商業(yè)產(chǎn)品，這部分描述的是存在的市場機(jī)遇以及產(chǎn)品要參與 競爭的市場。如果是企業(yè)信息系統(tǒng)，則應(yīng)描述要解決的業(yè)務(wù)問題或需要改進(jìn)的業(yè)務(wù)流程，以 及系統(tǒng)的應(yīng)用環(huán)境。 這部分內(nèi)容還應(yīng)對已有的產(chǎn)品和可能的解決方案進(jìn)行比

28、較評估，指出新產(chǎn)品的優(yōu)點(diǎn)。 說明有哪些問題因?yàn)闆]有該產(chǎn)品而在當(dāng)前無法解決。還要說明該產(chǎn)品怎樣符合市場潮流、技 術(shù)發(fā)展趨勢或企業(yè)的戰(zhàn)略方向。另外，還應(yīng)有一段簡短的說明描述如果需要為客戶提供一個 完整的解決方案，還需要哪些其他的技術(shù)、過程和資源。） 許多員工都通過自助餐廳的一個在線訂餐系統(tǒng)提出訂餐請求，要求在指定的 日期和時間內(nèi)將所訂的午餐送到公司的指定地點(diǎn)。通過這樣一個系統(tǒng)，使用這一 服務(wù)的員工可以節(jié)約相當(dāng)可觀的時間，而且訂到自己喜歡食物的機(jī)會也增大了。 這既提高了他們的工作生活質(zhì)量，也提高了他們的生產(chǎn)率。自助餐廳提前了解到 客戶需要哪些食物，就可以減少浪費(fèi)，并提高高員工的工作效率。要求送貨上門

29、 的訂餐員工將來還可以從本地的其他飯店來訂餐，這就大大擴(kuò)大了員工對食物的 選擇范圍，并通過與其他飯店的大量購餐協(xié)議而有可能節(jié)約費(fèi)用。Process Impact 公司也可以只在自助餐廳訂午餐，而在其他飯店訂早餐、晚餐、特定事件的用餐 和周末會餐。 1.3 業(yè)務(wù)目標(biāo)與成功標(biāo)準(zhǔn) （要求說明：用量化和可衡量的方式概述產(chǎn)品提供了哪些重要的業(yè)務(wù)利益。如果其他 文檔（如業(yè)務(wù)用例文檔）中已包含了這些信息，此處指明參考文檔即可，不必重復(fù)其內(nèi)容。 這一部分還應(yīng)明確涉眾如何定義和判斷項(xiàng)目的成功。說明哪些因素對項(xiàng)目獲得成功的影響最 大，無論這些因素是否處于組織的控制范圍內(nèi)。還要定義可衡量的標(biāo)準(zhǔn)，用于評估各項(xiàng)業(yè)務(wù) 目

30、標(biāo)是否已實(shí)現(xiàn)。） 15 BO -1：在第一版應(yīng)用之后的 6 個月內(nèi)，減少食物的浪費(fèi)。 度量標(biāo)準(zhǔn)（Scale）：每周被自助餐廳工作人員扔掉的食物的價值。 SC -1：在第一版應(yīng)用之后的 s 個月內(nèi)，目前在自助餐廳用午餐的員工中，75 的人使用在線訂餐系統(tǒng)。 SC -2：在第一版應(yīng)用之后的 3 個月內(nèi)，對自助餐廳滿意度的季度調(diào)查評價 要提高 0.5，而在第一版應(yīng)用之后的 12 個月內(nèi)，這種滿意度要提高 1.0。 1.4 業(yè)務(wù)風(fēng)險 （要求說明：概述與產(chǎn)品開發(fā)相關(guān)的主要風(fēng)險。風(fēng)險類別包括市場競爭、時間安排、 用戶認(rèn)可、實(shí)現(xiàn)技術(shù)以及可能對業(yè)務(wù)造成的負(fù)面影響。要評估每一項(xiàng)風(fēng)險可能造成的損失、 發(fā)生的幾率以

31、及對它的控制能力。找出所有可能降低風(fēng)險的必要措施。如果在業(yè)務(wù)用例分析 或類似文檔中已經(jīng)給出了這些信息，此處只需指明出處而不必重復(fù)該信息。） RI -1：使用該系統(tǒng)的員工太少，減少了對系統(tǒng)開發(fā)和變更自助餐廳經(jīng)營過程 的投資回報。 可能性 0.3，影響為 9。 RI -2：其他本地飯店可能并不認(rèn)何減價是員工使月這一系統(tǒng)的正當(dāng)理由，這 會減低員工對該系統(tǒng)的滿意度，并可能會減少他們對這一系統(tǒng)的使 月。 可能性為 0.4，影響為 3。 2 項(xiàng)目前景 （要求說明：這一部分建立系統(tǒng)的戰(zhàn)略前景，該系統(tǒng)將實(shí)現(xiàn)業(yè)務(wù)目標(biāo)。前景為產(chǎn)品生 命周期中所有的決策提供了背景。詳細(xì)的功能需求或項(xiàng)目計劃信息不應(yīng)包括在這一部分內(nèi)。

32、) 2.1 前景概述 （要求說明：用一個簡潔的聲明概括系統(tǒng)的長期目標(biāo)和意圖。聲明應(yīng)當(dāng)反映能夠滿足不 同涉眾需求的平衡的觀點(diǎn)。前景聲明可以理想化，但應(yīng)當(dāng)以當(dāng)前或預(yù)期的市場現(xiàn)狀、企業(yè)結(jié) 構(gòu)、團(tuán)體戰(zhàn)略和資源限制為依據(jù)。） 對那些希望通過公司自助餐廳或其他本地飯店在線訂餐的員工來說，“自助 餐廳訂餐系統(tǒng)”是一個基于 Internet 的應(yīng)月程序，它可以接受個人訂餐或團(tuán)體訂 餐，結(jié)算用餐費(fèi)用，并觸發(fā)將預(yù)訂餐送到 Process Impact 公司內(nèi)指定位置的事件。 16 與當(dāng)前的電話訂餐和人工訂餐不同，使用“自助餐廳訂餐系統(tǒng)”的雇員并不需要到 食堂內(nèi)去用餐，這既可以節(jié)約他灼的時間，又可以擴(kuò)大他們對食物的

33、選擇范周。 2.2 主要特性 （要求說明：為新產(chǎn)品的每一項(xiàng)主要特性或用戶功能進(jìn)行固定的、唯一的命名或編號， 突出其超越原有產(chǎn)品或競爭產(chǎn)品的特性。給每項(xiàng)特性一個唯一的標(biāo)號，這樣可以追蹤其去向 用戶需求、功能需求和其他系統(tǒng)元素。） FE- 1：根據(jù)自助餐廳提供的菜單來訂餐。 FE-2：根據(jù)真他本地飯店的送貨菜單來訂餐。 FE-3：請求送餐。 FE-4：創(chuàng)建、瀏覽、修改、刪除用餐預(yù)訂。 FE-5：通過公司的內(nèi)聯(lián)網(wǎng)訪問系統(tǒng)，或者授權(quán)員工通過外部 Internet 訪問系統(tǒng)。2.3 假設(shè)與依賴 （要求說明：記錄構(gòu)思項(xiàng)目和編寫前景與范圍文檔過程中涉眾所提出的每一項(xiàng)假設(shè)。 由于一方所做的假設(shè)往往不為其他各方

34、所知，因此通過將所有的假設(shè)記錄下來并進(jìn)行檢查， 各方就能對項(xiàng)目潛在的基本假設(shè)達(dá)成一致。這樣便能夠避免可能的混亂以及這種混亂會在將 來造成的影響。 這一部分還記錄項(xiàng)目對不在自身控制范圍內(nèi)的外部因素的主要依賴關(guān)系。這類外部因素 包括懸而未決的行業(yè)標(biāo)準(zhǔn)或政府法規(guī)、其他項(xiàng)目、第三方廠商及開發(fā)伙伴等。） AS-1：自助餐廳內(nèi)有可以訪問公司內(nèi)網(wǎng)的計算機(jī)和打印機(jī)。 AS-2：自助餐廳有送貨人員和送貨車輛，最多比請求的送貨時間晚 15 分鐘。 DE-1：如果某飯店有自己的聯(lián)機(jī)訂餐系統(tǒng)，那么“自助餐廳訂餐系統(tǒng)”必須能 與這一系統(tǒng)進(jìn)行雙向通信。 3 項(xiàng)目范圍 （要求說明：項(xiàng)目的范圍定義了解決方案的概念和范圍，同時

35、也要表明系統(tǒng)不能提供 哪些功能，它可以幫助涉眾建立現(xiàn)實(shí)的期望。） 3.1 第一版范圍 （要求說明：概述計劃在產(chǎn)品的第一個版本中實(shí)現(xiàn)的主要特性。描述產(chǎn)品的質(zhì)量特性， 17 產(chǎn)品依靠這些特性為不同類別的用戶提供預(yù)期利益。 如果目標(biāo)是集中開發(fā)力量和維持合理的項(xiàng)目進(jìn)度，就不要企圖在 1.0 版本中包含所有可 能的需求。那樣會導(dǎo)致項(xiàng)目范圍在不知不覺中增大，使得進(jìn)度延誤。應(yīng)該把注意力集中在那 些能夠在最短時間內(nèi)，以最適宜的成本，為最大多數(shù)用戶提供最大價值的特性上。） 3.2 后續(xù)版本范圍 （要求說明：如果要采取階段性的開發(fā)方式，需要決定推遲實(shí)現(xiàn)哪些特性，并為后續(xù) 的版本做出時間安排。后續(xù)版本能夠?qū)崿F(xiàn)更多的

36、需求和特性，并可完善最初的功能。隨著產(chǎn) 品的不斷成熟，系統(tǒng)的性能、可靠性和其他質(zhì)量特征也將得到改進(jìn)。） 表 1 版本范圍 3.3 限制與排除 (要求說明：管理范圍蔓延的方法之一是，定義項(xiàng)目包含的需求與不包含的需求之間的 界線。此處應(yīng)列出涉眾可能希望得到、但不在產(chǎn)品或其某個特定版本計劃之內(nèi)的功能和特 性。) LI-1：自助餐廳的有些食物不適宜送貨，因此“自助餐廳訂餐索統(tǒng)”的顧客使 用的送貨菜單是食堂整個菜單的一個子集。 LI -2“自助餐廳訂餐系統(tǒng)”只能用子 Process Impact 公司總部內(nèi)的自助餐廳。 4 項(xiàng)目環(huán)境 4.1 操作環(huán)境 （要求說明：描述系統(tǒng)將用于什么樣的環(huán)境，定義關(guān)鍵的可

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

38、度和人員。 對任何一個特定的項(xiàng)目而言，上述每個屬性都有三種影響因素： 驅(qū)動因素(Driver)：重要的成功目標(biāo)。 約束因素（Constraint）：項(xiàng)目必須在一定的限制下展開工作。 可調(diào)整因素(Degree of Freedom)：可以根據(jù)其他方面進(jìn)行平衡和調(diào)整的因素。 項(xiàng)目經(jīng)理的目標(biāo)是：在約束因素施加的限制內(nèi)，合理安排可調(diào)整因素，獲得最大的驅(qū) 動因素。 在項(xiàng)目屬性之間不可調(diào)和時，屬性間的優(yōu)先級順序指導(dǎo)項(xiàng)目管理者采取正確的行動。 例如，對于急需面市的系統(tǒng)，其進(jìn)度是第一優(yōu)先級，這樣在項(xiàng)目無法按照預(yù)定計劃前進(jìn)時， 就可能會推遲特定功能的實(shí)現(xiàn)，或者增加人員和投資。再例如，對于人員（或費(fèi)用）受限的 系

39、統(tǒng)，人員（費(fèi)用）是第一優(yōu)先級，在項(xiàng)目出現(xiàn)偏離時就可能延遲系統(tǒng)的完成期限，或者推 遲部分功能的實(shí)現(xiàn)。除特例情況之外，質(zhì)量都是一個不應(yīng)該被犧牲的項(xiàng)目屬性。） 表 2 項(xiàng)目屬性的示例 19 【附錄四】 需求文檔完整范例 本附錄通過“自助食堂訂餐系統(tǒng)(Cafeteria Ordering System COS)”這樣一個假想的小型 項(xiàng)目，闡述了本書所描述的某些需求文檔和圖。這里包括如下這些內(nèi)容： 前景和范圍文檔。 用例列表和若干用例描述。 部分軟件需求規(guī)格說明。 某些分析模型。 部分?jǐn)?shù)據(jù)字典。 若干業(yè)務(wù)規(guī)則。 因?yàn)檫@僅僅是一個范例，所以我們并不打算完善這些需求元素。我們的目標(biāo)只是提供一 種思想，各種類

40、型的需求信息之間彼此是如何關(guān)聯(lián)的，并演示我們可能如何編寫文檔每一部 分的內(nèi)容。在一個小型項(xiàng)目中，將不同的需求信息綜合到單一的文檔中，常常是有意義的， 因此我們可能沒有單獨(dú)的前景和范圍文檔、用例文檔和軟件需求規(guī)格說明。這些文檔中的信 息能夠以多種其他合理的方式來組織?；镜哪繕?biāo)是確保需求文檔清晰明了、完整和易使用。 這些文檔總的來說都遵照前面章節(jié)所描述的模板，但是，因?yàn)檫@只是一個小型項(xiàng)目， 所以對這些模板稍微作了一些簡化。有時，會將幾個部分合并起來，這是為了避免信息重復(fù)。 每一個項(xiàng)目都應(yīng)該考慮如何適應(yīng)組織的標(biāo)準(zhǔn)模板，以盡量適合于項(xiàng)目的規(guī)模和本質(zhì)。 1 前景和范圍文檔 1.1 業(yè)務(wù)需求 1背景、業(yè)

41、務(wù)機(jī)會和客戶需要 目前，Process Impact 公司的大多數(shù)員工平均每天要花費(fèi) 60 分鐘去自助食堂選擇、購買 并用午餐，其中大約有 20 分鐘要花在公司和自助食堂之間的往返路程、選擇自己喜歡的午 餐、以及以現(xiàn)金方式或以信用卡方式結(jié)算餐費(fèi)上。當(dāng)員工出去用午餐時，他們平均有 90 分 鐘時間不在崗。有些員工提前給自助食堂打電話預(yù)訂午餐，請自助食堂準(zhǔn)備好他們所選擇的 午餐。但是，員工并不是總能如愿以償，因?yàn)樽灾程糜行┦澄镆奄u完，而與此同時，自助 食堂又不可避免地會浪費(fèi)大量的食物，因?yàn)橛行┦澄餂]有賣出去而只好倒掉。早餐和晚餐同 樣面臨著這樣的問題，只是到自助食堂用餐的員工人數(shù)比午餐要少得多。

42、 許多員工都通過允許自助食堂用戶在線訂餐的一個系統(tǒng)而提出訂餐請求，要求在指定的 日期和時間內(nèi)將所訂的午餐送到公司的指定地點(diǎn)。通過這樣一個系統(tǒng)，使用這一服務(wù)的員工 可以節(jié)約相當(dāng)可觀的時間，而且訂到自己所喜歡的食物的機(jī)會也增大了。這既提高了他們的 工作生活質(zhì)量，也提高了他們的生產(chǎn)率。自助食堂提前了解到客戶需要哪些食物，就可以減 少浪費(fèi)，并提高自助食堂員工的工作效率。要求送貨上門的訂餐員工將來還可以從本地的飯 店來訂餐，這就大大擴(kuò)大了員工對食物的選擇范圍，并通過與飯店的大量購餐協(xié)議而有可能 節(jié)約費(fèi)用。Process Impact 公司也可以只在自助食堂訂午餐，而在飯店訂早餐、晚餐、特定 事件的用餐以

43、及周末會餐。 2業(yè)務(wù)目標(biāo)（Business Objective. BO）和成功標(biāo)準(zhǔn)（Success Criteria SC) BO-l：初始版本發(fā)布之后的 6 個月內(nèi)，自助食堂的食物浪費(fèi)減少 50%。 度量單位（scale）：自助食堂的工作人員每星期所倒掉的食物的價值。 20 計量(meter)檢查“自助食堂存貨系統(tǒng)（Cafeteria Inventory System）”的日志。 過去情況（past）2002，初步調(diào)研：30% 一般標(biāo)準(zhǔn)（plan）：小于 15% 最低標(biāo)準(zhǔn)（must）：小于 20% BO-2：初始版本發(fā)布之后的 12 個月內(nèi)，自助食堂的運(yùn)作費(fèi)用減少 50。 BO-3：初始版本

44、發(fā)布之后的 3 個月內(nèi)，每個雇員每天的平均有效工作時間增加 20 分鐘。 SC-1：目前通過自助食堂解決午餐問題的那些員工，在初始版本發(fā)布之后的 6 個月內(nèi)， 他們中有 75%的人使用“自助食堂訂餐系統(tǒng)”。 SC-2：初始版本發(fā)布之后的 3 個月內(nèi)，對自助食堂滿意度的季度調(diào)查評價要提高 0.5, 而在初始版本發(fā)布之后的 12 個月內(nèi)，這種滿意度要提高 1.0. 3業(yè)務(wù)風(fēng)險（RIsk) RI-1：“自助食堂雇員聯(lián)合會(Cafeteria Employees Union)”可能要求與雇員重新簽訂合 同，以反映新的雇員角色和自助食堂營業(yè)時間。（可能性為 0.6.影響為 3） RI-2：使用該系統(tǒng)的雇

45、員太少，減少了對系統(tǒng)開發(fā)和變更自助食堂經(jīng)營過程的投資回報。 （可能性為 0.3，影響為 9) RI-3：本地飯店可能并不認(rèn)同減價是雇員使用這一系統(tǒng)的正當(dāng)理由，這會減低雇員對該 系統(tǒng)的滿意度，并可能會減少他們對這一系統(tǒng)的使用。（可能性為 0.4，影響為 3） 1.2 解決方案的前景 1前景陳述 對那些希望通過公司自助食堂或本地飯店在線訂餐的員工來說，“自助食堂訂餐系統(tǒng)” 是一個基于 Internet 的應(yīng)用程序，它可以接受個人訂餐或團(tuán)體訂餐，結(jié)算用餐費(fèi)用，并觸發(fā) 將預(yù)訂餐送到 Process Impact 公司內(nèi)的指定位置。與當(dāng)前的電話訂餐和人工訂餐不同，使用 “自助食堂訂餐系統(tǒng)”的雇員并不需要

46、到食堂內(nèi)去用餐，這既可以節(jié)約他們的時間，又可以 增加他們對食物的選擇范圍。 2主要特性（FEature) FE-1：根據(jù)自助食堂提供的選擇菜單或送貨菜單來訂餐。 FE-2：根據(jù)本地飯店的送貨菜單來訂餐。 FE-3：創(chuàng)建、瀏覽、修改和刪除用餐預(yù)訂服務(wù)。 FE-4：注冊用餐的付費(fèi)方式。 FE-5：請求送餐。 FE-6：創(chuàng)建、瀏覽、修改和刪除自助食堂菜單。 FE-7：預(yù)訂自助食堂菜單上所沒有的定做菜。 FE-8：生成自助食堂定做菜的食譜和配料列表。 FE-9：通過公司的內(nèi)聯(lián)網(wǎng)可以訪問系統(tǒng)，或者授權(quán)的員工通過外部 Internet 訪問系統(tǒng)。 3假設(shè)(ASsumption)和依賴(DEpendency

47、) AS-1：自助食堂內(nèi)有可以訪問公司內(nèi)聯(lián)網(wǎng)的計算機(jī)和打印機(jī)，這樣自助食堂的雇員就 可以處理期望的訂單量，不會遺漏任何送貨時間。 AS-2：最多比請求的送貨時間晚 15 分鐘，自助食堂有送貨人員和送貨車輛，這樣就能 滿足所有訂單的送貨要求。 DE-1：如果某飯店有自己的聯(lián)機(jī)訂餐系統(tǒng)，那么“自助食堂訂餐系統(tǒng)”必須能與這一 系統(tǒng)進(jìn)行雙向通信。 1.3 范圍和局限性 21 LI-2：1初始版本和后續(xù)版本的范圍 2局限性（Limitation）和排斥性 LI-1：自助食堂的有些食物不適宜于送貨，因此“自助食堂訂餐系統(tǒng)”的顧客所用的菜單 是食堂整個菜單的一個子集。 “自助食堂訂餐系統(tǒng)”只能用于俄勒岡州 Clackamas 的 Process Impact 公司總部內(nèi) 的自助食堂。 1.4 業(yè)務(wù)上下文 1涉眾概覽 22 23 24 25 26 27 28 29 30 31 3 軟件需求規(guī)格說明 3.1 介紹 1目標(biāo) 軟件需求規(guī)格說明