需求分析文檔范例

《軟件需求（第2版）》，清華大學出版社，2004-11-1【原書名】SoftwareRequirements,SEcondEdition［原書信息］【原出版社】MicrosoftPress【作者】（美）KarlE.Wiegers【譯者】劉偉琴劉洪濤【開本】185x260【頁碼】357TOC\o"1-5"\h\z\o"CurrentDocument"D 需求文檔范例 1D.1 前景和范圍文檔 2D.1.1 業(yè)務需求 2\o"CurrentDocument"D.1.2 解決方案的前景 3\o"CurrentDocument"D.1.3 范圍和局限性 3\o"CurrentDocument"D.1.4 業(yè)務上下文 4\o"CurrentDocument"D.2 用例 6\o"CurrentDocument"D.3 軟件需求規(guī)格說明 10D.3.1 介紹 10D.3.2 總體描述 10D.3.3 系統(tǒng)特性 12\o"CurrentDocument"D.3.4 外部接口需求 14\o"CurrentDocument"D.3.5 其他非功能性需求 15\o"CurrentDocument"D.3.6 附錄A數(shù)據(jù)字典和數(shù)據(jù)模型 16\o"CurrentDocument"D.3.7 附錄B分析模型 18\o"CurrentDocument"D.4 業(yè)務規(guī)則 19D需求文檔范例該附錄通過“自助食堂訂餐系統(tǒng)（CafeteriaOrderingSystem，COS）”這樣一個假想的小型項目，闡述了本書所描述的某些需求文檔和圖。這里包括如下這些內容：前景和范圍文檔。用例列表和若干用例描述。部分軟件需求規(guī)格說明。某些分析模型。部分數(shù)據(jù)字典。若干業(yè)務規(guī)則。因為這僅僅是一個范例，所以我們并不打算完善這些需求元素。我們的目標只是提供一種思想，各種類型的需求信息之間彼此是如何關聯(lián)的，并演示我們可能如何編寫文檔每一部分的內容。在一個小型項目中，將不同的需求信息綜合到單一的文檔中，常常是有意義的，因此我們可能沒有單獨的前景和范圍文檔、用例文檔和軟件需求規(guī)格說明。這些文檔中的信息能夠以多種其他合理的方式來組織?；镜哪繕耸谴_保需求文檔清晰明了、完整和易使用。

