第一篇：如何編寫高質量的“軟件需求說明書”

如何編寫高質量“軟件需求說明書”

你的工程應該有個好的起點。一個小組要帶領客戶進入需求啟發階段而且你要寫軟件需求說明書。這份說明有些大，但客戶會很重視，所以說明必須得到贊同。

現在你正在設計其中的一個特性，已經發現了需求的一些問題。你可以用多種不同的方式解釋需求15；需求9 的說明正好與需求21相反，你因該相信哪一個？需求24非常含糊，你根本不明白它的意思；你不得不花上一個小時與2位開發人員討論需求30，只因為你們對其各有各的理解；并且，唯一能夠澄清這些問題的客戶沒有給你們答復。你被迫破解眾多需求的含義，并且你能預料到，如果你錯了，你要做大量的重復工作。

許多軟件需求說明書（SRS）寫得非常糟糕。任何產品的質量需要其原始材料的質量保證，糟糕的軟件需求說明書不可能產出優秀的軟件。不幸的是，幾乎沒有開發人員受過與需求的抽象、分析、文檔、質檢有關的教育。而且，沒有非常多的好需求可以借鑒學習，部分原因是很少有工程可以找到一個好的借鑒，其他原因是公司不愿意將其產品說明書放在公共區域。

這篇文章描述了高質量需求敘述和說明的幾個特性（特點）。我們將用這些觀點檢查一些有缺陷的需求，帶著痛楚重新編寫。而且我會談一些如何編寫好的需求的提示。你也許想通過這些質量標準評估你的工程需求。對于修訂，也許遲了，但你會學到一些有用的東西，并幫助你的小組在下次編寫出更好的需求。

不要期望能夠編寫出一份能體現需求應具備的所有特性的SRS。無論你怎么細化、分析、評論和優化需求，都不可能達到完美。但是，如果你牢記這些特性，你就會編寫出更好的需求，生產出更好的產品。

高質量需求敘述的特性

我們如何從一些有問題的需求中分辨出好的軟件需求？這一節將分別介紹需求敘述應體現的6個特性，下一節將從整體上介紹SRS文檔應具備的特性。判斷每個需求是否具備應有的特性的一種方式是由持有不同觀點的工程資金管理人所作的正規檢查。另一種有力的方法是在編寫代碼前依據需求編寫測試例子。測試例子能夠明確顯現在需求中描述的產品行為（特性），能夠顯現缺陷、冗余和含糊之處。

正確：每個需求必須精確描述要交付的功能。正確性依據于需求的來源，如真實的客戶或高級別的系統需求說明書。一個軟件需求與其對應的系統需求說明書相抵觸是不正確的（當然，系統需求說明書本身可能不正確）。

只有用戶的代表能夠決定用戶需求的正確性，這就是為什么在檢查需求時，要包括他們或他們的代理的關鍵所在。不包括用戶的需求檢查就會導致開發人員的：“這是沒意義的”，“這可能是他們的意思”等眾所周知的猜測。

可行性：在已知的能力、有限的系統及其環境中每個需求必須是可實現的。為了避免需求的不可行性，在需求分析階段應該有一個開發人員參與，在抽象階段應該有市場人員參與。這個開發人員應能檢查在技術上什么能做什么不能做，哪些需要需要額外的付出或者和其他的權衡。

必要性：每個需求應載明什么是客戶確實需要的，什么要順應于外部的需求，接口或標準。每個需求源于你認可、具有權說明需求的原始資料，這是考慮必需的另外情形（譯注，此句翻譯不順，請參照原文：Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements）。跟蹤每個需求回溯到出處，如用例，系統需求，規章，或來自其他用戶的意見。如果你不能標識出處，可能需求只是個鍍金的例子，沒有真正的必須。

優先權：為了表明在一個詳細的產品版本中應包含哪些要點，需要為每個需求，特征，或用例分配實現的優先權。客戶或其代理都應有強烈的責任建立優先權。如果所有的需求都被視為同等重要，那么由于在開發中，預算削減，計劃超時或組員的離開導致新的需求時，項目經理將不能起到作用。優先權的作用是提供給客戶的價值，實現的相關費用，實現相關聯的有關技術風險。

我是用3種級別的優先權：高優先權表明需求必須體現在下一個產品版本中，中優先權表明需求是必須的，但是如果需要可以推遲到晚一些的產品版本中，低優先權表明有它很好，但我們必須認識到如果沒有充足的時間或資源，它可以被放棄掉。

