如何描述軟體開發需求

1. 簡述軟體需求的含義和具體內容.為什麼需求分析對軟體開發工作特別重要

答：1.軟體需求的含義：
把軟體計劃期間建立的軟體可行性分析求精和細化，分析各種可能的解法，並且分配給各個軟體元素。需求分析是軟體定義階段中的最後一步，是確定系統必須完成哪些工作，也就是對目標系統提出完整、准確、清晰、具體的要求
2.軟體需求的內容：
深入描述軟體的功能和性能，確定軟體設計的約束和軟體同其他系統元素的介面細節，定義軟體的其他有效性需求，藉助於當前系統的邏輯模型導出目標系統邏輯模型，解決目標系統「做什麼」的問題。
需求分析可分為需求提出、需求描述及需求評審三個階段。

3.需求分析對軟體開發工作特別重要的原因：
軟體項目中百分之四十至百分之六十的問題都是在需求分析階段埋下的「禍根」。可許多組織仍在那些基本的項目功能上採用一些不合規范的方法，這樣導致的後果便是一條鴻溝(期望差異)—開發者開發的與用戶所想得到的軟體存在著巨大期望差異。在後期修改的時候會產生巨大的代價

2. 軟體需求說明怎麼寫

如何寫需求分析報告（軟體需求說明書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

3. 軟體項目需求開發基本步驟

由於軟體開發項目和組織文化的不同，對於需求開發沒有一個簡單的、公式化的途徑。下面列出了一些基本步驟，可以利用它們指導需求開發活動。對於需求的任何子集，那麼你就可以很有信心地繼續進行系統的每一部分的設計、構造，因為你將開發出一個好的產品：

1. 定義項目的視圖和范圍，確定每個功能的實現目的。

2. 確定用戶類（涉眾）。

3. 在每個用戶類中確定適當的代表。

4. 確定需求決策者和他們的決策過程。

5. 選擇你所用的需求獲取技術。

6. 運用需求獲取技術對作為系統一部分的使用實例進行開發並設置優先順序。

7. 從用戶那裡收集質量屬性的信息和其它非功能需求。

8. 詳細擬訂使用實例使其融合到必要的功能需求中。

9. 評審使用實例的描述和功能需求。

10. 如果有必要，就要開發分析模型用以澄清需求獲取的參與者對需求的理解。

11. 開發並評估用戶界面原型以助想像還未理解的需求。

12. 從使用實例中開發出概念測試用例。

13. 用測試用例來論證使用實例、功能需求、分析模型和原型

end

2018-5-19

4. 軟體需求文檔怎麼寫

軟體需求文檔是軟體項目由「概念化」階段進入「圖紙化階段的最主要的一個文檔。軟體需求的描述應該包含：軟體定位、目標市場、目標用戶、競爭對手等概述內容。以及軟體的結構、核心業務流程、具體用例描述、功能、內容描述等詳述內容。

需求文檔的主要使用對象：開發、測試、項目經理、交互設計師、運維及其他業務人員。開發可以根據需求文檔獲知整個軟體的邏輯；測試可以根據需求文檔建用例；項目經理可以根據需求文檔拆分工作包，並分配開發人員；交互設計師可以通過需求文檔來設計交互細節。需求文檔是項目啟動之前，必須要通過評審確定的最重要文檔。

產品的概況

介紹項目的背景

介紹產品定位

那些人會用到本軟體

項目可能涉及的角色

5. 如何做好軟體項目需求分析

軟體需求是指用戶對目標軟體系統在功能、行為、性能、設計約束等方面的期望，通過對應用問題及其環境的理解與分析，為問題涉及的信息、功能及系統行為建立模型，將用戶需求精確化、完全化、最終形成需求規格說明，這一系列的活動即構成軟體開發生命周期的需求分析階段。
需求分析是介於系統分析和軟體設計階段之間的重要橋梁。一方面，需求分析以系統規格說明和項目規劃作為分析活動的基本出發點，並從軟體角度對它們進行檢查與調整;另一方面，需求規格說明又是軟體設計、實現、測試直至維護的主要基礎。良好的分析活動有助於避免或盡早剔除早期錯誤，從而提高軟體生產率，降低開發成本，改進軟體質量。
需求分析階段的基本任務是深入描述軟體的功能和性能，確定軟體設計的限制和軟體同其它系統元素的介面細節，定義軟體其它有效的需求。
需求確定為什麼困難?
最主要的原因是對於開發小組的使用成員(包括用戶)來說，需求確定是極具認知性和創造性的活動。需求確定也許是仍在苦苦等待人工智慧支持的最後領域之一。
具體表現如下：
系統分析員對問題域的了解程度也是一大困難。
系統分析員感到需求確定很困難的另一個原因是問題域的動態性。
生活是動態的，公司也是。
項目團隊成員之間的溝通也一直是需求確定的另一大困難。
每個問題域都有術語。
最後，需求確定過程還會受到其它因素的影響。例如勞累、不舒服、開會時室內和窗外的干擾、團隊成員的壓力等等。

