目錄

論文寫作相關知識點：

需求分析工作內容：

需求分析的方法：

數據流圖的組成：

繪制數據流的步驟

面向對象的分析方法：

需求定義：

需求驗證

結構化方法：

---

論文寫作相關知識點：

需求分析：需求分析就是提煉、分析和仔細審查已經獲取到的需求，以確保所有的項目干系人都明白其含義并找出其中的錯誤、遺漏或其他不足的地方

需求分析工作內容：

繪制系統上下文范圍關系圖

創建用戶界面原型

分析需求的可行性

確定需求的優先級

為需求的優先級

創建數據字典

使用QFD

需求分析的方法：

結構化分析方法：SA方法的基本思想是自頂向下，逐層分解，把一個大問題分解成若干個小問題，每個小問題再分解成若干個更小的問題。經過逐層分解，每個最低層的問題都是足夠簡單、容易解決的，于是復雜的問題也就迎刃而解了。

數據流圖從數據傳遞和加工的角度，利用圖形符號通過逐層細分描述系統內各個部件的功能和數據在他們之間傳遞的情況，來說明系統所完成的功能。

數據流圖的主要作用如下：

DFD是理解和表達用戶需求的工具，是需求分析的手段。系統分析師可以通過DFD與用戶進行交流

DFD概況地描述了系統的內部邏輯過程，是需求分析結果的表達工具，也是系統設計的重要參考資料，是系統設計的起點

DFD作為一個存檔的文字材料，是進一步修改和充實開發計劃的依據

數據流圖的組成：

數據流：由一組固定成分的數據組成，表示數據的流向。每一個數據流都有一個定義明確的名字

加工：描述了輸入數據流到輸出數據流之間的變換，即輸入數據流經過什么處理后變成輸出數據流，每個加工都有一個名字和編號

數據存儲：用來存儲數據，每個數據存儲都有一個定義明確的名字標識

外部實體：是指存在與軟件系統之外的人員或者組織，它指出系統所需數據的發源地和系統所產生的數據的歸屬地。每個外部實體都有一個明確的名字標識

繪制數據流的步驟

畫系統的輸入和輸出

畫DFD的內部

為每一個數據流命名

為加工命名

面向對象的分析方法：

運用面向對象的分析方法，對問題域進行分析和理解，正確認識其中事物以及他們之間的關系，找出描述問題域和系統功能所需的類和對象，定義他們的屬性和職責，以及他們之間所形成的各種關系，最終產生一個符合用戶需求，并能直接反應問題與和系統功能的面向對象的分析模型及其詳細說明

面向對象分析工作的兩大成果：需求模型和分析模型

需求模型用例圖建立，屬于需求工作成果，為分析工作提供依據。構建用例模型的4個階段：

識別參與者

合并需求獲取用例

細化用例描述和調整用例模型

分析模型分析工作成果：用類圖建立，建立分析模型的過程

定義概念類

閱讀和理解需求文檔或用例描述

篩選出名詞短語，建立初始類清單

候選類：顯而易見類、明顯無意義類和不確定類

舍棄明顯無意義的類

小組討論不確定類別的類，直到將他們都合并或調整到其他兩個類別，并進行相應的操作

確定類之間的關系

當完成了類的尋找工作之后，就需要理清這些類之間的關系，類之間的主要關系有關聯、依賴、泛化、聚合、組合和實現

為類添加職責

類的職責包括兩個方面內容：一個是類所維護的知識，即成員變量或屬性；另一個是類能夠執行的行為，即成員方法或責任

建立交互圖

多個對象的行為通常采用對象交互來表示，可以使用uml的順序圖、活動圖、通信圖等

需求定義：

嚴格定義法

所有需求都能夠被預先定義

開發人員與用戶之間能夠準確而清晰地的交流

采用圖形或文字可以充分體現最終系統

原型法：原型法的需求定義過程是一個開發人員與用戶通力合作的反復過程。從一個能滿足用戶基本需求的原型系統開始，允許用戶在開發過程中提出更好的要求，根據用戶的要求不斷地對系統進行完善