明確：需求敘述的讀者應只能從其得到唯一的解釋說明，同樣，一個需求的多個讀者也應達成共識。自然語言極易導致含糊。要避免使用一些對于SRS作者很清楚但對于讀者不清楚的主觀詞匯，如：用戶友好性，容易，簡單，快速，有效，幾個，藝術級，改善的，最大，最小等等。每寫一個需要都應簡潔，簡單，直觀的采用用戶熟知的語言，不要采用計算機術語。檢查需求模糊的有效方式包括需求說明書的正規檢查，根據需求寫測試，建立用戶的假想來說明產品某個特定部分預期的特性。

可證實：看你是否能夠做出測試計劃或其他驗證方式，如檢查和實證，來決定在產品中每個需求是否正確的實現。如果需求是不可驗證的，決定需求是不是正確的實現就成了判斷的事。需求之間不一致，不可行，不明確也能導致不可證實。任何需求如果說產品將要支持什么也是不可證實的。

高質量需求說明的特征

一個完整的SRS不僅是包括長長的功能性需求列表，還包括外部接口描述和一些諸如質量屬性，期望性能的非功能性需求。下面描述了高質量的SRS的一些特性。

完整：不應該遺漏要求和必需的信息。完整性也是一個需求應具備的。發現缺少的信息很難，因為根本不存在。在SRS中將需求以分層目錄方式組織，將幫助評審人員理解功能性描述的結構，使他們很容易指出遺失的東西。

在需求抽象時，相對于系統功能，你過多的注意用戶的業務，將導致在需求的全局觀和引進不是真正必需的需求上顯得不足。在需求抽象上，應用用例方法會發揮很好的作用。能夠從不同角度察看需求的圖形分析模型也可以檢查出不完整性。

如果你知道已缺少一些信息，使用TBD（to be determined）標準標志可以突出這些缺陷，當你在構建產品的相關部分時，就可以從一個給定的需求集中解決所有的缺陷。

一致性：一致性需求就是不要于其他的軟件需求或高級別的系統（商業）需求發生沖突。需求中的不一致必須在開發開始前得到解決。只有經過調研才能確定哪些是正確的。修改需求時一定要謹慎，如果只審定修改的部分，沒有審定于修改相關的部分，就可能導致不一致性。

可修改性：當每個需求的要求修改了或維護其歷史更改時，你必須能夠審定SRS。也就是說每個需求必須相對于其他需求有其單獨的標示和分開的說明，便于清晰的查閱。通過良好的組織可以使需求易于修改，如：將相關的需求分組，建立目錄表，索引，以及前后參考（照）。

可追蹤：你應能將一個軟件與其原始材料相對應，如高級系統需求，用例，用戶的提議等。也能夠將軟件需求與設計元素，源代碼，用于構造實現和驗證需求的測試相對應。可追蹤的需求應該具有獨立標示，細密和結構化的編寫，不應過大，不應是敘述性的文字和公告式的列表。

需求質量的評審

這些有關需求質量的特性的描述在理論上都是非常好的，但一個好的需求到底是個什么樣子的呢？為了體現得更切合實際，我們做個小練習。下面有幾個從實際的工程選出的需求，依據上面的質量標準，評估每個需求，看看有什么問題，然后用更好的方式重寫。我將對每個例子都提出自己的分析和改進的建議。也歡迎你提出不同的見解。我所占優的只是我知道每個需求的出處。因為你我都不是真正的客戶，我們只能猜測每個需求的意圖。

例1．“產品應在不少于每60秒的正常周期內提供狀態信息”

這個需求是不完整的：狀態信息是什么，如何顯示給用戶。這個需求有幾處含糊。我們在談論產品的哪部分？狀態信息間隔真的假定為不少于60秒？，甚者每10年顯示一條新的狀態信息也可以？也許它的意圖是消息間隔不應超過60秒，那么1毫秒是不是太短？“每”這個詞導致了不確定性。問題的后果，就是需求的不可證實。

彌補缺陷，重寫需求的一種方法：

1、狀態信息

1．1后臺任務管理器因該以誤差上下不超過10秒的60秒間隔，在用戶界面的指定位置顯示狀態信息

1．2如果后臺進程處理正常，那么應該顯示任務已完成的百分數/比

1．3任務完成時，應顯示相關的信息

1．4后臺任務出錯應該顯示錯誤信息

為了分別測試和追蹤，我將其分成了多個需求。如果將幾個需求串接在一節中，在構造和測試時就很容易漏掉一個。

例2．“產品應瞬間在顯示和隱藏不可打印字符間切換”

