軟件需求文檔范例模板

1、XXX系統(tǒng)軟件需求文檔組長成員 年 月 日修改記錄版本號變更控制報告編號更改條款及內(nèi)容更改人審批人更改日期1.0初稿1.1添加數(shù)據(jù)流圖1.2添加業(yè)務(wù)規(guī)則目 錄1前景和范圍文檔41.1業(yè)務(wù)需求41.2解決方案的前景51.3范圍和局限性61.4業(yè)務(wù)上下文62用例描述文檔93需求規(guī)格說明書133.1引言133.2綜合描述133.3外部接口需求153.4系統(tǒng)特性163.5其他非功能性需求193.6其他需求20附錄A 詞匯表20附錄B 分析模型22附錄C 待確定問題的列表23該附錄通過“自助食堂訂餐系統(tǒng)（Cafeteria Ordering System，COS）”這樣一個假想的小型項目，闡述了本書所描

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

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

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

5、還可以從本地的飯店來訂餐，這就大大擴大了員工對食物的選擇范圍，并通過與飯店的大量購餐協(xié)議而有可能節(jié)約費用。Process Impact公司也可以只在自助食堂訂午餐，而在飯店訂早餐、晚餐、特定事件的用餐以及周末會餐。2.業(yè)務(wù)目標(biāo)（Business Objective，BO）和成功標(biāo)準(zhǔn)（Success Criteria，SC）BO-1：初始版本發(fā)布之后的6個月內(nèi)，自助食堂的食物浪費減少50%。度量單位（scale）：自助食堂的工作人員每星期所倒掉的食物的價值。計量（meter）：檢查“自助食堂存貨系統(tǒng)（Cafeteria Inventory System）”的日志。過去情況（past）2002.初

6、步調(diào)研：30%一般標(biāo)準(zhǔn)（plan）：小于15%最低標(biāo)準(zhǔn)（must）：小于20%。注 該范例展示了使用Planguage語言來精確陳述業(yè)務(wù)目標(biāo)或其他需求這樣一種方法。BO-2：初始版本發(fā)布之后的12個月內(nèi)，自助食堂的運作費用減少50%。BO-3：初始版本發(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)險（Ris

7、k）RI-1：“自助食堂雇員聯(lián)合會（Cafeteria Emp1oyees 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)理由，這會減低雇員對該系統(tǒng)的滿意度，并可能會減少他們對這一系統(tǒng)的使用。（可能性為0.4，影響為3）1.2 解決方案的前景1.前景陳述對那些希望通過公司自助食堂或本地飯店在線訂餐的員工來說，“自助食堂訂餐系統(tǒng)”是一個基于Internet的應(yīng)用程序，它

8、可以接受個人訂餐或團體訂餐，結(jié)算用餐費用，并觸發(fā)將預(yù)訂餐送到Process Impact公司內(nèi)的指定位置。與當(dāng)前的電話訂餐和人工訂餐不同，使用“自助食堂訂餐系統(tǒng)”的雇員并不需要到食堂內(nèi)去用餐，這既可以節(jié)約他們的時間，又可以增加他們對食物的選擇范圍。2.主要特性（FEature）FE-1：根據(jù)自助食堂提供的選擇菜單或送貨菜單來訂餐。FE-2：根據(jù)本地飯店的送貨菜單來訂餐。FE-3：創(chuàng)建、瀏覽、修改和刪除用餐預(yù)訂服務(wù)。FE-4：注冊用餐的付費方式。FE-5：請求送餐。FE-6：創(chuàng)建、瀏覽、修改和刪除自助食堂菜單。FE-7：預(yù)訂自助食堂菜單上所沒有的定做菜。FE-8：生成自助食堂定做菜的食譜和配料列

9、表。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)的計算機和打印機，這樣自助食堂的雇員就可以處理期望的訂單量，不會遺漏任何送貨時間。AS-2：最多比請求的送貨時間晚15分鐘，自助食堂有送貨人員和送貨車輛，這樣就能滿足所有訂單的送貨要求。DE-1：如果某飯店有自己的聯(lián)機訂餐系統(tǒng)，那么“自助食堂訂餐系統(tǒng)”必須能與這一系統(tǒng)進行雙向通信。1.3 范圍和局限性1.初始版本和后續(xù)版本的范圍特性版本1版本2版本3FE-1只能從午餐菜單中訂標(biāo)準(zhǔn)餐：交貨單的費用支付方式

10、只能是從工資中扣除除了午餐訂單外，也接受早餐訂單和晚餐訂單；費用的支付方式可以是信用卡和借記卡FE-2不實現(xiàn)不實現(xiàn)完全實現(xiàn)FE-3如果有時間就實現(xiàn)（具有中等優(yōu)先級）完全實現(xiàn)FE-4注冊的費用支付方式只能是從工資中扣除注冊的費用支付方式可以是信用卡和借記卡FE-5送餐地點只能是公司內(nèi)送餐地點還可以選擇在公司外面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)”只能用于俄勒岡州Clacka

