軟體需求分析怎麼寫

⑴ 軟體需求分析說明書中對性能的規定這部分怎麼寫啊

對性能的規定

1、精度

說明對該軟體的輸入、輸出數據精度的要求，可能包括傳輸過程中的精度。

2、時間特性要求

說明對於該軟體的時間特性要求，如對：

a、響應時間；

b、更新處理時間；

c、數據的轉換和傳送時間；

d、解題時間；等的要求。

3、靈活性

說明對該軟體的靈活性的要求，即當需求發生某些變化時，該軟體對這些變化的適應能力，如：

a、操作方式上的變化；

b、運行環境的變化；

c、同其他軟體的介面的變化；

d、精度和有效時限的變化；

e、計劃的變化或改進。

對於為了提供這些靈活性而進行的專門設計的部分應該加以標明。

4、輸入輸出要求

解釋各輸入輸出數據類型，並逐項說明其媒體、格式、數值范圍、精度等。對軟體的數據輸出及必須標明的控制輸出量進行解釋並舉例，包括對硬拷貝報告（正常結果輸出、狀態輸出及異常輸出）以及圖形或顯示報告的描述。

5、數據管理能力要求

說明需要管理的文卷和記錄的個數、表和文卷的大小規模，要按可預見的增長對數據及其分量的存儲要求作出估算。

6、故障處理要求

列出可能的軟體、硬體故障以及對各項性能而言所產生的後果和對故障處理的要求。

7、其他專門要求

如用戶單位對安全保密的要求，對使用方便的要求，對可維護性、可補充性、易讀性、可靠性、運行環境可轉換性的特殊要求等。

(1)軟體需求分析怎麼寫擴展閱讀：

軟體需求分析所要做的工作是深入描述軟體的功能和性能，確定軟體設計的限制和軟體同其它系統元素的介面細節，定義軟體的其它有效性需求。

進行需求分析時，應注意一切信息與需求都是站在用戶的角度上。盡量避免分析員的主觀想像，並盡量將分析進度提交給用戶。在不進行直接指導的前提下，讓用戶進行檢查與評價。從而達到需求分析的准確性。

分析員通過需求分析，逐步細化對軟體的要求，描述軟體要處理的數據域，並給軟體開發提供一種可轉化為數據設計、結構設計和過程設計的數據和功能表示。在軟體完成後，制定的軟體規格說明還要為評價軟體質量提供依據。

⑵ 軟體需求說明怎麼寫

如何寫需求分析報告（軟體需求說明書GB856T-88）

近來學校的一些科研項目又在申報了，一些學弟開始Q我一些軟體工程上書面的問題。大概的總結了下，寫到這里。本文涉及到的是需求分析部分的書寫，主要是根據國家標准文檔中的要求來的。

在互聯網公司或者一些敏捷開發的公司里，其實大家都是秉承著重開發，重討論，而輕文檔的態度。這個輕文檔並不是指沒有文檔或者幾乎不做文檔，而是在嚴格的文檔流程中解脫出來，只把最最實際的部分寫出來。這個特徵是有互聯網本身迭代周期短，版本發布快等特點決定的。而在實際的兼職項目的時候，同學們就要注意了，最重要的應該就是在簽合同的時候一定要附上最清楚的一份需求分析，雖然這份需求說明可能不是按照某些標准文檔而來的，描述清楚每個功能達到的效果，而這個效果一定要讓客戶點頭確認，而不能出現「應該是」、「可能是」、「也許是」這樣的模糊回答。否則在項目後期就會比較難過了。在學校申請的項目和大型公司項目開發中，是重視文檔流程的，一部一部來。所以還是看情況來對待文檔的深度和標准。

一、目錄：目錄要用word的「引用」—>」目錄」，自動生成目錄，一般都是要三級目錄。通常這部分基本都不需要改結構，直接更新頁碼即可。

二、內容部分。國家標准軟體需求說明書G856T-88下載

1引言

1.1編寫目的

說明編寫這份軟體需求說明書的目的，指出預期的讀者。

（這部分說明需求分析報告的概況，例如：本X需求分析報告是為S系統而編寫的。+S系統的兩句話概述。+本X報告旨在使U1（需求者）明確S系統的要求和細節，給U2(開發人員)了解需求實現的難度和困難，最終提供給U3（審核人、管理者）討論和審核，達到溝通效果）

1.2背景

說明：

a．待開發的軟體系統的名稱；

b．本項目的任務提出者、開發者、用戶及實現該軟體的計算中心或計算機網路；