計算機在瞬間不能做任何事，所以這個需求不切實可行。它的不完整性表現在沒有聲明觸發狀態切換的條件。軟件要在某些條件下更改自己？或者用戶為了模仿更改要做一些動作？而且，在文檔中改變顯示的范圍是多大：選中的文本，整個的文檔，或其他的？這也是個模糊的問題。不可打印字符合隱藏字符一樣嗎？或者是一些屬性標志或一些控制字符？問題的后果，就是需求的不可證實。

象這樣編寫需求也許更好一些：“用戶能夠在一個由特定觸發條件激活處于編輯的文檔中在顯示和隱藏所有HTML標記間切換”。現在就很清楚，不可打印字符是HTML標記。由于沒有定義觸發條件，需求對設計沒有約束力。只有設計人員選定了觸發條件后，你才能編寫測試驗證觸發的正確操作。

例3．“HTML分析器可以產生HTML標記錯誤報告，幫助HTML入門者快速解決錯誤”。單詞“快速”使其模糊，沒

有加進錯誤報告的定義也是其部完整。我不知道，你怎么驗證這個需求。找一個自稱為HTML的入門者，看看能不能根據錯誤報告快速解決錯誤？

試試這個：“HTML分析器可以產生一個錯誤報告，錯誤報告包含有在被分析文件中出錯的HTML文本和行號以及錯誤的描述。如果沒有錯誤，就不會產生錯誤報告”。現在我們知道了，什么會被加到出錯報告中，但是出錯報告是個什么樣子，則留由設計人員決定。我們還指定了一個例外：如果沒有發現錯誤，不產生錯誤報告。

例4．“如果可能，主管號碼應通過聯機校驗，而不是通過主全體主管號碼列表校驗”。真感到絕望，什么是“如果可能”：如果技術上可行？如果主全體主管號碼列表可以聯機獲得？要避免象“應該”的這類不確切的詞。客戶是需要這個功能性還是不需要。我曾看過一些需求說明書，采用諸如：應，將，應該/將要等一些詞描述優先級的細微差別。但我更喜歡用“應”清楚的說明需求的意圖，指明優先級。這是修改后的：系統應校驗輸入的主管號碼而不通過聯機的主全體主官號碼列表。如果在列表中沒有發現主管號碼，將會顯示一條錯誤信息，也不接受指令。

在理解各個已完成的糟糕需求上，開發人員將會遇到的難題是：開發人員與客戶將會在審核需求，未達成共識前發生激烈的爭論。詳細檢查大的需求文檔不是一件輕松的事情。我清楚有人做過，而且他們花在檢查上的每一分鐘都是值得的。相對于開發階段和用戶的抱怨電話，在這個階段修補缺陷是便宜的，編寫質量需求的方針

編寫優秀的需求是沒有公式化的方法的。這需要大量的經驗，要從你在過去的文檔中發現的問題學習。請在組織軟件需求文檔時，嚴格遵從這些方針。

句子和段落要短。采用主動語氣。使用正確的語法，拼寫，標點。使用術語，要保持一致性，并在術語表或數據字典中定義它們

要看需求是否被有效的定義，可以以開發人員的觀點看看。在內心將“當你們做完了找我”這句加到文檔尾部，看看能不能是你緊張起來。換句話說，你是否需要SRS的編寫者的額外解釋幫助開發人員很好的理解需求，以便于設計和實現？如果是的話，在繼續工作前，需求還需要細化。

需求編寫者還要努力正確地把握細化程度。要避免包含多個需求的長的敘述段落。有幫助的提示是編寫獨立的可測試的需求。如果你認為一小部分測試可以驗證一個需求的正確，那么它已經正確的細化了。如果你預想到多種不同類的測試，幾個需求可能已擠到了一起，需要拆分開。

密切關注多個需求合成了單個需求。一個需求中的連接詞“和”/“或”建議幾個需求合并。不要在一個需求中使用“和”/“或”。

通篇文檔細節上要保持一致。我曾看見過多個需求說明書前后不一致。如：“對于紅色合法的顏色代碼應是R”及“對于綠色合法的顏色代碼應是G”就有可以以分散的需求分離開，而“產品應能對來自語音編輯指示做出反應”應作為一個子系統，不應作為單個的功能性需求。

避免在SRS中過多的申述需求。在多處包含相同的需求可以使文檔更易于閱讀，但也會給文檔的維護增加困難。文檔的多份文本要在同一時間內全部更新，避免不一致性。