11、mas的Process Impact公司總部內(nèi)的自助食堂。1.4 業(yè)務(wù)上下文1.涉眾概覽涉 眾主要價值態(tài) 度主要興趣約束條件公司管理層提高員工生產(chǎn)率；節(jié)約自助食堂的費用強烈承諾完成版本2.如果有條件盡早完成版本3使用該系統(tǒng)所節(jié)約的費用必須超過開發(fā)此系統(tǒng)的費用和使用此系統(tǒng)的費用無自助食堂工作人員更高效地利用了工作人員的整個工作時間：提高了客戶的滿意度擔(dān)心與聯(lián)合會的關(guān)系，擔(dān)心食堂有可能會裁員；否則很愿意接受新系統(tǒng)保住工作培訓(xùn)工作人員，掌握使用Internet所必需的技能；必須有送貨人員和車輛顧客可以更好地選擇食物；節(jié)約了時間：更加方便積極支持新系統(tǒng)，但使用系統(tǒng)的次數(shù)可能沒有期望的次數(shù)多，這主要是因

12、為顧客考慮到在自助食堂和飯店就餐具有社會價值使用要簡單；送貨可靠；食物選擇的有效性需要訪問公司內(nèi)聯(lián)網(wǎng)薪資管理部門得不到什么益處：需要建立從工資中扣除餐費的注冊方案不愿意采用該軟件系統(tǒng)，但認(rèn)識到對公司和員工的整體利益，所以能以大局為重盡量減少對當(dāng)前薪資核算軟件所做的變更還沒有得到資源來實現(xiàn)薪資軟件的變更飯店經(jīng)理增加了銷售額；擴大了銷售范園，增加了新客戶雖然接受，但比較謹(jǐn)慎盡量少用新技術(shù)：關(guān)注送餐所需的資源和費用可能沒有足夠的人手和能力來處理訂單；可能需要得到Internet訪問權(quán)2.項目優(yōu)先級因素具體干活者約束條件自由度進度計劃3/l/03前完成第一版，到5/l/03前完成第二版；在不包括責(zé)任人

13、評審的情況下，最多可超過期限3個星期特性安排1.0版本實現(xiàn)的特性必須完全可操作質(zhì)量必須通過95%的用戶驗收測試；必須通過全部的安全性測試；所有的安全事務(wù)都必須遵守公司的安全標(biāo)準(zhǔn)工作人員項目團隊規(guī)模包括一名半日工作的項目經(jīng)理，兩名開發(fā)人員，和一名半日工作的測試人員；如果有必要，還可以另外再增加半日開發(fā)人員和半日測試人員費用在不包括責(zé)任人評審的情況下，財政預(yù)算最多可超支15%2 用例描述文檔各種用戶類確認(rèn)的“自助食堂訂餐系統(tǒng)”的用例和主要參與者如下所示：主要參與者用 例顧客1.訂餐2.變更訂單3.取消訂單4.查看菜單5.注冊從工資中扣除餐費的付費方式6.取消注冊的從工資中扣除餐費的付費方式7.訂購

14、標(biāo)準(zhǔn)餐8.修改所訂的標(biāo)準(zhǔn)餐9推翻所訂的標(biāo)準(zhǔn)餐菜單經(jīng)理10.創(chuàng)建菜單11.修改菜單12.定義特色菜自助食堂工作人員13.準(zhǔn)備餐14.生成付費請求15.請求送貨16.生成系統(tǒng)使用報告送餐人員17.送餐18.記錄送餐情況19.打印送餐說明用例ID號UC-1用例名稱訂餐創(chuàng)建者Karl Wiegerss最后更新者Jack McGillicutty創(chuàng)建日期2002年10月21日最后更新日期2002年11月7日參與者顧客描述顧客從公司內(nèi)聯(lián)網(wǎng)或從家里訪問“自助食堂訂餐系統(tǒng)”，隨意查看某一天的菜單，選擇自己想要的食物，提交訂單并要求在特定的時間窗口（15分鐘）內(nèi)送貨到指定的地點前置條件1.顧客登錄到“自助食堂訂

15、餐系統(tǒng)” 2.顧客注冊的付費方式是從工資中扣除后置條件1.訂單在“自助食堂訂餐系統(tǒng)”中的存儲狀態(tài)是“已接受”2.根據(jù)這一訂單的食物條目來更新食物存貨3.根據(jù)這一次的送貨請求，對請求的時間窗口更新剩余的送貨能力主干過程1.0 訂一份餐1.顧客要求查看某一天的菜單2.系統(tǒng)顯示有效食物菜單和當(dāng)日特色菜3.顧客從菜單中選擇一種或多種食物4.顧客表明訂餐完成5.系統(tǒng)顯示所訂菜單條目、單價和總價格，包括應(yīng)交納的稅和送貨費用6.顧客確認(rèn)訂餐訂單或請求修改訂餐訂單（回到第3步）7.系統(tǒng)顯示那一天中有效的送餐時間8.顧客選擇送餐時間和指定送餐地點9.顧客指定付費方式10.系統(tǒng)確認(rèn)接收訂單11.系統(tǒng)向顧客發(fā)送電子

