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

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

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

3、要求；本文中的“應”、“必須”含義等同；本文中的“現(xiàn)有的技術(shù)水平”指與該需求相關(guān)的行業(yè)中，可獲得的、已知的、可實際運用于生產(chǎn)的、可信的、經(jīng)過驗證的所有技術(shù)；本文中的需求可行性以通過審核發(fā)布的項目可行性研究報告為依據(jù)；2. 參考資料 GB 8566 計算機軟件開發(fā)規(guī)范 受控編號？GB 8567 計算機軟件產(chǎn)品開發(fā)文件編制指南 受控編號？GB/T 11457 軟件工程術(shù)語 受控編號？Systematic Software Testing Rick D.Craig, Stefan P.JaskielArtech House Publishers 2002-05-1 統(tǒng)一軟件開發(fā)過程RUP2000手冊

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

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

6、一個系統(tǒng)、組件或過程滿足客戶或用戶的需求的程度，或滿足期望值的程度。（“The degree to which a system, component, or process meets customer or user needs or expectations.” ISO/IEC9126中定義：與軟件產(chǎn)品滿足規(guī)定的和隱含的需求的能力有關(guān)的特征或特性的全體。（The totality of features and characteristics of a software product that bear on its ability to satisfy stated or impli

7、ed needs.）軟件質(zhì)量保證軟件質(zhì)量保證，是為保證產(chǎn)品和服務充分滿足消費者要求的質(zhì)量而進行的有計劃、有組織的活動。軟件質(zhì)量保證是面向消費者的活動，是為了使產(chǎn)品實現(xiàn)用戶要求的功能，站在用戶立場上來掌握產(chǎn)品質(zhì)量的。軟件的質(zhì)量保證就是向用戶及社會提供滿意的高質(zhì)量的軟件產(chǎn)品?？筛櫺灾溉绻恳粋€需求的來源、變更歷史是清晰的，在進一步產(chǎn)生和改變文件編制時，可以方便地引證每一個需求，則該軟件需求分析說明書就是可追蹤的。可修改性指如果一個軟件需求分析說明書的結(jié)構(gòu)和風格在需求有必要改變時是易于實現(xiàn)的、且改變后仍然完整、一致的，那么這個軟件需求分析說明書就是可修改的。可行性指在規(guī)定的時間限制和開銷下、在特定

8、的環(huán)境制約下、利用現(xiàn)有的技術(shù)、工具、資源和人力下，需求必須是可以實現(xiàn)的。具體包括：技術(shù)可行，現(xiàn)有的技術(shù)水平能夠?qū)崿F(xiàn)所有的需求；財政可行，有足夠的資金來實現(xiàn)所有的需求，且實現(xiàn)的成本在可接受的范圍內(nèi)；時間可行，在指定的時間范圍內(nèi)能夠?qū)崿F(xiàn)所有的需求；資源可行，有足夠的人力、物力來實現(xiàn)所有的需求；驗證標準用以判斷需求被實現(xiàn)后，實現(xiàn)的結(jié)果是否正確的依據(jù)。如：對于性能需求，其驗證標準是具體的性能指標；對于功能需求，其驗證標準是詳細的功能效果描述。軟件測試軟件測試是為了度量和提高被測軟件的質(zhì)量，對測試件進行工程設計、實施和維護的整個生命周期過程。(Systematic Software Testing)統(tǒng)一

9、建模語言（UML）UML(Unified Modeling Language)是一種構(gòu)建軟件系統(tǒng)和文檔的通用可視化建模語言。UML 能與所有的開發(fā)方法一同使用，可用于軟件開發(fā)的整個生命周期。UML 能表達系統(tǒng)的靜態(tài)結(jié)構(gòu)和動態(tài)信息，并能管理復雜的系統(tǒng)模型，便于軟件團隊之間的合作開發(fā)。UML 不是編程語言，但支持UML 語言的工具可以提供從UML 到各種編程語言的代碼生成，也可以提供從現(xiàn)有程序逆向構(gòu)建UML 模型。統(tǒng)一軟件開發(fā)過程（RUP）RUP 是一個通用軟件過程框架，可以應付種類廣泛的軟件系統(tǒng)、不同的應用領域、不同的組織類型、不同的性能水平和不同的項目規(guī)模?！敖y(tǒng)一過程”是基于構(gòu)件的，這意味著利

