炒股軟體開發需求文檔的重要性

❶ 如何理解需求分析的作用和重要性

通過對應問題及其環境的理解與分析，為問題涉及的信息、功能及系統行為建立模型，將用戶需求精確化、完全化，最終形成需求規格說明，這一系列的活動即構成軟體開發生命周期的需求分析階段。
需求分析是介於系統分析和軟體設計階段之間的橋梁。一方面，需求分析以系統規格說明和項目規劃作為分析活動的基本出發點，並從軟體角度對它們進行檢查與調整；另一方面，需求規格說明又是軟體設計、實現、測試直至維護的主要基礎。良好的分析活動有助於避免或盡早剔除早期錯誤，從而提高軟體生產率，降低開發成本，改進軟體質量。
需求工程是隨著計算機的發展而發展的，在計算機發展的初期，軟體規模不大，軟體開發所關注的是代碼編寫，需求分析很少受到重視。後來軟體開發引入了生命周期的概念，需求分析成為其第一階段。隨著軟體系統規模的擴大，需求分析與定義在整個軟體開發與維護過程中越來越重要，直接關繫到軟體的成功與否。人們逐漸認識到需求分析活動不再僅限於軟體開發的最初階段，它貫穿於系統開發的整個生命周期。80年代中期，形成了軟體工程的子領域——需求工程(requirementengineering,RE)。進入90年代以來，需求工程成為研究的熱點之一。從1993年起每兩年舉辦一次需求工程國際研討會(ISRE)，自1994年起每兩年舉辦一次需求工程國際會議(ICRE)，在1996年Springer-Verlag發行了一新的刊物——《RequirementsEngineering》。一些關於需求工程的工作小組也相繼成立，如歐洲的RENOIR()，並開始開展工作。
需求工程是指應用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題並定義目標系統的所有外部特徵的一門學科。它通過合適的工具和記號系統地描述待開發系統及其行為特徵和相關約束，形成需求文檔，並對用戶不斷變化的需求演進給予支持。RE可分為系統需求工程（如果是針對由軟硬體共同組成的整個系統）和軟體需求工程（如果僅是專門針對純軟體部分）。軟體需求工程是一門分析並記錄軟體需求的學科，它把系統需求分解成一些主要的子系統和任務，把這些子系統或任務分配給軟體，並通過一系列重復的分析、設計、比較研究、原型開發過程把這些系統需求轉換成軟體的需求描述和一些性能參數。
需求工程是一個不斷反復的需求定義、文檔記錄、需求演進的過程，並最終在驗證的基礎上凍結需求。80年代，HerbKrasner定義了需求工程的五階段生命周期：需求定義和分析、需求決策、形成需求規格、需求實現與驗證、需求演進管理。近來，MatthiasJarke和KlausPohl提出了三階段周期的說法：獲取、表示和驗證。
綜合了幾種觀點，可以把需求工程的活動劃分為以下5個獨立的階段：
（1）需求獲取：通過與用戶的交流，對現有系統的觀察及對任務進行分析，從而開發、捕獲和修訂用戶的需求；
（2）需求建模：為最終用戶所看到的系統建立一個概念模型，作為對需求的抽象描述，並盡可能多的捕獲現實世界的語義；
（3）形成需求規格：生成需求模型構件的精確的形式化的描述，作為用戶和開發者之間的一個協約；
（4）需求驗證：以需求規格說明為輸入，通過符號執行、模擬或快速原型等途徑，分析需求規格的正確性和可行性；
（5）需求管理：支持系統的需求演進，如需求變化和可跟蹤性問題。

❷ 軟體需求分析的作用

開發軟體系統最為困難的部分就是要准確說明開發什麼。最為困難的概念性工作便是要編寫出詳細的技術需求，這包括所有面向用戶、面向機器和其它軟體系統的介面。如果做錯，這將是會最終給系統帶來極大損害的一部分，並且以後再對它進行修改也極為困難。目前，國內產品的龐雜，一家企業可能有幾個系統並立運行，它們之間的介面是系統開發人員最頭痛的問題。對於商業最終用戶應用程序，企業信息系統和軟體作為一個大系統的一部分的產品是顯而易見的。但是對於我們開發人員來說，並沒有編寫出客戶認可的需求文檔，我們如何知道項目於何時結束？而如果我們不知道什麼對客戶來說是重要的，那我們又如何能使客戶感到滿意呢？
然而，即便並非出於商業目的的軟體需求也是必須的。例如庫、組件和工具這些供開發小組內部使用的軟體。當然你可能偶爾勿需文檔說明就能與其他人意見較為一致，但更常見的是出現重復返工這種不可避免的後果，而重新編制代碼的代價遠遠超過重寫一份需求文檔的代價，這些血的教訓正在國內的軟體開發者身上發生。

❸ 對於軟體開發而言文檔究竟有多大的作用

規范性的文檔是軟體開發最重要的環節,規范軟體開發的50%的時候是在寫各種文檔(需求文檔,概要設計,詳細設計,測試計劃,測試報告等)

❹ 如何理解需求分析在軟體開發中的重要性

