軟件需求分析說明書審查規(guī)范0002

1、軟件需求分析說明書審查規(guī)范文件編號受控編號版本1.0編制日期生效日期密級編制審核批準文件修改控制修改記錄編號修改狀態(tài)修改位置及內容修改人審核人批準人修改日期1.2.3.4.5.6.7.8.9目錄軟件需求分析說明書審查規(guī)范 1目錄 31. 引言 31.1. 目的 31.2. 適用范圍 31.3. 使用說明 42. 參考資料 43. 術語定義 44. 質量要求 64.1. 完整性 64.1.1. 整體內容完整性 64.1.2. 需求項信息完整性 84.2. 正確性 94.3. 一致性 104.4. 可驗證性 104.5. 劃分優(yōu)先級 104.6. 可用性 115. 附件 115.1.一些編寫建議

2、115.2. 部分參考實例 125.2.1.需求項表格 125.2.2. 表格需求項實例 135.2.3. 優(yōu)先級劃分方法實例 145.2.4. 軟件需求分析說明書模板 151. 引言1.1.目的軟件需求分析說明書在軟件開發(fā)、測試、質量保證、項目管理以及相關項目功能中起 著重要作用。為了保證軟件說明書對質量，本文檔具體描述了軟件需求分析說明書所 要包含的內容及其編制所要達到的質量要求。1.2.適用范圍作為軟件需求分析說明書是否可以進入正式評審的審查標準，符合該規(guī)范的可以 提交正式需求評審；作為測試人員編制軟件需求分析說明書審查列表的依據；作為開發(fā)人員編制軟件需求分析說明書的指導原則；1.3.使

3、用說明本文重點對需求分析說明書的內容進行要求，對表示方式、方法未明確提出要求對視 為不作要求；本文中的“應”、“必須”含義等同； 本文中的“現(xiàn)有的技術水平”指與該需求相關的行業(yè)中，可獲得的、已知的、可實際 運用于生產的、可信的、經過驗證的所有技術；本文中的需求可行性以通過審核發(fā)布的項目可行性研究報告為依據；2. 參考資料GB 8566 計算機軟件開發(fā)規(guī)范 受控編號？GB 8567 計算機軟件產品開發(fā)文件編制指南受控編號？GB/T 11457 軟件工程術語 受控編號？Systematic Software Testing Rick D.Craig, Stefan P.Jaskiel Artech

4、 House Publishers 2002-05-1統(tǒng)一軟件開發(fā)過程 RUP2000 手冊 IBM 公司 2000 年3. 術語定義GB/T 11457 所列術語和下列定義適用于本文需求系統(tǒng)必須符合的條件或具備的功能軟件需求分析 軟件需求分析的基本任務是準確地定義未來系統(tǒng)的目標，確定為了滿足用戶的需求， 系統(tǒng)必須做什么。需求分析包括需求獲取和需求規(guī)約：需求獲取是系統(tǒng)分析員通過學習以 及同用戶的交往，熟悉用戶領域的知識，并獲得對未來系統(tǒng)的需求；需求規(guī)約是系統(tǒng)分析 員在獲得了用戶的初步需求后，必須進行一致性分析和檢查，通過和用戶協(xié)商解決其中存 在的二義性和不一致性，并以一種規(guī)范的形式準確地表達用

5、戶的需求，形成軟件需求分析 說明書。軟件需求分析說明書 ( Software Requirements Specifications ，簡稱 SRS)： 軟件需求分析說明書(也稱軟件需求規(guī)格說明書、軟件需求分析報告)是軟件需求分 析階段得到的最終文檔，它以形式化的術語和表示對軟件的功能和性能進行詳細而具體的 描述。它是用戶和開發(fā)者之間的技術合同，是軟件設計、編碼階段的基礎,也是軟件測試和 驗收的依據。IEEE 軟件工程標準詞匯表 (1997 年)中定義為：(1) 用戶解決問題或達到目標所需的條件或權能 (Capability) 。(2) 系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)范或其它正式規(guī)定文檔所