16、郵件，確認(rèn)訂單細(xì)節(jié)、價格和送餐說明12.系統(tǒng)將訂單存儲在數(shù)據(jù)庫中，并發(fā)送電子郵件通知自助食堂工作人員，將食物信息發(fā)送給自助食堂庫存系統(tǒng)，并更新有效的送餐時間分支過程1.1 訂多份餐（第4步之后分支出來）1.顧客要求預(yù)訂另一份餐2.返回到第2步1.2 同樣的餐訂多份（第3步之后分支出來）1.顧客請求預(yù)訂指定數(shù)量的同樣食物的多份餐2.返回到第4步1.3 訂當(dāng)日特色菜（第2步之后分支出來）1.顧客從菜單中訂當(dāng)日特色菜2 返回到第5步異常1.0.E.1 訂單截止時間在當(dāng)前時間之前（第1步）1.系統(tǒng)通知顧客今天訂餐已太晚了2a，顧客取消訂單2b.系統(tǒng)終止用例3a，顧客請求選擇另一個日期3b 系統(tǒng)重新啟動

17、用例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è)務(wù)規(guī)則BR-1，BR-2，BR-3，BR-4，BR-8，BR-11，BR-12，BR-33特別需求1.顧客在確認(rèn)訂單之前的任何時間都可以取消訂單2.顧客能查看自己前6個月的全部訂餐，并可以重復(fù)其中的任一次訂

18、餐作為新的訂餐，只要所有食物在請求送餐日的菜單中都有效。（優(yōu)先級為中）假設(shè)1.假設(shè)30%的顧客會訂當(dāng)日特色菜（來源：根據(jù)前6個月的自助食堂數(shù)據(jù)所得）注意和問題1.如果客戶在今天的截止時間之前使用系統(tǒng)，那么默認(rèn)的日期是當(dāng)前日期。否則，默認(rèn)日期是自助食堂的下一個營業(yè)日2.如果顧客不要求送餐，那么“請求注冊付費方式是從工資中扣除”這一前置條件就不適用3.這一用例的峰值使用負(fù)載是當(dāng)?shù)貢r間早晨8點到10點用例ID號UC-5用例名稱注冊從工資中扣除餐費的付費方式創(chuàng)建者Karl Wiegers最后更新者Chris Zambito創(chuàng)建日期2002年10月21日最后更新日期2002年10月31日參與者顧客，薪資

19、核算系統(tǒng)（Payroll System）描述使用“自助食堂訂餐系統(tǒng)”并要求送餐的自助食堂顧客，必須注冊從工資中扣除餐費的付費方式。 “自助食堂訂餐系統(tǒng)”不支持現(xiàn)金購買，自助食堂會向“薪資核算系統(tǒng)”發(fā)出付費請求，這將從下次雇員工資中扣除餐費或是在發(fā)薪日直接交款前置條件1.顧客登錄到“自助食堂訂餐系統(tǒng)”后置條件1.顧客注冊從工資中扣除餐費的付費方式主干過程5.0 注冊從工資中扣除餐費的付費方式1.顧客請求注冊從工資中扣除餐費的付費方式2.系統(tǒng)調(diào)用“認(rèn)證用戶身份（Authenticate User s Identity）” 用例3.如果顧客符合注冊從工資中扣除餐費的付費方式，那么系統(tǒng)請求薪資核算系統(tǒng)

20、4.薪資核算系統(tǒng)確認(rèn)顧客具有合法資格5.系統(tǒng)通知顧客他有合法資格選擇從工資中扣除餐費的付費方式6.系統(tǒng)要求顧客確認(rèn)他期望注冊的是從工資中扣除餐費的付費方式7.顧客確認(rèn)他期望注冊的是從工資中扣除餐費的付費方式8.系統(tǒng)要求薪資核算系統(tǒng)建立從顧客的工資中扣除餐費。9.薪資核算系統(tǒng)確認(rèn)已建立了從工資中扣除餐費10.系統(tǒng)通知顧客已建立了從工資中扣除餐費.并向顧客提供注冊交易的確認(rèn)號分支過程無異常5.0.E.1 顧客身份認(rèn)證失?。ǖ?步）1 系統(tǒng)再給用戶兩次機會來糾正身份認(rèn)證2a.如果認(rèn)證成功，則顧客繼續(xù)進行用例2b.如果3次嘗試都認(rèn)證失敗，則系統(tǒng)通知顧客，將無效的認(rèn)證嘗試記入日志，并終止用例5.0.E.

21、2 顧客沒有資格從工資中扣除餐費（第4步）1.系統(tǒng)通知顧客他沒有資格從工資中扣除餐費，并給出具體理由2.系統(tǒng)終止用例5.0.E.3 顧客己經(jīng)有資格從工資中扣除餐費（第4步）1.系統(tǒng)通知顧客他已經(jīng)注冊了從工資中扣除餐費的付費方式2.系統(tǒng)終止用例包含驗證用戶身份（Authenticate Users Identity）優(yōu)先級高使用頻率平均每個雇員一次業(yè)務(wù)規(guī)則BR-86和BR-88決定雇員是否有資格從工資中扣除餐費特別需求1.按照公司制定的中等安全應(yīng)用程序的標(biāo)準(zhǔn)來執(zhí)行用戶認(rèn)證假設(shè)無注意和問題系統(tǒng)發(fā)布之后的最初兩星期，預(yù)計會相當(dāng)頻繁地執(zhí)行這一用例用例ID號UC-11用例名稱修改菜單創(chuàng)建者Karl Wi