c．該軟體系統同其他系統或其他機構的基本的相互來往關系。

（這部分可以將a,b,c分為2部分，例子如下：

1.2.1項目概況

本需求分析報告所預期開發的軟體系統是:S。S是（不是則無）SS系統的某一個功能子模塊，S和S1、S2等系統之間的聯系，以及概述其他系統的狀態等等。

1.2.2任務分配

a.任務提出者：xxx

b.軟體開發者：xx

c.產品使用者：xx

d.文檔編寫者：xx

e.預期產品使用者：xx

）

1.3定義

列出本文件中用到的專門術語的定義和外文首字母組詞的原片語。

（這部分很簡單，就是描述專業詞彙，比如

1. XML(Extensible Markup Language)即可擴展標記語言,它與HTML一樣,都是SGML(Standard Generalized Markup Language,標准通用標記語言)。

2. Word2,解釋。。。

）

1.4參考資料

列出用得著的參考資料，如：

a．本項目的經核準的計劃任務書或合同、上級機關的批文；

b．屬於本項目的其他已發表的文件；

c．本文件中各處引用的文件、資料、包括所要用到的軟體開發標准。列出這些文件資料的標題、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來源。

2任務概述

2.1目標

敘述該項軟體開發的意圖、應用目標、作用范圍以及其他應向讀者說明的有關該軟體開發的背景材料。解釋被開發軟體與其他有關軟體之間的關系。如果本軟體產品是一項獨立的軟體，而且全部內容自含，則說明這一點。如果所定義的產品是一個更大的系統的一個組成部分，則應說明本產品與該系統中其他各組成部分之間的關系，為此可使用一張方框圖來說明該系統的組成和本產品同其他各部分的聯系和介面。|

（

本模塊開發主要是為SS的整體服務，完成SS工作中的XX部分以及相關的工作。其涉及的范圍就是，從下達A、B命令後，到給出C結果的過程。具體描述：B1，來完成B11功能；B2，來完成B22功能；等等。本部分是（否）耦合在分詞工具包其他部分中的，主要為嵌入方式和先後方式相互交互。

圖

圖1.該系統的組成同其他各部分的聯系和介面

）

2.2用戶的特點

列出本軟體的最終用戶的特點，充分說明操作人員、維護人員的教育水平和技術專長，以及本軟體的預期使甩頻度。這些是軟體設計工作的重要約束

（例如：二次開發和系統調用人員：具有很高的專業知識水平，理解XX的運行機制。可以對開放代碼進行閱讀和分析，以完成其系統獨特的需求，提供給這部分用戶開放API手冊和Debug版本的源代碼即可；預期這部分用戶會占本系統總用戶量的多大部分。

xx使用者：具有一定的計算機操作能力和知識，了解xx領域的相關概念和用途。提供給這部分用戶操作手冊即可。預期這部分使用者主要是來簡單的xx操作。

維護人員：具有較高的計算機專業水平，可以對常見的系統Bug進行追蹤和分析，具有一定的測試能力。這部分用戶主要是採用了本系統之後的後期工作維護者。

等等

）

2.3假定和約束

列出進行本軟體開發工作的假定和約束，例如經費限制、開發期限等。

（這部分重要是對你有的技術力量、資金狀況、人力資源等情況的假設，以使得你可以在什麼樣的情況和時間范圍內完成工作。工期約束，經費約束，人員約束，地理約束，設備約束等幾個方面列舉說明。）

3需求規定

3.1對功能的規定

用列表的方式（例如IPO表即輸入、處理、輸出表的形式），逐項定量和定性地敘述對軟體所提出的功能要求，說明輸入什麼量、經怎樣的處理、得到什麼輸出，說明軟體應支持的終端數和應支持的並行操作的用戶數。

（例如：

INPUT輸入

PROCESS處理

OUTPUT輸出

LOAD負載量

A

預處理,做怎樣的動作，

AA

CC

B

BBBB

Bb

v

C

CCCC

cc

v

表一、xx模塊IPO表

對IPO表的簡單文字描述。

）

3.2對性能的規定

3.2.1精度

說明對該軟體的輸入、輸出數據精度的要求，可能包括傳輸過程中的精度。

（例如：

Xx目標處理：1Byt–10M，包括左右邊界值。

yy精度范圍：….

ZZ的精度：由於xx的特殊性，本系統均採用xx型來進行字元統計運算，概率部分以及其他比率部分精度精確到0.0x%。

）

3.2.2時間特性要求

