自從2023年提出「軟體工程」概念以來，軟體開發領域對於借鑑傳統工程的原則、方法，以提高質量、降低成本的探索就從未停止過。而在這個過程中，提出了許多不同的軟體開發模型，典型的有：瀑布式，快速原型法，以及迭代式開發等。
是由w.w.royce在2023年最初提出的軟體開發模型，在瀑布模型中，開發被認為是按照需求分析，設計，實現，測試 (確認)， 整合，和維護順序的進行。
在迭代式開發方法中，整個開發工作被組織為一系列的短小的、固定長度（如3周）的小專案，被稱為一系列的迭代。每一次迭代都包括了需求分析、設計、實現與測試。採用這種方法，開發工作可以在需求被完整地確定之前啟動，並在一次迭代中完成系統的一部分功能或業務邏輯的開發工作。再通過客戶的反饋來細化需求，並開始新一輪的迭代。
不同的開發模型，對於設計階段的工作要求也不盡相同。相對來說，瀑布式模型中對於設計文件的粒度要求得最細，而快速原型法對於設計的要求一般來說比較弱，迭代式開發在每一階段中的設計文件工作量都相對較少，但在軟體開發完成後，最終的設計文件完善程度要比快速原型法的好。
軟體設計的本質就是針對軟體的需求，建立模型，通過將模型對映為軟體，來解決實際問題。因此軟體設計需要解決的核心問題是建立合適的模型，使得能夠開發出滿足使用者需求的軟體產品，並具有以下特性：
因此，軟體設計並沒有一套放之四海而皆準的方法和模板，需要我們的設計開發人員在軟體的設計開發過程中針對軟體專案的特點進行溝通和協調，整理出對軟體專案團隊的行之有效的方式，進行軟體的設計。並保障軟體設計文件的一致性，完整性和可理解性。
在我們開發人員中，有很多人這樣理解：「軟體設計文件就是軟體架構師和設計人員的事情」，其實不然。設計文件是整個軟體開發團隊的產出，其中有些設計文件由架構師或者設計人員給出，有些文件由開發人員給出。這並沒有一定的區分。
我們經常聽到這樣的話：
這些言論，並不是正確的觀念，根據軟體專案的實際情況，軟體開發設計團隊可以約定設計文件的詳細程度。專案團隊需要保障設計文件的完整性和一致性，在專案進度緊張的情況下，軟體設計文件可以更初略一些；在專案時間充裕的情況下，相關文件可以更為詳盡。但是在專案開發過程中，需要軟體設計開發團隊對於設計文件有共同的理解。
通常來說，作為軟體專案，我們需要有這幾類文件
就像我之前說到的，在某個軟體團隊，對於以上的文件的要求是可以完全不同的，在簡單專案中，可能所有型別的文件放在乙個文件中進行說明；在複雜專案中，每一類文件可能都要寫幾個文件；而在最極端的情況下，可能每一類文件都能裝訂成幾冊。因此，在我們軟體設計和開發人員心目中需要明確的是：文件並不是我們進行設計的目標，也不是我們設計過程中額外的工作。
軟體設計文件是我們在軟體設計開發過程中形成的，用來在軟體設計開發團隊內部以及與各干係人之間進行溝通的文件，這些文件記錄了軟體專案中的各種知識，方案的思路、以及各種決策意見。
下面我們就軟體設計開發過程中必須要完成的工作進行梳理，而我們需要注意到，這些需要完成的工作，在不同的開發流程模型的指導下可能有不同的時間要求，而我們需要關注的是在這個階段內需要完成的工作，以及這個階段內我們需要溝通的人員。
需求分析
需求分析是我們進行任何乙個軟體專案設計開發過程中都必須要完成的工作。
這個工作通常與客戶一起完成。在不同的專案中，這個「客戶」可能來自真正的購買產品的使用者，使用系統的使用者，也有可能來自團隊的某個人員，如產品經理等。軟體設計開發團隊的參與成員根據專案的不同規模，則參與的人員也有所不同。原則上，設計開發人員參與的時間點越早，對於需求的理解和把握會更好。這個階段，通常需要軟體架構師參與其中。從資源優化的角度來說，開發人員不必參與需求分析，但需要理解需求。
需求分析的結果通常我們需要使用需求說明文件來描述，目前主流的需求描述方法包括：使用者例圖、使用者故事等方式。這些方式有所不同的側重，其核心思想就是描述清楚使用者的使用場景。但無論採取何種方式，進行需求的描述，需求說明需要明確以下幾點：
功能設計
功能設計與需求分析差不多同時在開展，在很多軟體專案中，對於功能設計不是特別重視。但對於某些軟體專案而言，這是乙個相當重要的工作。對於主要是使用者介面的軟體專案來說，功能設計可以看作是畫出原型介面，描述使用場景，獲得使用者認可的過程。而對於沒有介面的軟體專案來說，則功能設計與需求分析的區分更為模糊。
參與的人員與需求分析的參與人員類似，架構師更側重於參與此類工作，並給與一些實現層面的判斷和取捨。
功能設計需要明確的核心是：
系統架構設計
系統架構設計是乙個非常依賴於經驗的設計過程。需要根據軟體專案的特定功能需求和非功能性需求進行取捨，最終獲得乙個滿足各方要求的系統架構。系統架構的不同，將很大程度上決定系統開發和維護是否能夠較為容易的適應需求變化，以及適應業務規模擴張。
架構設計工作中，使用者參與程度很低。軟體開發團隊中的需求人員參與程度很低，但團隊中的所有核心設計和開發人員都應該參與其中，並達成一致意見。
架構設計的主要成果，是將系統的不同檢視予以呈現，並使之落實到開發中：
在軟體開發過程中，系統的架構不是一成不變的，隨著設計人員和開發人員對於系統的理解不斷深入，系統的架構也會發生演化。在軟體專案中，架構設計是開發團隊溝通的統一語言，設計文件必須要隨著系統的變化進行更新，保障開發團隊對於系統的理解和溝通的一致性。
模組/子系統概要設計
模組詳細設計
在瀑布式開發模型中，模組的詳細設計會要求比較嚴格，將所有類進行詳細設計。據我所知，除了一些對於系統健壯性要求非常嚴格的軟體專案，如國防專案，金融專案還要求有詳細設計文件之外。其他的專案大多採用其他方式來處理這樣的工作，如自動化測試等。
綜上所述，軟體設計文件作為軟體開發團隊的溝通、理解、知識共享的手段，具有非常重要的意義。而根據軟體團隊的規模，對於文件上承載的資訊詳細程度可以有不同程度的要求。我們軟體團隊對於*如何使用設計文件有乙個統一的理解，並堅持更新設計文件*，這就是軟體設計的最佳實踐！
分類:
others
標籤:
design
軟體設計文件
軟體設計文件的清單 1。結構文件。描述程式設計的文件，包括軟體所主要部分的描述以及相互之間的互動方式。2。資料流圖。表示資料在程式中如何流動的正規示意圖，戲稱 泡泡圖 3。狀態轉化圖。把軟體分解為基本狀態或者條件的一種正規示意圖。4。流程圖。用圖形描述程式邏輯的傳統方式。一旦投入使用，根據詳細的流圖...
軟體設計文件要求
詳細設計 文件規範 1.0概述 這部分提供對整個設計文件的概述。描述了所有資料，結構，介面和軟體構件級別的設計。1.1 目標和物件 描述軟體物件的所有目標。1.2 陳述範圍 軟體描述。主要輸入，過程功能，輸出的描述，不考慮詳細細節。1.3 軟體內容 軟體被置於商業或者 產品線中，討論相關的戰略問題。...
軟體設計文件 概要設計書
概要設計的基本任務 1 設計軟體系統結構 a.採用某種設計方法，將乙個複雜的系統按功能劃分成模組 b.確定每個模組的功能 c.確定模組之間的呼叫關係 d.確定模組之間的介面，即模組之間傳遞的資訊 e.評價模組結構的質量 2 資料結構及資料庫設計 a.資料結構的設計 b.資料庫設計 1 概念設計 2 ...