6、需具有的條 件或權能。(3) 一種反映上面 (1)或 (2)所描述的條件或權能的文檔說明。軟件質量IEEE 610.12-1990 中定義： 一個系統(tǒng)、組件或過程滿足客戶或用戶的需求的程度，或滿足期望值的程度。 ( “The degree to which a system, component, or processmeets customer or user needs or expectations.”ISO/IEC9126 中定義： 與軟件產品滿足規(guī)定的和隱含的需求的能力有關的特征或特性的全體。 ( The totality of features and characteristic

7、s of a software product that bear on its ability to satisfy stated or implied needs.)軟件質量保證 軟件質量保證，是為保證產品和服務充分滿足消費者要求的質量而進行的有計劃、有 組織的活動。軟件質量保證是面向消費者的活動，是為了使產品實現(xiàn)用戶要求的功能，站 在用戶立場上來掌握產品質量的。軟件的質量保證就是向用戶及社會提供滿意的高質量的 軟件產品。可跟蹤性 指如果每一個需求的來源、變更歷史是清晰的，在進一步產生和改變文件編制時，可 以方便地引證每一個需求，則該軟件需求分析說明書就是可追蹤的?？尚薷男?指如果一個軟件

8、需求分析說明書的結構和風格在需求有必要改變時是易于實現(xiàn)的、且 改變后仍然完整、一致的，那么這個軟件需求分析說明書就是可修改的?？尚行?指在規(guī)定的時間限制和開銷下、在特定的環(huán)境制約下、利用現(xiàn)有的技術、工具、資源 和人力下，需求必須是可以實現(xiàn)的。具體包括： 技術可行，現(xiàn)有的技術水平能夠實現(xiàn)所有的需求； 財政可行，有足夠的資金來實現(xiàn)所有的需求，且實現(xiàn)的成本在可接受的范圍內； 時間可行，在指定的時間范圍內能夠實現(xiàn)所有的需求； 資源可行，有足夠的人力、物力來實現(xiàn)所有的需求；驗證標準 用以判斷需求被實現(xiàn)后，實現(xiàn)的結果是否正確的依據。如：對于性能需求，其驗證標 準是具體的性能指標；對于功能需求，其驗證標準是

9、詳細的功能效果描述。軟件測試軟件測試是為了度量和提高被測軟件的質量，對測試件進行工程設計、實施和維護的 整個生命周期過程。 ( Systematic Software Testing )統(tǒng)一建模語言( UML )UML(Unified Modeling Language)是一種構建軟件系統(tǒng)和文檔的通用可視化建模語言。UML 能與所有的開發(fā)方法一同使用，可用于軟件開發(fā)的整個生命周期。 UML 能表達系統(tǒng) 的靜態(tài)結構和動態(tài)信息，并能管理復雜的系統(tǒng)模型，便于軟件團隊之間的合作開發(fā)。UML不是編程語言，但支持 UML 語言的工具可以提供從 UML 到各種編程語言的代碼生成，也 可以提供從現(xiàn)有程序逆向構

10、建 UML 模型。統(tǒng)一軟件開發(fā)過程( RUP)RUP 是一個通用軟件過程框架，可以應付種類廣泛的軟件系統(tǒng)、不同的應用領域、不 同的組織類型、不同的性能水平和不同的項目規(guī)模。“統(tǒng)一過程”是基于構件的，這意味 著利用它開發(fā)的軟件系統(tǒng)是由構件構成的，構件之間通過定義良好的接口相互聯(lián)系。在準 備軟件系統(tǒng)的所有藍圖的時候，“統(tǒng)一過程”使用的是“統(tǒng)一建模語言(Unified ModelingLanguage )”。事實上， UML 是“統(tǒng)一過程”的有機組成部分它們是被同步開發(fā)的。 然而，真正使“統(tǒng)一過程”與眾不同的方面可以用三個句話來表達：它是用例驅動的、以 基本架構為中心的、迭代式和增量性的。4. 質量

11、要求合格的軟件需求分析說明書要滿足如下質量要求：1. 完整性2. 正確性3. 一致性4. 可驗證性5. 劃分優(yōu)先級6. 可用性下面我們分別對每個質量要求進行說明，同時給出如何滿足各質量要求的指導原則。4.1.完整性完整性是指軟件需求分析說明書包含了所有應該具備的內容，由于不同的產品、項目 對軟件需求分析說明書所應該具備的內容的不完全相同，因此為了便于指導和規(guī)范文檔的 實際編制本規(guī)范將完整性劃分為整體內容完整性、需求項信息完整性，并針對不同的內容 提出不同的要求，包括：必須和可選，具體如下：4.1.1. 整體內容完整性整體內容完整性用以確定整個軟件需求分析說明書中具體應該包含的內容和不應該包含的

12、內容，具體如下：一 . 需求沒有遺漏：確定在需求分析說明書編制的過程中，沒有遺漏需求獲取階段所確定的需求。其依據為包括但不僅限于通過正式審核的下列文檔：1. 市場調研報告；2. 用戶需求調查報告；3. 需求分析討論會議記錄；二 . 需求沒有冗余：即同一需求不能在軟件需求分析說明書中出現(xiàn)多次；三 . 不存在超出產品 /項目范圍的需求；四 . 除設計上的特殊限制之外，軟件需求分析說明書中不描述任何設計、驗證或項目管理 細節(jié)的內容；五 . 軟件需求分析說明書必須包含下列信息：1. 目的：說明編寫這份軟件需求說明書的目的，指出預期的讀者2. 概述：說明產品或項目的背景、總體描述、功能、用戶特點、一般的

13、設計約束。 只描述影響產品及其需求的一般因素，不說明具體的需求，概述的目的僅近使需 求更易于理解3. 參考資料：列出軟件需求分析說明書中所有用得到的所有參考資料，詳細說明參 考資料的來源。內容包括但不僅限于：1) 本產品或項目的經過核準的計劃任務書或合同、上級機關的批文；2) 本項目的其他已通過審核的正式文檔；3) 企業(yè)內部制定發(fā)布的正式管理文件；4) 各處引用的資料，如出版物、網絡資訊；5) 所要用到的軟件開發(fā)標準。且每條參考資料記錄中包含的內容及格式應滿足下列要求(按類型劃分) ：1) 專著出版物：主要作者，其他作者，書名，版本，出版地：出版者，出 版年；2) 連續(xù)期刊出版物：文獻作者，文