需求分析可以使得開發和測試更能夠了解客戶的需求，把一些技術難點和可能遇到的難點問題提出來，盡早解決，並且達到一致，便於以後的開發和測試

❺ 軟體開發的需求文檔要具備哪些要素，格式如何

需求文檔的編寫內容包括很多的，但是需要根據該軟體的規模和具體要求進行編寫。 一份比較完整的詳細需求分析應該包括：1. 前言 2. 摘要 3. 系統詳細需求分析 3.1. 詳細需求分析 3.1.1. 詳細功能需求分析 3.1.2. 詳細性能需求分析 3.1.3. 詳細信息需求分析 3.1.4. 詳細資源需求分析 3.1.5. 詳細組織需求分析 3.1.6. 詳細系統運行環境及限制條件需求分析 3.1.7. 信息要求 3.1.8. 性能要求 3.2. 介面需求分析 3.2.1. 系統介面需求分析 3.2.2. 現有軟、硬體資源介面需求分析 4. 總體方案設計4.1. 系統總體結構 4.1.1. 系統組成、邏輯結構 4.1.2. 應用系統結構 4.1.3. 支撐系統結構 4.1.4. 系統集成 4.1.5. 系統工作流程
.2. 分系統詳細界面劃分 4.2.1. 應用分系統與支撐分系統的詳細界面劃分 4.2.2. 應用分系統之間的界面劃分 5. 應用分系統詳細設計 5.1. XX分系統詳細需求分析 5.1.1. 功能詳細需求分析 5.1.2. 性能詳細需求分析 5.1.3. 信息詳細需求分析 5.1.4. 限制條件詳細分析 5.2. XX分系統結構設計及子系統劃分 5.3. XX分系統功能詳細設計 5.4. 分系統界面設計 5.4.1. 外部界面設計 5.4.2. 內部界面設計 5.4.3. 用戶界面設計 6. 資料庫系統設計 6.1. 設計要求 6.2. 信息模型設計 6.3. 資料庫設計 6.3.1. 數據訪問頻度和流量 6.3.2. 資料庫選型 6.3.3. 異構資料庫的連接與數據傳遞方式
6.3.5. 數據共享方式設計 6.3.6. 數據安全性及保密設計 6.3.7. 數據字典設計
8. 信息編碼設計 8.1. 代碼結構設計 8.2. 代碼編制 9. 關鍵技術 9.1. 關鍵技術的提出 9.2. 關鍵技術的一般說明 9.3. 關鍵技術的實現方案 10. 系統配置 10.1. 硬體配置 10.2. 軟體配置 11. 限制 12. 組織機構及人員配置 12.1. 機構調整與確認 12.2. 組織機構的任務和職責 12.3. 人員配置方案 12.4. 培訓計劃 13. 工程實施計劃 13.1. 分期實施內容 13.2. 進度計劃 13.3. 實施條件 13.4. 測試與驗收 14. 投資預算 15. 參考和引用資料
16. 術語
這里還有很需要補充的，也有很多是可以不寫的；因為一份需求文檔不是誰能寫的，呵呵，在實際的工作中
是那些負責人才能寫這個的。如果是課設的話，只要在流程圖 邏輯結構 或者是XX分系統的設計圖上下點功夫就好了。說到格式 就是按上面的寫 然自己弄一個目錄 就像是我們平時翻書的時候看到的那種，這樣好閱讀。

❻ 需求分析在軟體開發中真的有那麼重要嗎

這是很明顯的，如果不知道要干什麼，那你怎麼開發呢。就像你要建一棟房子，但是你還沒有決定你要建別墅還是公寓，那你會開始建嗎，肯定是不會的。

❼ 軟體文檔在軟體開發中的作用

軟體文檔在軟體開發中起到很重要作用，如果沒有軟體文檔，後前的工作就難以展開，維護很難。軟體文檔其實可以看做是一個規范、標准，特別是前期的需求分析，利用軟體文檔可以很好的去了解業務邏輯等。

❽ 需求分析在軟體開發中的重要性

軟體需求分析特別重要。在軟體工程的歷史中，很長時間里人們一直認為需求分析是整個軟體工程中的一個簡單步驟，但在過去十多年中越來越多的人認識到它是整個過程中最關鍵的一個過程。只有通過軟體需求分析，才能把軟體功能和性能的總體概念描述為具體的軟體需求規格說明，從而奠定軟體開發的基礎。許多大型應用系統的失敗，最後均歸結到需求分析的失敗：要麼獲取需求的方法不當，使得需求分析不到位或不徹底，導致開發者反復多次地進行需求分析，致使設計、編碼、測試無法順利進行；要麼客戶配合不好，導致客戶對需求不確認，或客戶需求不斷變化，同樣致使設計、編碼、測試無法順利進行。參考文章： http://book.csdn.net/bookfiles/1047/100104731335.shtml

❾ 需求工程的重要性是什麼