22、egers最后更新者創(chuàng)建日期2002年10月21日最后更新日期參與者菜單經(jīng)理（Menu Manager）描述自助食堂菜單經(jīng)理可修改菜單的有效食物和特定日的價格，以反映有效食物或價格的變更，或者也可以定義當(dāng)日特色菜前置條件1.菜單已存在于系統(tǒng)中后置條件1.修改的菜單已經(jīng)保存起來主干過程11.0 編輯已存在的菜單1.菜單經(jīng)理請求查看某一特定日期的菜單2 系統(tǒng)顯示菜單3.菜單經(jīng)理修改菜單以添加新的食物項、刪除或變更食物項、創(chuàng)建或變更特色菜、或者變更價格4.菜單經(jīng)理請求保存修改過的菜單5.系統(tǒng)保存修改過的菜單分支過程無異常11.0.E.1 指定日期的菜單不存在（第1步）1.系統(tǒng)通知菜單經(jīng)理這一指定日期

23、的菜單不存在2.系統(tǒng)詢問菜單經(jīng)理他是否要創(chuàng)建這一指定日期的菜單3a.菜單經(jīng)理回答“是”3b.系統(tǒng)調(diào)用“創(chuàng)建菜單”用例4a.菜單經(jīng)理回答“否”4b.系統(tǒng)終止用例11.0.E.2 指定的日期已過去了（第1步）1.系統(tǒng)通知菜單經(jīng)理請求日期的菜單不能修改2.系統(tǒng)終止用例包含創(chuàng)建菜單優(yōu)先級高使用頻率每星期每個用戶大約使用20次業(yè)務(wù)規(guī)則BR-24特別需求1.菜單經(jīng)理可以在任何時候取消菜單修改功能。如果菜單已經(jīng)發(fā)生了變更，則系統(tǒng)會請求對取消進行確認(rèn)假設(shè)1.對Process Impact公司的每一個工作日都創(chuàng)建一個菜單，包括按照計劃雇員要在公司加班的周末和節(jié)假日3 需求規(guī)格說明書3.1 引言1.目標(biāo)軟件需求規(guī)

24、格說明描述了“自助食堂訂餐系統(tǒng)（Cafeteria Ordering System，COS）”1.0版本的軟件功能性需求和非功能性需求。這一文檔計劃由實現(xiàn)和驗證系統(tǒng)正確功能的項目團隊成員來使用。除非在其他地方另有說明，這里指定的所有需求都具有高優(yōu)先級，而且都要在版本1.0中加以實現(xiàn)。2.項目范圍和產(chǎn)品特性“自助食堂訂餐系統(tǒng)”允許Process Impact公司雇員向公司的自助食堂在線訂餐，并送餐到公司內(nèi)的指定地點。詳細(xì)的項目描述請參見Cafeteria Ordering System Vision and Scope Document（自助食堂訂餐系統(tǒng)前景和范圍文檔）1。文檔中這一部分的標(biāo)題為

25、“初始版本和后續(xù)版本的范圍”，列出了按照進度計劃在這一版本中實現(xiàn)的全部或部分特性。3.參考文獻(l) Karl Wiegers FE%W1Cafeterla Ordering System ViSIon and Scope Document, EWli# cesSI/projects/COS/COS=viSIon-and_scope.doc(2) Karl Wiegers BT#P9 Process Impact Intranet Development standard HR.# 1.3, EWlitE cesSI/corpor

26、ate/standards/PI intranet=dev=std.doc(3) Christine Zambito BT#Pi Process Impact BuSIness Rules CataIog, EWil#cesSI/corporate/po1icies/PI-buSIness=ru1es.doc(4) Christine Zambito BT#P9 Process Impact Internet Application USEr InterfaceStandard HR # 2.0 , E Wl tt # cesSI

27、/corporate/standards/ PI=internet=ui=std.doc3.2 綜合描述1. 產(chǎn)品前景“自助食堂訂餐系統(tǒng)”是一個新系統(tǒng)，它取代了當(dāng)前在Process Impact公司自助食堂內(nèi)以手工方式和電話方式預(yù)定和選擇午餐的過程。圖1是一幅關(guān)聯(lián)圖，它演示了1.0版本的外部實體和系統(tǒng)接口。期望系統(tǒng)演化若干個版本，最終與本地若干飯店的Internet訂餐服務(wù)相連接，并提供信用卡和借記卡授權(quán)服務(wù)。圖1 “自助食堂訂膂系統(tǒng)”版本1.0的關(guān)聯(lián)圖2. 產(chǎn)品功能在此只需要概略地總結(jié)。僅從業(yè)務(wù)層面陳述本軟件產(chǎn)品所應(yīng)具有的主要功能，在描述功能時應(yīng)該針對每一項需求準(zhǔn)確地描述其各項規(guī)格說明。如果

