第一篇：如何撰寫高質量的業務需求說明書

如何撰寫高質量的業務需求說明書

作者：渤海銀行資訊科技部張保軍 原文刊登于《金融電子化》

在日常工作中，銀行業務部門經常提出不同的業務需求，有新產品研發需求，有對現有系統功能改 進需求，有提取數據需求，有反映生產問題需求。這些需求提交給科技部門在信息系統中實現，科技部門經常說業務部門提交的業務需求涵義表達不清、內容描述不 完整等，科技人員難以按照業務部門要求實現。業務需求說明成為業務與科技經常扯皮、推諉、口舌之爭之標靶，影響了軟件項目研發進度和質量。

撰寫一份高質量的業務需求說明書真的很難嗎？本文就此與大家探討如何撰寫高質量的業務需求書。

一、說明書常見問題

（1）需求過于簡單。有的只是一句話，如在現行的企業網銀系統中增加批量代發工資功能，可以說，只給了一個需求題目，沒有內容描述，具體業務處理流程和要求沒有任何說明。

（2）需求內容不完整。業務需求書洋洋灑灑寫了不少，但仔細一看，整個需求說明書內容缺東少西，不是少了會計分錄，就是少了統計分析;不是少了界面輸入項目，就是少了業務處理過程及要輸出的結果等。

（3）需求內容描述不清晰。想要什么，業務流程如何處理，定義不清，概念界定模糊，有很多疑問。如需求書中對于統計報表只是畫出一個大概表樣，沒有給出統計口徑、數據來源等詳盡資料。

（4）業務需求說明書本是很嚴謹的文書形式，但撰寫人重視程度不夠。需求說明書普遍存在錯別字、語句涵義表達不清楚，口語化濃厚，引用圖表不準確，主題表達不夠清晰。

（5）需求說明書照搬照抄。為了圖省事，把一些軟件公司提供的產品功能介紹文檔改頭換面，作為業務需求說明書提交，業內人員一看就知道不是自己寫的，很多地方根本不符合本行業務處理流程和系統功能。

（6）需求說明書沒有統一撰寫格式，不管是研發新產品、對現有系統功能改進、還是提取數據和生產問題需求，都沒有一個簡單實用的需求格式，隨意書寫，或者提供的格式完全不符合業務人員要求，大家不愿意或根本無法使用。

二、質量不高原因分析（1）撰寫業務需求說明書時，業務部門沒有很好組織人員對其需求進行認真討論、分析，匆忙撰寫，完成后沒有很好斟酌修改完善，又匆匆忙忙提交給科技部門研發，事先也顧不上與科技部門做溝通，多聽聽科技人員的意見。（2）業務需求通常由銀行各個職能部門提出，業務部門只從自己負責的業務角度出發考慮，缺乏與其他業務部門之間必要的溝通交流，缺少整合 性。許多需求僅僅是出于單個專業的需要，而不是全行整體需要，造成業務做法不能很好相互借鑒，有的甚至產生矛盾。在信息系統中相互制肘，重復又各成體系，形成不必要的內耗。

（3）業務人員對信息系統及整個銀行業務處理流程及制度要求，缺乏深入了解掌握，造成撰寫的需求內容描述不清楚，不準確。

（4）需求說明書沒有模版，業務部門沒有參照，或是科技部門提供的模版實用性不強，不符合業務要求。或更多是科技部門從技術要求方面出發，按照軟件功能說明書內容格式讓業務部門撰寫需求。業務部門對很多技術要求不熟悉，不知道如何下手撰寫。再有，模版過于教科書化。文檔模版編寫時，沒有很好 依據公司自身現狀，從實際出發并實地征求業務部門意見，造成業務部門不愿意或無法按照科技部門提供的需求撰寫模版撰寫需求，達不到預期效果。（5）業務與科技部門缺少需求交流機制、交流平臺，大家都無法積極主動交流，無法傾聽相互之間的意見。

三、提高撰寫質量的措施

