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

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

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

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

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

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

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

6、用好的結(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ī)格說明書。 四、實驗步驟 1、 參考相關(guān)模板，初步理解軟件需求規(guī)格說明書的結(jié)構(gòu) 2、 結(jié)合項目實際，完成軟件需

7、求規(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．

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

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

10、定和 列出進(jìn)行本軟件開發(fā)工作的假定和約束，例如經(jīng)費限制、開發(fā)期限等。 約束 用列表的方式（例如 IPO 表即輸入、處理、輸出表的形式），逐項定量 和定性地敘述對軟件所提出的功能要求，說明輸入什么量、經(jīng)怎樣的處理、 得到什么輸出，說明軟件應(yīng)支持的終端數(shù)和應(yīng)支持的并行操作的用戶數(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ù)輸出及必須標(biāo)明的控制輸出量進(jìn)行解釋并舉例，包括 出要求 對硬拷貝報告（正常結(jié)果輸出、狀態(tài)輸出及異常輸出）以及圖形或顯示報 告的描述。 數(shù)據(jù)管 說明需要管理的文卷和記錄的個數(shù)、表和文卷的大小規(guī)模，要按可預(yù)見的 理能力 增長對數(shù)據(jù)及其份量的存儲要求作出估算。 要求 故障處 列出可能的軟件、硬件故障以及對各項性能而言所產(chǎn)生的后果和對故障處 理要求 理的要求。 其他專 門要求 a． 處理器型號及內(nèi)存容量；

12、運(yùn)行 b． 外存容量、聯(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、軟件

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

14、時的注意事項（定義、首字母縮寫和縮略語）。 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)和目的。 ④如果在此軟件需求規(guī)格說明之外，還存在著一個更高層次的規(guī)格說明（例如系統(tǒng)需求 規(guī)格說明），那么該部分的描述應(yīng)該與更高層次文檔的相關(guān)段落保持一致。 1.3 閱讀時的注意事項（定義、首字母縮寫

15、和縮略語） 定義了正確理解軟件需求規(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é)中： ①描述軟件需求規(guī)格說明余下部分所包含的內(nèi)容。 ②解釋軟件需求規(guī)格說明的組織方式。 2．總體描述 從總體上描述影響產(chǎn)品和需求的因素。這部

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

17、該描述較大系統(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)品在主存儲器和輔助存儲器上的局限性和可適用特性。 ⑦操作：用戶要求的正常和特殊操作。 ⑧地點改變需求：對指定地點、任務(wù)或者操作模式的需求，調(diào)整軟件裝置而需要改變的 地點或者任務(wù)的相關(guān)特征。 2.2 產(chǎn)品功能－ 概述軟件將要執(zhí)行的主要功能

18、。此處只需要概略的總結(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)驗和技術(shù)能力等。這些描述信息可 以用來解釋第 3

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

20、一個假設(shè)：軟件產(chǎn)品 的目標(biāo)硬件上會有某個特定的操作系統(tǒng)。而在實際情況中，如果這樣的情況并不存在，那么 文檔中的需求將不得不進(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é)）。

21、 ②細(xì)節(jié)需求要能夠回溯到相關(guān)的前期文檔，形成前后參照。 ③所有的需求都要被唯一的標(biāo)識。 ④需求的組織應(yīng)該盡可能的提高可讀性。 該部分內(nèi)容的最佳組織方式要依賴于軟件產(chǎn)品的應(yīng)用領(lǐng)域和特性?！睮EEE 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)

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

23、出項的關(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)字體、圖標(biāo)、按鈕標(biāo)簽、圖像、顏色選擇方案、組件的 tab 順序、常用控件等的 標(biāo)準(zhǔn)。 ③屏幕布局或解決方案的約束。 ④每個屏幕中將出現(xiàn)的標(biāo)準(zhǔn)按鈕、功能或者導(dǎo)航鏈接。 ⑤快捷鍵。． ⑥消息顯示約定。 ⑦便于軟件定位的布局標(biāo)準(zhǔn)。 ⑧滿足視力有問題的用戶的要求．， 3

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

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

26、.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ù)或者使用所指定的使用實例執(zhí)行任務(wù)。描述產(chǎn)品如何響應(yīng)可預(yù)知 的出錯條件或者非法輸人或動作。 3. 2.x.3.n 功能需求 x.n 對單個需求（功能的某個步驟或者某個方面）的清晰描述，常見形式為“RID：系 統(tǒng)應(yīng)該…”。 3.3 性能需求