這些文檔總的來說都遵循照前面章節(jié)所描述的模板，但是，因為這只是一個小型項目,所以對這些模板稍微作了一些簡化。有時，會將幾個部分合并起來，這是為了避免信息重復。每一個項目都應該考慮如何適應組織的標準模板，以盡量適合于項目的規(guī)模和本質。D.1前景和范D.1前景和范I文檔D.1.1業(yè)務需求背景、業(yè)務機會和客戶需要目前，ProcessImpact公司的大多數(shù)員工平均每天要花費60分鐘去自助食堂選擇、購買并用午餐，其中大約有20分鐘要花在公司和自助食堂之間的往返路程、選擇自己喜歡的午餐、以及以現(xiàn)金方式或以信用卡方式結算餐費上。當員工出去用午餐時，他們平均有90分鐘時間不在崗。有些員工提前給自助食堂打電話預訂午餐，請自助食堂準備好他們所選擇的午餐。但是，員工并不是總能如愿以償，因為自助食堂有些食物己賣完，而與此同時，自助食堂又不可避免地會浪費大量的食物，因為有些食物沒有賣出去而只好倒掉。早餐和晚餐同樣面臨著這樣的問題，只是到自助食堂用餐的員工人數(shù)比午餐要少得多。許多員工都通過允許自助食堂用戶在線訂餐的一個系統(tǒng)而提出訂餐請求，要求在指定的日期和時間內將所訂的午餐送到公司的指定地點。通過這樣一個系統(tǒng)，使用這一服務的員工可以節(jié)約相當可觀的時間，而且訂到自己所喜歡的食物的機會也增大了。這既提高了他們的工作生活質量，也提高了他們的生產率。自助食堂提前了解到客戶需要哪些食物，就可以減少浪費，并提高自助食堂員工的工作效率。要求送貨上門的訂餐員工將來還可以從本地的飯店來訂餐，這就大大擴大了員工對食物的選擇范圍，并通過與飯店的大量購餐協(xié)議而有可能節(jié)約費用。ProcessImpact公司也可以只在自助食堂訂午餐，而在飯店訂早餐、晚餐、特定事件的用餐以及周末會餐。業(yè)務目標（BusinessObjective,BO）和成功標準（SuccessCriteria,SC）BO-1:初始版本發(fā)布之后的6個月內，自助食堂的食物浪費減少50%。度量單位（scale）：自助食堂的工作人員每星期所倒掉的食物的價值。計量（meter）:檢查"自助食堂存貨系統(tǒng)（CafeteriaInventorySystem）〃的日志。過去情況（past）［2002.初步調研］:30%一般標準（plan）:小于15%最低標準（must）:小于20%。注該范例展示了使用Planguage語言來精確陳述業(yè)務目標或其他需求這樣一種方法。BO-2:初始版本發(fā)布之后的12個月內，自助食堂的運作費用減少50%。BO-3：初始版本發(fā)布之后的3個月內，每個雇員每天的平均有效工作時間增加20分鐘。SC-1：目前通過自助食堂解決午餐問題的那些員工，在初始版本發(fā)布之后的6個月內，他們中有75%的人使用“自助食堂訂餐系統(tǒng)〃。SC-2:初始版本發(fā)布之后的3個月內，對自助食堂滿意度的季度調查評價要提高0.5.而在初始版本發(fā)布之后的12個月內，這種滿意度要提高1.0。3.業(yè)務風險（Risk）RI-1:“自助食堂雇員聯(lián)合會（CafeteriaEmployeesUnion）〃可能要求與雇員重新簽訂合同，以反映新的雇員角色和自助食堂營業(yè)時間。（可能性為0.6，影響為3）RI-2:使用該系統(tǒng)的雇員太少，減少了對系統(tǒng)開發(fā)和變更自助食堂經營過程的投資回報。（可能性為0.3.影響為9）RI-3：本地飯店可能并不認同減價是雇員使用這一系統(tǒng)的正當理由，這會減低雇員對該系統(tǒng)的滿意度，并可能會減少他們對這一系統(tǒng)的使用。（可能性為0.4，影響為3）D.1.2解決方案的前景前景陳述對那些希望通過公司自助食堂或本地飯店在線訂餐的員工來說，“自助食堂訂餐系統(tǒng)〃是一個基于Internet的應用程序，它可以接受個人訂餐或團體訂餐，結算用餐費用，并觸發(fā)將預訂餐送到ProcessImpact公司內的指定位置。與當前的電話訂餐和人工訂餐不同，使用“自助食堂訂餐系統(tǒng)〃的雇員并不需要到食堂內去用餐，這既可以節(jié)約他們的時間，又可以增加他們對食物的選擇范圍。主要特性（FEature）FE-1：根據(jù)自助食堂提供的選擇菜單或送貨菜單來訂餐。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)。假設（ASsumption）和依賴（DEpendency）AS-1：自助食堂內有可以訪問公司內聯(lián)網的計算機和打印機，這樣自助食堂的雇員就可以處理期望的訂單量，不會遺漏任何送貨時間。AS-2:最多比請求的送貨時間晚15分鐘，自助食堂有送貨人員和送貨車輛，這樣就能滿足所有訂單的送貨要求。DE-1：如果某飯店有自己的聯(lián)機訂餐系統(tǒng)，那么“自助食堂訂餐系統(tǒng)〃必須能與這一系統(tǒng)進行雙向通信。D.1.3范圍和局限性1.初始版本和后續(xù)版本的范圍特性版本1版本2版本3FE-1只能從午餐菜單中訂標準餐：交貨單的費用支付方式只能是從工資中扣除除了午餐訂單外，也接受早餐訂單和晚餐訂單；費用的支付方式可以是信用卡和借記卡

特性版本1版本2版本3FE-2不實現(xiàn)不實現(xiàn)完全實現(xiàn)FE-3如果有時間就實現(xiàn)(具有中等優(yōu)先級)完全實現(xiàn)FE-4注冊的費用支付方式只能是從工資中扣除注冊的費用支付方式可以是信用卡和借記卡FE-5送餐地點只能是公司內送餐地點還可以選擇在公司外面FE-6完全實現(xiàn)FE-7不實現(xiàn)不實現(xiàn)完全實現(xiàn)FE-8不實現(xiàn)完全實現(xiàn)FE-9完全實現(xiàn)2.局限性(Limitation)和排斥性LI-1:自助食堂的有些食物不適宜于送貨，因此“自助食堂訂餐系統(tǒng)〃的顧客所用的菜單是食堂整個菜單的一個子集。LI-2：“自助食堂訂餐系統(tǒng)〃只能用于俄勒岡州Clackamas的ProcessImpact公司總部內的自助食堂。D.1.4業(yè)務上下文涉眾概覽涉眾主要價值態(tài)度主要興趣約束條件公司管理層提高員工生產率；節(jié)約自助食堂的費用強烈承諾完成版本2.如果有條件盡早完成版本3使用該系統(tǒng)所節(jié)約的費用必須超過開發(fā)此系統(tǒng)的費用和使用此系統(tǒng)的費用無自助食堂工作人員更高效地利用了工作人員的整個工作時間：提高了客戶的滿意度擔心與聯(lián)合會的關系，擔心食堂有可能會裁員；否則很愿意接受新系統(tǒng)保住工作培訓工作人員，掌握使用Internet所必需的技能；必須有送貨人員和車輛顧客可以更好地選擇食物；節(jié)約了時間：更加方便積極支持新系統(tǒng)，但使用系統(tǒng)的次數(shù)可能沒有期望的次數(shù)多，這主要是因為顧客考慮到在自助食堂和飯店就餐具有社會價值使用要簡單；送貨可靠；食物選擇的有效性需要訪問公司內聯(lián)網薪資管理部門得不到什么益處：需要建立從工資中扣除餐費的注冊方案不愿意采用該軟件系統(tǒng)，但認識到對公司和員工的整體利益，所以能以大局為重盡量減少對當前薪資核算軟件所做的變更還沒有得到資源來實現(xiàn)薪資軟件的變更飯店經理增加了銷售額；擴大了銷售范園，增加了新客戶雖然接受，但比較謹慎盡量少用新技術：關注送餐所需的資源和費用可能沒有足夠的人手和能力來處理訂單；可能需要得到Internet訪問權