提高業務需求撰寫質量，就要真正反映業務真實想法，和業務保持一致，并能提供科技部門軟件研發需要的業務需求，確保在軟件項目研發過程中，各項研發工作和需求之間的一致性，是需求管理的一項重要內容。

（1）業務與科技要建立良好的交流與合作關系。優秀的軟件產品是建立在優秀的業務需求基礎之上的，高質量的軟件產品來源于業務人員和技術人 員相互之間有效的交流與合作。業務與科技部門要建立一個良好的業務需求交流溝通渠道和機制，解決工作中有關需求不清、推諉扯皮現象的發生，以面對面交流為 主，郵件、電話為輔。業務人員撰寫完成業務需求后可以通過郵件的形式發給科技人員，讓科技人員提出修改完善建議，相互之間交流溝通后，經過對業務需求說明 書反復多次修改后再提交。

（2）科技部門要做好角色的轉變，幫助業務部門其實就是幫助自己，不要認為業務需求與科技部門無關。科技部門不能只關心技術，更應該關心產 品，跟蹤產品應用情況，參與業務需求制訂，與業務部門一起做好市場調研，參加前端性產品的研究和發展，幫助業務部門優化需求，可以提供業務需求說明書樣本 讓業務人員參照學習。

（3）業務需求要分類管理。業務需求通常可以分為新產品研發需求、功能變更需求、數據提取需求、生產問題需求等，針對不同業務要求設計不同 的業務需求撰寫格式。新產品需求需要設計詳細的需求撰寫格式。功能變更需求、數據提取需求和生產問題需求要專題專述，變更那里則提出那里的數據，哪個系統 出現了問題、出現的問題現象是什么等內容，要重點突出，內容描述簡單明了。（4）業務需求說明書撰寫基本要求。①標準化：他山之石，可以借鑒，善于學習運用CMMI標準及其他軟件公司好的做法，針對不同的業務需 求，都要給出一個符合公司實際，行之有效的撰寫標準。②易用性：業務部門撰寫的業務需求說明書要便于不同崗位人員進行閱讀、理解、學習和使用。③簡潔性： 業務需求書中描述的內容要突出主題，只反映要描述的問題，不包含其他不必要的東西，語言表達簡明扼要，一清二楚，可以配以適當的圖表，以增強其清晰性。④ 針對性：業務需求說明書要按不同的需求類型、面對不同的業務對象，實行差異化編制，根據實際需要進行編寫。⑤一致性：業務需求說明書中的文字描述應當十分 確切，對于同一業務描寫，不能出現多義性的描述，應當是一致，相互之間沒有矛盾。⑥完整性：業務需求說明書都應當是完整的、獨立的，沒有遺漏和丟失的內 容。對于需求內容相同的部分，這種重復是必要的，不要圖省事避免在文檔中出現“見XX文檔XX章節"的現象。⑦靈活性：不同的新產品研發需求，因其復雜程 度和規模不同，在保持需求格式不變的情況下，也需要對需求說明書內容中不同部分描述詳細程度做調整。⑧可追溯性：業務需求說明書作為軟件項目研發的一個重 要文檔，并不是孤立的，而是與各個階段完成的工作有密切的關系，隨著研發工作的逐步延伸，具有一定的繼承關系，體現出了可追溯的特性。如需求變更說明是在 原來業務需求說明書基礎之上的變更，軟件需求說明書會在詳細設計說明書、測試案例等文檔中有所體現。

（5）做好業務人員的培訓學習。在工作交流過程中，業務人員經常講，“科技人員總說業務需求寫得不清楚，怎樣寫才能符合科技要求？”因此，針對如何撰寫高質量的業務需求設計開發培訓課程，有針對性地對業務人員進行培訓，引導和教會業務人員撰寫業務需求說明書，通過工作不斷溝通交流、完善修 改，寫出一份業務與科技都滿意、高質量的業務需求也不是一件難事。