如果你遵從了這些方針，你能夠盡早地經常正式或非正式的審查需求，這些需求對于產品的構造，系統測試以及最后的客戶滿意，都會成為好的奠基石。并且要記住，沒有高質量的需求，軟件就象一盒巧克力，你永遠不知道你會得到什么。

第二篇：如何編寫高質量“軟件需求說明書”.doc

如何編寫高質量“軟件需求說明書”2003-01-27· · ··天極論壇 2 下一頁

你的工程應該有個好的起點。一個小組要帶領客戶進入需求啟發階段而且你要寫軟件需求說明書。這份說明有些大，但客戶會很重視，所以說明必須得到贊同。

現在你正在設計其中的一個特性，已經發現了需求的一些問題。你可以用多種不同的方式解釋需求15；需求9 的說明正好與需求21相反，你因該相信哪一個？需求24非常含糊，你根本不明白它的意思；你不得不花上一個小時與2位開發人員討論需求30，只因為你們對 其各有各的理解；并且，唯一能夠澄清這些問題的客戶沒有給你們答復。你被迫破解眾多需求的含義，并且你能預料到，如果你錯了，你要做大量的重復工作。

許多軟件需求說明書（SRS）寫得非常糟糕。任何產品的質量需要其原始材料的質量保證，糟糕的軟件需求說明書不可能產出優秀的軟件。不幸的是，幾乎沒有開發人員受過與需求的抽象、分析、文檔、質檢有關的教育。而且，沒有非常多的好需求可以借鑒學習，部分原因是很少有工程可以找到一個好的借鑒，其 他原因是公司不愿意將其產品說明書放在公共區域。

這篇文章描述了高質量需求敘述和說明的幾個特性（特點）。我們將用這些觀點檢查一些有缺陷的需求，帶著痛楚重新編寫。而且我會談一些如何編寫好 的需求的提示。你也許想通過這些質量標準評估你的工程需求。對于修訂，也許遲了，但你會學到一些有用的東西，并幫助你的小組在下次編寫出更好的需求。

不要期望能夠編寫出一份能體現需求應具備的所有特性的SRS。無論你怎么細化、分析、評論和優化需求，都不可能達到完美。但是，如果你牢記這些特性，你就會編寫出更好的需求，生產出更好的產品。

高質量需求敘述的特性

我們如何從一些有問題的需求中分辨出好的軟件需求？這一節將分別介紹需求敘述應體現的6個特性，下一節將從整體上介紹SRS文檔應具備的特性。判斷每個需求是否具備應有的特性的一種方式是由持有不同觀點的工程資金管理人所作的正規檢查。另一種有力的方法是在編寫代碼前依據需求編寫測試例子。測試 例子能夠明確顯現在需求中描述的產品行為（特性），能夠顯現缺陷、冗余和含糊之處。

正確：每個需求必須精確描述要交付的功能。正確性依據于需求的來源，如真實的客戶或高級別的系統需求說明書。一個軟件需求與其對應的系統需求說明書相抵觸是不正確的（當然，系統需求說明書本身可能不正確）。

只有用戶的代表能夠決定用戶需求的正確性，這就是為什么在檢查需求時，要包括他們或他們的代理的關鍵所在。不包括用戶的需求檢查就會導致開發人員的：“這是沒意義的”，“這可能是他們的意思”等眾所周知的猜測。

可行性：在已知的能力、有限的系統及其環境中每個需求必須是可實現的。為了避免需求的不可行性，在需求分析階段應該有一個開發人員參與，在抽象階段應該有市場人員參與。這個開發人員應能檢查在技術上什么能做什么不能做，哪些需要需要額外的付出或者和其他的權衡。

必要性：每個需求應載明什么是客戶確實需要的，什么要順應于外部的需求，接口或標準。每個需求源于你認可、具有權說明需求的原始資料，這是考慮 必需的另外情形（譯注，此句翻譯不順，請參照原文：Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements）。跟蹤每個需求回溯到出處，如用例，系統需求，規章，或來自其他用戶的意見。如果你不能標識出處，可能需求只是個鍍金的例子，沒有真正的必須。

優先權：為了表明在一個詳細的產品版本中應包含哪些要點，需要為每個需求，特征，或用例分配實現的優先權。客戶或其代理都應有強烈的責任建立優 先權。如果所有的需求都被視為同等重要，那么由于在開發中，預算削減，計劃超時或組員的離開導致新的需求時，項目經理將不能起到作用。優先權的作用是提供給客戶的價值，實現的相關費用，實現相關聯的有關技術風險。