14、獻其他作者，題名，刊物名，版本：在 原文獻中的位置；3) 標準：標準編，號標準名，公司受控編號；4) 文件：文件編號，文件名，文件版本5) 網絡資訊：作者，題名，發(fā)布網址，發(fā)布時間4. 術語定義：提供軟件需求分析說明書中用到的專門術語、縮寫詞、縮略語的定義， 這部分信息可以在軟件需求分析說明書中用一個單獨章節(jié)提供或者在附錄中提供， 也可以參考其他的文件；5. 具體需求：指產品或項目必須符合的條件或具備的功能，它包括軟件開發(fā)者在建 立設計時需要的全部細節(jié)。由于不同的產品項目其需求都不同，同樣的需求可以 使用不同的分類方法進行劃分，因此這里只列舉一種比較常見的劃分方式，并分 別加以說明：1) 功能

15、需求：規(guī)定了在不考慮物理約束的情況下必須能夠執(zhí)行的動作，也 就是通常所說的系統(tǒng)能夠做什么；2) 性能需求：是指軟件功能在執(zhí)行過程中需要滿足的強加條件，如速度、 效率、可使用性、響應時間、各種軟件功能的恢復時間、吞吐能力、精 度、頻率、資源用途等等兼容性、3) 屬性需求：可擴展性、可移植性、穩(wěn)定性、可靠性、可維護性、安全性、可配置性、 可服務性、 可安裝性，可國際化性、可用性、易 用性等方面的考慮因素；4) 外部接口：用戶、硬件、其他軟件和其他硬件的相互關系，如用戶接口、 軟件接口、硬件接口、通信接口等；5) 強加的設計限制或實現(xiàn)約束：說明必須遵守的技術標準和軟硬件限制等 設計約束，如對硬件配置