10、用它開發(fā)的軟件系統(tǒng)是由構(gòu)件構(gòu)成的，構(gòu)件之間通過定義良好的接口相互聯(lián)系。在準備軟件系統(tǒng)的所有藍圖的時候，“統(tǒng)一過程”使用的是“統(tǒng)一建模語言（Unified Modeling Language ）”。事實上，UML 是“統(tǒng)一過程”的有機組成部分它們是被同步開發(fā)的。然而，真正使“統(tǒng)一過程”與眾不同的方面可以用三個句話來表達：它是用例驅(qū)動的、以基本架構(gòu)為中心的、迭代式和增量性的。4. 質(zhì)量要求合格的軟件需求分析說明書要滿足如下質(zhì)量要求：1. 完整性2. 正確性3. 一致性4. 可驗證性5. 劃分優(yōu)先級6. 可用性下面我們分別對每個質(zhì)量要求進行說明，同時給出如何滿足各質(zhì)量要求的指導原則。4.1. 完整性

11、 完整性是指軟件需求分析說明書包含了所有應該具備的內(nèi)容，由于不同的產(chǎn)品、項目對軟件需求分析說明書所應該具備的內(nèi)容的不完全相同，因此為了便于指導和規(guī)范文檔的實際編制本規(guī)范將完整性劃分為整體內(nèi)容完整性、需求項信息完整性，并針對不同的內(nèi)容提出不同的要求，包括：必須和可選，具體如下：4.1.1. 整體內(nèi)容完整性整體內(nèi)容完整性用以確定整個軟件需求分析說明書中具體應該包含的內(nèi)容和不應該包含的內(nèi)容，具體如下：一. 需求沒有遺漏：確定在需求分析說明書編制的過程中，沒有遺漏需求獲取階段所確定的需求。其依據(jù)為包括但不僅限于通過正式審核的下列文檔：1. 市場調(diào)研報告；2. 用戶需求調(diào)查報告；3. 需求分析討論會議記

12、錄；二. 需求沒有冗余：即同一需求不能在軟件需求分析說明書中出現(xiàn)多次；三. 不存在超出產(chǎn)品/項目范圍的需求；四. 除設計上的特殊限制之外，軟件需求分析說明書中不描述任何設計、驗證或項目管理細節(jié)的內(nèi)容；五. 軟件需求分析說明書必須包含下列信息：1. 目的：說明編寫這份軟件需求說明書的目的，指出預期的讀者2. 概述：說明產(chǎn)品或項目的背景、總體描述、功能、用戶特點、一般的設計約束。只描述影響產(chǎn)品及其需求的一般因素，不說明具體的需求，概述的目的僅近使需求更易于理解3. 參考資料：列出軟件需求分析說明書中所有用得到的所有參考資料，詳細說明參考資料的來源。內(nèi)容包括但不僅限于：1) 本產(chǎn)品或項目的經(jīng)過核準的

13、計劃任務書或合同、上級機關(guān)的批文；2) 本項目的其他已通過審核的正式文檔；3) 企業(yè)內(nèi)部制定發(fā)布的正式管理文件；4) 各處引用的資料，如出版物、網(wǎng)絡資訊；5) 所要用到的軟件開發(fā)標準。 且每條參考資料記錄中包含的內(nèi)容及格式應滿足下列要求（按類型劃分）：1) 專著出版物：主要作者，其他作者，書名，版本，出版地：出版者，出版年；2) 連續(xù)期刊出版物：文獻作者，文獻其他作者，題名，刊物名，版本：在原文獻中的位置；3) 標準：標準編，號標準名，公司受控編號；4) 文件：文件編號，文件名，文件版本5) 網(wǎng)絡資訊：作者，題名，發(fā)布網(wǎng)址，發(fā)布時間4. 術(shù)語定義：提供軟件需求分析說明書中用到的專門術(shù)語、縮寫詞

14、、縮略語的定義，這部分信息可以在軟件需求分析說明書中用一個單獨章節(jié)提供或者在附錄中提供，也可以參考其他的文件；5. 具體需求：指產(chǎn)品或項目必須符合的條件或具備的功能，它包括軟件開發(fā)者在建立設計時需要的全部細節(jié)。由于不同的產(chǎn)品項目其需求都不同，同樣的需求可以使用不同的分類方法進行劃分，因此這里只列舉一種比較常見的劃分方式，并分別加以說明：1) 功能需求：規(guī)定了在不考慮物理約束的情況下必須能夠執(zhí)行的動作，也就是通常所說的系統(tǒng)能夠做什么；2) 性能需求：是指軟件功能在執(zhí)行過程中需要滿足的強加條件，如速度、效率、可使用性、響應時間、各種軟件功能的恢復時間、吞吐能力、精度、頻率、資源用途等等3) 屬性需

