《軟件需求分析》實(shí)驗(yàn)指導(dǎo)書(總68頁)

《《軟件需求分析》實(shí)驗(yàn)指導(dǎo)書(總68頁)》由會(huì)員分享，可在線閱讀，更多相關(guān)《《軟件需求分析》實(shí)驗(yàn)指導(dǎo)書(總68頁)（68頁珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

1、 《軟件需求分析》 實(shí) 驗(yàn) 指 導(dǎo) 書 2013 年 9 月 中文 軟件需求分析 課 程 編 號(hào) 5011011093 課程 Software Requirement 名稱 英文 適 用 專 業(yè) 軟件工程 Analysis 總學(xué)時(shí) 32 理論教學(xué)學(xué)時(shí) 28 課 4 內(nèi) 學(xué) 分 2 實(shí)踐教學(xué)學(xué)時(shí) 課 8 外 執(zhí)筆者 劉冰 編 寫 日 期 2012 年 3 月 《需

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

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

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

5、用實(shí)例派生出的功能需求文檔，還要編寫產(chǎn)品的非功能需求文檔，包括質(zhì)量屬 性和外部接口需求。至此，我們綜合前面的相關(guān)分析結(jié)果，來進(jìn)行需求說明書的編寫，進(jìn)一 步理解由業(yè)務(wù)需求，用戶需求，功能需求三個(gè)部分綜合而形成軟件需求說明書的過程。 二、實(shí)驗(yàn)的軟硬件環(huán)境 硬件：微型計(jì)算機(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、要求： 完成軟件需求規(guī)格說明書的編寫： （1）用好的結(jié)構(gòu)化和自然語言編寫文檔型文檔

6、（2）建立圖形化模型。 （3） 編寫形式化規(guī)格說明，這可以通過使用數(shù)學(xué)上精確的形式化邏輯語言來定義需求。 2、具體任務(wù)： 開發(fā)“管理信息系統(tǒng)”（如人事管理信息系統(tǒng)、財(cái)務(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í)際，完成軟件需求規(guī)格說明書 3、 進(jìn)一步檢查、完

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

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

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

10、束，例如經(jīng)費(fèi)限制、開發(fā)期限等。 約束 用列表的方式（例如 IPO 表即輸入、處理、輸出表的形式），逐項(xiàng)定量 和定性地?cái)⑹鰧?duì)軟件所提出的功能要求，說明輸入什么量、經(jīng)怎樣的處理、 得到什么輸出，說明軟件應(yīng)支持的終端數(shù)和應(yīng)支持的并行操作的用戶數(shù)。 對(duì)功能 的規(guī)定 需求 規(guī)定 例子：  I:原始捕獲的數(shù)據(jù)幀 P：按照既定的數(shù)據(jù)幀存儲(chǔ)格式，存儲(chǔ)到離線文件中 O：數(shù)據(jù)幀文件 1． 1． 精度 對(duì)性能 2． 2． 時(shí)間特性要求 的規(guī)定 3． 3． 靈活性 解釋各輸入輸出數(shù)據(jù)類型，

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

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

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

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

15、說明所必需的術(shù)語、首字母縮寫和縮略語。 這部分內(nèi)容也可以通過添加附錄或者引用其他文檔來提供。 1.4 參考文獻(xiàn) 在這一節(jié)中： ①提供需求規(guī)格說明文檔引用的全部文檔的清單列表。 ②利用標(biāo)題、報(bào)告編號(hào)（如果適用）舊期和出版機(jī)構(gòu)來標(biāo)識(shí)文檔。 ③指出參考文獻(xiàn)的來源，在該來源中可以獲得文獻(xiàn)。 這部分內(nèi)容也可以通過添加附錄或者引用其他文檔來提供。 1.5 組織方式（文檔組織） 在這一節(jié)中： ①描述軟件需求規(guī)格說明余下部分所包含的內(nèi)容。 ②解釋軟件需求規(guī)格說明的組織方式。 2．總體描述 從總體上描述影響產(chǎn)品和需求的因素。這部分并不涉及將在文檔第 3 部分（詳細(xì)需求描

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