第二篇：如何編寫高質量“軟件需求說明書”.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中過多的申述需求。在多處包含相同的需求可以使文檔更易于閱讀，但也會給文檔的維護增加困難。文檔的多份文本要在同一時間內全部更新，避免不一致性。

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

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

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

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

現在你正在設計其中的一個特性，已經發現了需求的一些問題。你可以用多種不同的方式解釋需求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中過多的申述需求。在多處包含相同的需求可以使文檔更易于閱讀，但也會給文檔的維護增加困難。文檔的多份文本要在同一時間內全部更新，避免不一致性。

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

第四篇：如何撰寫高質量論文

如何撰寫高質量論文

一看論文的選題是否有創新

所謂選題，就是要確定文章的主題，明確文章要寫些什么，要闡述什么思想觀點。古人說，“意在筆先”，也就是說，只有確定好了主題。才好動筆。還有人說，“確定一個好的主題，等于完成論文工作的一半”。因此，確定論文主題是撰寫論文的第一要務。

那么，怎樣才能選好主題呢?最關鍵的就是主題要有新意。創新是文章的靈魂，論文的好壞就取決于此。我們評價一篇文章有沒有價值，就看這篇文章有沒有新意。“文貴出新”，這是最根本的要求：那么，什么是“新”呢?主要表現為新的思想、新的見解、新的視角。一是觀念要新。就是說，文章寫作的指導思想要正確，要符合新的教育思想和教育觀念。如果你文章講的仍然是舊的觀念、舊的培養模式、舊的教學方法，那就不行了。比如，我們對教學觀的探討，就經歷了一個從“知識本位”到“能力本位”，再到現在的“以人為本”的過程。現在，你寫文章講教學觀，就要講以人為本，以學生為本，千萬不要講以知識為本位。二是角度要新。就是說，論文選題的角度要別具一格。“一樹梅花萬首詩”，“橫看成嶺側成峰，遠近高低各不同”，講的就是觀察事物的新視角。選題同樣有個角度問題、找切入點的問題。同樣的問題，同樣的材料，不同人來選就有不同的感受、不同的主題。因為他們看問題的角度不同。我們在選題時必須堅持：“老問題要有新角度，常規的東西要有特色。”如《融“逗”于數學教學中》一文，通過相聲能逗大家樂這二現象啟示，把相聲“逗”的藝術應用到數學教學中，來激發和保持學生的學習興趣，作者選題的角度就比較獨特。又如《在數學教學中如何培養學生的閱讀能力》、《淺談在課堂教學中合作技能的培養》，選題也比較好，很有新意。

在選題時，中小學教師要注意兩個問題．一是陳舊雷同，二是貪大求全。選題陳舊雷同和貪大求全都有悖創新，寫出來的論文也談不上有什么價值，論文題目小，觀點集中，以小見大，就容易做到厚積而薄發。題目小的對立面就是大而空，貪大求全。如《素質教育淺談》、《素質教育中的數學教育》、《職業教育之管見》、《談語文教育中的思想教育》、《淺談創新教育》等。這些題目的概念外延都很大、很全，盡管有的在“談”前冠以“淺”字，或者綴以“之管見”，但那都是客套話。關鍵是貪的面大，要談的問題根本沒談清楚。在實際中，初學寫作的人比較喜歡用全景式、統覽式、鳥瞰式的題目來寫文章，這些文章可能涵蓋的內容多，比較容易寫。殊不知，有不少這類文章，因為沒談清楚而被編輯“槍斃”。

二看論文的題目是否恰當

題目是什么?《說文解字》中是這樣解釋的：“題”，就是額頭，“目”，就是眼睛。人們常說，器宇軒昂、眉目清秀是帥哥靚女的“題目”，給人留下的印象是瀟灑和漂亮。文章的題目亦然。如果第一眼見你的文章題目不行，那就完蛋了。如《抓關鍵，提質量》一文，明顯缺少一個副標題，一看題目，不明白文章的主題到底是什么。