27、闡述了不同的應(yīng)用領(lǐng)域?qū)Ξa(chǎn)品性能的需求，并解釋它們的原理以幫助開發(fā)人員做出合理 的設(shè)計選擇。確定相互合作的用戶數(shù)、所支持的操作、響應(yīng)時間以及與實時系統(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ì)量屬性

28、 詳盡陳述對客戶或開發(fā)人員至關(guān)重要的產(chǎn)品質(zhì)量屬性。這些特性必須是確定、定量的而 且在可能時是可驗證的。 關(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é)果。 ②有助于閱讀

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

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

31、 【附錄三】前景與范圍文檔寫作范例 ——自助餐廳在線訂餐系統(tǒng) 業(yè)務(wù)需求、高層次解決方案和系統(tǒng)特性都應(yī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 項目前景 2.1 前景概述 2.2 主要特性 2.3 假設(shè)與依賴 3 項目范圍 3.1 第一版范圍 3.2 后續(xù)版本范圍 3.3 限制與排除 4 項目環(huán)境 4.1

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

33、4 現(xiàn)金或信用卡方式結(jié)賬上。當(dāng)員工到自助餐廳之外去用午餐時，他們平均有 90 分鐘時間不在崗。有些員工提前給自助食堂打電話預(yù)訂午餐，請自助餐廳準(zhǔ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ù)流程，

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

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

36、些因素對項目獲得成功的影響最 大，無論這些因素是否處于組織的控制范圍內(nèi)。還要定義可衡量的標(biāo)準(zhǔn)，用于評估各項業(yè)務(wù) 目標(biāo)是否已實現(xiàn)。） 15 BO -1：在第一版應(yīng)用之后的 6 個月內(nè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

37、.4 業(yè)務(wù)風(fēng)險 （要求說明：概述與產(chǎn)品開發(fā)相關(guān)的主要風(fēng)險。風(fēng)險類別包括市場競爭、時間安排、 用戶認(rèn)可、實現(xiàn)技術(shù)以及可能對業(yè)務(wù)造成的負(fù)面影響。．要評估每一項風(fēng)險可能造成的損失、 發(fā)生的幾率以及對它的控制能力。找出所有可能降低風(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)的

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

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

40、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)思項目和編寫前景與范圍文檔過程中涉眾所提出的每一項假設(shè)。 由于一方所做的假設(shè)往往不為其他各方所知，因此通過將所有的假設(shè)記錄下來并進(jìn)行檢查， 各方就能對項目潛在的基本假設(shè)達(dá)成一致。這樣便能夠避免可能的混亂以及這種混亂會在將 來造成的影響。 這一部分還記錄項目對不在自身控制范圍內(nèi)的外部因素的主要依賴關(guān)系。這類外部因素 包括懸而未決的行業(yè)

41、標(biāo)準(zhǔn)或政府法規(guī)、其他項目、第三方廠商及開發(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 項目范圍 （要求說明：項目的范圍定義了解決方案的概念和范圍，同時也要表明系統(tǒng)不能提供 哪些功能，它可以幫助涉眾建立現(xiàn)實的期望。） 3.1 第一版范圍 （要求說明：概述計劃在產(chǎn)品的第一個版本中實現(xiàn)的主要特性。描述產(chǎn)品的質(zhì)量特性， 17

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

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

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

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

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

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

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

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

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

51、的食物的價值。 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)作費用減少 50％。 BO-3：初始版本發(fā)布之后的 3 個月內(nèi)，每個雇員每天的平均有效工作時間增加 20 分鐘。 SC-1：目前通過自助食堂解決午餐問題的那些員工，在初始版本發(fā)布之后的 6 個月內(nèi)， 他們中有 75%的人使用“自助食堂

52、訂餐系統(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)的雇員太少，減少了對系統(tǒng)開發(fā)和變更自助食堂經(jīng)營過程的投資回報。 （可能性為 0.3，影響為 9) RI-3：本地飯店可能并不認(rèn)同減價是雇員使用這一系統(tǒng)的正當(dāng)理由，這會減

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

54、菜單或送貨菜單來訂餐。 FE-2：根據(jù)本地飯店的送貨菜單來訂餐。 FE-3：創(chuàng)建、瀏覽、修改和刪除用餐預(yù)訂服務(wù)。 FE-4：注冊用餐的付費方式。 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) AS-1：自助食堂內(nèi)有可以訪問公司內(nèi)聯(lián)網(wǎng)的計算機(jī)和打印機(jī)，這樣自助食堂的雇員就 可以處理期望的訂單量，不會遺

55、漏任何送貨時間。 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)”的顧客所用的菜單 是

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

57、 23 24

58、 25 26

59、 27 28

60、 29 30

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

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

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

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

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

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