28、存在引起誤解的可能，在陳述本軟件產(chǎn)品主要功能的作用領(lǐng)域時，也需要對應(yīng)陳述本軟件產(chǎn)品的非作用領(lǐng)域，以利讀者理解本軟件產(chǎn)品。為了很好地組織產(chǎn)品功能，使每個讀者都容易理解，可以采用列表的方法給出。也可以采用圖形方式，將主要的需求分組以及它們之間的聯(lián)系使用數(shù)據(jù)流程圖的頂層圖或類圖進行表示，這種表示方法是很有用的。3.用戶類和用戶特性用戶類描述顧客（優(yōu)先考慮） 顧客是俄勒岡州Clackamas的Process Impact公司的雇員，他們希望從公司的自助食堂訂餐并能送貨上門。大約有600名潛在顧客，其中估計有400人預(yù)計平均每星期每人使用“自助食堂訂餐系統(tǒng)”4次（來源：根據(jù)當(dāng)前自助食堂的使用數(shù)據(jù)）。顧客

29、有時會由于團體事件或有來賓而訂好多份餐。估計90%的訂單是通過公司的內(nèi)聯(lián)網(wǎng)而提交的，10%的訂單是從家里提交的。所有的顧客都可以從他們的辦公室訪問公司內(nèi)聯(lián)網(wǎng)。有些顧客希望建立固定的訂餐，每天送同樣的飯菜，或者是自動送當(dāng)日特色菜。顧客必須能推翻對某一具體日期的訂餐自助食堂工作人員 Process Impact公司自助食堂目前雇傭了大約20名“自助食堂工作人員”，他們從“自助食堂訂餐系統(tǒng)”接受訂單，準(zhǔn)備飯菜，對要送貨上門的飯菜進行打包，打印送餐說明，并請求送餐。自助食堂工作人員需要接受培訓(xùn).學(xué)會如何使用計算機、Web瀏覽器和“自助食堂訂餐系統(tǒng)”菜單經(jīng)理菜單管理人是自助食堂的雇員，也許就是食堂經(jīng)理，

30、他負(fù)責(zé)建立并維護自助食堂有效的食物條目日常菜單，和某一天每一個食物條目的有效時間。有些飯菜不適宜于送貨上門。菜單管理人也要定義食堂的每日特色菜。菜單經(jīng)理還需要定期編輯菜單，以反映計劃內(nèi)的無效的或價格發(fā)生了變更的食物送餐人員當(dāng)自助食堂工作人員準(zhǔn)備訂單所要求送的飯菜時，他們打印送餐說明并向送餐人員發(fā)出送餐請求，送餐人員是食堂的其他雇員或者是承包人。送餐人員為每餐都要挑選食物和準(zhǔn)備送餐說明，并將它送到顧客手里。送餐人員與系統(tǒng)的主要交互將是偶爾重新打印送餐說明并確認(rèn)餐已送到（或沒有送到）顧客手中4.運行環(huán)境（Operation Environment，OE）OE-1：“自助食堂訂餐系統(tǒng)”的操作將通過如

31、下的Web瀏覽器來完成：Microsoft Internet Explorer版本5.0和6.0，Netscape Communicator版本4.7和Netscape版本6和版本7。OE-2：“自助食堂訂餐系統(tǒng)”將運行在一個服務(wù)器中，該服務(wù)器運行當(dāng)前由公司批準(zhǔn)的Red Hat Linux版本和Apache HTTP Server。OE-3：“自助食堂訂餐系統(tǒng)”將允許用戶通過公司內(nèi)聯(lián)網(wǎng)來訪問，如果用戶被授權(quán)在公司的外部穿過防火墻來訪問，那么用戶也可以在家里通過Internet來訪問該系統(tǒng)。5.設(shè)計和實現(xiàn)的約束條件（constraint）CO-1：系統(tǒng)的設(shè)計、編碼和維護文檔將遵照Process

32、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代碼將遵照HTML4.0標(biāo)準(zhǔn)。CO-4：所有腳本都用Perl語言來編寫。6.用戶文檔（User Documentation，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)不會將采用這一模板的

33、訂餐訂單存儲到數(shù)據(jù)庫中，也不會將這種訂單提交給自助食堂。7.假設(shè)（ASsumption）和依賴（DEpendency）AS-1：只要是要求員工在崗的每一個公司工作日，自助食堂在早餐、午餐和晚餐時都會營業(yè)。DE-1：“自助食堂訂餐系統(tǒng)”的運行依賴于“薪資核算系統(tǒng)”所做出的變更，它接受用“自助食堂訂餐系統(tǒng)”訂餐的付費請求。DE-2：“自助食堂訂餐系統(tǒng)”的運行依賴于“自助食堂庫存系統(tǒng)”所做出的變更，當(dāng)接受“自助食堂訂餐系統(tǒng)”訂單后，它更新食物條目的有效性。3.3 外部接口需求1.用戶界面（User Interfaces，UI）UI-1：“自助食堂訂餐系統(tǒng)”的屏幕畫面將遵照Process Impact

