軟考筆記（五）高級系統架構師/分析師：系統需求工程 需求分析

目錄

• 軟考官網 報名通道
• 軟考架構師筆記（一）：計算機系統基礎
• 軟考架構師筆記（二）：計算機網絡基礎與信息安全
• 軟考架構師筆記（三）：操作系統基礎
• 軟考架構師筆記（四）：企業信息化與系統規划
• 軟考架構師筆記（五）：系統需求工程 需求分析
• 軟考架構師筆記（六）：數據庫
• 軟考架構師筆記（七）：系統分析 系統設計
• 軟考架構師筆記（八）：系統架構
• 軟考架構師筆記（九）：軟件工程與項目管理
• 軟考架構師筆記（十）：系統測試 維護 穩定性

需求工程

軟件需求是指用戶對系統在功能、行為、性能、設計約束等方面的期望。
軟件需求是指用戶解決問題或達到目標所需的條件或能力，是系統或系統部件要滿足合同、標准、規范或其他正式規定文檔所需具有的條件或能力，以及反映這些條件或能力的文檔說明。

需求開發：

• 需求獲取
• 需求分析
• 需求定義（需求規格說明書）
• 需求驗證

需求管理:

• 變更控制
• 版本控制
• 需求跟蹤
• 需求狀態跟蹤

需求分類：

• 業務需求(整體全局)
• 用戶需求(用戶視角)
• 系統需求(計算機化)
•  
• 基本需求(明示，常規需求)
• 期望需求(隱含)
• 興奮需求(多余)

需求獲取

用戶訪談：用戶訪談是最基本的一種需求獲取手段，其形式包括結構化和非結構化兩種。用戶訪談是通過1對1（或1對2，1對3）的形式與用戶面對面進行溝通，以獲取用戶需求。用戶訪談具有良好的靈活性，有較寬廣的應用范圍。但是，也存在着許多困難，例如，用戶經常較忙，難以安排時間；面談時信息量大，記錄較為困難；溝通需要很多技巧，同時需要系統分析師具有足夠的領域知識等。另外，在訪談時，還可能會遇到一些對於企業來說比較機密和敏感的話題。因此，這看似簡單的技術，也需要系統分析師具有豐富的經驗和較強的溝通能力。

采樣是指從種群中系統地選出有代表性的樣本集的過程，通過認真研究所選出的樣本集，可以從整體上揭示種群的有用信息。對於信息系統的開發而言，現有系統的文檔（文件）就是采樣種群。當開始對一個系統做需求分析時，查看現有系統的文檔是對系統有初步了解的最好方法。但是，系統分析師應該查看哪些類型的文檔，當文檔的數據龐大，法——研究時，就需要使用采樣技術選出有代表性的數據。采樣技術不僅可以用於收集數據，還可以用於采集訪談用戶或者是采集觀察用戶。在對人員進行采樣時，上面介紹的采樣技術同樣適用。通過采樣技術，選擇部分而不是選擇種群的全部，不僅加快了數據收集的過程，而且提高了效率，從而降低了開發成本。另外，采樣技術使用了數理統計原理，能減少數據收集的偏差。但是，由於采樣技術基於統計學原理，樣本規模的確定依賴於期望的可信度和已有的先驗知識，很大程度上取決於系統分析師的主觀因素，對系統分析師個人的經驗和能力依賴性很強，要求系統分析師具有較高的水平和豐富的經驗。

聯合需求計划：為了提高需求獲取的效率，越來越多的企業傾向於使用小組工作會議來代替大量獨立的訪談。聯合需求計划（Joint Requirement Planning，JRP）是一個通過高度組織的群體會議來分析企業內的問題並獲取需求的過程，它是聯合應用開發（Joint Application Development，JAD）的一部分。

需求分類

簡單地說，軟件需求就是系統必須完成的事以及必須具備的品質。需求是多層次的，包括業務需求、用戶需求和系統需求，這三個不同層次從目標到具體，從整體到局部，從概念到細節。
（1）業務需求。業務需求是指反映企業或客戶對系統高層次的目標要求，通常來自項目投資人、購買產品的客戶、客戶單位的管理人員、市場營銷部門或產品策划部門等。通過業務需求可以確定項目視圖和范圍。
（2）用戶需求。用戶需求描述的是用戶的具體目標，或用戶要求系統必須能完成的任務。也就是說，用戶需求描述了用戶能使用系統來做些什么。通常采取用戶訪談和問卷調查等方式，對用戶使用的場景（scenarios）進行整理，從而建立用戶需求
（3）系統需求。系統需求是從系統的角度來說明軟件的需求，包括功能需求、非功能需求和設計約束等。

 