需求規格說明書SRS是需求開發活動的產物

范圍

引用文件

需求

合格性規定

需求可追蹤性

尚未解決的問題

注解

附錄

需求驗證

需求驗證的方法的有兩種

需求評審，需求評審就是需求開發階段結束前進行技術評審，評審的對象就是SRS。對SRS進行評審可以發現那些二義性的或不確定性的需求，為項目干系人提供在需求問題上達成共識的方法，技術評審可以分為以下三種類型

評審：評審是指一次正式的會議，在會議上向用戶或其他項目干系人介紹一個或一組工作產品，以征求對方的意見和批準

檢查：檢查是一種 正式的評估方法，將由非制作者本人的個人或小組詳細檢查工作產品，以驗證是否有錯誤、是否違反開發標準、是否存在其他問題

走查：是一個評審過程，由某個開發人員領導一個或多個開發團隊成員對它的工作產品進行檢查，由其他成員對技術、風格、可能的錯誤、是否違反開發標準和其他問題提出意見

正式評審，是一種結構化的評審技術，一般通過會議的形式來進行評審，需要經過以下過程：

計劃，首先要對評審定制計劃，以確定評審的重點和范圍，并確保所有參與者理解自己的角色和評審的目標

準備：評審之前，應該收集要評審的工作產品和所有背景資料，并分發給評審參與者

進行評審，要進行成功的評審，首先，評審小組人員應理解評審流程，理解自己的角色，一般來說，評審流程是一個重復進行的循環過程，包括評審員提出問題，討論問題，同時對問題進行確認，確定缺陷（需要解決的地方），直到沒有確定的問題時再繼續下一步；其次，會議主持人（協調員）要確保評審按議程進行，并以當前的主題為重點。主持人應該確保對枝節問題的討論不會使評審脫離正軌，而且所有評審人員都以平等的身份參加討論；最后，在評審的過程中，要注意確認問題而不是試圖解決問題，要對所有問題和討論做好記錄

對評審結果采取行動，評審結束時，要確定問題列表的優先順序，并跟蹤問題以及解決辦法

需求管理，主要的活動有：變更控制、版本控制、需求跟蹤和需求狀態跟蹤

需求變更管理過程

問題分析和變更描述，需要識別和分析需求問題，形成明確的變更協議，以檢查他的有效性，從而產生一個更明確的需求變更提議

變更分析和成本計算，使用可追溯性信息和系統需求的一般知識，對需求變更提議進行影響分析和評估，變更成本計算應包括對需求文檔的修改、系統修改的設計和實現的成本。一旦分析完成并且被確認，應該進行是否執行這一變更的決策

變更實現，這要求需求文檔和系統設計以及實現都要同時修改

版本控制，主要包括需求文檔的版本

需求跟蹤：可以使用需求跟蹤能力鏈進行客戶需求與下一級工作產品的雙向跟蹤

需求狀態跟蹤：定義需求狀態，要求的每一個狀態，需求的狀態可以分為已變更，未變更等；變更控制委員會負責對變更進行決策，變更控制委員會的成員來自：產品或計劃管理部門、技術支持部門、開發部門、測試或質量保證部門、市場部門或客戶代表、制作用戶文檔的部門；

結構化方法：

????????結構化方法也稱為生命周期法，由結構化分析、結構化設計和結構化程序設計三部分組成，結構化方法基本思想是將系統的生命周期劃分系統規劃、系統分析、系統設計、系統實施、系統維護階段。結構化方法遵循系統工程原理，按照事先設計好的程序和步驟，使用一定的開發工具，完成規定的文檔，在結構化和模塊化的基礎上進行信息系統的開發工作

????????結構化方法的優點：開發目標清晰化、開發工作階段化、開發文檔規范化、設計方法結構化。缺點：開發周期長、難以適應需求變化、很少考慮數據結構

????????結構化開發對應的開發模型是瀑布模型，在結構化開發中會使用數據流圖、ER圖、狀態轉換圖、模塊結構圖、流程圖等工具

總結

以上是生活随笔為你收集整理的2022下半年，系统架构师论文写作相关知识点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。