說明對於該軟體的時間特性要求，如對：

a．響應時間；

b．更新處理時間；

c．數據的轉換和傳送時間；

d．解題時間；等的要求。

(這部分只要一一列舉就可以：

由於xxx過程中，需要大量xxxx操作或怎樣，故xx解題時間占總時間的最大部分。其次就是xx轉換和存儲的開銷。其具體時間特性要求，如下：

a．xx響應時間：xxms左右；

b．yy更新處理時間：yy；

c．zz數據的轉換和傳送時間：zz；

d．vv解題時間：vv。

等等

)

3.2.3靈活性

說明對該軟體的靈活性的要求，即當需求發生某些變化時，該軟體對這些變化的適應能力，如：

a．操作方式上的變化；

b．運行環境的變化；

c．同其他軟體的介面的變化；

d．精度和有效時限的變化；

e．計劃的變化或改進。

對於為了提供這些靈活性而進行的專門設計的部分應該加以標明。

（這部分按列舉來即可，由於本模塊第一目的是用於xxx，其次則是xxxx。故本模塊的靈活性在於實際應用者的不同。當需求發生某些變化時，該軟體對這些變化的適應能力。具體情況如下：

f．操作方式上的變化：採用集成運行制和獨立運行制兩種模式，集成運行制是把本模塊嵌入到分詞工具包的主框架中，提供給用戶具有一定UI的可操作軟體；獨立運行制是可以獨立運行於後台，並提供給各種程序調用的模式的工作方式，以增強其生命力。

g．運行環境的變化：主採用Windows平台的編譯版本運行和調試，在時間允許的情況下，同步開發支持SUSE Linux的伺服器版本。；

h．同其他軟體的介面的變化：在盡量保證介面不出現變動的情況下，允許介面的重載和再定義。但介面的命名規則是統一的；

i．精度和有效時限的變化：精度在必須調整的條件下，可以上下浮動10個百分點；有效時限則依據現實的測試情況允許稍大范圍的變化。

j．計劃的變化或改進：工作時間安排會存在必然的浮動，這部分要協同分詞工具包課題設計組其他成員一同來進行商定，前期的計劃可以稍微有些變動，後期的安排盡量按照計劃執行。

等等

）

3.3輸人輸出要求

解釋各輸入輸出數據類型，並逐項說明其媒體、格式、數值范圍、精度等。對軟體的數據輸出及必須標明的控制輸出量進行解釋並舉例，包括對硬拷貝報告（正常結果輸出、狀態輸出及異常輸出）以及圖形或顯示報告的描述。

（這部分可以把輸入輸出分為3.3.1輸入要求和3.3.2輸出要求，如下給出一個單元的例子。

XXX輸出

數據名稱：XXX輸出數據

實際含義：用於XX,表示XXXX

數據類型：Character(字元串)

數據格式：XX

數據約束：由於xxx,，大小在xx以內

）

3.4數據管理能力要求

說明需要管理的文卷和記錄的個數、表和文卷的大小規模，要按可預見的增長對數據及其分量的存儲要求作出估算。

（

根據實際系統要求列舉即可

Name名稱

Number數量

Size大小

Increase增長

詞典xx

xx

xxxx

並行執行，其大小依據實際xx大文本而增長

）

3.5故障處理要求

列出可能的軟體、硬體故障以及對各項性能而言所產生的後果和對故障處理的要求。

（包括軟體壓力，內存不足，硬體損壞等，這部分可以根據網路到其常見故障。）

3.6其他專門要求

如用戶單位對安全保密的要求，對使用方便的要求，對可維護性、可補充性、易讀性、可靠性、運行環境可轉換性的特殊要求等。

（例如安全保密性：密鑰更換等；預期擴展：擴展兼容等；OS更換：Slackware轉SUSE等

）

4運行環境規定

4.1設備

列出運行該軟體所需要的硬設備。說明其中的新型設備及其專門功能，包括：

a．處理器型號及內存容量；

b．外存容量、聯機或離線、媒體及其存儲格式，設備的型號及數量；

c．輸入及輸出設備的型號和數量，聯機或離線；

d．數據通信設備的型號和數量；

e．功能鍵及其他專用硬體

（列舉說明即可）

4.2支持軟體

列出支持軟體,包括要用到的操作系統、編譯（或匯編）程序、測試支持軟體等。

（操作系統和版本：xxxx

支撐環境和版本：xxxx

備用IDE環境和版本：xxxx

與該軟體有關的軟體組件：xxxx

後續可能擴展環境：xxxx