我是用3種級別的優先權：高優先權表明需求必須體現在下一個產品版本中，中優先權表明需求是必須的，但是如果需要可以推遲到晚一些的產品版本中，低優先權表明有它很好，但我們必須認識到如果沒有充足的時間或資源，它可以被放棄掉。

明確：需求敘述的讀者應只能從其得到唯一的解釋說明，同樣，一個需求的多個讀者也應達成共識。自然語言極易導致含糊。要避免使用一些對于SRS 作者很清楚但對于讀者不清楚的主觀詞匯，如：用戶友好性，容易，簡單，快速，有效，幾個，藝術級，改善的，最大，最小等等。每寫一個需要都應簡潔，簡單，直觀的采用用戶熟知的語言，不要采用計算機術語。檢查需求模糊的有效方式包括需求說明書的正規檢查，根據需求寫測試，建立用戶的假想來說明產品某個特定部 分預期的特性。

可證實：看你是否能夠做出測試計劃或其他驗證方式，如檢查和實證，來決定在產品中每個需求是否正確的實現。如果需求是不可驗證的，決定需求是不 是正確的實現就成了判斷的事。需求之間不一致，不可行，不明確也能導致不可證實。任何需求如果說產品將要支持什么也是不可證實的。

高質量需求說明的特征

一個完整的SRS不僅是包括長長的功能性需求列表，還包括外部接口描述和一些諸如質量屬性，期望性能的非功能性需求。下面描述了高質量的SRS的一些特性。

完整：不應該遺漏要求和必需的信息。完整性也是一個需求應具備的。發現缺少的信息很難，因為根本不存在。在SRS中將需求以分層目錄方式組織，將幫助評審人員理解功能性描述的結構，使他們很容易指出遺失的東西。

在需求抽象時，相對于系統功能，你過多的注意用戶的業務，將導致在需求的全局觀和引進不是真正必需的需求上顯得不足。在需求抽象上，應用用例方法會發揮很好的作用。能夠從不同角度察看需求的圖形分析模型也可以檢查出不完整性。

如果你知道已缺少一些信息，使用TBD（to be determined）標準標志可以突出這些缺陷，當你在構建產品的相關部分時，就可以從一個給定的需求集中解決所有的缺陷。

一致性：一致性需求就是不要于其他的軟件需求或高級別的系統（商業）需求發生沖突。需求中的不一致必須在開發開始前得到解決。只有經過調研才能確定哪些是正確的。修改需求時一定要謹慎，如果只審定修改的部分，沒有審定于修改相關的部分，就可能導致不一致性。

可修改性：當每個需求的要求修改了或維護其歷史更改時，你必須能夠審定SRS。也就是說每個需求必須相對于其他需求有其單獨的標示和分開的說明，便于清晰的查閱。通過良好的組織可以使需求易于修改，如：將相關的需求分組，建立目錄表，索引，以及前后參考（照）。

可追蹤：你應能將一個軟件與其原始材料相對應，如高級系統需求，用例，用戶的提議等。也能夠將軟件需求與設計元素，源代碼，用于構造實現和驗證需求的測試相對應。可追蹤的需求應該具有獨立標示，細密和結構化的編寫，不應過大，不應是敘述性的文字和公告式的列表。

需求質量的評審

這些有關需求質量的特性的描述在理論上都是非常好的，但一個好的需求到底是個什么樣子的呢？為了體現得更切合實際，我們做個小練習。下面有幾個 從實際的工程選出的需求，依據上面的質量標準，評估每個需求，看看有什么問題，然后用更好的方式重寫。我將對每個例子都提出自己的分析和改進的建議。也歡 迎你提出不同的見解。我所占優的只是我知道每個需求的出處。因為你我都不是真正的客戶，我們只能猜測每個需求的意圖。

例1．“產品應在不少于每60秒的正常周期內提供狀態信息”

這個需求是不完整的：狀態信息是什么，如何顯示給用戶。這個需 求有幾處含糊。我們在談論產品的哪部分？狀態信息間隔真的假定為不少于60秒？，甚者每10年顯示一條新的狀態信息也可以？也許它的意圖是消息間隔不應超 過60秒，那么1毫秒是不是太短？“每”這個詞導致了不確定性。問題的后果，就是需求的不可證實。

彌補缺陷，重寫需求的一種方法：

1、狀態信息

1．1后臺任務管理器因該以誤差上下不超過10秒的60秒間隔，在用戶界面的指定位置顯示狀態信息

1．2如果后臺進程處理正常，那么應該顯示任務已完成的百分數/比