34、 Internet Application User Interface standard（Process Impact公司的Internet應(yīng)用程序用戶界面標(biāo)準(zhǔn)）版本2.0 4。UI-2：系統(tǒng)對所顯示的每個HTML網(wǎng)頁都提供幫助鏈接，解釋如何使用這些網(wǎng)頁。UI-3：Web頁面的全部導(dǎo)航和食物條目選擇，除了綜合使用鼠標(biāo)和鍵盤共同完成外，還可以只通過鍵盤來單獨完成。2.硬件接口硬件接口還沒有確定。3.軟件接口（Software Interfaces，SI）SI-1： 自助食堂存貨系統(tǒng)。SI-1.1：“自助食堂訂餐系統(tǒng)”通過程序界面向“自助食堂存貨系統(tǒng)”發(fā)送所訂的食物條目數(shù)量。SI-1.2：“自助

35、食堂訂餐系統(tǒng)”將輪詢“自助食堂存貨系統(tǒng)”，以確定請求的食物是否有效。SI-1.3：當(dāng)“自助食堂存貨系統(tǒng)”通知“自助食堂訂餐系統(tǒng)”某一指定的食物條目已經(jīng)沒貨時，“自助食堂訂餐系統(tǒng)”會從當(dāng)日的菜單中將該食物條目刪除。SI-2：“薪資管理系統(tǒng)”。“自助食堂訂餐系統(tǒng)”通過程序界面與“薪資管理系統(tǒng)”進行通信，完成下面這些操作：SI-2.1：允許顧客注冊從工資中扣除餐費的付費方式。SI-2.2：允許顧客取消所注冊的從工資中扣除餐費的付費方式。SI-2.3：檢查顧客是否注冊了從工資中扣除餐費的付費方式。SI -2.4：為所購餐提交付費請求。SI-2.5：退還全部或部分上面的費用，其原因是因為顧客拒絕了所訂的

36、餐，或?qū)λ粷M意，也可能是因為沒能按照送餐說明完成送餐任務(wù)。4.通信接口（Communications Interfaces，CI）CI-1:“自助食堂訂餐系統(tǒng)”將向顧客發(fā)送電子郵件消息，以確認(rèn)收到訂單、價格和送餐說明。CI-2：“自助食堂訂餐系統(tǒng)”將向顧客發(fā)送電子郵件消息，以報告訂單接受之后訂單中或送餐中存在的問題。3.4 系統(tǒng)特性需要進行詳細(xì)的需求記錄，詳細(xì)列出與該系統(tǒng)功能相關(guān)的詳細(xì)功能需求，并且，唯一地標(biāo)識每一項需求。這是必須提交給用戶的軟件功能，使得用戶可以使用所提供的功能執(zhí)行服務(wù)或者使用所指定的使用實例執(zhí)行任務(wù)。描述軟件產(chǎn)品如何響應(yīng)己知的出錯條件、非法輸入、非法動作。如果每一項功能需

37、求都能用一項，也只需要用一項測試用例就能進行驗證，那么就可以認(rèn)為功能需求已經(jīng)適當(dāng)?shù)剡M行描述了。如果某項功能需求找不到合適的測試用例，或者必須使用多項測試用例才能驗證，那么該項功能需求的描述必然存在某些問題。功能需求是根據(jù)系統(tǒng)功能，即軟件產(chǎn)品所提供的主要服務(wù)來組織的?？梢酝ㄟ^使用實例、運行模式、用戶類、對象類或者功能等級來組織這部分內(nèi)容，也可以便用這些元素的組合?？偠灾?，必須選擇一種是讀者容易理解預(yù)期產(chǎn)品的組織方案。用簡短的語句說明功能的名稱，例如：“1. 訂餐”。按照組織的順序，逐條闡述系統(tǒng)功能。無論說明的是何種功能，都應(yīng)該針對該系統(tǒng)功能重復(fù)敘述（1）（3）這三個部分?？梢酝ㄟ^各種方式來組織

38、這一部分內(nèi)容，例如采用：使用實例、運行模式、用戶類、對象類、功能等級等，也可以采用它們的組合。其最終目的是，讓讀者容易理解即將開發(fā)的軟件產(chǎn)品。一般來說，每個使用實例都對應(yīng)一個系統(tǒng)功能，因而按照使用實例來組織內(nèi)容比較容易讓用戶理解。對應(yīng)一些被共享的獨立使用實例，可以定義一些公用系統(tǒng)功能。必須特別注意的是，在綜合描述部分“產(chǎn)品的功能”中描述的全部需求，以及它們的規(guī)格說明；必須在某個系統(tǒng)功能描述中有所反映，而且不應(yīng)重復(fù)。1.訂餐（1）描述和優(yōu)先級自助食堂的顧客其身份得到驗證之后，他們就可以訂餐，并可以要求送到公司內(nèi)指定的地點，也可以去食堂內(nèi)就餐。只要所訂餐還沒有準(zhǔn)備好，顧客就可以取消或改變訂單。優(yōu)先

