怎樣編寫業務需求一、背景知識簡介二、怎樣編寫高質量的業務需求文檔三、實例分析與展示一、背景知識簡介1.軟件工程學的基本思想軟件工程學的基本思想就是將軟件當作一種工程產品來處理，從時間角度對軟件開發和維護的復雜問題進行分解，把軟件生命的漫長周期依次劃分為若干個相對獨立的階段，并給每個階段賦予明確而有限的任務。階段關鍵問題結束標準可行性研究系統建設是否可行？可行性研究報告需求分析系統必須做什么？軟件需求說明書總體設計概括地說，應該如何解決這個問題？推薦的系統架構詳細設計怎樣具體實現這個系統？編碼和單元測試編寫正確的程序模塊源程序清單；單元測試方案和結果綜合測試符合要求的軟件綜合測試方案和結果系統運維持久的滿足用戶需要的軟件2.需求分析的重要性1.在失敗的項目中，需求不明確、需求不完整和需求變化等方面的原因占到了60％。2.軟件的需求分析是軟件生存周期的重要階段，它是聯絡顧客與軟件開發者的紐帶。3.業務需求文檔的定義業務需求文檔是對一種待開發的系統的描述，是系統開發人員與顧客就產生一種什么樣的系統互相交流的產物，是系統各項后續開發的基礎。4.業務需求文檔的作用開發企業根據包括在軟件需求闡明書中描述的系統來估計開發成本，制定規劃并預測進度安排、工作量和資源；開發人員依賴它來理解他們將要開發的系統，并據此進行編碼工作；測試人員根據文檔中對系統行為的描述制定測試計劃、測試用例，進行測試工作。系統運維人員和技術支持根據文檔理解系統的功能；根據業務需求文檔編寫顧客手冊。業務需求文檔是我們系統建設過程樹立的一種對的的航標。有了這樣一種航標，就可以使我們最終可以抵達一種對的的彼岸。二、怎樣撰寫高質量的

業務需求文檔

1.業務需求文檔的常見問題（1）需求過于簡樸。（2）需求內容不完整。（3）需求內容描述不清晰。（4）需求不具有可行性。（5）需求文檔沒有統一撰寫格式。2.提高撰寫質量的措施（1）業務人員和技術人員要建立良好的交流與合作關系。倡導的讓業務人員、技術人員、開發人員構成一種團體，使用統一的語言，來體現大家都清晰明白的概念。（2）技術人員應當轉變觀念，積極參與業務需求的編寫，不要認為業務需求與技術人員無關。（3）使用業務需求原則模板1．引言1.1編寫目的描述你編寫這篇文檔的目的和作用。但最關鍵的是，詳細闡明哪些人可以使用這篇文檔，做什么。1.2業務背景可以描寫與項目有關的單位現實狀況、問題分析與處理思緒，以及觸發開發該項目的大背景、政策法規，等等。1.3項目目的（或任務概述）就是項目能為顧客帶來什么利益，處理顧客什么問題，或者說怎樣才算項目成功。1.4參照資料參照資料的名稱、作者、版本、編寫日期。1.5名詞定義文檔中也許使用的多種術語或名詞的定義與約定，可以根據需要刪減。2．整體概述這部分可以對系統進行一種整體性框架性地描述。3.功能需求一種一種的詳細描述系統中的每個功能模塊（或子系統），包括業務描述、功能描述、輸入輸出、表單樣式、數據來源等等。這部分是業務需求文檔中最重要的部分。3.1功能描述可以用自然語言描述模塊的功能。對某些流程性的事務，用自然語言比較繁瑣的，可以畫流程圖來輔助描述。3.2實現方式從顧客界面的角度，描述系統的功能。4.非功能性需求重要關注系統的性能、安全性、可靠性、易用性等等。例：內網考勤要支持高并發操作（估計并發顧客峰值：xxx）。例：數據導出功能。

可靠性就是系統可以可靠運行，包括系統成熟度（數據吞吐量、并發顧客量、持續不停機性能等）、數據容錯度、系統易恢復性，等等。可支持性：在需求分析與設計階段，可支持性實際上體目前，我們與否能有效識別系統可變的需求，并可以提供合理的方案。3.業務需求文檔編寫的一般原則（1）完整性：對詳細需求的描述應當完整清晰。（2）一致性：對于同一業務描寫，不能出現多義性的描述，應當是一致，互相之間沒有矛盾。（3）防止在多處論述同一需求：由于一種需求需要更新時，所有對它的描述都必須更新，否則輕易導致不一致性，給閱讀人員帶來困惑。例：“執行任務時，系統應在不少于每60秒的正常周期內顯示出狀態信息”。重寫需求的一種措施如下：1.在顧客界面的XX位置顯示狀態信息，狀態的刷新間隔為60秒；2.假如后臺進程處理正常，那么應當顯示任務已完畢的比例；3.任務完畢時，應顯示有關的信息；4.