1．3任務完成時，應顯示相關的信息

1．4后臺任務出錯應該顯示錯誤信息

為了分別測試和追蹤，我將其分成了多個需求。如果將幾個需求串接在一節中，在構造和測試時就很容易漏掉一個。

例2．“產品應瞬間在顯示和隱藏不可打印字符間切換”

計算機在瞬間不能做任何事，所以這個需求不切實可行。它的不完整性 表現在沒有聲明觸發狀態切換的條件。軟件要在某些條件下更改自己？或者用戶為了模仿更改要做一些動作？而且，在文檔中改變顯示的范圍是多大：選中的文本，整個的文檔，或其他的？這也是個模糊的問題。不可打印字符合隱藏字符一樣嗎？或者是一些屬性標志或一些控制字符？問題的后果，就是需求的不可證實。

象這樣編寫需求也許更好一些：“用戶能夠在一個由特定觸發條件激活處于編輯的文檔中在顯示和隱藏所有HTML標記間切換”。現在就很清楚，不可 打印字符是HTML標記。由于沒有定義觸發條件，需求對設計沒有約束力。只有設計人員選定了觸發條件后，你才能編寫測試驗證觸發的正確操作。

例3．“HTML分析器可以產生HTML標記錯誤報告，幫助HTML入門者快速解決錯誤”。單詞“快速”使其模糊，沒

有加進錯誤報告的定義也是其部完整。我不知道，你怎么驗證這個需求。找一個自稱為HTML的入門者，看看能不能根據錯誤報告快速解決錯誤？

試試這個：“HTML分析器可以產生一個錯誤報告，錯誤報告包含有在被分析文件中出錯的HTML文本和行號以及錯誤的描述。如果沒有錯誤，就不 會產生錯誤報告”。現在我們知道了，什么會被加到出錯報告中，但是出錯報告是個什么樣子，則留由設計人員決定。我們還指定了一個例外：如果沒有發現錯誤，不產生錯誤報告。

例4．“如果可能，主管號碼應通過聯機校驗，而不是通過主全體主管號碼列表校驗”。真感到絕望，什么是“如果可能”：如果技術上可行？如果主全 體主管號碼列表可以聯機獲得？要避免象“應該”的這類不確切的詞。客戶是需要這個功能性還是不需要。我曾看過一些需求說明書，采用諸如：應，將，應該/

將 要等一些詞描述優先級的細微差別。但我更喜歡用“應”清楚的說明需求的意圖，指明優先級。這是修改后的：系統應校驗輸入的主管號碼而不通過聯機的主全體主 官號碼列表。如果在列表中沒有發現主管號碼，將會顯示一條錯誤信息，也不接受指令。

在理解各個已完成的糟糕需求上，開發人員將會遇到的難題是：開發人員與客戶將會在審核需求，未達成共識前發生激烈的爭論。詳細檢查大的需求文檔 不是一件輕松的事情。我清楚有人做過，而且他們花在檢查上的每一分鐘都是值得的。相對于開發階段和用戶的抱怨電話，在這個階段修補缺陷是便宜的，編寫質量需求的方針

編寫優秀的需求是沒有公式化的方法的。這需要大量的經驗，要從你在過去的文檔中發現的問題學習。請在組織軟件需求文檔時，嚴格遵從這些方針。

句子和段落要短。采用主動語氣。使用正確的語法，拼寫，標點。使用術語，要保持一致性，并在術語表或數據字典中定義它們

要看需求是否被有效的定義，可以以開發人員的觀點看看。在內心將“當你們做完了找我”這句加到文檔尾部，看看能不能是你緊張起來。換句話說，你 是否需要SRS的編寫者的額外解釋幫助開發人員很好的理解需求，以便于設計和實現？如果是的話，在繼續工作前，需求還需要細化。

需求編寫者還要努力正確地把握細化程度。要避免包含多個需求的長的敘述段落。有幫助的提示是編寫獨立的可測試的需求。如果你認為一小部分測試可以驗證一個需求的正確，那么它已經正確的細化了。如果你預想到多種不同類的測試，幾個需求可能已擠到了一起，需要拆分開。

密切關注多個需求合成了單個需求。一個需求中的連接詞“和”/“或”建議幾個需求合并。不要在一個需求中使用“和”/“或”。

通篇文檔細節上要保持一致。我曾看見過多個需求說明書前后不一致。如：“對于紅色合法的顏色代碼應是R”及“對于綠色合法的顏色代碼應是G”就有可以以分散的需求分離開，而“產品應能對來自語音編輯指示做出反應”應作為一個子系統，不應作為單個的功能性需求。