6. 軟體開發 用戶需求說明書怎麼寫

規范化軟體開發過程中的《需求說明書》的編寫，使之成為整個開發工作的基礎。2 適用范圍本規范適用於集團開發項目的（軟體）《需求說明書》的編寫。3 編寫內容提示1 引言3.1.1 背景說明說明被開發軟體的名稱，任務提出者，用戶及實現該軟體的計算機網路。3.1.2 參考資料列出有關資料(名稱，發表日期，出版單位，作者等)。3.1.3 術語和縮寫詞列出本文件中用到的專門術語的定義，及術語縮寫詞。3.2 軟體總體概述3.2.1 目標軟體開發的意圖、應用目標、作用范圍以及需說明背景材料。3.2.2 系統模型圖示說明該軟體的所有功能及其相互關系和數據傳遞情況。3.2.3 假設和約束說明影響軟體開發、運行環境和系統能力（如預告出錯類型的能力）的某些假設和約束。3.3 詳細需求詳細描述此軟體系統的功能需求和性能需求。3.3.1 功能需求對系統中每一個功能，要詳細描述（圖示或文字）。概述 敘述功能名稱，目標和作用。 輸入 輸入該功能的信息。 處理 描述該功能做什麼，如何對輸入信息進行加工並轉換成輸出信息。 輸出 列出內部生成的文件。3.3.2 性能需求定量地描述此軟體系統應滿足的具體性能需求。可考慮以下方面：3.3.2.1精度說明系統的精度要求，如：數據的精度要求。 數字計算的精度要求。 數據傳送的誤碼率要求。3.3.2.2 時間特性說明系統的時間特性要求，如：解題時間。 詢問和更新數據文件的響應時間。 系統各項功能的順序關系。3.3.2.3 靈活性說明當需求發生某些變化時系統的適應能力，指出為適應這些變化而需要設計的軟體成分和過程。3.3.2.4系統容量包括系統的設計容量和理論（計算）容量。3.3.3 輸入和輸出解釋各輸入輸出數據類型，並逐項說明某媒體、格式、數值范圍等。對軟體的數據輸出及必須標明的控制輸出量進行解釋並舉例，包括對硬拷貝報告（正常結果輸出、狀態輸出及異常輸出）以及圖形或顯示報告的描述。3.3.4 數據管理能力說明需要管理的文卷和記錄的個數、表和文卷的大小規模，要按可預見的增長對數據及其分量的存儲要求作估算。3.3.5 故障處理列出可能的軟體、硬體故障以及對各項性能而言所產生的後果和對故障處理的要求。

7. 關於軟體開發需求的文字描述，請教大家如何描述

需求規格說明書：主要從用戶角度（需求或市場人員根據用戶要求編寫）描述軟體需要實現的功能，各個功能模塊，各個功能模塊的重要性，以及業務流程等。系統設計說明書：主要從軟體開發（程序員）角度描述軟體需要實現功能，如何劃分這些功能模塊，各個功能模塊的關系，軟體的業務流程等。總結：內容基本都一樣！只是表現形式不一樣！閱讀對象不一樣！

8. 軟體的需求分析怎麼寫啊

軟體需求分析免費下載

鏈接:https://pan..com/s/1qNBwqvbRS5ziBSIeanLQAQ

需求分析也稱為軟體需求分析、系統需求分析或需求分析工程等，是開發人員經過深入細致的調研和分析，准確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統必須做什麼的過程。

9. 軟體需求說明怎麼寫

一 引言

1、編寫目的

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

2、背景說明：

(1)待開發的軟體系統的名稱。

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

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

3、定義

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

4、參考資料

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

(1)本項目的經核準的計劃任務書或合同、上級機關的批文。

(2)屬於本項目的其他已發表的文件。

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

二 任務概述

1、目標

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

2、用戶的特點

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

3、假定和約束

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

三 需求規定

1、對功能的規定

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

2、對性能的規定

(1)精度

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