管理維度：

• 基本需求
• 期望需求
• 興奮需求

需求分析 SA

需求分析是一種軟件工程活動，它在系統級軟件分配和軟件設計間起到橋梁的作用，需求分析使得系統工程師能夠刻畫出軟件的功能和性能，指明軟件和其他系統元素的接口，並建立軟件必須滿足的約束。
需求分析允許系統分析師細化軟件的分解，並建立將被軟件處理的數據、功能和行為模型。最后，需求規約為開發者和客戶提供了軟件開發完成后質量評估的依據。
需求分析為軟件設計師提供了可被翻譯成數據、架構、界面和過程設計的模型，
需求分析的任務是發現、求精、建模和規約的過程，包括詳細地細化由系統工程師建立並在軟件項目計划中明確的軟件范圍，創建所需數據、信息和控制流及操作行為的模型，此外，還要分析可選擇的解決方案，並將它們分配到各軟件元素中去。
需要注意的是，在需求分析階段要得到詳細的規約是不可能的。客戶可能並不能精確地肯定需要什么，開發者可能不能肯定可用什么特定的方法來適當地完成功能和性能。

 

DFD 數據流圖

數據流圖DFD是SA方法中的重要工具，是表達系統內部數據的流動並通過數據流描述系統功能的一種方法。 
DFD還可被認為是一個系統模型，在信息系統開發中，如果采用結構化方法，則一般將DFD作為需求規格說明書的一個組成部分。用例模型描述了一組用例、參與者及它們之間的關系。
通常使用數據字典作為該工具的補充說明。

（1）DFD是理解和表達用戶需求的工具，是需求分析的手段。由於DFD簡明易懂，不需要任何計算機專業知識就可以理解它，因此，系統分析師可以通過DFD與用戶進行交流。
（2）DFD概括地描述了系統的內部邏輯過程，是需求分析結果的表達工具，也是系統設計的重要參考資料，是系統設計的起點。
（3）DFD作為一個存檔的文字材料，是進一步修改和充實開發計划的依據。

需求分析之面向對象 OOA

類封裝組成

在系統設計過程中，類可以分為三種類型，分別是實體類、邊界類和控制類。

1、實體類實體類的主要職責是存儲和管理系統內部的信息，它也可以有行為，甚至很復雜的行為，但這些行為必須與它所代表的實體對象密切相關。實體類映射需求中的每個實體，實體類保存需要存儲在永久存儲體中的信息，例如，在線教育平台系統可以提取出學員類和課程類，它們都屬於實體類。實體類通常都是永久性的，它們所具有的屬性和關系是長期需要的，有時甚至在系統的整個生存期都需要。

2.控制類控制類用於描述一個用例所具有的事件流控制行為，控制一個用例中的事件順序。
例如，用例“身份驗證”可以對應於一個控制類“身份驗證器”，它提供了與身份驗證相關的所有操作。控制類用於對一個或幾個用例所特有的控制行為進行建模，控制對象（控制類的實例）通常控制其他對象，因此，它們的行為具有協調性。通常情況下，控制類沒有屬性，但一定有方法。

3.邊界類邊界類用於描述外部參與者與系統之間的交互，它位於系統與外界的交接處，包括所有窗體、報表、打印機和掃描儀等硬件的接口，以及與其他系統的接口。
要尋找和定義邊界類，可以檢查用例模型，每個參與者和用例交互至少要有一個邊界類，邊界類使參與者能與系統交互。
邊界類是一種用於對系統外部環境與其內部運作之間的交互進行建模的類。
常見的邊界類有窗口、通信協議、打印機接囗、傳感器和終端等。實際上，在系統設計時，產生的報表都可以作為邊界類來處理。

用例建模 描述系統需求

在OOA方法中，構建用例模型一般需要經歷四個階段，分別是識別參與者、合並需求獲得用例、細化用例描述和調整用例模型，其中前三個階段是必需的。