39、級為高。（2）刺激/響應(yīng)序列刺激：顧客請求訂餐，可以是一份或多份。響應(yīng)：系統(tǒng)向顧客詢問訂餐細(xì)節(jié)、付費方式和送餐說明。刺激：顧客請求改變訂單。響應(yīng)：如果訂單狀態(tài)是“已接受”，則系統(tǒng)允許用戶編輯以前的訂單。刺激：顧客請求取消訂單。響應(yīng)：如果訂單狀態(tài)是 “已接受”，則系統(tǒng)取消訂單。（3）功能性需求Order.Place登錄到“自助食堂訂餐系統(tǒng)”的顧客可以通過該系統(tǒng)訂餐，訂一份或多份都可以O(shè)rder.Place.Register系統(tǒng)將確認(rèn)訂餐的顧客所注朋的付費方式是從工資中扣除餐費的付費方式Order.Plaoe.Register.No如果顧客沒有注冊從工資中扣除餐費的付費方式，那么系統(tǒng)將為顧窯提供一

40、些選擇方案，顧客可以現(xiàn)在注冊并繼續(xù)進行訂餐，也可以訂餐后去食堂月餐（不送餐），或者還可以退出“自助食堂訂餐系統(tǒng)”O(jiān)rder.Place.Date系統(tǒng)將提示顧客輸入用餐日期（請參見BR-8）Order.Place.Date.Cutoff如果訂餐日期是當(dāng)前日期，而訂餐時間已過了截止時間，那么系統(tǒng)將通知顧客訂餐太晚了，今天己不能訂餐了。顧客可以政變訂餐日期，或者也可以取消訂單Order.Deliver.SElect顧客將指定只是訂餐或者是還要求送餐Order.Deliver.Location如果訂單是要求送餐，雨且送餐日仍有有效的送餐時間，那么顧客將提供一個有效的送餐地點Order.Deliver.

41、Notimes如果送餐日己沒有有效的送餐時間，那么系統(tǒng)將通知顧客。顧客既可以取消訂單，也可以選擇去食堂就餐Order.Deliver.Times系統(tǒng)將顯示訂餐日剩余的有效送餐時間。顧客可以從顯示的送餐時間中選擇一個時間，也可以將訂單改為去食堂就餐，或者也可以取消訂單Order.Menu.Date系統(tǒng)將顯示指定日期的菜單OrderMenu.Available當(dāng)前日期的菜單只顯示至少在自助食堂存貨的一個供應(yīng)間中有貨的那些食物Order.Units.Food系統(tǒng)允許顧客表明他希望訂餐的每個菜單條目的份數(shù)Order,Units.Multiple系統(tǒng)允許用戶訂多份同樣的餐，但其最大份數(shù)只能是訂單中的所有

42、菜單條目的有效份數(shù)中的最小值Order.Units.TooMany如杲顧客所訂的某一菜單項的份數(shù)超過了目前自助食堂存貨中的數(shù)量，那么系統(tǒng)將通知顧客他所能訂的食物條目的最大份數(shù)Order.Units.Change如果食堂存貨中的食物不能滿足顧客的數(shù)量要求，那么顧客可以改變所訂的份數(shù)，也可以改變所訂的同樣餐的份數(shù)，或者也可以取消訂餐Order.Confrm.Display如果顧客表明他不希望再訂食物了，那么系統(tǒng)將顯示他所訂的食物條目，每一食物條目的單價，以及應(yīng)該支付多少費用，具體計算方法請參見BR-12Order.Conf1rm.Prompt系統(tǒng)提示顧客確認(rèn)訂餐的訂單Order.Conf1rm.N

43、ot如果顧客不確認(rèn)訂單，那么顧客既可以編輯訂單，也可以取消訂單Order.Conf1rm.More顧客可以通過系統(tǒng)再另外訂餐，可以是同一天的，也可以不是同一天的。BR-3和BR-4與在單一訂單中訂多份餐有關(guān)系Ordcr.Pay.Method當(dāng)顧客表明他已經(jīng)完成訂餐時，系統(tǒng)會要求用戶逸擇一種付費方式。Order.Pay.Deliver請參見BR-llOrder.Pay.Pickup如果顧客選擇在食堂就餐，那么系統(tǒng)會讓顧客選擇付費方式，可以是從工資中扣除，也可以是在就餐時支付現(xiàn)金Order.Pay.Details系統(tǒng)將顯示所訂的食物條日、費用、付費方式和送貨說明Order.Pay.Conf1rm顧

44、客可以確認(rèn)訂單，也可以請求編輯訂單，或者也可以請求取消訂單Order.pay.Congfirm.Deduct 如果顧客確認(rèn)訂單，并選擇了從工資中扣除餐費的付費方式，那么系統(tǒng)將向“薪資核算系統(tǒng)”發(fā)出一個付費請求Ordcr.Bg.Confrm.OK如果付費請求被接受，那么系統(tǒng)將顯示一條消息來確認(rèn)訂單已接受，消息中包括從工資中扣除餐費的事務(wù)號Mer.Pay.Con8rm.NG如果付費請求被拒絕，系統(tǒng)將顯示一條消息來說明拒絕的理由。顧客可以取消訂單，也可以改為現(xiàn)金支付方式，或者是去食堂就餐Order.Done當(dāng)顧客確認(rèn)了訂單時，系統(tǒng)會將下面幾步作為一個事務(wù)來處理Ordcr.Done.Store為該訂單