15、求：可擴展性、可移植性、穩(wěn)定性、可靠性、可維護性、 兼容性、 安全性、可配置性、 可服務性、 可安裝性，可國際化性、可用性、易用性等方面的考慮因素；4) 外部接口：用戶、硬件、其他軟件和其他硬件的相互關(guān)系，如用戶接口、軟件接口、硬件接口、通信接口等；5) 強加的設計限制或?qū)崿F(xiàn)約束：說明必須遵守的技術(shù)標準和軟硬件限制等設計約束，如對硬件配置的要求，對軟件開發(fā)環(huán)境限制、運行環(huán)境限制和對軟件設計、實現(xiàn)方式的限制；六. 包含第五條中未列出但應該在需求分析說明書中說明的其他信息；七. 對第五條第5項具體需求所列出的幾類需求的要求：除功能需求總是必須的，其他需求根據(jù)產(chǎn)品/項目的實際情況進行增刪裁減。4.1

16、.2. 需求項信息完整性需求項信息完整性指每個具體需求的需求項需包含足夠的信息，來詳細明確定義需求要實現(xiàn)的目標。一. 針對每個需求項，必須包含下列信息：1. 唯一標識：跟蹤需求的標簽，唯一且不變，建議采用“項目編號+內(nèi)部編號”方式，使需求編號在整個公司的范圍內(nèi)都是唯一點；2. 簡要描述：簡單描述該需求要實現(xiàn)的目標；3. 類型：需求的類型，依所采用的需求分類方法而定；4. 目的：簡要描述提出該需求的目的，若很明顯則寫“略”；5. 來源：誰提出該需求，具體可以是人(客戶、用戶、員工)、公司、市場等；6. 詳細描述：對該需求的詳細說明；由于不同類型的需求其詳細描述需要包含的內(nèi)容不同，下面分類列出具體

17、應該包含的詳細內(nèi)容：A. 功能性需求：應包括但不僅限于下列內(nèi)容：1) 環(huán)境要求：完成該功能應該滿足的具體條件，如什么狀態(tài)、情況、什么樣的軟硬件環(huán)境下可以進行該功能；2) 觸發(fā)者：使該功能的執(zhí)行的人或事，可以是用戶或是其他系統(tǒng)、定時事件等；3) 輸入：描述該功能執(zhí)行前及在執(zhí)行過程中所有輸入的詳細定義。例如：數(shù)據(jù)類型輸入的數(shù)據(jù)類型、數(shù)量、度量單位、源、時間關(guān)系、要求（如精度）； 功能執(zhí)行過程中的用戶操作控制信息；事件類型輸入的事件時間設定；所引用的用以統(tǒng)一定義輸入的有關(guān)接口說明或接口控制文件。4) 處理：該功能所完成的任務，即從輸入到輸出的變換操作過程。具體應包括但不僅限于下列內(nèi)容：對所有輸入的有

18、效性檢查；對所有輸入的處理順序、流程或方法，即系統(tǒng)如何把輸入變換成相應輸出，可以使用自然語言、方程式、數(shù)學算法、邏輯操作、圖、表、狀態(tài)機等不同表達方式進行描述；對所有輸出有效性的檢查；對所有異常情況的處理及響應，例如，溢出、通信故障、要所有非合法輸入的響應、錯誤處理等；5) 輸出：描述該功能所有最終預期結(jié)果的詳細定義。如：數(shù)據(jù)類型輸出的數(shù)據(jù)類型、數(shù)量、目的地、度量單位、時間關(guān)系、要求（如精度）； 所引用的用以統(tǒng)一定義輸出的有關(guān)接口說明或接口控制文件。B. 非功能性需求：性能需求：達到該性能需求必須具備的條件或限制；該性能需求所要達到的具體性能指標屬性需求：可移植性：具體列出要求可以移植的平臺；