）

4.3介面

說明該軟體同其他軟體之間的介面、數據通信協議等。

(例如：

a．用戶和主程序調用介面(圖中介面1)。這個介面採用封裝API形式和函數調用形式，分別以外部調用和內部調用的方式為不同用戶提供使用本機械分詞工具的入口。例如以xxxx方式調用DLL文件，以xxxx方式調用函數。如下圖2所示。

圖2.軟體介面調用圖

b.xx介面(圖中介面2)。這里是一個xxx的介面調用過程。xxxx

)

4.4控制

說明控制該軟體的運行的方法和控制信號，並說明這些控制信號的來源。

(例如：

下面通過圖表的形式，將本模塊以及涉及到本模塊的軟體模塊的運行方法、控制信號，以及這些控制信號的來源，其中箭頭所指方向對應的模塊的控制信號來自箭頭另一方向的模塊，具體情況如下：

圖3 .控制流程圖

圖3的具體說明情況如下表所示：

Name模塊名稱

Method運行方式

Signal控制信號

Forward控制去向

主程序模塊

運行框架

用戶調用或運行

1.調用xx模塊

2.調用xx方法

3.調用標准輸出模塊

xxx模塊

xxx

xxx調用

Xxx模塊

)

附錄：軟體設計文檔國家標准(GB8567–88)軟體設計文檔國家標准(GB8567–88)GB8567——88
操作手冊（GB8567——88）.doc 資料庫設計說明書（GB8567——88）.doc
測試分析報告（GB8567——88）.doc 數據要求說明書（GB856T——88）.doc
測試計劃（GB8567——88）.doc 圖1.doc
概要設計說明書（GB8567——88）.doc 文件給制實施規定的實例（GB8567-88）.doc
開發進度月報（GB8567——88）.doc 詳細設計說明書（GB8567——88）.doc
可行性研究報告（GB8567——88）.doc 項目開發計劃（GB856T——88）.doc
模塊開發卷宗（GB8567——88）.doc 項目開發總結報告（GB8567——88）.doc
軟體需求說明書（GB856T——88）.doc 用戶手冊（GB8567——88）.doc

⑶ 軟體需求分析

自己上網查就能看到許多的版本！！

⑷ 軟體的需求分析怎麼寫啊

1. 引言

1.1編寫目的:編寫此文檔的目的是進一步定製軟體開發的細節問題,便於用戶與開發商協調工作.本文檔面向的讀者主要是項目委託單位的管理人員.希望能使本軟體開發工作更具體.

1.2項目背景

1.2.1項目委託單位:****公司

1.2.2開發單位:***公司

1.3定義

1.4參考資料

2. 任務概述

2.1目標:

<1> 決策支持:根據公司的要求及時提供所需報表及文件,並在適當時候對各部門領導給予銷售及進貨等方面的提示

<2>提高效率:利用軟體進行管理,避免人工管理的失誤以及 延遲性,從而實現高效率的管理.

2.2運行環境:

<1> 硬體方面:Pentium級處理晶元
1兆顯存的兼容顯卡
256色,800*600的兼容顯示器
標准兼容列印機

<2>軟體方面: WIN95操作系統

2.3條件與限制:

編程用計算機一台
完成期限2000/7/1
無資金供給

3. 數據概述

數據流程圖如下:

3.1靜態數據:包括系統登錄密碼,各資料庫所在位置,系統分析原始數據

3.2 動態數據:包括各資料庫內各項顯示數據,用戶登錄信息,系統時間

3.3資料庫描述:

人事管理資料庫:公司內人員的個人詳細信息,包括檔案信息
銷售管理資料庫:當日銷售記錄及以前的銷售統計,用於銷售分析
財務管理資料庫:公司內部賬目及收支情況詳表
技術管理資料庫:公司所需各技術檔案的詳細記錄(包括文檔)

3.4 數據字典:

<1>數據流詞條描述:

1.數據流名:登錄信息
來源:用戶的輸入
去向:系統內部檢驗部分
組成:用戶名,密碼
流通量:每次登錄輸入一次

2.數據流名:登錄結果
來源:系統
去向:用戶
組成:返回信息
流通量:每次登錄返回一次

3.數據流名:輸入修改信息
來源:用戶
去向:系統判斷部分
組成:根據各資料庫內容而不同
流通量:依用戶輸入而定

4.數據流名:反饋信息
來源:系統判斷部分
去向:用戶
組成:系統經判斷後發回的字元數據
流通量: 依系統當前信息而定

