軟件需求分析使用說明審查規(guī)范標(biāo)準(zhǔn)

1、!-軟件需求分析說明書審查規(guī)范文件編號受控編號版本1.0編制日期生效日期密級編制審核批準(zhǔn)文件修改控制修改記錄編號修改狀態(tài)修改位置及內(nèi)容修改人審核人批準(zhǔn)人修改日期1.2.3.4.5.6.7.8.目錄軟件需求分析說明書審查規(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. 部分參考實例

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

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

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

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

6、說明。軟件質(zhì)量IEEE 610.12-1990 中定義：一個系統(tǒng)、組件或過程滿足客戶或用戶的需求的程度，或滿足期望值的程度。(“Thedegree to which a system, comp onent, or process meets customer or user n eeds or expectati on s.”ISO/IEC9126 中定義：與軟件產(chǎn)品滿足規(guī)定的和隱含的需求的能力有關(guān)的特征或特性的全體。(The totality offeatures and characteristics of a software product that bear on its abil

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

8、求分析說明書就是可修改的?？尚行灾冈谝?guī)定的時間限制和開銷下、在特定的環(huán)境制約下、禾U用現(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)所有的需求；驗證標(biāo)準(zhǔn)用以判斷需求被實現(xiàn)后，實現(xiàn)的結(jié)果是否正確的依據(jù)。如：對于性能需求，其驗證標(biāo) 準(zhǔn)是具體的性能指標(biāo)；對于功能需求，其驗證標(biāo)準(zhǔn)是詳細(xì)的功能效果描述。軟件測試軟件測試是為了度量和提高被測軟件的質(zhì)量，對測試件進(jìn)行工程設(shè)計、實施和維護(hù)的 整個生

9、命周期過程。(Systematic Software Testi ng)統(tǒng)一建模語言(UML )UML( Un ified Modeli ng Lan guage)是一種構(gòu)建軟件系統(tǒng)和文檔的通用可視化建模語言。UML能與所有的開發(fā)方法一同使用，可用于軟件開發(fā)的整個生命周期。UML能表達(dá)系統(tǒng)的靜態(tài)結(jié)構(gòu)和動態(tài)信息， 并能管理復(fù)雜的系統(tǒng)模型，便于軟件團(tuán)隊之間的合作開發(fā)。UML不是編程語言，但支持 UML語言的工具可以提供從 UML到各種編程語言的代碼生成，也可 以提供從現(xiàn)有程序逆向構(gòu)建 UML模型。統(tǒng)一軟件開發(fā)過程(RUP)RUP是一個通用軟件過程框架，可以應(yīng)付種類廣泛的軟件系統(tǒng)、不同的應(yīng)用領(lǐng)域、不

10、 同的組織類型、不同的性能水平和不同的項目規(guī)模?！敖y(tǒng)一過程”是基于構(gòu)件的，這意味著利用它開發(fā)的軟件系統(tǒng)是由構(gòu)件構(gòu)成的，構(gòu)件之間通過定義良好的接口相互聯(lián)系。在準(zhǔn)備軟件系統(tǒng)的所有藍(lán)圖的時候，“統(tǒng)一過程”使用的是“統(tǒng)一建模語言(Uni fied Modeli ngLanguage )”。事實上，UML是“統(tǒng)一過程”的有機(jī)組成部分一一它們是被同步開發(fā)的。 然而，真正使“統(tǒng)一過程”與眾不同的方面可以用三個句話來表達(dá)：它是用例驅(qū)動的、以基 本架構(gòu)為中心的、迭代式和增量性的。4. 質(zhì)量要求合格的軟件需求分析說明書要滿足如下質(zhì)量要求：1. 完整性2. 正確性3. 一致性4. 可驗證性5. 劃分優(yōu)先級6. 可用

11、性下面我們分別對每個質(zhì)量要求進(jìn)行說明，同時給出如何滿足各質(zhì)量要求的指導(dǎo)原則。4.1. 完整性完整性是指軟件需求分析說明書包含了所有應(yīng)該具備的內(nèi)容，由于不同的產(chǎn)品、項目 對軟件需求分析說明書所應(yīng)該具備的內(nèi)容的不完全相同，因此為了便于指導(dǎo)和規(guī)范文檔的 實際編制本規(guī)范將完整性劃分為整體內(nèi)容完整性、需求項信息完整性，并針對不同的內(nèi)容 提出不同的要求，包括：必須和可選，具體如下：4.1.1. 整體內(nèi)容完整性整體內(nèi)容完整性用以確定整個軟件需求分析說明書中具體應(yīng)該包含的內(nèi)容和不應(yīng)該包 含的內(nèi)容，具體如下：一.需求沒有遺漏：確定在需求分析說明書編制的過程中，沒有遺漏需求獲取階段所確定的需求。其依據(jù)為包括但不僅

12、限于通過正式審核的下列文檔：1. 市場調(diào)研報告；2. 用戶需求調(diào)查報告；3. 需求分析討論會議記錄；二.需求沒有冗余：即同一需求不能在軟件需求分析說明書中出現(xiàn)多次；三不存在超出產(chǎn)品/項目范圍的需求；四.除設(shè)計上的特殊限制之外，軟件需求分析說明書中不描述任何設(shè)計、驗證或項目管理 細(xì)節(jié)的內(nèi)容；五軟件需求分析說明書必須包含下列信息：1. 目的：說明編寫這份軟件需求說明書的目的，指出預(yù)期的讀者2. 概述：說明產(chǎn)品或項目的背景、總體描述、功能、用戶特點(diǎn)、一般的設(shè)計約束。 只描述影響產(chǎn)品及其需求的一般因素，不說明具體的需求，概述的目的僅近使需 求更易于理解3. 參考資料：列出軟件需求分析說明書中所有用得到

13、的所有參考資料，詳細(xì)說明參 考資料的來源。內(nèi)容包括但不僅限于：1）本產(chǎn)品或項目的經(jīng)過核準(zhǔn)的計劃任務(wù)書或合同、上級機(jī)關(guān)的批文；2）本項目的其他已通過審核的正式文檔；3）企業(yè)內(nèi)部制定發(fā)布的正式管理文件；4）各處引用的資料，如出版物、網(wǎng)絡(luò)資訊；5）所要用到的軟件開發(fā)標(biāo)準(zhǔn)。且每條參考資料記錄中包含的內(nèi)容及格式應(yīng)滿足下列要求（按類型劃分）：1）專著出版物：主要作者，其他作者，書名，版本，出版地：出版者，出 版年；2）連續(xù)期刊出版物：文獻(xiàn)作者，文獻(xiàn)其他作者，題名，刊物名，版本：在 原文獻(xiàn)中的位置；3）標(biāo)準(zhǔn)：標(biāo)準(zhǔn)編，號標(biāo)準(zhǔn)名，公司受控編號；4）文件：文件編號，文件名，文件版本5）網(wǎng)絡(luò)資訊：作者，題名，發(fā)布網(wǎng)

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

15、響應(yīng)時間、各種軟件功能的恢復(fù)時間、吞吐能力、精 度、頻率、資源用途等等3）屬性需求：可擴(kuò)展性、可移植性、穩(wěn)定性、可靠性、可維護(hù)性、兼容性、安全性、可配置性、可服務(wù)性、可安裝性，可國際化性、可用性、易用性等方面的考慮因素；4）外部接口：用戶、硬件、其他軟件和其他硬件的相互關(guān)系，如用戶接口、軟件接口、硬件接口、通信接口等；5）強(qiáng)加的設(shè)計限制或?qū)崿F(xiàn)約束：說明必須遵守的技術(shù)標(biāo)準(zhǔn)和軟硬件限制等 設(shè)計約束，如對硬件配置的要求，對軟件開發(fā)環(huán)境限制、運(yùn)行環(huán)境限制 和對軟件設(shè)計、實現(xiàn)方式的限制；六. 包含第五條中未列出但應(yīng)該在需求分析說明書中說明的其他信息；七. 對第五條第5項具體需求所列出的幾類需求的要求：除

16、功能需求總是必須的，其他需 求根據(jù)產(chǎn)品/項目的實際情況進(jìn)行增刪裁減。4.1.2. 需求項信息完整性需求項信息完整性指每個具體需求的需求項需包含足夠的信息，來詳細(xì)明確定義需求 要實現(xiàn)的目標(biāo)。一.針對每個需求項，必須包含下列信息：1. 唯一標(biāo)識：跟蹤需求的標(biāo)簽，唯一且不變，建議采用“項目編號+內(nèi)部編號”方式，使需求編號在整個公司的范圍內(nèi)都是唯一點(diǎn)；2. 簡要描述：簡單描述該需求要實現(xiàn)的目標(biāo)；3. 類型：需求的類型，依所采用的需求分類方法而定；4. 目的：簡要描述提出該需求的目的，若很明顯則寫“略”；5. 來源：誰提出該需求，具體可以是人（客戶、用戶、員工）、公司、市場等；6. 詳細(xì)描述：對該需求的

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

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

19、能需求所要達(dá)到的具體性能指標(biāo) 屬性需求：可移植性：具體列出要求可以移植的平臺；可維護(hù)性：具體列出保證可維護(hù)性的具體的方法；安全性：具體列出要達(dá)到的安全級別或安全程度；兼容性：具體列出所要兼容的平臺或軟硬件環(huán)境； 可測試性：具體列出保證該特性的具體功能和方法； 可靠性：具體列出可靠性的要求，如無故障運(yùn)行時間； 設(shè)計限制：列出所有的限制因素，如：需遵守的技術(shù)標(biāo)準(zhǔn)：列出所有必須遵守的技術(shù)標(biāo)準(zhǔn)、規(guī)范（包含標(biāo)準(zhǔn)名、標(biāo) 準(zhǔn)編號、版本號（或發(fā)布日期）、公司受控編號信息）硬件限制：列出所有影響或約束產(chǎn)品/項目的硬件成分，如運(yùn)行環(huán)境最低配置; 軟件限制：列出所有影響或約束產(chǎn)品/項目的軟件成分，如軟件開發(fā)環(huán)境限制

20、、 軟件運(yùn)行環(huán)境限制和軟件的設(shè)計限制；7. 驗證標(biāo)準(zhǔn)：用于該需求被實現(xiàn)后，檢查實現(xiàn)結(jié)果是否符合需求，給測試或用戶提 供明確的驗證依據(jù)。如：對于性能需求，列出具體的性能指標(biāo)；對于功能需求， 給出詳細(xì)的實現(xiàn)效果；若驗證標(biāo)準(zhǔn)已包含在詳細(xì)描述中，則指明位置即可；8. 優(yōu)先級：用以表明該需求在產(chǎn)品/項目中的重要程度及被實現(xiàn)代優(yōu)先順序，應(yīng)定義優(yōu)先級的劃分方式，不同的產(chǎn)品 /項目可以采用不同的劃分方式；9. 依賴性：對其他需求的存在、變化的依賴，如列出本需求所引用的需求，若無任 何依賴，則寫“無”；.包含第一條中未列出但應(yīng)該在需求項中說明的其他信息；4.2. 正確性正確性指對需求的定義必須是對的，它涵蓋了軟

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

22、讀者并不清楚的主觀性詞語（除了已經(jīng)對這些詞語進(jìn)行了明確的定義或引用說明），具體如：“待定”、“可能”、“即將”、“考慮”、“最好”、“最差”、“一般情況”、“特殊情況”、“可以”、“用戶友好性”，“容易”， “簡單”，“快速”，“有效”，“幾個”，“藝術(shù)級”，“改善的”，“最大”，“最小”、“較 好”、“較差”、“等等”、“一期實現(xiàn)”、“根據(jù)需要”、“如果可能”、“高級”。4.3. 一致性致性指不存在內(nèi)容相互矛盾的地方。具體應(yīng)滿足但不僅限于下列要求:1. 同一內(nèi)容在整個軟件需求分析說明書中其內(nèi)涵和外延都是一致的；2. 不存在一個需求與軟件的其他需求或高級別的系統(tǒng)需求發(fā)生沖突的現(xiàn)象；3. 術(shù)語的

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

24、求， 必須給出已經(jīng)量化的所要達(dá)到的具體性能指標(biāo)，且這些指標(biāo)都能用某種方法或工具進(jìn)行測量；3. 需求必須一致的，詳見質(zhì)量要求的“一致性”部分；4. 需求必須是明確的，詳見質(zhì)量要求的“正確性”部分的第5條；如任何需求如果說“產(chǎn)品/項目將要支持什么”是不可驗證的，必須具體說明何時支持， 如何支持。4.5. 劃分優(yōu)先級劃分優(yōu)先級指為每個需求指定實施的優(yōu)先級，以表明它在產(chǎn)品/項目中的重要程度及被實現(xiàn)代優(yōu)先順序。具體應(yīng)滿足下列要求：為整個軟件需求分析說明書制定統(tǒng)一的優(yōu)先級劃分標(biāo)準(zhǔn)；為每個需求指定一個定義好的優(yōu)先級；46可用性可用性指需求分析說明書易于閱讀、理解、修改、跟蹤、維護(hù)、管理。具體應(yīng)滿足但 不僅限

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

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

27、含的信息，應(yīng)在文檔中適當(dāng)?shù)奈恢锰砑樱?. 附件此章節(jié)內(nèi)容只作為開發(fā)人員編寫軟件需求分析說明書時的一個參考，不作為審查的內(nèi) 容。5.1. 一些編寫建議列出軟件需求分析說明書編寫過程中的一些建議，這些建議的描述相對比較定性、籠 統(tǒng)。1. 使用書面語，不用口語；2. 使用短句和短的段落；3. 采用主動語氣；4. 語句表達(dá)方式的風(fēng)格要保持一致；5. 編寫時盡量使用定量、客戶的詞匯，少用定性、主觀的詞匯;6. 編寫時以開發(fā)人員的角度來審視是否需要軟件需求分析說明書作者的額外解釋和幫助開發(fā)人員才能理解需求，才能進(jìn)行設(shè)計和實現(xiàn)？若是，則需進(jìn)一步細(xì)化需求;7. 避免一個段落中包含了多個的需求；8. 對軟件需求