“文章要好，題目要巧”。有的文章題目好，令人拍案叫絕，過目不忘，甚至終生難忘。例如，馬克思的《哲學的貧困》、《路易.波拿巴十八日》，恩格斯的《反杜林論》、《社會主義從空想到科學的發展》，列寧的《寧肯少些，但要好些》、《進一步，退兩步》，毛澤東的《星星之火，可以燎原》、《反對本本主義》、《別了，司徒雷登》，鄧小平的《兩個“凡是”不符合馬克思主義》、《尊重知識，尊重人才》、《科學技術是第一生產力》，江澤民的《創新是民族進步的靈魂》、《面向新世紀的中國共產黨》等等，都是十分好的題目。有些理論家、學者的文章題目也起得非常好，如胡喬木的《西藏的革命和尼赫魯的哲學》、《中國共產黨怎樣發展了馬克思主義》，胡繩的《馬克思主義是發展的理論》，郭沫若的《甲申三百年祭》、《科學的春天》等等，堪稱題目的典范。至于魯迅先生，更是文章高手，他的文和題，極具創造力和個性，諸如《一件小事》、《辱罵與恐嚇決不是戰斗》、《戰士與蒼蠅》、《中國人失掉了自信心了嗎?》、《罵殺和捧殺》、《老調子已經唱完》等等，清新雋永，回味無窮。

那么，怎樣的題目才算好呢?有三點是共識的：第一，貼切、醒目、生動，不能太平淡；第二，題目要小一些、短一些、簡潔-些，題目不能太長，不要超過20個字。第三，要有爪．1生，切忌似曾相識，人云亦云。總的來說，文章的題目要令人耳目一新。如，《融“逗”于數學教學中》、《課堂導語的設計》、《班主任的“糊涂藝術”》等，就是很好的題目。

三看論文的觀點是否有吸引力

在中小學教師撰寫的論文中，很多觀點都是照搬有關雜志上文章的觀點，沒有自己的體會和特色。也就是說，觀點一般化，沒有吸引力。如《讓學生主動參與學習，真正成為學習主人》一文，寫了四個觀點：創造情境；動手操作；質疑問難；交流討論。主題很好，但觀點缺乏新意，太一般化了。又如《在創新中求發展----對小學數學課堂教學的幾點探討》一文，講了四個觀點：改進課堂教學結構；改革課堂教學方法；改進課堂教學的組織形式；突出學生的主體作用，優化課堂練習過程。觀點覆蓋面太大，每一個觀點都可以寫一篇大文章。又如《淺談數學課堂教學與素質教育》一文，講了5個觀點：素質教育的主體性；素質教育的發展性；素質教育的差異性；素質教育的創造性；素質教育的滲透性。雖然作者結合教學實踐談了素質教育的“五性”，但以這“五性”為二級標題，就不貼切，針對性和吸引力都不強。

一篇優秀的教學論文，它的觀點應該語言精練，緊扣中心，并且能準確地概括自己所寫的內容。有一位同志寫了一篇《寫字教學斷想》的文章，這篇文章總共談了三個觀點。原先的三個觀點是：1．重視教師的寫字基本功；2．平時寫字也要有練字意識；3．抓好“一寸”是關鍵。這三個觀點概括每段的內容本來是準確的，但他覺得比較一般化，不能給人留下深刻的印象。于是，他反復琢磨，作出了如下修改：1．打鐵還得自身硬；2．提筆即是練字時；3．牽牛要牽牛鼻子。意思還是那個意思，但用的是熟語。熟語大家經常說，生動形象，表現力強，讀者看一篇就記住了，表達的效果就不一樣。

四看論文是否有自己的感受