5.數據流名:識別信息
來源:系統內部檢驗部分
去向:系統判斷部分
組成:系統各資料庫的標識信息
流通量:用戶每次輸入流通一次

6.數據流名:處理信息
來源:系統判斷部分
去向:各資料庫處理部分
組成:讀取/修改標識,讀取/修改的變數名稱
流通量:用戶每次輸入流通一次

7.數據流名:讀取修改
來源:系統判斷部分
去向:系統各資料庫
組成:讀取/修改標識,讀取/修改內容
流通量: 用戶每次輸入流通一次

<2>數據文件詞條描述:

1.數據文件名:人事數據
簡述:存儲人員信息
數據文件組成:人員的各項信息(以CString類型為主)

2.數據文件名:銷售數據
簡述:存儲當日及從前的銷售記錄
數據文件組成:銷售的各項信息

3.數據文件名:財務數據
簡述:存儲財務管理信息
數據文件組成:財務管理的各項記錄

4.數據文件名:技術數據
簡述:存儲公司內部使用的技術檔案信息
數據文件組成:技術檔案名稱,內容

<3>加工邏輯詞條描述:

1.加工名:檢驗
簡要描述:判斷用戶的許可性
輸入數據流:登錄信息
輸出數據流:登錄結果
加工邏輯:判斷是否與系統內部用戶信息相符合

2.加工名:判斷
簡要描述:判斷用戶的操作並進行相應的讀取/存儲工作
輸入數據流:輸入修改信息
輸出數據流:反饋信息
加工邏輯:判斷用戶的操作->調用資料庫->讀取/修改->反饋

3.加工名:人事檔案管理
簡要描述:對人事資料庫進行相應要求的操作,並與判斷部分交互
輸入數據流:處理信息,讀取修改
輸出數據流: 讀取修改, 處理信息
加工邏輯:判斷用戶要讀取/修改的內容->反饋用戶所需信息

4.加工名:銷售統計
簡要描述:對銷售資料庫進行相應要求的操作,並與判斷部分交互
輸入數據流:處理信息,讀取修改
輸出數據流: 讀取修改, 處理信息
加工邏輯:判斷用戶要讀取/修改的內容->反饋用戶所需信息

5.加工名:財務統計
簡要描述:對財務資料庫進行相應要求的操作,並與判斷部分交互
輸入數據流:處理信息,讀取修改
輸出數據流: 讀取修改, 處理信息
加工邏輯:判斷用戶要讀取/修改的內容->反饋用戶所需信息

6.加工名:技術管理
簡要描述:對技術統計資料庫進行相應要求的操作,並與判斷部分交互信息
輸入數據流:處理信息,讀取修改
輸出數據流: 讀取修改, 處理信息
加工邏輯:判斷用戶要讀取/修改的內容->反饋用戶所需信息

<4>源點及匯點詞條描述:

名稱:用戶
簡要描述:既是源點又是匯點,發出動作信息給"檢驗"和"判斷"加工,通過交互界面接受反饋信息有關數據流:登錄結果,登錄信息,輸入修改信息,反饋信息
數目:一個

4. 功能需求

4.1功能劃分

可細分為四部分:人事管理,銷售管理,財務管理,技術檔案管理

4.2功能描述

<1>人事功能:

(1)能對公司內部的所有人員有關檔案詳細資料記錄並保存。
(2)能對資料庫內人事檔案的數據進行查閱和修改。
(3)能按部門或姓名檢索人員。
(4)當某員工的僱用期限達到整年時，按時提醒。

<2>銷售統計功能

(1)按日對公司的銷售情況進行統計,包括銷售額\銷售數量\各地區銷售比例\不同銷售方式的銷售量比例以及銷售毛利潤情況
(2)制定銷售情況的月報表\季報表以及年報表對銷售情況進行分析,對不同銷售人員的業績進行評定

<3>財務管理功能

(1)協助財務人員進行計算機管理,對庫存情況\進貨情況\銷貨進行登錄和輸出
(2) 根據預設的庫存情況提醒進貨
(3) 對收款情況進行統計,在應收帳款達到預設值時進行提示

<4>技術管理功能

(1)對技術資料進行登錄
(2)對維修記錄進行登錄和統計,按不同型號的機器進行故障整體分析,並作出分析報告
(3)對維修配件的需求進行管理並及時提示備貨

5. 性能需求

5.1數據精確度:因為此數據為公司內部數據,所以要求不能有誤差