16、的要求，對軟件開發(fā)環(huán)境限制、運行環(huán)境限制 和對軟件設計、實現(xiàn)方式的限制；六 . 包含第五條中未列出但應該在需求分析說明書中說明的其他信息；七. 對第五條第 5 項具體需求所列出的幾類需求的要求：除功能需求總是必須的，其他需 求根據產品 /項目的實際情況進行增刪裁減。4.1.2. 需求項信息完整性需求項信息完整性指每個具體需求的需求項需包含足夠的信息，來詳細明確定義需求 要實現(xiàn)的目標。一 . 針對每個需求項，必須包含下列信息：1. 唯一標識：跟蹤需求的標簽，唯一且不變，建議采用“項目編號+內部編號”方式，使需求編號在整個公司的范圍內都是唯一點；2. 簡要描述：簡單描述該需求要實現(xiàn)的目標；3. 類

17、型：需求的類型，依所采用的需求分類方法而定；4. 目的：簡要描述提出該需求的目的，若很明顯則寫“略”；5. 來源：誰提出該需求，具體可以是人 (客戶、用戶、員工 )、公司、市場等；6. 詳細描述：對該需求的詳細說明；由于不同類型的需求其詳細描述需要包含的內 容不同，下面分類列出具體應該包含的詳細內容：A. 功能性需求：應包括但不僅限于下列內容：1) 環(huán)境要求： 完成該功能應該滿足的具體條件，如什么狀態(tài)、情況、什么樣的 軟硬件環(huán)境下可以進行該功能；2) 觸發(fā)者： 使該功能的執(zhí)行的人或事，可以是用戶或是其他系統(tǒng)、定時事件等；3) 輸入： 描述該功能執(zhí)行前及在執(zhí)行過程中所有輸入的詳細定義。例如：數據

18、類型輸入的數據類型、數量、度量單位、源、時間關系、要求(如 精度)；功能執(zhí)行過程中的用戶操作控制信息； 事件類型輸入的事件時間設定； 所引用的用以統(tǒng)一定義輸入的有關接口說明或接口控制文件。4) 處理 ：該功能所完成的任務，即從輸入到輸出的變換操作過程。具體應包括 但不僅限于下列內容：對所有輸入的有效性檢查； 對所有輸入的處理順序、流程或方法，即系統(tǒng)如何把輸入變換成相應輸 出，可以使用自然語言、方程式、數學算法、邏輯操作、圖、表、狀態(tài)機等 不同表達方式進行描述；對所有輸出有效性的檢查；對所有異常情況的處理及響應，例如，溢出、通信故障、要所有非合法 輸入的響應、錯誤處理等；5）輸出： 描述該功能所

19、有最終預期結果的詳細定義。如： 數據類型輸出的數據類型、數量、目的地、度量單位、時間關系、要求 （如精度）；所引用的用以統(tǒng)一定義輸出的有關接口說明或接口控制文件。B. 非功能性需求：性能需求： 達到該性能需求必須具備的條件或限制； 該性能需求所要達到的具體性能指標屬性需求： 可移植性：具體列出要求可以移植的平臺； 可維護性：具體列出保證可維護性的具體的方法； 安全性：具體列出要達到的安全級別或安全程度； 兼容性：具體列出所要兼容的平臺或軟硬件環(huán)境； 可測試性：具體列出保證該特性的具體功能和方法； 可靠性：具體列出可靠性的要求，如無故障運行時間；設計限制： 列出所有的限制因素，如： 需遵守的技術