寫論文要有自己的感受和個性，千萬不要盲目地照搬照抄。教學論文如果寫得實在，讓人讀后就會感到所舉例子來自自己的教學實踐，不虛假且操作性強。這樣的文章，讀者讀起來才有親切之感，才會津津有味，永讀不厭。因此，教學論文的“實”主要體現在實踐性和應用性上。如有篇《感受古詩語言的精練與優美》的論文，講了五點：一是比較辨析，感受語文的精確性；二是品味推敲，學習語言的精練性；三是拓展描述，體悟語言的豐富性；四是朗讀背誦，體會語言的音韻美；五是角色表演，體會語言的情感性。文章從五個方面來論述古詩語言的精練與優美，一看感受就很實在，又讓人知道怎樣操作。每一點下面又都有具體例子，一點也不空洞。這是一篇既有實踐性，又有應用性的好論文。

每年中小學教育教學優秀論文的評選，發現不少論文純粹是定義、概念、觀點加上一些例子的簡單組合，缺乏自己的分析、綜合、提煉、推理，看不出到底是作者本人的感受，還是別人的感受，不能給人以深刻的印象。有的論文引用經典和名言過多，缺乏自己的見解和分析。誠然，恰當地引用經典和名言能給文章起到畫龍點睛的作用。但引用要恰到好處，適可而止，如果過多過濫，則適得其反。一篇教學論文真正能打動讀者、啟迪讀者的，往往并不一定是經典和名言的力量，而是論文作者對教學領域中某些方面、某些問題深邃而獨到的見解和縝密精辟的分析。因此，教學論文要反映對教育或教學現象的一些真實認識和感受。只有認識深刻，感受才能新穎；是自己的感受，才能有個性，才能給人以新知。

五看論文的思路是否清晰，結構是否嚴謹

許多中小學教師的論文存在論述欠完整，層次不清，思路混亂，缺乏邏輯性的現象。這是撰寫教學論文最忌諱的。要克服這一毛病，寫論文時就必須重視布局謀篇。所謂布局謀篇。就是籌劃采用怎樣的結構，選擇哪些材料，才能有效地表達主題。布局謀篇，是寫好文章的一個重要問題，是必不可少的一個準備過程。如果說一篇文章的主題猶如人之“靈魂”，一篇文章的材料好比人之“血肉”，那么一篇文章的結構，正恰似人之“骨骼”。沒有靈魂只能是一個軀殼；沒有血肉就只剩了一個空架子；而沒有堅實、健壯的骨骼，血肉就無所依附，靈魂也無處寄托。因此，布局謀篇這個工作做好了，就會思路暢通，順理成章．否則，心中無數，邊想邊寫，就難以寫好文章。

第五篇：招標需求說明書

競爭性談判-需求說明書

（參考）

行政部：

為配合**開業慶典活動籌備安排，特向貴部提出慶典活動項目招標（競爭性談判）需求，具體說明如下：

一、招標（競爭性談判）內容：

**開業慶典系列活動項目承辦單位招標（競爭性談判）。

二、招標（競爭性談判）項目的基本需求：

（一）活動整體安排：

根據改制工作進度安排，**擬于2009年**月中下旬獲批成立，并擬于**月**日舉行開業儀式慶典活動，活動內容擬包括：

1、開業慶典儀式：

（1）時間安排：**月**日上午（時長約為1小時）。

（2）地點安排：**大廈東廣場

（3）出席人數：擬邀請省、市各級領導和重要嘉賓合計約250人。

（4）主要流程：A、省、監管單位、市、農商行領導分別致辭。

B、主要領導共同揭牌儀式。

C、**公益捐贈儀式。

2、開業慶典晚宴：

（1）時間安排：**月**日晚上（時長約為2小時）。

共 5 頁·第 1 頁

（2）地點安排：擬于**香格里拉大酒店（**廳）或**路**酒店（國際宴會廳）。

（3）出席人數：擬邀請省、市各級領導和重要嘉賓合計約500人。

（4）主要流程：A、省、市領導致辭。

B、主要領導祝酒儀式。

C、表演助興（如歌舞、魔術、雜技等）及現

場抽獎環節。

（二）承辦工作要求：