17、期。這些部分包括： ①系統(tǒng)接口：系統(tǒng)接口對(duì)軟件產(chǎn)品的功能要求。 ②用戶界面：軟件產(chǎn)品和用戶之間接口的邏輯特征和優(yōu)化要求。 ③硬件接口：軟件產(chǎn)品和較大系統(tǒng)中硬件組件之間接口的邏輯特征。 ④軟件接口：其他軟件系統(tǒng)對(duì)軟件產(chǎn)品的要求。： ⑤交流接口：本地網(wǎng)絡(luò)協(xié)議之類的交流接口要求。～ ⑥內(nèi)存：軟件產(chǎn)品在主存儲(chǔ)器和輔助存儲(chǔ)器上的局限性和可適用特性。 ⑦操作：用戶要求的正常和特殊操作。 ⑧地點(diǎn)改變需求：對(duì)指定地點(diǎn)、任務(wù)或者操作模式的需求，調(diào)整軟件裝置而需要改變的 地點(diǎn)或者任務(wù)的相關(guān)特征。 2.2 產(chǎn)品功能－ 概述軟件將要執(zhí)行的主要功能。此處只需要概略的總結(jié)，其詳細(xì)內(nèi)容將在第

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

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

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

21、形成前后參照。 ③所有的需求都要被唯一的標(biāo)識(shí)。 ④需求的組織應(yīng)該盡可能的提高可讀性。 該部分內(nèi)容的最佳組織方式要依賴于軟件產(chǎn)品的應(yīng)用領(lǐng)域和特性。〔IEEE 830-19981 為該部分的文檔組織提供了 8 種不同的模板方式，圖 15 一 5 所示的模板為其中之一。 圖 15 -6 所示的模板是按照系統(tǒng)特性來進(jìn)行需求組織的，除此之外也可以按照操作模式、 類／對(duì)象、刺激／響應(yīng)、功能分解、用戶類別等方式進(jìn)行組織。關(guān)于其他幾種組織方式可參 見教材的附錄一（P423-428）。 [IEEE 830-1998」將需求分成了 5 種類別，并據(jù)此進(jìn)行內(nèi)容的組織。這 5 種內(nèi)容是： ①功能需求。

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

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

24、件每一接口的特征。這種描述可能包括支持的硬件類型、軟硬件之 間交流的數(shù)據(jù)和控制信息的性質(zhì)以及所使用的通信協(xié)議等。 3.1.3 軟件接口 描述該產(chǎn)品與其他外部組件（由名字和版本識(shí)別）的連接，包括數(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é)議及電子表格等。定義了相關(guān)的消息格式。規(guī)定通信安全或力

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

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

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

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

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

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

31、范圍文檔寫作范例 ——自助餐廳在線訂餐系統(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)險(xiǎn) 2 項(xiàng)目前景 2.1 前景概述 2.2 主要特性 2.3 假設(shè)與依賴 3 項(xiàng)目范圍 3.1 第一版范圍 3.2 后續(xù)版本范圍 3.3 限制與排除 4 項(xiàng)目環(huán)境 4.1 操作環(huán)境 4.2 涉眾 4.

32、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ā)的動(dòng) 機(jī)。必要的情況下，還需要說明應(yīng)用的歷史延續(xù)過程。） 目前，Process Impact 公司的大多數(shù)員工平均每天要花費(fèi) 60 分鐘去白助餐廳 用午餐，其中大約有 20 分鐘要花在公司和自助餐廳之間的往返、選擇午餐和以 14 現(xiàn)金或信用卡方式結(jié)

33、賬上。當(dāng)員工到自助餐廳之外去用午餐時(shí)，他們平均有 90 分鐘時(shí)間不在崗。有些員工提前給自助食堂打電話預(yù)訂午餐，請(qǐng)自助餐廳準(zhǔn)備好 他們選擇的午餐。但是，員工并不總是能夠如愿以償，因?yàn)樽灾蛷d有些食物已 賣完。而與此同時(shí)，自助餐廳又在浪費(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)

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

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

36、些因素是否處于組織的控制范圍內(nèi)。還要定義可衡量的標(biāo)準(zhǔn)，用于評(píng)估各項(xiàng)業(yè)務(wù) 目標(biāo)是否已實(shí)現(xiàn)。） 15 BO -1：在第一版應(yīng)用之后的 6 個(gè)月內(nèi)，減少食物的浪費(fèi)。 度量標(biāo)準(zhǔn)（Scale）：每周被自助餐廳工作人員扔掉的食物的價(jià)值。 SC -1：在第一版應(yīng)用之后的 s 個(gè)月內(nèi)，目前在自助餐廳用午餐的員工中，75 ％的人使用在線訂餐系統(tǒng)。 SC -2：在第一版應(yīng)用之后的 3 個(gè)月內(nèi)，對(duì)自助餐廳滿意度的季度調(diào)查評(píng)價(jià) 要提高 0.5，而在第一版應(yīng)用之后的 12 個(gè)月內(nèi)，這種滿意度要提高 1.0。 1.4 業(yè)務(wù)風(fēng)險(xiǎn) （要求說明：概述與產(chǎn)品

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