避免在SRS中過多的申述需求。在多處包含相同的需求可以使文檔更易于閱讀，但也會給文檔的維護增加困難。文檔的多份文本要在同一時間內全部更新，避免不一致性。

如果你遵從了這些方針，你能夠盡早地經常正式或非正式的審查需求，這些需求對于產品的構造，系統測試以及最后的客戶滿意，都會成為好的奠基石。并且要記住，沒有高質量的需求，軟件就象一盒巧克力，你永遠不知道你會得到什么。

第三篇：需求規格說明書編寫心得

需求規格說明書編寫心得

以下是本人總結的《需求規格說明書》編寫心得，由于人個水平有限，歡迎大家補充。

1.需求編寫依據

合同、招投標文件、調研記錄以及項目經理提供的已確定的需求規格說明書（內部）等。

2.主動與項目經理的溝通

反復的溝通，才能深入把握項目的實際需求，獲得更多的資訊和資料。

3.項目背景

1)闡述目前遇到了什么樣的問題，并充分說明該問題的嚴重性和緊迫性，若能提供一些數據或運用一些真實、典型的案例，不僅可以充分的說明該問題同時還能表明你對該項目的了解；

2)如何解決該問題；

3)為什么要提出這樣一個系統；

4)最后扼要概述該系統的長遠戰略意義。

這樣從邏輯上層層遞進，不僅可以讓自己的思維嚴謹起來，也使自己寫出來的東西變得專業些。

4.系統總體概述

簡單介紹系統的基本情況、特點、展示功能框架及闡述其優勢。主要圍繞是什么，有什么樣的功能特點，能起到什么樣的作用。

5.術語與用詞

列出與系統有關的在文檔中一定會提到的專業術語，沒有提到的術語則不需要列出，否則會給讀者帶來一定的負擔。還有要統一表達方式，如“修改”，“編輯”，“用戶”，“員工”等等，以避免引發歧義。

另外，需求文檔不需要華麗的詞語，以客觀事實的原則，切忌摻和主觀思想，注意用詞準確，精簡表達其業務就可以。同時還需注意幾點：等等、很多等抽象詞盡量不使用；我認為、以為等主觀詞語切忌出現，盡量避免口語化。

6.描述模塊

在編寫模塊時，通常包括模塊描述、重要業務及流程、功能需求定義、業務數據字典、原型界面圖等。

? 模塊描述

要明確指出建設了哪些功能，幫助用戶實現什么、目標、基礎等

? 重要業務及流程

對該業務進行認真分析，得出該功能事項的有效規則，以激發該功能。可以通過畫流程圖，快速幫助閱讀者理解，但一定要注意質量，避免產生誤導。

? 功能需求定義

需求中每個功能點力求寫的清楚，一個需求文檔下來能清楚統計出功能有多少個，并指明什么用戶使用。一般情況下，要先寫簡單的，權限少的角色。此文檔是設計的基礎，是系統驗收的依據。

? 數據字典

寫出實體類的中英文屬性名稱、類型和說明（如是否為表主鍵）。

? 重要界面原型圖

該功能模塊的重要原型圖。

第四篇：《××項目軟件需求變更說明書》

軟件需求變更說明書

項目名稱： 長益高速收費數據分析系統一、概述

因湖南省高速公路聯網拆分系統軟件升級，導致長益下屬收費站入口和出

口交易數據、拆分數據、代收拆分數據無法獲取。而現階段省高管局監控中心無法在上報報表日期內提供拆分數據，從而導致長益高速收費數據分析系統無法輸出相關報表。經過深入了解和分析，在與業主方多次探討后，提出以下變更說明。

二、變更內容

? MTC實收和流量

原始情況：

人工收費系統出口站收費數據和出口流量的導入，是由收費站工作

人員從站級拆帳網下載的“收費數據統計報表”并再錄入部分細分數據，導入長益收費數據分析系統。

變更后：

收費站工作人員在分析系統中MTC實收功能模塊中只錄入出口各車

型實收收入、各車型流量、免費車流量、綠通車流量、系統外收入、綠通車減免金額、免費車減免金額、手工票金額。

運營部工作人員在分析系統中MTC實收功能模塊中導入本路段各站

進，其他路段出的代收流量的各車型估算流量。其中包括各車型流量、綠通車流量、免費車流量。

? MTC實得

原始情況：

人工收費系統實得數據的導入，是由收費站工作人員從站級拆帳網