19、可維護性：具體列出保證可維護性的具體的方法；安全性：具體列出要達到的安全級別或安全程度；兼容性：具體列出所要兼容的平臺或軟硬件環(huán)境；可測試性：具體列出保證該特性的具體功能和方法；可靠性：具體列出可靠性的要求，如無故障運行時間；設計限制：列出所有的限制因素，如：需遵守的技術(shù)標準: 列出所有必須遵守的技術(shù)標準、規(guī)范（包含標準名、標準編號、版本號（或發(fā)布日期）、公司受控編號信息）硬件限制：列出所有影響或約束產(chǎn)品/項目的硬件成分，如運行環(huán)境最低配置；軟件限制：列出所有影響或約束產(chǎn)品/項目的軟件成分，如軟件開發(fā)環(huán)境限制、軟件運行環(huán)境限制和軟件的設計限制；7. 驗證標準：用于該需求被實現(xiàn)后，檢查實現(xiàn)結(jié)果是

20、否符合需求，給測試或用戶提供明確的驗證依據(jù)。如：對于性能需求，列出具體的性能指標；對于功能需求，給出詳細的實現(xiàn)效果；若驗證標準已包含在詳細描述中，則指明位置即可；8. 優(yōu)先級：用以表明該需求在產(chǎn)品/項目中的重要程度及被實現(xiàn)代優(yōu)先順序，應定義優(yōu)先級的劃分方式，不同的產(chǎn)品/項目可以采用不同的劃分方式； 9. 依賴性：對其他需求的存在、變化的依賴，如列出本需求所引用的需求，若無任何依賴，則寫“無”；二. 包含第一條中未列出但應該在需求項中說明的其他信息；4.2. 正確性正確性指對需求的定義必須是對的，它涵蓋了軟件需求分析說明書中所定義的需求與用戶的實際需求是一致的、對需求內(nèi)容的描述是明確、準確、精確

21、和無歧義的。具體應滿足但不僅限于下列要求：1. 每個需求與用戶的實際需求是一致，即正確表達了用戶的真正需求，可以使用讓用戶確認的方式來保證；2. 內(nèi)容的表達沒有錯誤，應滿足包括但不僅限于下列要求：1) 使用正確的語法，拼寫，標點；2) 無錯字和別字；3) 用詞貼確；3. 內(nèi)容的表達無歧義，如同一讀者對同一表達通過不同的斷句方式得出多種正確的理解；4. 無不一致的內(nèi)容，詳見質(zhì)量要求的“一致性”部分；5. 沒有因使用不明確的表述而存在可隨意發(fā)揮的內(nèi)容，如：描述中出現(xiàn)了對于軟件需求分析說明書作者自己很清楚但讀者并不清楚的主觀性詞語（除了已經(jīng)對這些詞語進行了明確的定義或引用說明），具體如：“待定”、“

22、可能”、“即將”、“考慮”、“最好”、“最差”、“一般情況”、“特殊情況”、“可以”、“用戶友好性”，“容易”，“簡單”，“快速”，“有效”，“幾個”，“藝術(shù)級”，“改善的”，“最大”，“最小”、“較好”、“較差”、“等等”、“一期實現(xiàn)”、“根據(jù)需要”、“如果可能”、“高級”。4.3. 一致性 一致性指不存在內(nèi)容相互矛盾的地方。具體應滿足但不僅限于下列要求：1. 同一內(nèi)容在整個軟件需求分析說明書中其內(nèi)涵和外延都是一致的；2. 不存在一個需求與軟件的其他需求或高級別的系統(tǒng)需求發(fā)生沖突的現(xiàn)象；3. 術(shù)語的定義與標準、規(guī)范、行業(yè)用戶的定義一致；4. 需求被引用時的含義與定義時的含義保持一致；5. 術(shù)

23、語被引用時的含義與定義時的含義保持一致，若某一術(shù)語在某一特殊的行文中使用時具有多種歧義，那么對該術(shù)語的每種含義作出解釋并指出其適用場合；4.4. 可驗證性 可驗證性指針對每項需求能夠找到某種方法，通過這種方法可以驗證該需求被實現(xiàn)后其實現(xiàn)的結(jié)果是否正確。具體應滿足但不僅限于下列要求：1. 每個需求必須是可行的，只有可行的才是可驗證的；2. 每個需求項必須有明確的驗證標準，且驗證標準在現(xiàn)有的技術(shù)水平下是可測量的（能夠找到某種測試方法，通過這種方法可以明確判斷出是否已經(jīng)達到預期指定的要求），如對于該性能需求，必須給出已經(jīng)量化的所要達到的具體性能指標，且這些指標都能用某種方法或工具進行測量；3. 需求