38、 3。 2 項(xiàng)目前景 （要求說明：這一部分建立系統(tǒng)的戰(zhàn)略前景，該系統(tǒng)將實(shí)現(xiàn)業(yè)務(wù)目標(biāo)。前景為產(chǎn)品生 命周期中所有的決策提供了背景。詳細(xì)的功能需求或項(xiàng)目計(jì)劃信息不應(yīng)包括在這一部分內(nèi)。) 2.1 前景概述 （要求說明：用一個(gè)簡潔的聲明概括系統(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ù)。） 對(duì)那些希望通過公司自助餐廳或其他本地飯店在線訂餐的員工來說，“自助 餐廳訂餐系統(tǒng)”是一個(gè)基于 Internet 的應(yīng)月程序，它可以接受個(gè)人訂餐或團(tuán)體訂 餐，結(jié)算用餐

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

40、E-3：請(qǐng)求送餐。 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è)往往不為其他各方所知，因此通過將所有的假設(shè)記錄下來并進(jìn)行檢查， 各方就能對(duì)項(xiàng)目潛在的基本假設(shè)達(dá)成一致。這樣便能夠避免可能的混亂以及這種混亂會(huì)在將 來造成的影響。 這一部分還記錄項(xiàng)目對(duì)不在自身控制范圍內(nèi)的外部因素的主要依賴關(guān)系。這類外部因素 包括懸而未決的行業(yè)標(biāo)準(zhǔn)或政府法規(guī)、其他項(xiàng)目、第三方廠商及開發(fā)

41、伙伴等。） AS-1：自助餐廳內(nèi)有可以訪問公司內(nèi)網(wǎng)的計(jì)算機(jī)和打印機(jī)。 AS-2：自助餐廳有送貨人員和送貨車輛，最多比請(qǐng)求的送貨時(shí)間晚 15 分鐘。 DE-1：如果某飯店有自己的聯(lián)機(jī)訂餐系統(tǒng)，那么“自助餐廳訂餐系統(tǒng)”必須能 與這一系統(tǒng)進(jìn)行雙向通信。 3 項(xiàng)目范圍 （要求說明：項(xiàng)目的范圍定義了解決方案的概念和范圍，同時(shí)也要表明系統(tǒng)不能提供 哪些功能，它可以幫助涉眾建立現(xiàn)實(shí)的期望。） 3.1 第一版范圍 （要求說明：概述計(jì)劃在產(chǎn)品的第一個(gè)版本中實(shí)現(xiàn)的主要特性。描述產(chǎn)品的質(zhì)量特性， 17 產(chǎn)品依靠這些特性為不同類別的用

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

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

44、操作環(huán)境相關(guān)的問題包括： ①用戶是地理分散的還是集中的？ 18 ②不同的用戶會(huì)在什么時(shí)間訪問系統(tǒng)？ ③數(shù)據(jù)在何處生成，用于何處？ ④訪問數(shù)據(jù)時(shí)的最大響應(yīng)時(shí)間是否已知？ ⑤用戶能否容忍服務(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)先級(jí)達(dá)成 一致。這些屬性包歌括：特性（功能、范圍）、質(zhì)量、成

45、本、進(jìn)度和人員。 對(duì)任何一個(gè)特定的項(xiàng)目而言，上述每個(gè)屬性都有三種影響因素： ①驅(qū)動(dòng)因素(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ū) 動(dòng)因素。 在項(xiàng)目屬性之間不可調(diào)和時(shí)，屬性間的優(yōu)先級(jí)順序指導(dǎo)項(xiàng)目管理者采取正確的行動(dòng)。 例如，對(duì)于急需面市的系統(tǒng)，其進(jìn)度是第一優(yōu)先級(jí)，這樣在項(xiàng)目無法按照預(yù)定計(jì)劃前進(jìn)時(shí)， 就可能會(huì)推遲特定功能的實(shí)現(xiàn)，或者增加人員和投

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

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

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