1、本次慶典活動項目執行工作中的客戶邀請、禮品購置、宴席餐飲、媒體投放等均由我單位另行安排，承辦單位提交的投標方案內容應包括：

（1）對活動整體流程的策劃，并提供相應的策劃方案書、時間進度和分工安排表等書面材料。

（2）對會場宣傳布置的構思，要求宣傳布置范圍以**大廈為中心、輻射周邊1000米內主要路段，包括各項平面設計、物料設計、舞臺設計等，并提供相應的平面設計稿、三維效果圖、物料清單等。

（3）對節目和演員的建議，包括歌舞、雜技、魔術等，并提供相應的節目和演員情況介紹、費用報價等；中標后可根據我單位實際要求進行調整變更，并負責具體聯系邀請和彩排協調等工作。

（4）對司儀和導演的推薦，包括開業儀式司儀1人、晚宴司

儀2人、晚宴導演1人，并提供相應的個人介紹材料、費用報價等；中標后可根據我單位實際要求進行調整變更，并負責具體聯系邀請和彩排協調等工作。

（5）對公益捐贈舉措的建議，包括與國內外知名慈善機構、官方組織等的捐贈合作，提供相關機構情況、捐贈模式等情況介紹，中標后協助我單位聯系溝通。

（6）對活動執行協調措施的說明，包括戶外活動可能涉及的消防、環保、治安等公共安全問題，及施工質量、效率和安全性問題，提供相關解決措施說明；中標后需負責執行消防、城管、環保、公安等相關申報程序。

（7）除上述內容外，對我單位臨時補充要求的回復。

2、針對上述要求，我單位制定了“宣傳策劃基本要求說明”（見本需求附件1），各投標單位須以此基本要求說明為基礎制定整體活動方案，并在投標方案中對開業慶典儀式和開業慶典晚會分別進行報價（含稅），報價表應列明估算的相關尺寸、數量、材質等內容，各項報價應合理、真實、具備可操作性。

3、中標單位須適應我單位內部的法律文書審核和財務報批支付等流程規定，并統一提供中標公司發票。本次慶典活動項目費用將按30%預付、30%二期、40%尾款方式分三次支付，其中預付款于合同簽定后五個工作日內支付，二期款于實施當天前五個工作日內支付，尾款將于活動結束后十個工作日內結清。

（三）投標公司資質要求：

1、投標單位應為國內綜合實力較強、行業信譽較好的公關策劃/品牌傳播/廣告制作公司，注冊資本需折合人民幣200萬元（含）以上，登記在職員工30人（含）以上；

2、投標單位應具備成熟完善的分工架構和服務流程，自有專職策劃及客服人員5人以上、高級設計人員5人以上、專業工程人員10人以上，有曾為三家以上國內知名大型企業策劃執行各類大型慶典活動的成功案例。自設大型制作工廠或具備國內4A評級（含）以上的廣告公司將優先考慮；

3、投標單位主要辦公場所應在本市區范圍內。

4、投標單位應根據上述要求提供相關證明文件、文字和圖片介紹資料。

三、招標建議：

1、每一投標單位必須同時承辦開業慶典儀式和開業慶典晚會兩項活動；

2、中標單位數量：壹個。

3、建議評標方式：投票法。由我單位開業慶典活動領導小組組成評委會，根據投標單位的綜合實力、策劃創意、整體報價等，投票選出中標候選單位，報單位領導審批確定后公布。

4、我單位可根據實際需要對“宣傳策劃基本要求說明”的項目內容進行增減。

5、投標單位須提交資料包括：

（1）開業慶典活動整體策劃方案（含報價）；

（2）投標單位相關資質證明文件、文字和圖片介紹資料；

（3）我單位要求的其他資料。

6、考慮到慶典活動籌備時間較緊，建議本次招標（競爭性談判）流程于**月**日前完成并公布結果。

附件：**慶典活動宣傳策劃基本要求說明

**辦公室年月日