20、標準 : 列出所有必須遵守的技術標準、規(guī)范（包含標準名、標 準編號、版本號（或發(fā)布日期） 、公司受控編號信息） 硬件限制：列出所有影響或約束產品 / 項目的硬件成分，如運行環(huán)境最低配置；軟件限制：列出所有影響或約束產品 / 項目的軟件成分，如軟件開發(fā)環(huán)境限制、 軟件運行環(huán)境限制和軟件的設計限制；7. 驗證標準：用于該需求被實現(xiàn)后，檢查實現(xiàn)結果是否符合需求，給測試或用戶提 供明確的驗證依據。如：對于性能需求，列出具體的性能指標；對于功能需求， 給出詳細的實現(xiàn)效果；若驗證標準已包含在詳細描述中，則指明位置即可；8. 優(yōu)先級：用以表明該需求在產品 /項目中的重要程度及被實現(xiàn)代優(yōu)先順序，應定義 優(yōu)先級

21、的劃分方式，不同的產品 /項目可以采用不同的劃分方式；9. 依賴性：對其他需求的存在、變化的依賴，如列出本需求所引用的需求，若無任 何依賴，則寫“無”；. 包含第一條中未列出但應該在需求項中說明的其他信息；4.2.正確性正確性指對需求的定義必須是對的，它涵蓋了軟件需求分析說明書中所定義的需求與 用戶的實際需求是一致的、對需求內容的描述是明確、準確、精確和無歧義的。具體應滿 足但不僅限于下列要求：1. 每個需求與用戶的實際需求是一致，即正確表達了用戶的真正需求，可以使用讓 用戶確認的方式來保證；2. 內容的表達沒有錯誤，應滿足包括但不僅限于下列要求：1）使用正確的語法，拼寫，標點；2）無錯字和別

22、字；3）用詞貼確；3. 內容的表達無歧義，如同一讀者對同一表達通過不同的斷句方式得出多種正確的 理解；4. 無不一致的內容，詳見質量要求的“一致性”部分；5. 沒有因使用不明確的表述而存在可隨意發(fā)揮的內容，如：描述中出現(xiàn)了對于軟件 需求分析說明書作者自己很清楚但讀者并不清楚的主觀性詞語（除了已經對這些 詞語進行了明確的定義或引用說明） ，具體如：“待定”、“可能”、“即將”、“考慮” 、“最好”、 “最差”、 “一般情況”、 “特殊情況”、 “可以”、 “用戶友好性”， 易”，“簡單”，“快速”，“有效”，“幾個”，“藝術級”，“改善的”，“最大”，“最 小”、“較好”、 “較差”、“等等”、

23、 “一期實現(xiàn)”、 “根據需要”、 “如果可能”、 “高級”4.3.一致性一致性指不存在內容相互矛盾的地方。具體應滿足但不僅限于下列要求：1. 同一內容在整個軟件需求分析說明書中其內涵和外延都是一致的；2. 不存在一個需求與軟件的其他需求或高級別的系統(tǒng)需求發(fā)生沖突的現(xiàn)象；3. 術語的定義與標準、規(guī)范、行業(yè)用戶的定義一致；4. 需求被引用時的含義與定義時的含義保持一致；5. 術語被引用時的含義與定義時的含義保持一致，若某一術語在某一特殊的行文中使用時具有多種歧義，那么對該術語的每種含義作出解釋并指出其適用場合；4.4.可驗證性可驗證性指針對每項需求能夠找到某種方法，通過這種方法可以驗證該需求被實現(xiàn)

24、后 其實現(xiàn)的結果是否正確。具體應滿足但不僅限于下列要求：1. 每個需求必須是可行的，只有可行的才是可驗證的；2. 每個需求項必須有明確的驗證標準，且驗證標準在現(xiàn)有的技術水平下是可測量的 （能夠找到某種測試方法，通過這種方法可以明確判斷出是否已經達到預期指定 的要求），如對于該性能需求，必須給出已經量化的所要達到的具體性能指標，且 這些指標都能用某種方法或工具進行測量；3. 需求必須一致的，詳見質量要求的“一致性”部分；4. 需求必須是明確的，詳見質量要求的“正確性”部分的第 5 條；如任何需求如果 說“產品 /項目 將要支持什么”是不可驗證的，必須具體說明何時支持，如何支持。4.5.劃分優(yōu)先級