24、必須一致的，詳見質(zhì)量要求的“一致性”部分；4. 需求必須是明確的，詳見質(zhì)量要求的“正確性”部分的第5條；如任何需求如果說“產(chǎn)品/項目將要支持什么”是不可驗證的，必須具體說明何時支持，如何支持。4.5. 劃分優(yōu)先級劃分優(yōu)先級指為每個需求指定實施的優(yōu)先級，以表明它在產(chǎn)品/項目中的重要程度及被實現(xiàn)代優(yōu)先順序。具體應滿足下列要求：為整個軟件需求分析說明書制定統(tǒng)一的優(yōu)先級劃分標準；為每個需求指定一個定義好的優(yōu)先級；4.6. 可用性可用性指需求分析說明書易于閱讀、理解、修改、跟蹤、維護、管理。具體應滿足但不僅限于下列要求：1. 每項需求都有唯一標識，便于需求的引用、跟蹤、管理；2. 明確指出需求間的相互關(guān)

25、聯(lián)，便于在需求變更時確定變更所涉及和影響的范圍；3. 明確說明每項需求的來源和目的，便于需求的跟蹤、維護；4. 維護記錄需求的修改歷史，便于需求的跟蹤、管理；5. 對需求進行良好的組織，如：對需求進行類型劃分后將相關(guān)的需求分組，對需求進行層次劃分使需求的結(jié)構(gòu)層次清晰，為需求建立目錄表、索引等。便于需求的閱讀、管理。6. 編寫、排版風格保持統(tǒng)一，便于閱讀、理解，如對于同一類的內(nèi)容，使用相同的表達方式和方法；7. 最終產(chǎn)品的每一個特性用某一術(shù)語描述，便于修改、維護；8. 部分編寫格式符合一定的標準，如參考文檔記錄的格式；9. 需求的粗細粒度要保持一致；如軟件需求分析說明書中同時存在下列的需求描述，

26、其粒度是不一致的：“用戶信息對于紅色合法的顏色代碼應是R”、“對于綠色合法的顏色代碼應是G”、“產(chǎn)品應能對來自語音編輯指示做出反應”，最后一個需求應作為一個子系統(tǒng)而不應作為單個的功能性需求。10. 對多處出現(xiàn)的同一內(nèi)容進行統(tǒng)一的定義再分別引用，便于修改、維護和保證一致性；11. 避免將多個需求合成單個需求12. 若選擇使用某軟件需求分析說明書的模板，應：1) 如果模板中的個別章節(jié)或部分內(nèi)容不適用，則在軟件需求分析說明書中要保留章節(jié)號并寫明不適用，不應刪除；2) 若模板中未列出，但需求中應該包含的信息，應在文檔中適當?shù)奈恢锰砑樱?. 附件此章節(jié)內(nèi)容只作為開發(fā)人員編寫軟件需求分析說明書時的一個參考

27、，不作為審查的內(nèi)容。5.1. 一些編寫建議列出軟件需求分析說明書編寫過程中的一些建議，這些建議的描述相對比較定性、籠統(tǒng)。1. 使用書面語，不用口語；2. 使用短句和短的段落；3. 采用主動語氣；4. 語句表達方式的風格要保持一致；5. 編寫時盡量使用定量、客戶的詞匯，少用定性、主觀的詞匯；6. 編寫時以開發(fā)人員的角度來審視是否需要軟件需求分析說明書作者的額外解釋和幫助開發(fā)人員才能理解需求，才能進行設計和實現(xiàn)？若是，則需進一步細化需求；7. 避免一個段落中包含了多個的需求；8. 對軟件需求說明書進行持續(xù)的改進，軟件產(chǎn)品的開發(fā)過程中，在項目的開始階段可能無法詳細說明某些細節(jié)，在開發(fā)過程中可能發(fā)現(xiàn)缺