5.2時間特性:當日銷售統計要求有即時性,馬上能反應出存貨的問題;同時財務管理數據計算當前存貨情況,並對進貨情況進行估算

5.3 適應性:此軟體只在公司內部管理人員的機器上使用,因此不考慮適應性

6. 運行需求

6.1用戶界面:

屏幕格式:

(1)要求有菜單及工具欄以方便操作
(2)各資料庫信息可在屏幕上直接修改
(3)各數據統計結果可在屏幕上顯示
(4)進行系統分析後的結果在另一窗口中顯示

報表格式:

(1)人事管理報表只要求有個人的普通數據
(2)銷售統計報表要求可分別列印當日統計或之前的統計
(3)財務統計報表要求列印出存貨及公司帳務詳表
(4)技術管理報表要求可以分別列印技術檔案總表和任一技術檔案文檔內容菜單格式:要求菜單項大致與WIN95標准相同,另外附加的功能做到新的單項中輸入輸出時間:年份以4位數字表示

6.2硬體介面:需要標准列印機介面進行報表列印

6.3 軟體介面:Windows標准介面

7. 其他需求

可使用性:要求容易使用,界面友好

安全保密性:因本數據屬於公司內部管理用關鍵數據,因此除公司管理人員外,其他人員不得訪問.要求設有登錄密碼檢驗功能,並且此密碼可以在以後進行修改

可維護性:要求本軟體的維護文檔齊全,便於維護

⑸ 需求分析實例軟體的需求分析一般怎麼寫

正好我參加日本的軟體比賽時寫過 這是我那時候些的需求分析設計書的目錄 你看看吧
一. 智能家居背景介紹... 3
（一）. 背景介紹... 3
二. 語音識別智能家居解決方案... 4
（一）. 方案總體介紹... 4
（二）. 語音識別智能家居解決方案實現原理... 6
（三）. 無線技術... 7
三. 方案實例——語音識別智能百葉窗簾... 8
（一）. 實例簡介... 8
（二）. 系統功能... 8
（三）. 詳細實現... 9
1. 硬體設計... 9
2. 軟體設計思路... 12
（四）. 操作方法及步驟... 14
1. 訓練：... 14
2. 識別階段:. 14
四. 總結... 15

⑹ 怎樣寫軟體開發需求分析

1、需求分析文檔的重要性
在軟體項目開發的生命周期中，可以說需求分析文檔占據著很重要的作用。
（1）它是和用戶進行交流得出的一個規范結果
（2）它是衡量和評價項目功能是否達到用戶需要的標准
（3）它對後期的資料庫設計、概要設計、詳細設計以及整個編碼開發、系統測試起著指引的作用

⑺ 軟體 開發項目 需求分析 怎麼寫最好給個案例看看