項目優(yōu)先級因素具體干活者約束條件自由度進度計劃3/1/03前完成第一版，到5/1/03前完成第二版；在不包括責任人評審的情況下，最多可超過期限3個星期特性安排1.0版本實現(xiàn)的特性必須完全可操作質量必須通過95%的用戶驗收測試；必須通過全部的安全性測試；所有的安全事務都必須遵守公司的安全標準工作人員項目團隊規(guī)模包括一名半日工作的項目經理，兩名開發(fā)人員，和一名半日工作的測試人員；如果有必要，還可以另外再增加半日開發(fā)人員和半日測試人員費用在不包括責任人評審的情況下，財政預算最多可超支15%

D.2用例各種用戶類確認的“自助食堂訂餐系統(tǒng)〃的用例和主要參與者如下所示:主要參與者用例顧客訂餐變更訂單取消訂單查看菜單注冊從工資中扣除餐費的付費方式取消注冊的從工資中扣除餐費的付費方式訂購標準餐修改所訂的標準餐9推翻所訂的標準餐菜單經理創(chuàng)建菜單修改菜單定義特色菜自助食堂工作人員準備餐生成付費請求15.請求送貨16.生成系統(tǒng)使用報告送餐人員送餐記錄送餐情況打印送餐說明用例ID號UC-1用例名稱訂餐創(chuàng)建者KarlWiegerss最后更新者JackMcGillicutty創(chuàng)建日期2002年10月21日最后更新日期2002年11月7日參與者顧客描述顧客從公司內聯(lián)網或從家里訪問“自助食堂訂餐系統(tǒng)〃，隨意查看某一天的菜單，選擇自己想要的食物，提交訂單并要求在特定的時間窗口（15分鐘）內送貨到指定的地點前置條件顧客登錄到“自助食堂訂餐系統(tǒng)〃顧客注冊的付費方式是從工資中扣除后置條件訂單在“自助食堂訂餐系統(tǒng)〃中的存儲狀態(tài)是“巳接受〃根據(jù)這一訂單的食物條目來更新食物存貨根據(jù)這一次的送貨請求，對請求的時間窗口更新剩余的送貨能力主干過程1.0訂一份餐顧客要求查看某一天的菜單系統(tǒng)顯示有效食物菜單和當日特色菜顧客從菜單中選擇一種或多種食物顧客表明訂餐完成

