商品期貨分析軟體需求說明

『壹』 期貨分析軟體的常見軟體

天狼星商品期貨軟體：
1.主力跟庄技術。
2.智能氣象表功能。

3.首創主力跟庄技術和智能氣象表功能。主力圖/風向標是市場上最准確的商品期貨日內走勢預測工具，同時高頻成交單數據和動態委託博弈數據監控主力行為；分別從普通機構、游資等角度全方位透析市場超級主力的建倉和操盤過程，准確跟蹤超級主力。

『貳』 軟體詳細設計說明書和軟體需求分析說明書

上網查唄

『叄』 怎樣做軟體的需求分析

軟體需求的定義：
（1）用戶解決問題或達到目標所需的條件或能力。
（2）系統或系統部件要滿足合同、標准、規范或其它正式規定文檔所需具有的條件或能力。
（3）一種反映上面(1)或(2)所描述的條件或權能的文檔說明。 實通俗的講，「需求」就是用戶的需要，它包括用戶要解決的問題、達到的目標、以及實現這些目標所需要的條件，它是一個程序或系統開發工作的說明，表現形式一般為文檔形式。
需求工程的定義：
需求分析的過程，也叫做需求工程和需求階段，它包括了需求開發和需求管理兩個部分。需求開發是指從情況收集、分析和評價到編寫文檔、評審等一系列產生需求的活動，分為四個階段：情況獲取、分析、制訂規格說明和評審。這四個階段不一定是遵循線性順序的，他們的活動是相互獨立和反復的。需求管理是軟體項目開發過程中控制和維持需求約定的活動，它包括：變更控制、版本控制、需求跟蹤、需求狀態跟蹤等工作。
需求開發與管理的一些方法：
（1）繪制關聯圖：繪制系統關聯圖是用於定義系統與系統外部實體間的界限和介面的簡單模型。
（2）可行性分析：在允許的成本、性能要求下，分析每項需求實施的可行性，提出需求實現相關風險，包括與其它需求的沖突，對外界因素的依賴和技術障礙。
（4）系統原型：當用戶自身對有的需求不十分清楚時，我們可以建立一個系統原型，用戶通過評價原型更好地理解所要解決的問題。。
（5）圖形分析模型：繪制圖形分析模型是編制軟體需求規格說明重要手段。它們能幫助分析人員理清數據、業務模式、工作流程以及他們之間的關系，找出遺漏、冗餘和不一致的需求。這樣的模型包括數據流圖、實體關系圖、狀態變換圖、對話框圖、對象類及交互作用圖。
（6）數據字典：數據字典是對系統用到的所有數據項和結構的定義，以確保開發人員使用統一的數據定義。在需求階段，數據字典至少應定義客戶數據項，確保客戶與開發小組是使用一致的定義和術語。
需求管理的方法主要包括以下一些方面：
1）確定需求變更控制過程。制定一個選擇、分析和決策需求變更的過程，所有的需求變更都需遵循此過程。
2）進行需求變更影響分析。評估每項需求變更，以確定它對項目計劃安排和其它需求的影響，明確與變更相關的任務並評估完成這些任務需要的工作量。通過這些分析將有助於需求變更控制部門做出更好的決策。
3）建立需求基準版本和需求控製版本文檔。確定需求基準，這是項目各方對需求達成一致認識時刻的一個快照，之後的需求變更遵循變更控制過程即可。每個版本的需求規格說明都必須是獨立說明，以避免將底稿和基準或新舊版本相混淆。
4）維護需求變更的歷史記錄。將需求變更情況寫成文檔，記錄變更日期、原因、負責人、版本號等內容，及時通知到項目開發所涉及的人員。為了盡量減少困惑、沖突、誤傳，應指定專人來負責更新需求。
5）跟蹤每項需求的狀態。可以把每一項需求的狀態屬性（如已推薦的，已通過的，已實施的，或已驗證的）保存在資料庫中，這樣可以在任何時候得到每個狀態類的需求數量。
6）衡量需求穩定性。可以定期把需求數量和需求變更（添加、修改、刪除）數量進行比較。過多的需求變更"是一個報警信號"，意味著問題並未真正弄清楚。
4.需求分析評價標准
（1）清晰：目前大多數的需求分析採用的仍然是自然語言，自然語言對需求分析最大的弊病就是它的二義性，所以開發人員需要對需求分析中採用的語言做某些限制。例如盡量採用主語＋動作的簡單表達方式。需求分析中的描述一定要簡單，千萬不要採用疑問句、修飾這些復雜的表達方式。 除了語言的二義性之外，注意不要使用行話，就是計算機術語。需求分析最重要的是和用戶溝通，可是用戶多半不是計算機的專業人士，如果在需求分析中使用了行話，就會造成用戶理解上的困難。
（2）完整：需求的完整性是非常重要的，如果有遺漏需求，則不得不返工，在軟體開發過程中，最糟糕的事情莫過於在軟體開發接近完成時發現遺漏了一項需求。但實際情況是，需求的遺漏是常發生的事情，這不僅僅是開發人員的問題，更多發生在用戶那裡。要做到需求的完整性是很艱難的一件事情，它涉及到需求分析過程的各個方面，貫穿整個過程，從最初的需求計劃制定到最後的需求評審。
（3）一致：一致性是指用戶需求必須和業務需求一致，功能需求必須和用戶需求一致。在需求過程中，開發人員需要把一致性關系進行細化，比如用戶需求不能超出預前指定的范圍。嚴格的遵守不同層次間的一致性關系，就可以保證最後開發出來的軟體系統不會偏離最初的實現目標。
（4）可測試：一個項目的測試從什麼時候開始呢？有人說是從編碼完成後開始，有人說是編碼的時候同時進行單元測試，編碼完成後進行系統測試，這些結論都不完全正確。實際上，測試是從需求分析過程就開始了，因為需求是測試計劃的輸入和參照。這就要求需求分析是可測試的，只有系統的所有需求都是可以被測試的，才能夠保證軟體始終圍繞著用戶的需要，保證軟體系統是成功的。