代理商和旅遊景點管理系統項目開發背景 消費劵管理系統是一個面向廣大客戶來源以及一個和代理商的業務流程的一個項目，由於該系統涉及的客戶面和業務較廣，系統的各項功能與各項管理消費劵息息相關，因此做好項目系統需求分析顯得至關重要。根據實際情況採用各種技術手段對消費劵的管理，爭取代理商、景點和客戶之間得到最大限度的需求。編寫的目的 為了讓開發人員能夠很快的了解該項目，了解該項目的需求，知道該項目的具體實現的功能，通過文檔信息知道了該項目所涉及到的資料庫表和每個表有哪些欄位。項目系統需求分析 代理商：1、 代理商以5折優惠從景點出購買消費劵（消費劵有面值不等的，目前未知）。2、 代理商預付一定的預付款（如5萬元）從景點處購入2倍的消費劵（就是10萬元）。3、 代理商賣出給客戶均以7折賣出4、 代理商預付款余額不得低於一定的金額（未知。如：預付款余額不低於2000等）。5、 代理商在預付款余額低於一定的金額後，需要及時補充（如：幾個工作日內景點收到補充的預付款）。景點：1、 景點對客戶使用的消費劵進行消費劵驗證（如：消費劵卡號驗證，是否已過期等）。2、 景點對客戶所使用的消費劵不得以任何方式返還（如：消費劵1000，用去900，那麼也不得返還100元金額）。客戶：1、客戶使用消費劵必須在消費劵能使用的范圍2、客戶在使用消費劵必須在消費劵的有效期內使用，預期作廢。3、客戶使用消費劵消費時，若消費金額＞實際消費金額，應付實際消費金額—消費劵金額。共同補充：1、 預付款余額=預付款當前余額—客戶實際消費金額（備註：若客戶使用1000元的消費劵消費了800，那麼客戶實際消費金額=800）功能分析描述 根據登陸人員的許可權不同，頁面不同所執行不同的操作登陸功能 1、 經理登陸管理2、 員工登陸操作登陸功能描述 1、 代理商經理登陸，經理有許可權完善資料，建立工作組，員工信息的錄入。添加景點以及景點的相關信息（如：景點的名稱，景點的地點，景點經理的聯系方式）。管理財政，查看每個景點消費劵的售出量和使用量，對賬單，對賬表，根據實際情況，列印各個景點的消費劵和消費劵的面值，列印消費劵的數目、該消費劵的折扣，信息都錄入數據。根據消費劵的售出情況計算所得的利潤。查看預付款余額，不足的及時補充。2、 代理商員工登陸，登陸出售消費劵界面，激活消費劵的金額，記錄每個景點的出售的消費劵的面額（激活的），各個景點的消費劵的出售數量。3、 景點經理登陸，經理完善資料，建立工作組，員工信息的錄入，添加代理商以及代理商的信息（如：代理商的名稱，代理商的地點，代理商經理的聯系方式）。查看每個代理商在我們景點銷售情況及使用情況。查看每個代理商的預付款余額是否已不足（不足提示該代理商），對賬單，對賬表。4、 景點員工登陸，登陸收費系統，驗證客戶所使用的消費劵是否已激活，該客戶使用的消費劵是哪個代理商出售的，該消費劵的金額是多少，哪一天消費的，都記錄下來。項目涉及數據的分析代理商和景點數據分析 1、代理商和景點的角色分析：經理，員工，涉及到的就是用戶名（username），先不用管它是經理還是員工，後面有該用戶的許可權的，我分析的數據：代理商用戶表（AgentUser）主鍵AIDNumber用戶名AUserNameVarchar（10）用戶密碼AUserPasswordVarchar（20）用戶許可權（角色表外鍵）AUserRightsNumber↓角色表主鍵RIDNumber角色RoleVarchar（12）2、景點信息表：景點信息表主鍵SIDNumber景點名稱ScenicSpotNameVarchar（30）景點地址ScenicSpotAddressVarchar（100）景點聯系電話ScenicSpotNOVarchar（15）景點折扣ScenicSpotDisCountNumber消費劵數據分析 消費劵信息表主鍵CCIDVarcher（20）消費劵面值CCMoneyNumber消費劵屬於哪個景點（景點信息表外鍵）SIDVarchar（20）消費劵折扣SDiscountNumer詳細賬單表 賬單表主鍵ZidVarcher（20）金額MoneyNumber屬於哪個景點（景點信息表外鍵）SIDNumer對賬單，對賬表分析 1、 按一定的是時間（比如一個月）會生成一個具體的賬單以便於在管理人員的查看和管理，代理商對每個景點的銷售消費劵的情況和景點對每個代理商銷售的情況都記錄保存。2、 按一個月算每個月雙方要對賬單。列印消費劵分析 1、 不能列印任何面值兩個相同的卡號，用一個軟體以一個數字開頭進行遞增。2、 列印每個景點的消費劵，根據該景點在我們代理商的銷售情況，按實際情況進行列印（面值，張數）最後補充一個，客戶是不是可以上網查詢自己的消費劵真假面值，目前在考慮

⑻ 軟體需求分析範文

http://www.souku.com.cn/dasous.jsp?key=%C8%ED%BC%FE%B1%A8%B8%E6&search_type=ALL
這里有很多，你到網上搜一下應該有。
參考資料：www.souku.com.cn

http://www.8wen.com/search/docs/%C8%ED%BC%FE%D0%E8%C7%F3%B7%D6%CE%F6%C0%FD%CE%C4/1
呵呵，希望能幫到你

⑼ 項目需求分析怎麼寫