主要參與者用例系統(tǒng)顯示所訂菜單條目、單價和總價格，包括應交納的稅和送貨費用顧客確認訂餐訂單或請求修改訂餐訂單（回到第3步）系統(tǒng)顯示那一天中有效的送餐時間顧客選擇送餐時間和指定送餐地點顧客指定付費方式系統(tǒng)確認接收訂單系統(tǒng)向顧客發(fā)送電子郵件，確認訂單細節(jié)、價格和送餐說明12.系統(tǒng)將訂單存儲在數(shù)據(jù)庫中，并發(fā)送電子郵件通知自助食堂工作人員，將食物信息發(fā)送給自助食堂庫存系統(tǒng)，并更新有效的送餐時間分支過程1.1訂多份餐（第4步之后分支出來）顧客要求預訂另一份餐返回到第2步1.2同樣的餐訂多份（第3步之后分支出來）顧客請求預訂指定數(shù)量的同樣食物的多份餐返回到第4步1.3訂當日特色菜（第2步之后分支出來）1.顧客從菜單中訂當日特色菜2返回到第5步異常1.0.E.1訂單截止時間在當前時間之前（第1步）1.系統(tǒng)通知顧客今天訂餐巳太晚了2a，顧客取消訂單2b.系統(tǒng)終止用例3a，顧客請求選擇另一個日期3b系統(tǒng)重新啟動用例1.0.E.2沒有有效的送餐時間（第1步）1.系統(tǒng)通知顧客送餐日己沒有有效的送餐時間2a.顧客取消訂單2b.系統(tǒng)終止用例3.顧客請求在自助食堂選擇訂單（跳過第7步和第8步）12.E.1不能完成指定數(shù)量的同樣食物的多份餐（第1步）1.系統(tǒng)通知顧客它所能提供的同樣食物曲多份餐的最大數(shù)量2顧客變更所訂的同樣食物的份數(shù)，或者取消訂單包含無優(yōu)先級高使用頻率大約400名用戶，平均每天使用一次業(yè)務規(guī)則BR-1，BR-2，BR-3，BR-4，BR-8，BR-11，BR-12，BR-33特別需求顧客在確認訂單之前的任何時間都可以取消訂單顧客能查看自己前6個月的全部訂餐，并可以重復其中的任一次訂餐作為新的訂餐，只要所有食物在請求送餐日的菜單中都有效。（優(yōu)先級為中）假設1.假設30%的顧客會訂當日特色菜（來源：根據(jù)前6個月的自助食堂數(shù)據(jù)所得）主要參與者用例注意和問題如果客戶在今天的截止時間之前使用系統(tǒng)，那么默認的日期是當前日期。否則，默認日期是自助食堂的下一個營業(yè)日如果顧客不要求送餐，那么“請求注冊付費方式是從工資中扣除〃這一前置條件就不適用這一用例的峰值使用負載是當?shù)貢r間早晨8點到10點用例ID號UC-5用例名稱注冊從工資中扣除餐費的付費方式創(chuàng)建者KarlWiegers最后更新者ChrisZambito創(chuàng)建日期2002年10月21日最后更新日期2002年10月31日參與者顧客，薪資核算系統(tǒng)（PayrollSystem）描述使用“自助食堂訂餐系統(tǒng)〃并要求送餐的自助食堂顧客，必須注冊從工資中扣除餐費的付費方式?！白灾程糜啿拖到y(tǒng)〃不支持現(xiàn)金購買，自助食堂會向“薪資核算系統(tǒng)〃發(fā)出付費請求，這將從下次雇員工資中扣除餐費或是在發(fā)薪日直接交款前置條件1.顧客登錄到“自助食堂訂餐系統(tǒng)〃后置條件1.顧客注冊從工資中扣除餐費的付費方式主干過程5.0注冊從工資中扣除餐費的付費方式顧客請求注冊從工資中扣除餐費的付費方式系統(tǒng)調用“認證用戶身份（AuthenticateUser’sIdentity）"用例如果顧客符合注冊從工資中扣除餐費的付費方式，那么系統(tǒng)請求薪資核算系統(tǒng)薪資核算系統(tǒng)確認顧客具有合法資格系統(tǒng)通知顧客他有合法資格選擇從工資中扣除餐費的付費方式系統(tǒng)要求顧客確認他期望注冊的是從工資中扣除餐費的付費方式顧客確認他期望注冊的是從工資中扣除餐費的付費方式系統(tǒng)要求薪資核算系統(tǒng)建立從顧客的工資中扣除餐費。薪資核算系統(tǒng)確認巳建立了從工資中扣除餐費系統(tǒng)通知顧客巳建立了從工資中扣除餐費.并向顧客提供注冊交易的確認號分支過程無異常5.0.E.1顧客身份認證失?。ǖ?步）1系統(tǒng)再給用戶兩次機會來糾正身份認證2a.如果認證成功，則顧客繼續(xù)進行用例2b.如果3次嘗試都認證失敗，則系統(tǒng)通知顧客，將無效的認證嘗試記入日志，并終止用例5.0.E.2顧客沒有資格從工資中扣除餐費（第4步）系統(tǒng)通知顧客他沒有資格從工資中扣除餐費，并給出具體理由系統(tǒng)終止用例5.0.E.3顧客己經有資格從工資中扣除餐費（第4步）系統(tǒng)通知顧客他巳經注冊了從工資中扣除餐費的付費方式系統(tǒng)終止用例包含驗證用戶身份(AuthenticateUser’sIdentity)優(yōu)先級高使用頻率平均每個雇員一次業(yè)務規(guī)則BR-86和BR-88決定雇員是否有資格從工資中扣除餐費特別需求1.按照公司制定的中等安全應用程序的標準來執(zhí)行用戶認證