45、分配下一個有效的訂單號并存儲這一訂單，其訂單的初始狀態(tài)設(shè)置為“已接受”O(jiān)rder,DoncInventory向“自助食堂存貨系統(tǒng)”發(fā)送一條消息，包括訂單中每種食物條目的份數(shù)Order.Done.Menu更新當(dāng)前訂單的訂餐日期所對應(yīng)的菜單，從自助食堂存貨中扣除訂單中的食物條目數(shù)量，以反映所有食物條目的最新狀況Order.Done,Times更新訂餐日期中剩余的有效送餐時間Order.Done.Patron向顧客發(fā)送電子郵件消息，消息包括訂單和支付費用的有關(guān)信息Order.Done.Cateteria向自助食堂工作人員發(fā)送電子郵件消息，消息包括訂單的有關(guān)信息Order.Done.Failure如果

46、Order.Donc中的任何一步不成功，則系統(tǒng)將回滾事務(wù)，通知用戶訂單不成功，并說明失敗的原因Order.Previous.Period系統(tǒng)允許顧客瀏覽前6個月的全部訂餐。 【優(yōu)先級為中】Order.Previous.Reorder顧客可以重新預(yù)訂他前6個月所訂過的任一餐，只要新訂率中的所有食物條目在用餐日的菜單中有效即可。 【優(yōu)先級為中】（本范例不提供改變和取消訂餐訂單的功能性需求）2.創(chuàng)建、瀏覽、修改和刪除訂餐（該范例不提供細(xì)節(jié)）3.注冊訂餐的付費方式（該范例不提供細(xì)節(jié)）4.請求送餐（該范例不提供細(xì)節(jié)）5.創(chuàng)建、瀏覽、修改和刪除自助食堂菜單（該范例不提供細(xì)節(jié)）3.5 其他非功能性需求1.性

47、能（PErformance）需求PE-1：在當(dāng)?shù)貢r間早晨8點到10點這一段高峰期間，系統(tǒng)將能適應(yīng)400個用戶，平均每個會話估計持續(xù)8分鐘。PE-2：系統(tǒng)生成的所有Web頁面，通過速率為40KBps的調(diào)制解調(diào)器在不超過10秒的時間內(nèi)可以全部下載下來。PE-3：用戶提交了查詢之后，對查詢的響應(yīng)時間不能超過7秒，在此時間內(nèi)要將查詢結(jié)果顯示在屏幕上。PE-4：用戶向系統(tǒng)提交信息后，系統(tǒng)將在4秒內(nèi)向用戶顯示確認(rèn)消息。2.防護性需求防護性需求還沒有確定。3.安全性（SEcurity）需求SE -1：所有涉及功能信息或個人身份信息的網(wǎng)絡(luò)事務(wù)，都要按照BR-33進行加密操作。SE-2：除瀏覽菜單外，用戶必須登

48、錄到“自助食堂訂餐系統(tǒng)”才能完成其他所有操作。SE-3：顧客的登錄受計算機系統(tǒng)訪問控制策略的限制，具體請參照BR-35。SE-4：自助食堂的工作人員，只有那些授權(quán)為菜單經(jīng)理的成員，才能通過系統(tǒng)創(chuàng)建或編輯菜單，具體請參照BR-24。SE-5：只有那些被授權(quán)可以在家訪問公司內(nèi)聯(lián)網(wǎng)的用戶，才可以在公司以外的地方使用“自助食堂訂餐系統(tǒng)”。SE-6：系統(tǒng)只允許顧客瀏覽他們自己以前的訂單，而不能瀏覽其他顧客的訂單。4.軟件質(zhì)量屬性Availability（可用性）-1：“自助食堂訂餐系統(tǒng)”將對公司內(nèi)聯(lián)網(wǎng)的用戶可用，撥號用戶在當(dāng)?shù)貢r間早晨5點到晚上12點99.9%的時間可用，當(dāng)?shù)貢r間晚上12點到早晨5點則9

49、5%的時間可用。Robustness（健壯性）-1：如果在訂單得到確認(rèn)或取消之前，用戶和系統(tǒng)的連接中斷，那么用戶應(yīng)該能通過“自助食堂訂餐系統(tǒng)”恢復(fù)不完整的訂單。5 業(yè)務(wù)規(guī)則下面是單獨業(yè)務(wù)規(guī)則（Business Rule，BR）類別的一個范例：ID規(guī)則定義規(guī)則類型靜態(tài)或動態(tài)來 源BR-1送餐的時間窗口是15分鐘，以每一刻鐘開始事實靜態(tài)自助食堂經(jīng)理BR-2送餐必須在當(dāng)?shù)貢r間上午10點和下午2點之間完成約束動態(tài)自助食堂經(jīng)理BR-3一張訂單上的所有飯菜必須送到同一個地點約束靜態(tài)自助食堂經(jīng)理BR-4一張訂單上的所有飯菜必須采用同一種付費方式來支付費用約束靜態(tài)自助食堂經(jīng)理BR-8訂餐必須在用餐日前14天內(nèi)預(yù)約束動態(tài)自助食堂經(jīng)理BR-11如果是送餐上門的訂單，則顧客必須通過從工資中扣除餐費的方式來支付餐費約束動態(tài)自助食堂