『肆』 如何進行軟體需求分析

需求的定義包括從用戶角度（系統的外部行為），以及從開發者角度（一些內部特性）來闡述需求。
關鍵的問題是一定要編寫需求文檔。我曾經目睹過一個項目中途更換了所有的開發者，客戶被迫與新的需求分析者坐到一起。系統的分析人員說："我們想與你談談你的需求。"客戶的第一反應便是："我已經將我的要求都告訴你們前任了，現在我要的就是給我編一個系統"。而實際上，需求並未編寫成文檔，因此新的分析人員不得不從頭做起。所以如果只有一堆郵件、會談記錄或一些零碎的未整理的對話，你就確信你已明白用戶的需求，那完全是自欺欺人。
需求的另外一種定義認為需求是"用戶所需要的並能觸發一個程序或系統開發工作的說明"。有些需求分析專家拓展了這個概念："從系統外部能發現系統所具有的滿足於用戶的特點、功能及屬性等"。這些定義強調的是產品是什麼樣的，而並非產品是怎樣設計、構造的。而下面的定義則從用戶需要進一步轉移到了系統特性：
需求是指明必須實現什麼的規格說明。它描述了系統的行為、特性或屬性，是在開發過程中對系統的約束。
從上面這些不同形式的定義不難發現：並沒有一個清晰、毫無二義性的"需求"術語存在，真正的"需求"實際上在人們的腦海中，這個人們主要是指客戶，但一般情況下，用戶並不能描述自己的需要，只就需要系統分析人員根據用戶的自己語言的描述整理出相關的需要再進一步和客戶核對。系統分析員和客戶需要確保所有項目風險承擔者在描述需求的那些名詞的理解上務必達成共識。
任何文檔形式的需求（例如如下將要描述的需求規格說明書）僅是一個模型，一種描述。

『伍』 期貨分析軟體的介紹

期貨分析軟體是在期貨行情軟體的基礎上增加一些分析功能，比如技術指標、買賣信號、畫線分析等，以供期貨投資者參考；

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

對性能的規定

1、精度

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

2、時間特性要求

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

a、響應時間；

b、更新處理時間；

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

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

3、靈活性

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

a、操作方式上的變化；

b、運行環境的變化；

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

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

e、計劃的變化或改進。

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

4、輸入輸出要求

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

5、數據管理能力要求

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

6、故障處理要求

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

7、其他專門要求

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

(6)商品期貨分析軟體需求說明擴展閱讀：

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

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

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

『柒』 做軟體的需求分析和設計，要寫哪些東西

第一章
引言
1.1
編寫目的
1.2
項目背景
1.
基本定義
第二章
產品概述
2.1
目標
2.2
運行環境
2.
條件與限制
第三章
業務規范分析
.1
業務規范分析
.2
業務數據流圖
.2
數據詞典
.
數據採集
第四章
功能需求
.1
功能劃分
.2
功能描述
.
軟體介面
.
故障處理
第五章
其它需求
.1
應用環境
.2
其它要求

『捌』 期貨分析軟體有什麼功能在哪裡下載呢

為了科學有效地預判期貨市場中的價格趨勢，規模較大的期貨公司都會開發屬於自己公司的期貨分析軟體，在技術分析的框架下，應用統計科學，依託軟體技術開發，力求建立行之有效的期貨分析系統。專業的期貨投資分析系統有幾千種工具，比如趨勢線、均線、振盪指標或反彈線等等。如果你有行情分析需求，建議你下載銀河期貨一站通APP試試。

『玖』 軟體需求說明怎麼寫

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