28、陷、缺點和錯誤，一旦發(fā)現(xiàn)需立即按需求管理的流程改進；9. 不要在一個需求中使用“和”/“或”，以避免將多個需求合成一個需求；10. 使用需求編制、管理工具，以便需求的變更并保證變更后需求仍是一致的、保證編寫和排版風格的統(tǒng)一；11. 盡量使用形式化的語言，少用自然語言，如使用UML、圖、表格、規(guī)范化模型等方式。因為盡管自然語言是豐富多彩的，但不易精確表述；12. 編寫時重點在其表達的內(nèi)容，不要拘泥于表達的形式，形式可以多種多樣，合適易用的即可；13. 建議選擇使用適用的需求分析說明書模板；5.2. 部分參考實例列出軟件需求分析說明書中部分重要內(nèi)容的常見表示方式的例子。5.2.1. 需求項表格 使

29、用表格的方式來組織需求項的內(nèi)容。唯一標識【必須】(跟蹤需求的標簽，唯一且不變，建議采用(項目編號+文檔的內(nèi)部編號)方式，使需求編號在整個公司的范圍內(nèi)都是唯一點)簡要描述【必須】(簡單描述該需求要實現(xiàn)的目標) 類型【必須】(需求的類型，依需求的分類方法而定)目的【可選】(簡要描述提出該需求的目的，若很明顯則寫“略”)來源【必須】(指誰提出該需求，具體可以是人(客戶、用戶、員工)、公司、市場等)詳細描述【必須】對該需求的詳細說明；由于不同類型的需求其詳細描述需要包含的內(nèi)容不同，下面分類列出具體應該包含的詳細內(nèi)容：A. 功能性需求：應包括但不僅限于下列內(nèi)容：1. 環(huán)境要求：完成該功能應該滿足的具體條

30、件，如什么狀態(tài)、情況、什么樣的軟硬件環(huán)境下可以進行該功能；2. 觸發(fā)者：使該功能的執(zhí)行的人或事，可以是用戶或是其他系統(tǒng)、定時事件等；3. 輸入：描述該功能執(zhí)行前及在執(zhí)行過程中所有輸入的詳細定義。例如：數(shù)據(jù)類型輸入的數(shù)據(jù)類型、數(shù)量、度量單位、源、時間關(guān)系、要求（如精度）； 功能執(zhí)行過程中的用戶操作控制信息；事件類型輸入的事件時間設定；所引用的用以統(tǒng)一定義輸入的有關(guān)接口說明或接口控制文件。4. 處理：該功能所完成的任務，即從輸入到輸出的變換操作過程。具體應包括但不僅限于下列內(nèi)容：對所有輸入的有效性檢查；對所有輸入的處理順序、流程或方法，即系統(tǒng)如何把輸入變換成相應輸出，可以使用自然語言、方程式、數(shù)學

31、算法、邏輯操作、圖、表、狀態(tài)機等不同表達方式進行描述；對所有輸出有效性的檢查；對所有異常情況的處理及響應，例如，溢出、通信故障、要所有非合法輸入的響應、錯誤處理等；5. 輸出：描述該功能所有最終預期結(jié)果的詳細定義。如：數(shù)據(jù)類型輸出的數(shù)據(jù)類型、數(shù)量、目的地、度量單位、時間關(guān)系、要求（如精度）； 所引用的用以統(tǒng)一定義輸出的有關(guān)接口說明或接口控制文件。非功能性需求：性能需求：達到該性能需求必須具備的條件或限制；該性能需求所要達到的具體性能指標屬性需求：可移植性：具體列出要求可以移植的平臺；可維護性：具體列出保證可維護性的具體的方法；安全性：具體列出要達到的安全級別或安全程度；兼容性：具體列出所要兼容的平臺或軟硬件環(huán)境；可測試性：具體列出保證該特性的具體功能和方法；設計限制：列出具體的限制因素；驗證標準【必須】（用于后期檢查實現(xiàn)結(jié)果是否符合需求，給測試或用戶提供明確的驗證依據(jù)。如：對于性能需求，列出具體的性能指標；對于功能需求，給出詳細的實現(xiàn)效果；若驗證標準已包含在詳細描述中，則指明位置即可。）優(yōu)先級【必須】(用以表明該需求在產(chǎn)品/項目中的重要程度及被實現(xiàn)代優(yōu)先順序，應定義優(yōu)先級的劃分方式，不同的產(chǎn)品/項目可以采用不同的劃分方式)依賴性【必須】(對其他需求的存在、變化的依賴，如列出本需求所引用的需求，若無任何依賴，則寫“無”。)