用例是一種描述系統需求的方法，使用用例的方法來描述系統需求的過程就是用例建模。
在用例圖中，主要包括參與者、用例和通信關聯三種元素，如上圖所示。
通信關聯
用例
參與者
（1）參與者。參與者是指存在於系統外部並與系統進行交互的任何事物，既可以是使用系統的用戶，也可以是其他外部系統和設備等外部實體。
（2）用例。用例是在系統中執行的一系列動作，這些動作將生成特定參與者可見的價值結果。也就是說，用例表示系統所提供的服務，它定義了系統是如何被參與者所使用的，它描述的是參與者為了使用系統所提供的某一完整功能而與系統之間發生的一段對話。
（3）通信關聯。通信關聯表示的是參與者和用例之間的關系，或用例與用例之間的關系。箭頭表示在這一關系中哪一方是對話的主動發起者，箭頭所指方是對話的被動接受者，箭尾所指方是對話的主動發起者。如果不想強調對話中的主動與被動關系，可以使用不帶箭頭的關聯實線。在用例模型中，信息流不是由通信關聯來表示的，該信息流是黑默以存在的，並且是雙向的，它與箭頭所指的方向沒有關系。

使用UML建模

（引用博客 UML是什么？  原文鏈接：https://blog.csdn.net/Ellen5203/article/details/83268630）

統一建模語言（Unified Modeling Language——UML）是一種面向對象的建模語言，它可以實現大型復雜系統各種成分描述的可視化、說明並構造系統模型，以及建立各種所需的文檔，是一種定義良好、易於表達、功能強大且普遍適用的建模語言。

UML組成：

                      

UML基本內容詳述
（1）視圖
視圖是表達系統的某一方面特征的UML建模元素的子集；視圖並不是圖，它是由一個或多個圖組成的對系統某個角度的抽象。

• 用例視圖： 核心視圖強調從用戶的角度看到的或需要的系統功能。
• 邏輯視圖： 該視圖用於描述系統內實現的邏輯功能，展現系統的靜態或結構組成及特征。
• 組件視圖： 該視圖從系統實現的角度來描述模型對象間的關系。
• 配置視圖： 該視圖用於說明系統的物理配置。

（2）圖表
圖表是描述視圖內容的圖。
1）用例圖：用於描述外部項與系統提供的使用事件之間的聯系, 用例圖描述一組用例、參與者及它們之間的關系。用戶角度描述系統功能；參與者是外部觸發因素；（包括用戶、組織、外部系統，時間）用例是功能單元。

2）類圖： 用於描述系統的靜態結構。類可以用不同方式連接，主要包括聯合、依賴、獨立和包裝。一個系統一般有多張類圖，一個類可在不同的視圖中出現。

3）對象圖：用於表述系統在某個時刻的靜態結構。對象圖也可作為協作圖的一部分，說明一組對象之間的動態協作關系。
對象圖與類圖的區別：對象圖表示的是類中的許多對象實例，而不是類本身。

4）狀態圖：用於說明類中的對象可能具有的狀態，以及由時間引起的狀態的改變。
簡單理解：描述了系統元素的狀態條件和響應。

 

 

5）順序圖（時序圖）：用於描述對象間的動態協作關系。表達了對象間發行消息的時序，同時也表達出對象間的相互作用，以及當系統執行到某個特定位置時可能會發生的事。
簡單理解：按時間順序描述系統元素間的交互。

 

 

 

6）協作圖（通信圖）：按照時間和空間順序描述系統元素間的交互和它們之間的關系。是一種交互圖，它強調收發消息的對象或參與的組織結構。

與順序圖的區別：順序圖強調的是時序通信圖強調的是對象之間的組織結構（關系）

7）活動圖：用於描述系統活動的流程。活動圖由活動狀態組成，它包含將完成的活動的說明。當一個動作完成時，激發一個明確的事件並轉到一個新的狀態。它可以描述並行執行的活動。另外，它還包括了當動作部分完成時收到或發出的消息的說明。
簡單理解：本質上是流程圖，描述系統的執行順序。

 

 

8）構建圖，組件圖：用於描述組件代碼的物理結構。它建立了一個從邏輯視圖到物理視圖的映射。同時，它還描述了組件的依賴關系，可以用來分析一個組件的變化對另一個組件所產生的影響。

9）配置圖
  用於描述系統中軟件和硬件的物理結構。

10）狀態圖

11）定時圖

定時圖是一種新增的、特別適合實時和嵌入式系統建模的交互圖，也稱為計時圖，計時圖關注沿着線性時間軸、生命線內部和生命線之間的條件改變。它描述對象狀態隨着時間改變的情況，很像示波器，適合分析周期和非周期性任務。
定時圖強調消息跨越不同對象或參與者的實際時間，而不僅僅關心消息的相對順序。

12）部署圖 

  軟硬件之間映射