49、自助食堂打電話預(yù)訂午餐，請(qǐng)自助食堂準(zhǔn)備好他們所選擇的 午餐。但是，員工并不是總能如愿以償，因?yàn)樽灾程糜行┦澄镆奄u完，而與此同時(shí)，自助 食堂又不可避免地會(huì)浪費(fèi)大量的食物，因?yàn)橛行┦澄餂]有賣出去而只好倒掉。早餐和晚餐同 樣面臨著這樣的問題，只是到自助食堂用餐的員工人數(shù)比午餐要少得多。 許多員工都通過允許自助食堂用戶在線訂餐的一個(gè)系統(tǒng)而提出訂餐請(qǐng)求，要求在指定的 日期和時(shí)間內(nèi)將所訂的午餐送到公司的指定地點(diǎn)。通過這樣一個(gè)系統(tǒng)，使用這一服務(wù)的員工 可以節(jié)約相當(dāng)可觀的時(shí)間，而且訂到自己所喜歡的食物的機(jī)會(huì)也增大了。這既提高了他們的 工作生活質(zhì)量，也提高了他們的生產(chǎn)率。自助食堂提前了解到客戶需要哪

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

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

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

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

54、飯店的送貨菜單來訂餐。 FE-3：創(chuàng)建、瀏覽、修改和刪除用餐預(yù)訂服務(wù)。 FE-4：注冊(cè)用餐的付費(fèi)方式。 FE-5：請(qǐng)求送餐。 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ī)和打印機(jī)，這樣自助食堂的雇員就 可以處理期望的訂單量，不會(huì)遺漏任何送貨時(shí)間。 AS-2：最多比請(qǐng)求

55、的送貨時(shí)間晚 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)”的顧客所用的菜單 是食堂整個(gè)菜單的一個(gè)子集。 “自助食堂訂

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

57、 24 25

58、 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 版本 的軟件功能性需求和非功能性需求。這一文檔計(jì)劃由實(shí)現(xiàn)和驗(yàn)證系統(tǒng)正確功能的項(xiàng)目團(tuán)隊(duì)成 員來使用。除非在其他地方另有說明，這里指定的所有需求都具有高優(yōu)先級(jí)，而且都要在版 本 1.0 中加以實(shí)現(xiàn)。 2．項(xiàng)目范圍和產(chǎn)品特性 “自助食堂訂餐系統(tǒng)”允許 Process Impact 公司雇員向公司的自助食堂在線訂餐，并送 餐到公司內(nèi)的指定地點(diǎn)。詳細(xì)的項(xiàng)目描

62、述請(qǐng)參見 Cafeteria Ordering 枷 tem Visionand Scope Document(自助食堂訂餐系統(tǒng)前景和范圍文檔）【1】。文檔中這一部分的標(biāo)題為“初始版本和 后續(xù)版本的范圍”，列出了按照進(jìn)度計(jì)劃在這一版本中實(shí)現(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 Intranet Development S

63、tandard 版本 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 3.2 總體描述 1．產(chǎn)品遠(yuǎn)景規(guī)劃

64、 “自助食堂訂餐系統(tǒng)”是一個(gè)新系統(tǒng)，它取代了當(dāng)前在 Process Impact 公司自助食堂內(nèi) 以手工方式和電話方式預(yù)定和選擇午餐的過程。圖 D.1 是一幅關(guān)聯(lián)圖，它演示了 1.0 版本的 外部實(shí)體和系統(tǒng)接口。期望系統(tǒng)演化若干個(gè)版本，最終與本地若干飯店的 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)行在一個(gè)服務(wù)器中，該服務(wù)器運(yùn)行當(dāng)前由公司批準(zhǔn)的 Red Hat Linux 版本和 Apache HT

66、TP Server。 “自助食堂訂餐系統(tǒng)”將允許用戶通過公司內(nèi)聯(lián)網(wǎng)來訪問，如果用戶被授權(quán)在公 司的外部穿過防火墻來訪問，那么用戶也可以在家里通過 Internet 來訪問該系統(tǒng)。 4．設(shè)計(jì)和實(shí)現(xiàn)的約束條件（constraint） CO-1：系統(tǒng)的設(shè)計(jì)、編碼和維護(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：所有腳本都用 Perl 語言來編寫。