(2)時間特性要求

說明對於該軟體的時間特性要求，如對：
① 響應時間。
② 更新處理時間。
③ 數據的轉換和傳送時間。
④ 解題時間。
等的要求。

(3)靈活性

說明對該軟體的靈活性的要求，即當需求發生某些變化時，該軟體對這些變化的適應能力，如：
① 操作方式上的變化。
② 運行環境的變化。
③ 同其他軟體的介面的變化。
④ 精度和有效時限的變化。
⑤ 計劃的變化或改進。
對於為了提供這些靈活性而進行的專門設計的部分應該加以標明。

3、輸入輸出要求

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

4、數據管理能力要求

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

5、故障處理要求

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

6、其它專門要求

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

四 運行環境規定

1、設備

列出運行該軟體所需要的硬體設備。說明其中的新型設備及其專門功能，包括：
(1) 處理器型號及內存容量。
(2) 外存容量、聯機或離線、媒體及其存儲格式，設備的型號及數量。
(3) 輸入及輸出設備的型號和數量，聯機或離線。
(4) 數據通信設備的型號和數量。
(5) 功能鍵及其他專用硬體。

2、支持軟體

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

3、介面

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

4、控制

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

五 數據要求

1、數據的邏輯描述

對數據進行邏輯描述時可把數據分為動態數據和靜態數據。所謂靜態數據，指在運行過程中主要作為參考的數據，它們在很長的一段時間內不會變化，一般不隨運行而改變。所謂動態數據．包括所有在運行中要發生變化的數據以及在運行中要輸入、輸出的數據。進行描述時應把各數據元素邏輯地分成若干組，列如函數、源數據或對於其應用更為恰當的邏輯分組。給出每一數據元的名稱（包括縮寫和代碼）、定義（或物理意義）度量單位、值域、格式和類型等有關信息。

(1) 靜態數據??列出所有作為控制或參考用的靜態數據元素。
(2) 動態輸人數據??列出動態輸入數據元素（包括在常規運行中或聯機操作中要改變的數據）。
(3) 動態輸出數據??列出動態輸出數據元素（包括在常規運行中或聯機操作中要改變的數據）。
(4) 內部生成數據??列出向用戶或開發單位中的維護調試人員提供的內部生成數據。
(5) 數據約定??說明對數據要求的制約。逐條列出對進一步擴充或使用方面的考慮而提出的對數據要求的限制（容量、文卷、記錄和數據元的個數的最大值）。對於在設計和開發中確定是臨界性的限制更要明確指出。

2、數據的採集

(1) 要求和范圍

按數據元的邏輯分組來說明數據採集的要求和范圍，指明數據的採集方法，說明數據採集工作的承擔者是用戶還是開發者。具體的內容包括：
① 輸入數據的來源：例如是單個操作員、數據輸入站，專業的數據輸入公司或它們的一個分組。
② 數據輸入（指把數據輸入處理系統內部）所用的媒體和硬體設備。如果只有指定的輸入點的輸入才是合法的，則必須對此加以說明。
③ 接受者：說明輸出數據的接受者。
④ 輸出數據的形式和設備列出輸出數據的形式和硬設備。無論接受者將接收到的數據是列印輸出，還是CRT上的一組字元、一幀圖形，或一聲警鈴，或向開關線圈提供的一個電脈沖，或常用介質如磁碟、磁帶、穿孔卡片等，均應具體說明。
⑤ 數據值的范圍：給出每一個數據元的合法值的范圍。
⑥ 量綱：給出數字的度量單位、增量的步長、零點的定標等。在數據是非數字量的情況下，要給出每一種合法值的形式和含意。
⑦ 更新和處理的頻度：給出預定的對輸入數據的更新和處理的頻度。如果數據的輸入是隨機的，應給出更新處理的頻度的平均值，或變化情況的某種其他度量。

(2) 輸入的承擔者

說明預定的對數據輸入工作的承擔者。如果輸入數據同某一介面軟體有關，還應說明該介面軟體的來源。

(3) 預處理

對數據的採集和預處理過程提出專門的規定，包括適合應用的數據格式、預定的數據通信媒體和對輸入的時間要求等。對於需經模擬轉換或數字轉換處理的數據量，要給出轉換方法和轉換因子等有關信息，以便軟體系統使用這些數據。

(4) 影響

說明這些數據要求對於設備、軟體、用戶、開發單位所可能產生的影響，例如要求用戶單位增設某個機構等。

10. 怎樣寫軟體開發需求分析

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