12）4+1 視圖
     需求分析模型：  邏輯視圖（類與對象） -> 實現視圖（物理代碼與文件） -> 部署視圖（軟件到硬件的映射） -> 進程視圖（線程，進程，並發）    圍繞 用例視圖 

    軟件體系結構。“4+1”視圖模型從5個不同的視角包括邏輯視圖、進程視圖、物理視圖、開發視圖和場景視圖來描述軟件體系結構。

 

 

模型元素
  模型元素代表面向對象中的類、對象、接口、消息和關系等概念。UML中的模型元素包括事物和事物之間的聯系，常見的聯系包括關聯關系、依賴關系、泛化關系、實現關系和聚合關系。
基本機制
  UML的基本機制表現為各種圖標上的附加信息，用於描述那些模型元素無法表達的內容。
1）修飾
  通過特定的修飾把一些語義加到模型元素上。
2）注釋
  UML提供增加注釋的方式以表達那些模型元素無法表示的信息。
3）說明
  用於增加無法正式在圖中表示的元素實例的附加說明，可以由文本的形式對圖中相應部分的責任和權限加以說明。

規則是構造塊如何放在一起的規定，包括為構造塊命名；給一個名字以特定含義的語境，即范圍；怎樣使用或看見名字，即可見性；事物如何正確、一致地相互聯系，即完整性；運行或模擬動態模型的含義是什么，即執行。
公共機制是指達到特定目標的公共UML方法，主要包括規格說明（詳細說明）、修飾、公共分類（通用划分）和擴展機制4種。規格說明是事物語義的細節描述，它是模型真正的核心。

UML在需求分析中的使用：

UML有三種基本的構造塊，分別是事物（thing）、關系（relationship）和圖（diagram）。事物是UML的重要組成部分，關系把事物緊密聯系在一起，圖是多個相互關聯的事物的集合。

UML用關系把事物結合在一起，主要有下列四種關系：

1. 依賴（Dependency）。依賴是兩個事物之間的語義關系，其中一個事物發生變化會影響另一個事物的語義。
2. 關聯（Association）。關聯描述一組對象之間連接的結構關系。
   　　聚合關系：整體與部分生命周期不同；  
           組合關系：整體與部分生命周期相同；
3. 泛化是一般化和特殊化的關系，描述特殊元素的對象可替換一般元素的對象。
4. 實現（Realization）。實現是類之間的語義關系，其中的一個類指定了由另一個類保證執行的契約。

 

 

 

 

 

UML2.0

（1）組合結構圖描述結構化類（例如，構件或類）的內部結構，包括結構化類與系統其余部分的交互點。組合結構圖用於畫出結構化類的內部內容。
（2）定時圖也稱計時圖，定時圖也是一種交互圖，它強調消息跨越不同對象或參與者的實際時問，而不僅僅只是關心消息的相對順序。
（3）制品圖描述計算機中一個系統的物理結構。制品包括文件、數據庫和類似的物理比特集合。制品圖通常與部署圖一起使用。制品也給出了它們實現的類和構件。
（4）交互概覽圖是活動圖和順序圖的混合物。它是活動圖的變體，描述業務過程中的控制流概覽，軟件過程中的詳細邏輯概覽，以及將多個圖進行連接，抽象掉了消息和生命線。
  

 

 

需求變更

一個大型軟件系統的需求通常是會發生變化的。在進行需求變更時，可以參考以下的需求變更策：

（1）所有需求變更必須遵循變更控制過程；
（2）對於未獲得批准的變更，不應該做設計和實現工作；
（3）變更應該由項目變更控制委員會決定實現哪些變更；
（4）項目風險承擔者應該能夠了解變更數據庫的內容；
（5）決不能從數據庫中刪除或者修改變更請求的原始文檔；
（6）每一個集成的需求變更必須能跟蹤到一個經核准的變更請求

 

需求管理

需求管理是一個對系統需求變更、了解和控制的過程。需求管理過程與需求開發過程相互關聯，當初始需求導出的同時就啟動了需求管理計划，一旦形成了需求文檔的初稿，需求管理活動就開始了。關於需求管理過程域內的原則和策，可以參考：①需求管理的關鍵過程領域不涉及收集和分析項目需求，而是假定己收集了軟件需求，或者已由更高一級的系統給定了需求。②開發人員在向客戶以及有關部門承諾某些需求之前，應該確認需求和約束條件、風險、偶然因素、假定條件等。③關鍵處理領域同樣建議通過版本控制和變更控制來管理需求文檔。