下載的“拆帳統計報表”，導入長益收費數據分析系統。

代收實得的導入，是由運營部工作人員從拆帳網下載的“長張高速

公司名稱，版本號

2公路聯網收費實際分配收入統計表”，導入長益數據分析系統。

變更后：

運營部工作人員在分析系統中MTC實得功能模塊中導入估算MTC各

車型拆分收入。其中包括本路段各車型收入、系統外收入及代收業主各車型收入、系統外收入。

? 報表輸出

由于原始基礎數據的變更，所導致從數據模型上的建立發生了變化，從而將導致原長益數據分析系統輸出報表無法根據原來基礎數據的數據輸出，需要轉換為估算的數據輸出，需要對所有的報表進行修改。

需要修改的報表有以下：

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

? 公司－綠色通道車輛 公司－收費站拆帳情況表 公司－單車收費標準計算表 公司－流量對比表 公司－各類車流量收入比重對比圖 公司－各類車流量收入比重表 公司－實征率 公司－高速免費車 公司－收費車流量統計 公司－ETC收費車與免費車 公司－月流量分析 公司－ETC征費情況 公司－月收入圖 公司－月收費情況總表 公司-收費車流量與收入統計 路勁-收入影響因素對比表 路勁-項目每月輸入及車流匯總表 路勁-各站每月收入及車流匯總表 路勁-歷年路費收入圖 路勁-歷年次票車流量圖 路勁-日報 省局-交通流量統計月報表 省局-綠色通道和免費車公司名稱，版本號

? 省局-其他收入分項統計

? 三年同天對比-1月

? 三年同期對比-2月

? 三年同天對比-3月

? 三年同期對比-4月

? 三年同期對比-5月

? 三年同期對比-6月

? 三年同期對比-7月

? 三年同期對比-8月

? 三年同期對比-9月

? 三年同期對比-10月

? 三年同期對比-11月

? 三年同期對比-12月

? 周報-高速公路

? 周報-總表

? 周報-流量圖

? 周報-收入圖

? 周報-老路

? 月報-月收費

? 月報-財務系統內金額拆帳

? 月報-月度收費情況

公司名稱，版本號 4

第五篇：如何寫軟件項目需求說明書

如何寫軟件項目需求說明書

進入軟件開發行業也有一段時間了，大大小小項目也接觸了一些，對于怎么寫好項目需求文檔做一下總結，發表一下自己的看法。1 獲取需求：

作為需求方也就是甲方，通過語言描述或文檔的方式將需求（系統需要提供的功能）提交給開發人員（需求分析人員）。

獲得需求的方式可以有多種多樣：電話詢問、現場考察、聆聽用戶講解、閱讀用戶編制的相關文件(如招標書)，其實這些方法都是GET方式，我們可以通過以下兩類技術手段來達到：GET(獲取)和PUSH(引導、反饋、激發)相互結合的方式來得到我們真正的需求，而這兩個過程都是必須交互進行的，一般我們可以篩選一名非常有經驗(包括談判技巧、深厚的業務和技術背景、人緣很好、勤奮努力)的人士擔任需求工程師，長期在客戶那里工作。2 需求分析人員

（1）根據客戶提供的文檔或語言描述，將需求按功能劃分，以用例圖的方式表達系統提供的功能模塊及功能模塊之間的關系，完成用例圖后與客戶確認大的功能模塊，并對每個功能模塊做進一步的溝通詳細記錄用戶所提供的關鍵性的描述，此過程需要系統分析人員對客戶進行引導。

（2）對每個功能模塊進行詳細分析與描述，具體信息包括：用戶角色、功能說描述、IPO的方式進行描述（即輸入項、輸出項、處理）、要提供必要的功能說明，如果使文檔更加直觀，更容易讓客戶理解，可以用UI的方式表達輸入輸出，配合必要的描述，這樣對于客戶更加容易理解，需要與客戶進行大量的溝通確認。

（3）編寫數據字典：在需求階段，很難使團隊的思路一致，建立一個合適的機制是完全必要的，這就是數據字典，數據字典是對系統用到的所有數據項和結構的定義，以確保開發人員使用統一的數據定義。在需求階段，數據字典至少應定義客戶數據項以確保客戶與開發小組是使用一致的定義和術語。分析和設計工具通常包括數據字典組件。

（4）關于文檔具體表述的格式與形式，要根據所要表達的功能來確定，最重要的是把事情描述清楚,這事最終的目的；

(5)需求文檔確定后，設計人員根據這份需求文檔進行系統的設計工作了。