28、說明書進(jìn)行持續(xù)的改進(jìn)，軟件產(chǎn)品的開發(fā)過程中，在項目的開始階段 可能無法詳細(xì)說明某些細(xì)節(jié)，在開發(fā)過程中可能發(fā)現(xiàn)缺陷、缺點(diǎn)和錯誤，一旦發(fā) 現(xiàn)需立即按需求管理的流程改進(jìn)；9. 不要在一個需求中使用“和”/ “或”，以避免將多個需求合成一個需求；10. 使用需求編制、管理工具，以便需求的變更并保證變更后需求仍是一致的、保證 編寫和排版風(fēng)格的統(tǒng)一；11. 盡量使用形式化的語言，少用自然語言，如使用 UML、圖、表格、規(guī)范化模型等 方式。因為盡管自然語言是豐富多彩的，但不易精確表述；12. 編寫時重點(diǎn)在其表達(dá)的內(nèi)容，不要拘泥于表達(dá)的形式，形式可以多種多樣，合適 易用的即可；13. 建議選擇使用適用的需求分

29、析說明書模板；5.2. 部分參考實例列出軟件需求分析說明書中部分重要內(nèi)容的常見表示方式的例子。5.2.1.需求項表格使用表格的方式來組織需求項的內(nèi)容。唯一標(biāo)識【必須】（跟蹤需求的標(biāo)簽，唯一且不變，建議米用（項目編號+文檔的內(nèi)部編號）方式，使需求編號在整個公司的范圍內(nèi)都是唯一點(diǎn)）簡要描述【必須】（簡單描述該需求要實現(xiàn)的目標(biāo) ）類型【必須】（需求的類型，依需求的分類方法而定）目的【可選】（簡要描述提出該需求的目的，若很明顯則寫“略”）來源【必須】（指誰提出該需求，具體可以是人 （客戶、用戶、員工）、公司、 市場等）詳細(xì)描述【必須】對該需求的詳細(xì)說明；由于不冋類型的需求其詳細(xì)描述需要包 含的內(nèi)容不同

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

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

32、植性：具體列出要求可以移植的平臺；可維護(hù)性：具體列出保證可維護(hù)性的具體的方法；安全性：具體列出要達(dá)到的安全級別或安全程度； 兼容性：具體列出所要兼容的平臺或軟硬件環(huán)境； 可測試性：具體列出保證該特性的具體功能和方法； 設(shè)計限制：列出具體的限制因素；驗證標(biāo)準(zhǔn)【必須】（用于后期檢查實現(xiàn)結(jié)果是否符合需求，給測試或用戶提供明確 的驗證依據(jù)。如：對于性能需求，列出具體的性能指標(biāo)；對于功能需求， 給出詳細(xì)的實現(xiàn)效果；若驗證標(biāo)準(zhǔn)已包含在詳細(xì)描述中，則指明位置即 可。）優(yōu)先級【必須】（用以表明該需求在產(chǎn)品 /項目中的重要程度及被實現(xiàn)代優(yōu)先順 序，應(yīng)定義優(yōu)先級的劃分方式，不冋的產(chǎn)品/項目可以采用不冋的劃分方式）依賴性【必須】（對其他需求的存在、變化的依賴，如列出本需求所引用的需求， 若無任何依賴，則寫“無”。）5.2.2. 表格需求項實