項目需求分析的概念需求分析是指理解用戶需求，就軟體功能與客戶達成一致，估計軟體風險和評估項目代價，最終形成開發計劃的一個復雜過程。（這個和我在微軟體驗到的又不太一樣，微軟的需求分析大多是市場人員和用戶協助小組的人去評估用戶的接受程度，這一點也可以理解，因為公司的性質有根本差別）在這個過程中，用戶的確是處在主導地位，需求分析工程師和項目經理要負責整理用戶需求，為之後的軟體設計打下基礎。需求分析階段結束後，要求得到：1.SRS文檔(System Requirement Specification); 2.DRM 文檔；3.Acceptance Plan. 從廣義上理解：需求分析包括需求的獲取、分析、規格說明、變更、驗證、管理的一系列需求工程。
狹義上理解：需求分析指需求的分析、定義過程。 一、為什麼要需求分析需求分析就是分析軟體用戶的需求是什麼.如果投入大量的人力，物力,財力,時間,開發出的軟體卻沒人要,那所有的投入都是徒勞.如果費了很大的精力,開發一個軟體,最後卻不滿足用戶的要求,從而要重新開發過,這種返工是讓人痛心疾首的.(相信大家都有體會)比如,用戶需要一個for linux的軟體,而你在軟體開發前期忽略了軟體的運行環境,忘了向用戶詢問這個問題,而想當然的認為是開發for windows的軟體,當你千辛萬苦地開發完成向用戶提交時才發現出了問題,那時候你是欲哭無淚了,痕不得找塊豆腐一頭撞死.
需求分析之所以重要,就因為他具有決策性,方向性,策略性的作用,他在軟體開發的過程中具有舉足輕重的地位.大家一定要對需求分析具有足夠的重視.在一個大型軟體系統的開發中,他的作用要遠遠大於程序設計. 二、需求分析的任務簡言之,需求分析的任務就是解決"做什麼"的問題,就是要全面地理解用戶的各項要求,並准確地表達所接受的用戶需求.三、需求分析的過程需求分析階段的工作,可以分為四個方面:問題識別,分析與綜合,制訂規格說明,評審.
問題識別
就是從系統角度來理解軟體,確定對所開發系統的綜合要求,並提出這些需求的實現條件,以及需求應該達到的標准.這些需求包括：功能需求(做什麼),性能需求(要達到什麼指標),環境需求(如機型,操作系統等),可靠性需求(不發生故障的概率）,安全保密需求,用戶界面需求,資源使用需求(軟體運行是所需的內存,CPU等),軟體成本消耗與開發進度需求,預先估計以後系統可能達到的目標.
分析與綜合
逐步細化所有的軟體功能,找出系統各元素間的聯系,介面特性和設計上的限制,分析他們是否滿足需求,剔除不合理部分,增加需要部分.最後,綜合成系統的解決方案,給出要開發的系統的詳細邏輯模型(做什麼的模型).
制訂規格說明書
即編制文檔,描述需求的文檔稱為軟體需求規格說明書.請注意,需求分析階段的成果是需求規格說明書(好象軟考曾經考過這個問題),向下一階段提交.
評審
對功能的正確性,完整性和清晰性,以及其它需求給予評價.評審通過才可進行下一階段的工作,否則重新進行需求分析。 四、需求分析的方法需求分析的方法有很多.這里只強調原型化方法,其它的方法如:結構化方法,動態分析法等(個人認為,對初學者不必深究這些方法,實際上我也從來沒用過這些方法)在此不討論.
原型化方法是十分重要的(是軟考等常考的知識點).原型就是軟體的一個早期可運行的版本,它實現了目標系統的某些或全部功能.
原型化方法就是盡可能快地建造一個粗糙的系統,這系統實現了目標系統的某些或全部功能,但是這個系統可能在可靠性,界面的友好性或其他方面上存在缺陷.建造這樣一個系統的目的是為了考察某一方面的可行性,如演算法的可行性,技術的可行性,或考察是否滿足用戶的需求等.如,為了考察是否滿足用戶的要求,可以用某些軟體工具快速的建造一個原型系統,這個系統只是一個界面,然後聽取用戶的意見,改進這個原型.以後的目標系統就在原型系統的基礎上開發.
原型主要有三種類型(軟考考過):探索型,實驗型,進化型.探索型:目的是要弄清楚對目標系統的要求,確定所希望的特性,並探討多種方案的可行性.實驗型:用於大規模開發和實現前,考核方案是否合適,規格說明是否可靠.進化型:目的不在於改進規格說明,而是將系統建造得易於變化,在改進原型的過程中,逐步將原型進化成最終系統。
在使用原型化方法是有兩種不同的策略:廢棄策略,追加策略.廢棄策略:先建造一個功能簡單而且質量要求不高的模型系統，針對這個系統反復進行修改,形成比較好的思想,據此設計出較完整,准確,一致,可靠的最終系統.系統構造完成後,原來的模型系統就被廢棄不用.探索型和實驗型屬於這種策略。
追加策略:先構造一個功能簡單而且質量要求不高的模型系統，作為最終系統的核心,然後通過不斷地擴充修改,逐步追加新要求，發展成為最終系統。進化型屬於這種策略.