需求工程的重要性主要表現在: 增強了項目涉眾對復雜產品特徵在細節和相互依賴關繫上的理解， 增強了項目涉眾對需求( 尤其是復雜需求) 的掌握 ; 增進了項目涉眾之間的交流， 減少了可能的誤解和交流偏差; 需求管理能夠更加有效地處理需求變更，提高了生產效率; 需求跟蹤信息能夠更加准確地反映項目的進展情況，以便進行更好的項目決策; 使得項目涉眾認識到需求在項目工作中的重要性， 使得需求的作用得到重視和有效發揮。良好的需求分析和管理工作， 才能把系統的功能描述和性能指標轉化為具體的軟體需求規格說明書，成為系統建設的依據和基礎。

需求工程的內容

需求獲取階段
需求獲取首先需要的是技術的支持，其次，在需求獲取工作中主要涉及了 3 個至關重要的因素：應搜集什麼信息；從什麼來源中搜集信息；用什麼機制或技術搜集信息。再次，需求獲取的開始，代表著軟體項目正式開始實施，正所謂萬事開頭難。綜合上述 3 個點使得需求獲取成為軟體開發中最困難、最關鍵、最易出錯也是最需要交流的方面。在工作開展中，主要是就業務流程、組織架構、軟硬體環境和現有系統等相關內容進行溝通，挖掘系統最終用戶的真正需求，把握需求的方向。在需求獲取調研會中首先對需求獲取方法作了驗證。現行的需求獲
取方法一般有基於調查的需求獲取方法、基於用例的需求獲取方法、原型法等幾種方法。各種需求獲取方法各有利弊。

需求分析階段
需求分析與需求獲取是密切相關的，需求獲取是需求分析的基礎，需求分析是需求獲取的直接表現，兩者相互促進，相互制約。需求分析與需求獲取的不同主要在於需求分析是在已經了解承建方的實際的客觀的較全面的業務及相關信息的基礎上，結合軟、硬體實現方案，並做出初步的系統原型給承建方做演示。承建方則通過原型演示來體驗業務流程的合理化、准確性、易用性。同時，用戶還要通過原型演示及時地發現並提出其中存在的問題和改進意見和方法。

需求文檔編寫階段
需求開發的最終成果是，在對所要開發的產品達成共識後，所編寫的具體的文檔。需求文檔是在需求獲取和需求分析兩個階段任務結束時生成的，所以文檔要包含所有需求。在此階段先要從軟體工程和文檔管理的角度出發依據相關的標准審核需求文檔內容，確定需求文檔內容是否完整。對需求文檔中存留問題進行修改的工作。

需求確認階段
需求確認主要是針對《需求規格說明書》的評審，保證需求符合優秀需求成熟的特徵，並且符合好的需求規格說明的特徵。在需求確認階段需要保證以下幾點：
（1）軟體需求規格說明正確描述了預期的滿足各方涉眾需求的系統能力和特徵。
（2）從系統需求、業務規則或其他來源中正確的推導出軟體需求。
（3）需求是完整的、高質量的。
（4）需求的表示在所有地方都是一致的。
（5）需求為繼續進行產品設計和構造提供充分的基礎。

需求跟蹤階段與需求復用階段
需求跟蹤是指通過比較需求文檔與後續工作成果之間的對應關系，確保產品依據需求文檔進行開發，建立與維護「需求——設計——編程——測試」之間的一致性，確保所有工作成果符合用戶需求。需求跟蹤是一項需要進行大量手工勞動的任務，在系統開發和維護的過程中一定要隨時對跟蹤聯系鏈信息進行更新。需求跟蹤能力的好壞會直接影響產品質量，降低維護成本，容易實現復用，同時，需求跟蹤還需要建設方的大力支持。

需求復用階段
在軟體項目實施過程中，許多不同項目間存在著許多相似的需求，尤其是類型相同的項目在不同的用戶群眾的實施中，需求的相似性就更加明顯、更加普遍了。有了需求復用，建設方就能快速的形成一個需求的原型，這樣，後期的需求工作只需要在此原型的基礎上進行修改、擴充和完善即可，大大提高了需求分析的工作進度。所以，對於需求的復用就需要加以重視。對於需求復用，首要責任就是要提取可復用的需求，對需求復用的理解和擴充。其次就是要保證需求復用不存在沖突。

需求變更控制階段
需求變更在軟體項目開發中是不可避免的。無休止的需求變更只會造成各種資源無休止的浪費，但是其中也不乏有許多是必要的、合理的需求變更。對於需求變更，首先是要盡量及早的發現，以避免更大的損失。其次，是要採取相應的、合理的變更管理制度和流程，這樣同樣可以降低需求變更帶來的風險。

版本控制階段
版本控制是管理需求規格說明和其他項目文檔必不可少的一個方面，也是需求變更文檔化管理的最有效辦法。可以詳細記錄發生需求變更的需求文檔版本的版本，發生變更的原因，變更發生的控制記錄，並對變更後的需求文檔進行唯一版本號的標識。使得每個成員都能及時訪問最新版本的需求文檔。
實施版本控制的基礎是需求基線，所謂需求基線就是項目組成員一經承諾將在某一特定產品版本中實現的功能性和非功能性需求的集合。需求基線的確定可以保證項目的涉眾各方可以對發布的產品中希望具有的功能和屬性有一個一致的理解。