用戶需求說明書與需求規(guī)格說明書的區(qū)別

精品文檔精品文檔PAGEPAGE1迎下載用戶需求說明書與需求規(guī)格說明書的區(qū)別1（期望），從開發(fā)、測試的角度去講產品功能。2文檔。缺點：層次越多，信息損失的越多，誤解的概率就越大。權衡的結果：基本上是依據項目的規(guī)模而定。3任何意義了。4、最新的做法UML用例、場景描述和事件―應表，既可面向客戶，又可面向開發(fā)設計；一個什么功能，以滿足某個方面的需求?！鞠嚓P知識】（含矩陣圖）、需求變更狀態(tài)跟蹤表，以及與其配套產出的指南型文件。“需求開發(fā)”的文檔大體上包含需求規(guī)格說明書，需求規(guī)格說明書檢查表，需求開發(fā)指南等。重點是體現出產品要滿足哪些功能，哪些是重點、熱點。中有標準的模板，重點是站在客戶的角度講產品功能。業(yè)務需求（Businessrequirement）表示組織或客戶高層次的目標。業(yè)務希望達到的目標。使用前景和范圍（visionand文檔來記錄業(yè)務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（projectcharter或marketrequirement）文檔。用戶需求（userrequirement）描述的是用戶的目標，或用戶要求系統必須能完成的任務。用例、場景描述和事件――響應表都是表達用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統來做些什么。功能需求（functionalrequirement）規(guī)定開發(fā)人員必須在產品中實現的被稱作行為需求（behavīoralrequirement，因為習慣上總是用“應該”系統應該發(fā)送電子郵件來通知用戶已接受其預定”。功能求。產品特性，所謂特性feature，是指一組邏輯上相關的功能需求，它們?yōu)橐员阌脩裟軌驁?zhí)行某項任務。系統需求（systemrequirement）用于描述包含有多個子系統的產品（即系統）的頂級需求。系統可以只包含軟件系統，也可以既包含軟件又包含硬件子系統。人也可以是系統的一部分，因此某些系統功能可能要由人來承擔。業(yè)務規(guī)則包括企業(yè)方針、政府條例、工業(yè)標準、會計準則和計算方法等。業(yè)業(yè)務規(guī)則常常會限制誰能夠執(zhí)行某些特定用例，或者規(guī)定系統為符合相關規(guī)則必須實現某些特定功能。有時，功能中特定的質量屬性（通過功能實現）也源于業(yè)務規(guī)則。所以，對某些功能需求進行追溯時，會發(fā)現其來源正是一條特定的業(yè)務規(guī)則。SRS預期特性。SRS我們一般把它當作文檔，其實，SRS還可以是包含需求信息的數據庫或電子表格；或者是存儲在商業(yè)需求管理工具中的信息；而對于小型項目，甚至可能是一疊索引卡片。開發(fā)、測試、質量保證、項目管理和其他相關的項目功能都要用到SRS。（有時也叫行為需求。ITSMITISO20000IT業(yè)務需求：是要完組織的使命，達成組織的愿景的各個業(yè)務流程和業(yè)務單元具有的需求。業(yè)務需求服從于組織需求。用戶需求：用戶級的需求，是在業(yè)務級的需求下，各個崗位協作完成業(yè)務分需求。。所有的用它在范圍內嗎？”。如果答案是肯定的，則該需求屬于需求規(guī)格說求的負責人或投資管理人來決定：是否擴大項目范圍以容納新的需求。這是一個可能影響項目進度和預算的商業(yè)決策。非功能需求，包括性能指標和對質量屬性的描述。質量屬性（qualityattribute）對產品的功能描述作了補充，它從不同方面描述了產品的各種特性。這些特性包括可用性、可移植性、完整性、效率和健壯性，它們對用的質量屬性，它規(guī)定了業(yè)務需求中“有效（efficiently”是產品的靈魂，對于個人級的軟件這么說或許很恰當，當對于企業(yè)級甚至是行業(yè)級的產品，其靈魂有兩個：一個是產品帶給用戶的價值，另一個是產品的品質，簡單的說，就是價值和品質。但其成為一個產品的前提應該是滿足約束，否則就不應該設計、開發(fā)、進入市場而成為一個垃圾。用戶需求、功能需求區(qū)別。簡單的就是：用戶需求。用戶需要在應用系統業(yè)務流程，表格樣式等。功能需求。將用戶需求歸類分解為計算