最近需要做乙個b/s結構的小系統，需要用jsp開發（考慮與其它平台的整合）。 這週跟使用者談了一下，開始編寫需求分析文件。昨天寫完乙個初版的需求文件出來，拿去跟使用者談了一下，發現還有好幾個內容沒有包含進去。今天再修改完整一點。
以前都是用cobol開發，也沒有細寫分析文件，只有系統設計文件，最後導致在測試過程中程式**反覆修改。希望這次按軟體開發的標準流程走一遍，把後期的程式開發的時間縮短一點。按前人正常的開發流程的經驗，軟體開發只佔整體時間的30%左右，前面寫可行性分析，需求分析，系統設計（概述，詳細）要佔50%的時間。希望這次自己能做得好一點。a good begin makes a good ending.
今天先把自己的寫的需求分析文件模板共享出來。希望大家提提意見。
1．引言
1.1編寫的目的
說明編寫這份需求說明書的目的,指出預期的讀者.
1.2背景
a. 待開發的系統的名稱;
b. 本專案的任務提出者、開發者、使用者；
c. 該系統同其他系統或其他機構的基本的相互來往關係。
1.3定義
列出本檔案中用到的專門術語的定義和外文首字母組詞的原片語。
1.4參考資料
列出用得著的參考資料。
2．任務概述
2.1目標
敘述該系統開發的意圖、應用目標、作用範圍以及其他應向讀者說明的有關該系統開發的背景材料。解釋被開發系統與其他有關系統之間的關係。
2.2使用者的特點
列出本系統的終端使用者的特點，充分說明操作人員、維護人員的教育水平和技術專長，以及本系統的預期使用頻度。
2.3假定和約束
列出進行本系統開發工作的假定和約束。
3．需求規定
3.1對功能的規定
用列表的方式，逐項定量和定性地敘述對系統所提出的功能要求，說明輸入什麼量、經怎麼樣的處理、得到什麼輸出，說明系統的容量,包括系統應支援的終端數和應支援的並行操作的使用者數等指標。
3.2 對效能的規定
3.2.1時間特性要求
說明對於該系統的時間特性要求。
3.2.2靈活性
說明對該系統的靈活性的要求，即當需求發生某些變化時，該系統對這些變化的適應能力。
3.3資料管理能力要求（針對軟體系統）
說明需要管理的文捲和記錄的個數、表和文捲的大小規模，要按可預見的增長對資料及其分量的儲存要求作出估算。
效能測試從需求分析開始
自從年後轉崗專職自動化測試崗位後，效能測試基本被我丟一邊了，好久沒更新效能測試相關的部落格了。今晚和朋友討論完自動化測試框架的優化之後，有認識的同行問我乙個效能相關的問題，就和他聊了下我的一些建議。這篇部落格，就以今晚的效能話題為主，聊聊效能測試中，從需求分析開始，要做哪些事情吧。一 產品需求 1 ...
需求分析 需求文件（需求分析結果）的作用
需求分析學習指導目錄 1 在需求方面達成一致 需求是一種反覆進行的過程，涉及到各種各樣具有不同背景和要求的使用者，需求文件必須有助於需求分析師與使用者之間的溝通，以及需求分析師與軟體設計師和測試工程師之間的溝通 2 為軟體設計提供基礎 需求文件必須為軟體設計人員提供精確的輸入，因為設計人員不是應用領...
需求分析 及需求文件的編寫
通常，軟體開發工程師和軟體測試工程師的工作都開始於軟體需求說明書成型的基礎上。那麼軟體需求說明書到底是怎麼來的，軟體的需求分析到底怎麼做？今天我就針對這個話題結合我自己的一些理解和經歷來梳理一下。需求分析的目標是將產品的需求功能梳理，並且用通俗易懂的文字描述，為開發人員和測試人員提供依據。那麼需求的...