主要參與者用例假設無注意和問題系統(tǒng)發(fā)布之后的最初兩星期，預計會相當頻繁地執(zhí)行這一用例用例ID號UC-11用例名稱修改菜單創(chuàng)建者KarlWiegers最后更新者創(chuàng)建日期2002年10月21日最后更新日期參與者菜單經理（MenuManager）描述自助食堂菜單經理可修改菜單的有效食物和特定日的價格，以反映有效食物或價格的變更，或者也可以定義當日特色菜前置條件1.菜單巳存在于系統(tǒng)中后置條件1.修改的菜單巳經保存起來主干過程11.0編輯巳存在的菜單1.菜單經理請求查看某一特定日期的菜單2系統(tǒng)顯示菜單菜單經理修改菜單以添加新的食物項、刪除或變更食物項、創(chuàng)建或變更特色菜、或者變更價格菜單經理請求保存修改過的菜單系統(tǒng)保存修改過的菜單分支過程無異常11.0.E.1指定日期的菜單不存在（第1步）系統(tǒng)通知菜單經理這一指定日期的菜單不存在系統(tǒng)詢問菜單經理他是否要創(chuàng)建這一指定日期的菜單3a.菜單經理回答“是〃3b.系統(tǒng)調用“創(chuàng)建菜單〃用例4a.菜單經理回答“否〃4b.系統(tǒng)終止用例11.0.E.2指定的日期巳過去了（第1步）系統(tǒng)通知菜單經理請求日期的菜單不能修改系統(tǒng)終止用例包含創(chuàng)建菜單優(yōu)先級高使用頻率每星期每個用戶大約使用20次業(yè)務規(guī)則BR-24特別需求1.菜單經理可以在任何時候取消菜單修改功能。如果菜單巳經發(fā)生了變更，則系統(tǒng)會請求對取消進行確認假設1.對ProcessImpact公司的每一個工作日都創(chuàng)建一個菜單，包括按照計劃雇員要在公司加班的周末和節(jié)假日D.3軟件需求規(guī)格說明D.3.1介紹目標軟件需求規(guī)格說明描述了“自助食堂訂餐系統(tǒng)(CafeteriaOrderingSystem,COS)”1.0版本的軟件功能性需求和非功能性需求。這一文檔計劃由實現(xiàn)和驗證系統(tǒng)正確功能的項目團隊成員來使用。除非在其他地方另有說明，這里指定的所有需求都具有高優(yōu)先級，而且都要在版本1.0中加以實現(xiàn)。項目范圍和產品特性“自助食堂訂餐系統(tǒng)”允許ProcessImpact公司雇員向公司的自助食堂在線訂餐，并送餐到公司內的指定地點。詳細的項目描述請參見CafeteriaOrderingSystemVisionandScopeDocument(自助食堂訂餐系統(tǒng)前景和范圍文檔)【1】。文檔中這一部分的標題為“初始版本和后續(xù)版本的范圍”，列出了按照進度計劃在這一版本中實現(xiàn)的全部或部分特性。參考文獻KarlWiegersFE%W1CafeterlaOrderingSystemViSIonandScopeDocument,EWli[#cesSI/projects/COS/COS=viSIon-andscope.docKarlWiegersBT#P9ProcessImpactIntranetDevelopmentstandardHR.#1.3,EWlitEcesSI/corporate/standards/PIintranet=dev=std.docChristineZambitoBT#PiProcessImpactBuSInessRulesCataIog,EWil#cesSI/corporate/po1icies/PI-buSIness=ru1es.docChristineZambitoBT#P9ProcessImpactInternetApplicationUSErInterfaceStandardHR#2.0,EWltt#cesSI/corporate/standards/PI=internet=ui=std.docD.3.2總體描述產品遠景規(guī)劃“自助食堂訂餐系統(tǒng)”是一個新系統(tǒng)，它取代了當前在ProcessImpact公司自助食堂內以手工方式和電話方式預定和選擇午餐的過程。圖D.1是一幅關聯(lián)圖，它演示了1.0版本的外部實體和系統(tǒng)接口。期望系統(tǒng)演化若干個版本，最終與本地若干飯店的Internet訂餐服務相連接，并提供信用卡和借記卡授權服務。

送餐要求扣除餐費響應送餐要求'飯菜狀-態(tài)更新」醺飯菜確認送餐訂單信息 X訂單和菜單改單從工資中扣餐費訂餐信息菜單內容、\要求從工資中扣除餐費》送餐要求扣除餐費響應送餐要求'飯菜狀-態(tài)更新」醺飯菜確認送餐訂單信息 X訂單和菜單改單從工資中扣餐費訂餐信息菜單內容、\要求從工資中扣除餐費》付款要求菜單管理人顧客送餐人員自助食堂目錄系統(tǒng)r自助餐廳/ 工作人員工資系統(tǒng)圖D.1“自助食堂訂膂系統(tǒng)〃版本1.0的關聯(lián)圖用戶類和用戶特性用戶類描述顧客（優(yōu)先考慮）顧客是俄勒岡州Clackamas的ProcessImpact公司的雇員，他們希望從公司的自助食堂訂餐并能送貨上門。大約有600名潛在顧客，其中估計有400人預計平均每星期每人使用“自助食堂訂餐系統(tǒng)〃4次（來源：根據(jù)當前自助食堂的使用數(shù)據(jù)）。顧客有時會由于團體事件或有來賓而訂好多份餐。估計90%的訂單是通過公司的內聯(lián)網而提交的，10%的訂單是從家里提交的。所有的顧客都可以從他們的辦公室訪問公司內聯(lián)網。有些顧客希望建立固定的訂餐，每天送同樣的飯菜，或者是自動送當日特色菜。顧客必須能推翻對某一具體日期的訂餐自助食堂工作人員ProcessImpact公司自助食堂目前雇傭了大約20名“自助食堂工作人員〃，他們從“自助食堂訂餐系統(tǒng)〃接受訂單，準備飯菜，對要送貨上門的飯菜進行打包，打印送餐說明，并請求送餐。自助食堂工作人員需要接受培訓.學會如何使用計算機、Web瀏覽器和“自助食堂訂餐系統(tǒng)〃菜單經理菜單管理人是自助食堂的雇員，也許就是食堂經理，他負責建立并維護自助食堂有效的食物條目日常菜單，和某一天每一個食物條目的有效時間。有些飯菜不適宜于送貨上門。菜單管理人也要定義食堂的每日特色菜。菜單經理還需要定期編輯菜單，以反映計劃內的無效的或價格發(fā)生了變更的食物送餐人員當自助食堂工作人員準備訂單所要求送的飯菜時，他們打印送餐說明并向送餐人員發(fā)出送餐請求，送餐人員是食堂的其他雇員或者是承包人。送餐人員為每餐都要挑選食物和準備送餐說明，并將它送到顧客手里。送餐人員與系統(tǒng)的主要交互將是偶爾重新打印送餐說明并確認餐巳送到（或沒有送到）顧客手中3.運行環(huán)境（OperationEnvironment,OE）OE-1：“自助食堂訂餐系統(tǒng)〃的操作將通過如下的Web瀏覽器來完成：MicrosoftInternetExplorer版本5.0和6.0，NetscapeCommunicator版本4.7和Netscape版本6和版本7。OE-2：“自助食堂訂餐系統(tǒng)〃將運行在一個服務器中，該服務器運行當前由公司批準的RedHatLinux版本和ApacheHTTPServeroOE-3：“自助食堂訂餐系統(tǒng)〃將允許用戶通過公司內聯(lián)網來訪問，如果用戶被授權在公司的外部穿過防火墻來訪問，那么用戶也可以在家里通過Internet來訪問該系統(tǒng)。設計和實現(xiàn)的約束條件(constraint)CO-1：系統(tǒng)的設計、編碼和維護文檔將遵照ProcessImpactIntranetDevelopmentStandard(ProcessImpact公司內聯(lián)網開發(fā)標準)版本1.3【2】。CO-2:系統(tǒng)將采用公司標準的當前Oracle數(shù)據(jù)庫引擎。CO-3:所有HTML代碼將遵照HTML4.0標準。CO-4:所有腳本都用Perl語言來編寫。用戶文檔(UserDocumentation,UD)UD-1：系統(tǒng)將提供一個分層的和跨鏈接的HTML聯(lián)機幫助系統(tǒng)，它描述并演示了所有系統(tǒng)功能。UD-2:如果是一個新用戶第一次使用該系統(tǒng)，系統(tǒng)可以根據(jù)用戶的要求，提供一個聯(lián)機教程，這樣用戶可以使用靜態(tài)教程菜單來具體實踐一下如何訂餐。系統(tǒng)不會將采用這一模板的訂餐訂單存儲到數(shù)據(jù)庫中，也不會將這種訂單提交給自助食堂。假設(ASsumption)和依賴(DEpendency)AS-1：只要是要求員工在崗的每一個公司工作日，自助食堂在早餐、午餐和晚餐時都會營業(yè)。DE-1：“自助食堂訂餐系統(tǒng)〃的運行依賴于“薪資核算系統(tǒng)〃所做出的變更，它接受用“自助食堂訂餐系統(tǒng)〃訂餐的付費請求。DE-2：“自助食堂訂餐系統(tǒng)〃的運行依賴于“自助食堂庫存系統(tǒng)〃所做出的變更，當接受“自助食堂訂餐系統(tǒng)〃訂單后，它更新食物條目的有效性。D.3.3系統(tǒng)特性1.訂餐描述和優(yōu)先級自助食堂的顧客其身份得到驗證之后，他們就可以訂餐，并可以要求送到公司內指定的地點，也可以去食堂內就餐。只要所訂餐還沒有準備好，顧客就可以取消或改變訂單。優(yōu)先級為高。刺激/響應序列刺激：顧客請求訂餐，可以是一份或多份。響應：系統(tǒng)向顧客詢問訂餐細節(jié)、付費方式和送餐說明。刺激：顧客請求改變訂單。響應：如果訂單狀態(tài)是“已接受〃，則系統(tǒng)允許用戶編輯以前的訂單。刺激：顧客請求取消訂單。響應：如果訂單狀態(tài)是“已接受〃，則系統(tǒng)取消訂單。功能性需求Order.Place登錄到“自助食堂訂餐系統(tǒng)〃的顧客可以通過該系統(tǒng)訂餐，訂一份或多份都可以Order.Place.Register系統(tǒng)將確認訂餐的顧客所注朋的付費方式是從工資中扣除餐費的付費方式Order.Plaoe.Register.No如果顧客沒有注冊從工資中扣除餐費的付費方式，那么系統(tǒng)將為顧窯提

供一些選擇方案，顧客可以現(xiàn)在注冊并繼續(xù)進行訂餐，也可以訂餐后去食堂月餐（不送餐），或者還可以退出“自助食堂訂餐系統(tǒng)〃Order.Place.Date系統(tǒng)將提示顧客輸入用餐日期（請參見BR-8）Order.Place.Date.Cutoff如果訂餐日期是當前日期，而訂餐時間巳過了截止時間，那么系統(tǒng)將通知顧客訂餐太晚了，今天己不能訂餐了。顧客可以政變訂餐日期，或者也可以取消訂單Order.Deliver.SElect顧客將指定只是訂餐或者是還要求送餐Order.Deliver.Location如果訂單是要求送餐，雨且送餐日仍有有效的送餐時間，那么顧客將提供一個有效的送餐地點Order.Deliver.Notimes如果送餐日己沒有有效的送餐時間，那么系統(tǒng)將通知顧客。顧客既可以取消訂單，也可以選擇去食堂就餐Order.Deliver.Times系統(tǒng)將顯示訂餐日剩余的有效送餐時間。顧客可以從顯示的送餐時間中選擇一個時間，也可以將訂單改為去食堂就餐，或者也可以取消訂單Order.Menu.Date系統(tǒng)將顯示指定日期的菜單Order'Menu.Available當前日期的菜單只顯示至少在自助食堂存貨的一個供應間中有貨的那些食物Order.Units.Food系統(tǒng)允許顧客表明他希望訂餐的每個菜單條目的份數(shù)Order,Units.Multiple系統(tǒng)允許用戶訂多份同樣的餐，但其最大份數(shù)只能是訂單中的所有菜單條目的有效份數(shù)中的最小值Order.Units.TooMany如杲顧客所訂的某一菜單項的份數(shù)超過了目前自助食堂存貨中的數(shù)量，那么系統(tǒng)將通知顧客他所能訂的食物條目的最大份數(shù)Order.Units.Change如果食堂存貨中的食物不能滿足顧客的數(shù)量要求，那么顧客可以改變所訂的份數(shù)，也可以改變所訂的同樣餐的份數(shù)，或者也可以取消訂餐Order.Confrm.Display如果顧客表明他不希望再訂食物了，那么系統(tǒng)將顯示他所訂的食物條目，每一食物條目的單價，以及應該支付多少費用，具體計算方法請參見BR-12Order.Conf1rm.Prompt系統(tǒng)提示顧客確認訂餐的訂單Order.Conf1rm.Not如果顧客不確認訂單，那么顧客既可以編輯訂單，也可以取消訂單Order.Conf1rm.More顧客可以通過系統(tǒng)再另外訂餐，可以是同一天的，也可以不是同一天的。BR-3和BR-4與在單一訂單中訂多份餐有關系Ordcr.Pay.Method當顧客表明他巳經完成訂餐時，系統(tǒng)會要求用戶逸擇一種付費方式。Order.Pay.Deliver請參見BR-llOrder.Pay.Pickup如果顧客選擇在食堂就餐，那么系統(tǒng)會讓顧客選擇付費方式，可以是從工資中扣除，也可以是在就餐時支付現(xiàn)金Order.Pay.Details系統(tǒng)將顯示所訂的食物條日、費用、付費方式和送貨說明Order.Pay.Conf1rm顧客可以確認訂單，也可以請求編輯訂單，或者也可以請求取消訂單Order.pay.Congfirm.Deduct如果顧客確認訂單，并選擇了從工資中扣除餐費的付費方式，那么系統(tǒng)將向“薪資核算系統(tǒng)〃發(fā)出一個付費請求Ordcr.Bg.Confrm.OK如果付費請求被接受，那么系統(tǒng)將顯示一條消息來確認訂單巳接受，消息中包括從工資中扣除餐費的事務號Mer.Pay.Con8rm.NG如果付費請求被拒絕，系統(tǒng)將顯示一條消息來說明拒絕的理由。顧客可以取消訂單，也可以改為現(xiàn)金支付方式，或者是去食堂就餐Order.Done當顧客確認了訂單時，系統(tǒng)會將下面幾步作為一個事務來處理Ordcr.Done.Store為該訂單分配下一個有效的訂單號并存儲這一訂單，其訂單的初始狀態(tài)設置為“巳接受〃Order,Donc'Inventory向“自助食堂存貨系統(tǒng)〃發(fā)送一條消息，包括訂單中每種食物條目的份數(shù)Order.Done.Menu更新當前訂單的訂餐日期所對應的菜單，從自助食堂存貨中扣除訂單中的食物條目數(shù)量，以反映所有食物條目的最新狀況Order.Done,Times更新訂餐日期中剩余的有效送餐時間Order.Done.Patron向顧客發(fā)送電子郵件消息，消息包括訂單和支付費用的有關信息Order.Done.Cateteria向自助食堂工作人員發(fā)送電子郵件消息，消息包括訂單的有關信息Order.Done.Failure如果Order.Donc中的任何一步不成功，則系統(tǒng)將回滾事務，通知用戶訂單不成功，并說明失敗的原因Order.Previous.Period系統(tǒng)允許顧客瀏覽前6個月的全部訂餐?！緝?yōu)先級為中】Order.Previous.Reorder顧客可以重新預訂他前6個月所訂過的任一餐，只要新訂率中的所有食物條目在用餐日的菜單中有效即可?！緝?yōu)先級為中】（本范例不提供改變和取消訂餐訂單的功能性需求）創(chuàng)建、瀏覽、修改和刪除訂餐（該范例不提供細節(jié)）注冊訂餐的付費方式（該范例不提供細節(jié)）請求送餐（該范例不提供細節(jié)）創(chuàng)建、瀏覽、修改和刪除自助食堂菜單（該范例不提供細節(jié)）D.3.4外部接口需求用戶界面（UserInterfaces，UI）UI-1:“自助食堂訂餐系統(tǒng)〃的屏幕畫面將遵照ProcessImpactInternetApplicationUserInterfacestandard（ProcessImpact公司的Internet應用程序用戶界面標準）版本2.0【4】。UI-2:系統(tǒng)對所顯示的每個HTML網頁都提供幫助鏈接，解釋如何使用這些網頁。UI-3：Web頁面的全部導航和食物條目選擇，除了綜合使用鼠標和鍵盤共同完成外，還可以只通過鍵盤來單獨完成。硬件接口硬件接口還沒有確定。軟件接口（SoftwareInterfaces，SI）SI-1：自助食堂存貨系統(tǒng)。SI-1.1：“自助食堂訂餐系統(tǒng)〃通過程序界面向“自助食堂存貨系統(tǒng)〃發(fā)送所訂的食物條目數(shù)量。SI-1.2：“自助食堂訂餐系統(tǒng)〃將輪詢“自助食堂存貨系統(tǒng)〃，以確定請求的食物是否有效。SI-1.3:當“自助食堂存貨系統(tǒng)〃通知“自助食堂訂餐系統(tǒng)〃某一指定的食物條目已經沒貨時，“自助食堂訂餐系統(tǒng)〃會從當日的菜單中將該食物條目刪除。SI-2："薪資管理系統(tǒng)〃?！白灾程糜啿拖到y(tǒng)〃通過程序界面與“薪資管理系統(tǒng)〃進行通信，完成下面這些操作：SI-2.1：允許顧客注冊從工資中扣除餐費的付費方式。SI-2.2:允許顧客取消所注冊的從工資中扣除餐費的付費方式。SI-2.3:檢查顧客是否注冊了從工資中扣除餐費的付費方式。SI-2.4：為所購餐提交付費請求。SI-2.5：退還全部或部分上面的費用，其原因是因為顧客拒絕了所訂的餐，或對它不滿意，也可能是因為沒能按照送餐說明完成送餐任務。通信接口（CommunicationsInterfaces,CI）CI-1:“自助食堂訂餐系統(tǒng)〃將向顧客發(fā)送電子郵件消息，以確認收到訂單、價格和送餐說明。CI-2：“自助食堂訂餐系統(tǒng)〃將向顧客發(fā)送電子郵件消息，以報告訂單接受之后訂單中或送餐中存在的問題。D.3.5其他非功能性需求性能（PErformance）需求PE-1:在當?shù)貢r間早晨8點到10點這一段高峰期間，系統(tǒng)將能適應400個用戶，平均每個會話估計持續(xù)8分鐘。PE-2：系統(tǒng)生成的所有Web頁面，通過速率為40KBps的調制解調器在不超過10秒的時間內可以全部下載下來。PE-3：用戶提交了查詢之后，對查詢的響應時間不能超過7秒，在此時間內要將查詢結果顯示在屏幕上。PE-4:用戶向系統(tǒng)提交信息后，系統(tǒng)將在4秒內向用戶顯示確認消息。防護性需求防護性需求還沒有確定。安全性（SEcurity）需求SE-1:所有涉及功能信息或個人身份信息的網絡事務，都要按照BR-33進行加密操作。SE-2:除瀏覽菜單外，用戶必須登錄到“自助食堂訂餐系統(tǒng)〃才能完成其他所有操作。SE-3:顧客的登錄受計算機系統(tǒng)訪問控制策略的限制，具體請參照BR-35。SE-4：自助食堂的工作人員，只有那些授權為菜單經理的成員，才能通過系統(tǒng)創(chuàng)建或編輯菜單，具體請參照BR-24。SE-5：只有那些被授權可以在家訪問公司內聯(lián)網的用戶，才可以在公司以外的地方使用“自助食堂訂餐系統(tǒng)〃。SE-6:系統(tǒng)只允許顧客瀏覽他們自己以前的訂單，而不能瀏覽其他顧客的訂單。軟件質量屬性Availability（可用性）-1：“自助食堂訂餐系統(tǒng)〃將對公司內聯(lián)網的用戶可用，撥號用戶在當?shù)貢r間早晨5點到晚上12點99.9%的時間可用，當?shù)貢r間晚上12點到早晨5點則95%的時間可用。Robustness（健壯性）-1:如果在訂單得到確認或取消之前，用戶和系統(tǒng)的連接中斷，那么用戶應該能通過“自助食堂訂餐系統(tǒng)〃恢復不完整的訂單。D.3.6附錄A數(shù)據(jù)字典和數(shù)據(jù)模型送餐說明=顧客名字+顧客電話號碼+用餐日期+送餐地點+送餐時間窗口送餐地點=*將所訂的餐送到哪個大樓和房間*送餐時間窗口=*送餐的時間間隔是15分鐘；以每一刻鐘開始和結束*雇員ID號=*訂餐雇員在公司中的ID號：是由6個字符數(shù)字組成的字符串*食物條目描述=*菜單中食物條目的文本描述，最多100個字符*食物條目價格=*一份菜單食物條目的稅前費用，以美元和美分來計算*用餐日期=*送餐或就餐日期;格式為MM/DD/YYYY ；如果訂單截止日期在當前日期之后，則用餐日期的默認值