25、劃分優(yōu)先級指為每個需求指定實施的優(yōu)先級，以表明它在產品/項目中的重要程度及被實現(xiàn)代優(yōu)先順序。具體應滿足下列要求：10為整個軟件需求分析說明書制定統(tǒng)一的優(yōu)先級劃分標準； 為每個需求指定一個定義好的優(yōu)先級；4.6.可用性可用性指需求分析說明書易于閱讀、理解、修改、跟蹤、維護、管理。具體應滿足但 不僅限于下列要求：1. 每項需求都有唯一標識，便于需求的引用、跟蹤、管理；2. 明確指出需求間的相互關聯(lián)，便于在需求變更時確定變更所涉及和影響的范圍；3. 明確說明每項需求的來源和目的，便于需求的跟蹤、維護；4. 維護記錄需求的修改歷史，便于需求的跟蹤、管理；5. 對需求進行良好的組織，如：對需求進行類型劃

26、分后將相關的需求分組，對需求 進行層次劃分使需求的結構層次清晰，為需求建立目錄表、索引等。便于需求的 閱讀、管理。6. 編寫、排版風格保持統(tǒng)一，便于閱讀、理解，如對于同一類的內容，使用相同的 表達方式和方法；7. 最終產品的每一個特性用某一術語描述，便于修改、維護；8. 部分編寫格式符合一定的標準，如參考文檔記錄的格式；9. 需求的粗細粒度要保持一致；如軟件需求分析說明書中同時存在下列的需求描述， 其粒度是不一致的：“用戶信息對于紅色合法的顏色代碼應是R ”、“對于綠色合法的顏色代碼應是 G”、“產品應能對來自語音編輯指示做出反應”，最后一個需求 應作為一個子系統(tǒng)而不應作為單個的功能性需求。1

27、0. 對多處出現(xiàn)的同一內容進行統(tǒng)一的定義再分別引用，便于修改、維護和保證一致 性；11. 避免將多個需求合成單個需求12. 若選擇使用某軟件需求分析說明書的模板，應：1) 如果模板中的個別章節(jié)或部分內容不適用，則在軟件需求分析說明書中要保 留章節(jié)號并寫明不適用，不應刪除；2) 若模板中未列出，但需求中應該包含的信息，應在文檔中適當的位置添加；5. 附件此章節(jié)內容只作為開發(fā)人員編寫軟件需求分析說明書時的一個參考，不作為審查的內 容。5.1.一些編寫建議列出軟件需求分析說明書編寫過程中的一些建議，這些建議的描述相對比較定性、籠 統(tǒng)。1. 使用書面語，不用口語；2. 使用短句和短的段落；113. 采

28、用主動語氣；4. 語句表達方式的風格要保持一致；5. 編寫時盡量使用定量、客戶的詞匯，少用定性、主觀的詞匯；6. 編寫時以開發(fā)人員的角度來審視是否需要軟件需求分析說明書作者的額外解釋和 幫助開發(fā)人員才能理解需求，才能進行設計和實現(xiàn)？若是，則需進一步細化需求；7. 避免一個段落中包含了多個的需求；8. 對軟件需求說明書進行持續(xù)的改進，軟件產品的開發(fā)過程中，在項目的開始階段 可能無法詳細說明某些細節(jié)，在開發(fā)過程中可能發(fā)現(xiàn)缺陷、缺點和錯誤，一旦發(fā) 現(xiàn)需立即按需求管理的流程改進；9. 不要在一個需求中使用“和”/ “或”，以避免將多個需求合成一個需求；10. 使用需求編制、管理工具，以便需求的變更并保

29、證變更后需求仍是一致的、保證 編寫和排版風格的統(tǒng)一；11. 盡量使用形式化的語言，少用自然語言，如使用UML、圖、表格、規(guī)范化模型等方式。因為盡管自然語言是豐富多彩的，但不易精確表述；12. 編寫時重點在其表達的內容，不要拘泥于表達的形式，形式可以多種多樣，合適 易用的即可；13. 建議選擇使用適用的需求分析說明書模板；列出軟件需求分析說明書中部分重要內容的常見表示方式的例子。521需求項表格使用表格的方式來組織需求項的內容。唯一標識【必須】（跟蹤需求的標簽，唯一且不變，建議采用（項目編號+文檔的內部編號）方式，使需求編號在整個公司的范圍內都是唯一點）簡要描述【必須】（簡單描述該需求要實現(xiàn)的目

30、標 ）類型【必須】（需求的類型，依需求的分類方法而定 ）目的【可選】（簡要描述提出該需求的目的，若很明顯則寫“略”）來源【必須】（指誰提出該需求，具體可以是人 （客戶、用戶、員工）、公司、 市場等）詳細描述【必須】對該需求的詳細說明；由于不冋類型的需求其詳細描述需要包 含的內容不同，下面分類列出具體應該包含的詳細內容：A.功能性需求：應包括但不僅限于下列內容：1. 環(huán)境要求：完成該功能應該滿足的具體條件，如什么狀態(tài)、情況、 什么樣的軟硬件環(huán)境下可以進行該功能；2. 觸發(fā)者：使該功能的執(zhí)行的人或事，可以是用戶或是其他系統(tǒng)、定 時事件等；3. 輸入：描述該功能執(zhí)行前及在執(zhí)行過程中所有輸入的詳細定義

31、。例如：數據類型輸入的數據類型、數量、度量單位、源、時間關系、 要求（如精度）；功能執(zhí)行過程中的用戶操作控制信息； 事件類型輸入的事件時間設定； 所引用的用以統(tǒng)一定義輸入的有關接口說明或接口控制文件。4. 處理：該功能所完成的任務，即從輸入到輸出的變換操作過程。具 體應包括但不僅限于下列內容：對所有輸入的有效性檢查； 對所有輸入的處理順序、流程或方法，即系統(tǒng)如何把輸入變換成相應輸出，可以使用自然語言、方程式、數學算法、邏輯操作、 圖、表、狀態(tài)機等不冋表達方式進仃描述；對所有輸出有效性的檢查；對所有異常情況的處理及響應，例如，溢出、通信故障、要所 有非合法輸入的響應、錯誤處理等；5. 輸出：描述

32、該功能所有最終預期結果的詳細定義。如：數據類型輸出的數據類型、數量、目的地、度量單位、時間關系、要求（如精度）； 所引用的用以統(tǒng)一定義輸出的有關接口說明或接口控制文件。非功能性需求： 性能需求：達到該性能需求必須具備的條件或限制；該性能需求所要達到的具體性能指標 屬性需求：可移植性：具體列出要求可以移植的平臺；可維護性：具體列出保證可維護性的具體的方法；安全性：具體列出要達到的安全級別或安全程度； 兼容性：具體列出所要兼容的平臺或軟硬件環(huán)境； 可測試性：具體列出保證該特性的具體功能和方法； 設計限制：列出具體的限制因素；驗證標準【必須】（用于后期檢查實現(xiàn)結果是否符合需求，給測試或用戶提供明 確的驗證依據。如：對于性能需求，列出具體的性能指標；對于功能需 求，給出詳細的實現(xiàn)效果；若驗證標準已包含在詳細描述中，則指明位 置即呵。）優(yōu)先級【必須】（用以表明該需求在產品/項目中的重要程度及被實現(xiàn)代優(yōu)先順 序，應定義優(yōu)先級的劃分方式，不冋的產品 /項目可以采用不冋的劃分 方式）依賴性【必須】（對其他需求的存在、變化的依賴，如列出本需求所引用的需 求，若無任