需求分析與建模最佳實踐

時間 2019-12-09

標籤需求分析建模最佳實踐欄目快樂工作简体版

原文原文鏈接

編輯推薦:

本文來自於簡書，需求分析的任務不是分析系統如何實現用戶的須要，而是對業務分析，造成一個體系完整，內容清晰的業務框架，以指導後續的設計開發工做。數據庫

1.1 需求分析建模的要點與誤區數據結構

1.1.1 需求分析到底作什麼架構

需求分析的任務不是分析系統如何實現用戶的須要，而是對業務分析，造成一個體系完整，內容清晰的業務框架，以指導後續的設計開發工做。框架

需求分析就是先分解，再提煉，在這個過程當中消除矛盾。數據庫設計

1.1.1.1 分解工具

現代需求工程理論更建議採用業務導向分解，而非傳統的系統導向分解。性能

》業務流程爲線索的分解結構優化

這種結構是以業務流程爲主線索，對於聯機事務處理系統，管理信息系統而言都是很是適用的方法。編碼

》程序結構爲線索的分解結構設計

這種分解結構過早的進入了程序結構，割裂了與問題域之間的聯繫，從醫致使對問題研究不足的狀況，從而下降需求質量，增長變動風險。這種結構適用於問題不復雜，系統與問題關聯性不強的狀況，例如工具軟件，面向設備的系統等。

》基於場景的分解結構

對於決策支持系統，面向用戶的嵌入式系統，就比較適合使用場景做爲線索。這些場景向上能夠總結成一系列關注點或功能域，向下能夠分解成具體的決策步驟。

》基於數據的分解結構

》小結

選擇了合適的分解結構以後，就能夠按其線索把需求規格說明書大綱肯定下來了，就知道應該捕獲什麼信息了，信息捕獲回來以後就將其填充到大綱裏，並不斷驗證。

1.1.1.2 提煉

分解是一種自頂向下的方法，按任何一種線索分解，都會破壞其餘線索的完整性。因此還須要自底向上的方法進行提煉，抽取出共性的部分，創建針對全局的領域模型。

1.1.1.3 消除矛盾

1.1.2 建模的目標和要點

建模的過程比結果重要。

建模是需求分析的主要手段。但若是爲了建模而建模，它就會變成一個問題，致使華而不實，形成溝通障礙。

1.1.2.1 建模的目的

建模的好處在於更好地理解正在開發的系統。建模的目的在於幫助咱們按照須要的樣式對系統進行可視化，提供一種詳細說明系統的結構或行爲的方法，給出一個指導系統構造的模板，對咱們所作出的決策進行文檔化。

1.1.2.3 建模的要點與原則

要點：設計要文檔化；用可視化的模型表達架構；不要爲了建模而建模，若是模型不能對系統的構建起到幫助做用，那麼就是一種人力資源的浪費。

模型是用來溝通的，所以僅當須要的時候才構建模型。

1.1.3 選擇建模工具的要點

1.1.3.1 正確認識建模方法論

建模的要點是根據要完成的任務，選擇合適的建模工具。

1.1.3.2 正確認識UML

》UML的發展歷史

》UML的準確理解

》爲何要用UML建模

》如何選擇UML圖

1.2 週期一：理清框架與脈絡

任務：理清需求的結構框架(領域類圖)，行爲脈絡(流程圖和用例圖)。

輸入：需求定義階段產生的業務時間列表和報表列表。

輸出：領域模型和用例模型。

該任務對應於RUP中細化階段的第一次迭代，該階段的結束標誌是標識除了絕大部分用例，生成了領域模型。

1.2.1 業務流程分析

每一個業務事件都是流程的觸發，所以針對每一個事件都應該繼續作流程分析。不過根據流程的複雜度做出裁剪，簡單的流程能夠只用文本描述，複雜的流程能夠經過流程圖表示。

1.2.1.1 業務流程分析任務概述

業務流程分析，具體來講就是識別，分析現有業務活動，肯定活動之間的關係，瞭解活動須要接受哪些信息，產生哪些數據，肯定數據傳輸路線，標識出活動是由哪些部門，崗位負責。

分析過程當中，要注意抓住核心業務和主要活動點，部門之間的銜接，工做中繁瑣，反覆，成本高，效率低，時間長，轉手多的活動。

1.2.1.2 業務流程分析與流程管理理論的關係

業務流程是對信息系統進行庖丁解牛的核心線索。

》流程的六大特性：目標性，內在性，總體性，動態性，層次性，結構性。

》工做流實現的本質

》流程設計（BPD）的原則

1 流程應該以產出爲中心，而非任務爲中心。

2 讓須要獲得流程產出的人本身執行流程。一方面如今流程設計常常引入自助的概念；第二個方面是任務應該由誰來執行能夠參照這一原則。

3 將決策權放到更低的管理職位上，這樣會獲得更高的效率。在需求分析時，若是發現流程的決策點在較高的管理崗位上，就應該注意它常常會帶來執行上的瓶頸，也就會影響系統的正常運做。

4 流程多樣化。由於場景不一樣，同一個業務事件可能會執行不一樣的流程，在系統開發時，應該充分考慮到。

5 單點接觸客戶。這一點充分體現了流程對外部客戶滿意度的關注，也是將來流程變化的一個常見趨勢。

》流程改進（BPR）的ESIA策略

ESIA就是清除低效環節（E），簡化瓶頸點（S），整合資源（I），繁瑣任務自動化（A）。

這些因素就是致使流程發生變化的主要緣由。

1.2.1.3 業務流程分析的要點與產物

在進行業務流程分析時，有幾個關鍵點：

》流程是有層次的

部門級是需求分析的主線索，崗位級是需求細節填充時的工做內容，組織級是對部門級流程的抽象歸納。

》流程是有類型的

主要類型包括：

生產性流程：是流程中最重要的部分，一般也最容易標識。

管理型流程：是對生產性流程的管控，對質量效率進度等進行控制的流程，容易忽略。

支撐性流程：是對生產性流程的補充，一般是協做部門，本部門員工執行，也是容易丟失的部分。

》流程分析的產物

應該儘量地使用模型來描述流程。最常使用的有三種：跨職責流程圖，活動圖和數據流圖。

跨職責流程圖：強調業務背景。Visio是最佳工具。

活動圖：強調對軟件開發的指導。Rose，Together都是最佳工具之一。

數據流圖：強調數據的流通加工和處理。Visio是最佳工具。

1.2.1.4 跨職責流程圖應用基礎與要點

》元素

流程名稱，職責帶區，流程階段，流程元素。

》繪製要點

要保障繪製出來的流程圖是真實有效的，就必需要強化用戶參與。

要善於，勇於拋棄細節，不要過早鑽研到業務活動的具體步驟中。

要拋棄一次成型的思路，使用迭代的方式，畫草搞，談問題，改草搞，再討論，再修正，直到達成共識。

全部職責帶區上的活動都細化到具體的崗位。

每一個活動之間的關係都已經沒有疑問，都達成共識。

1.2.1.5 活動圖應用基礎與要點

活動圖就是能夠支持並行行爲的流程圖。

在完成活動圖或跨職責流程圖以後，還須要注意：

》進行瓶頸分析。

》進行利益分析。

當流程圖繪製完成以後，花些時間進行瓶頸和利益分析，會有意想不到的收穫。

1.2.1.1 數據流圖應用基礎

對於數據流爲主線索的處理過程很是合適。

》主要元素

》分層的數據流圖

1.2.2 業務實體分析

具體來講，就是要了解這個問題域中有哪些業務實體，它們之間存在什麼樣的邏輯關係，數量關係，以及有什麼相應的結構規則。

1.2.2.1 業務實體分析任務概述

在領域建模過程當中，更多地採用自底向上的方法，針對每個業務事件或報表，分析類圖片斷，而後再將這些片斷抽象，提煉，合併，造成全局的領域模型。

實體分析的產物有兩種可選模型：類圖，ER圖。推薦使用類圖。

1.2.2.2 類圖應用基礎與要點

》面向對象思想

》類的表示方法

》類之間的關係：關聯，泛化，組合。

》肯定類的主要職責：屬性和方法。

領域模型(類圖)，是自底向上合併出來的。

領域模型應該遵循：拒絕實現細節，大類不拆分，子類不合並，同類不抽象。

領域模型：以面向對象的視角看待現實世界，經過類圖來描述事物之間的關係。所以主要工做是找出相關的類，以及他們之間的關係。

分析模型：分析模型是針對軟件系統分析，領域模型則偏重對業務分析。分析模型主要用到實體類，控制類，邊界類。

設計模型：設計模型將直接對編碼予以指導。

1.2.2.3 ER圖應用基礎

ER圖的優點在於更好地跟數據庫設計結合，缺點在於語義較類圖更弱一些。

》數據建模過程

1.2.3 角色與使用場景分析

用例分析技術，能更好地以用戶的角度，將系統看成一個黑盒子，瞭解並梳理需求，解釋如何使用系統(場景)。

1.2.3.1 用例分析技術概述

用例分析技術，包含兩個部分：用例圖，用例描述。用例圖是目錄，用例描述是封裝全部需求的形式。

1.2.3.2 參與者與用例

參與者是一種角色，能夠是人，能夠是其餘系統，能夠是硬件設備，也能夠是時鐘，但必定要是在系統以外。

參與者是直接使用系統的最終用戶，任何間接與系統相關的人員是StakeHolder，不是參與者。

1.2.3.3 用例圖

千萬不要爲了使用擴展，包含關係而使用他們。擴展用例建模一般都是優先級較低的事件。面向客戶的用例圖一般都不該該出現包含關係，這些事情應該是在面向開發團隊時才進行填充和概括的細節。

1.2.3.4 用例的來源

如何從需求中概括出用例呢?一般能夠採用兩種方法：自頂向下導出法，自底向上合併法。

》自頂向下導出法

就是從流程圖中派生出用例圖。而流程圖是經過劃分主題域，再從主題域標識業務事件，而後經過業務事件繪製出來流程圖。

拿到流程圖後，咱們首先能夠跟客戶進行邊界肯定和角色肯定，以得出表示系統邊界的用例圖。

1 邊界肯定。首先排除掉不直接使用系統的崗位。

2 肯定角色。對剩下的職責帶區進行角色化。

3 肯定用例。用例是從職責帶區中的業務活動中派生出來的。

4 繪製用例圖。有了以上分析，咱們獲得了角色，參與者，用例，就能夠繪製出用例圖了。

》自底向上合併法

對於一些中小項目而言，流程並不是涇渭分明，從流程開始梳理會比較困難，就適合採用自底向上合併法，從需求捕獲階段獲得的需求列表着手，合併出須要的用例。

1 收集原始需求。

2 肯定參與者。

3 合併用例。

4 繪製用例圖。

用例的注意事項：

1 用例圖的顆粒度取決於業務價值。

2 用業務動詞命名用例十分重要，不要在用新增xx，修改xx，刪除xx，查詢xx了。

3 採用先過後人的方式分析，而非先人後事。

1.3 週期二：肯定需求細節

這一階段的任務，是對上一階段產出的用例模型和領域模型進行細節填充。對於行爲需求的用例，咱們要填充事件流，包括：相關需求或功能點，界面原型，用例規則與約束。對於數據需求的領域類，咱們要填充字段與格式，包括字段信息，字段格式與規則，計算規則，結構規則。

1.3.1 肯定行爲需求的細節

行爲需求對應的是「人，事，物，接口」四大需求主線中的「事」，這也是軟件功能需求的主體內容。

1.3.1.1 用例的靈活運用

行爲需求能夠分爲四個類型：業務功能，報表功能，接口，技術支持。

1.3.1.2 用例描述模板

對於行爲用例來講，須要整理的內容有事件流，相關需求或功能點，界面原型，規則或約束四個方面。

事件流分析：場景和用例的關係，相似對象與類之間的關係，一個用例是對一組相似場景的抽象。而一個用例一般是一組事件流所構成。

1.3.1.3 業務用例與系統用例

業務用例描述的是全部業務操做，系統用例則只描述與系統相關的業務步驟。要警戒將系統用例寫成界面操做。

下面是機場checkin的業務用例與系統用例示範：

業務用例

很明顯，2，3，1，9都是跟系統無關的步驟，將他們去除後，就從業務用例獲得了系統用例。

系統用例

》建立業務用例的好處：避免開發層面斷章取義，而使系統步驟融入到業務場景中；提供業務優化的可能性；更好設置將來的拓展點。

》事件流描述中，應該保留主語。可使用表格或者文字的方式。

避免在用例事件流描述中出現實現細節，分支結構，循環結構。特別是不能出現多路分支結構。

1.3.1.5 界面原型

》要點：軟件需求規格里的用戶界面原型，是約束，建議，而非解決方案。需求分析人員也只能給用戶界面設計提供依據，而非設計。

》不要忽略交互。能夠採起動態原型的方式，也能夠用狀態圖表示界面的流轉。

》別讓界面掩蓋本質。

1.3.1.6 規則與約束

規則是在實現時應該考慮的東西，約束是對技術選擇時的限制條件。

》規則的類型：業務規則，數據規則，界面規則。

業務規則：與業務邏輯相關的規則。

數據規則：數據結構層面上的規則。好比長度，類型等。

界面規則：用戶界面相關的規則。好比什麼顏色的數據顯示不一樣的等級。

》規則的層次

數據與界面規則一般都是微觀規則，而業務規則卻一般涉及宏觀微觀等多種不一樣層次，所以在組織時須要注意其中的差異。

總之，對於規則與約束，有一個核心原則，就是「只寫針對本用例的內容」。

1.3.1.7 基於stakeholder利益分析的需求挖掘

1.3.2 肯定結構需求細節

若是說行爲需求從用例模型中得出，結構需求就是從領域模型中得出。咱們將從基本內容和常見盲區兩個角度來講明結構需求的細節填充。

1.3.2.1 基本內容

》領域模型的組織

從領域模型的組織角度來講，一般會首先按照主題域進行第一次分解，一個主題域對應一個領域模型，而後根據須要將各個主題域共性的領域類抽取出來，造成全局公共領域類模型。對於每一個主題域內的領域模型而言，涉及的領域類可能仍是不少，就能夠根據邏輯關係劃分爲不一樣的包，每一個包就是一個邏輯相關的領域類圖的片斷。接着對每一個片斷進行概述。就獲得如下層次：

在xx類中，咱們就能夠對每一個領域類作進一步描述了。一般都是從「數據窗口分析」，「數據組成與格式」，「派生數據的計算方法」三個角度進行描述。

》數據窗口分析

系統中的公共數據常常成爲工做交叉和衝突的地方，對於這種狀況，建議採用數據窗口的方式處理，即將公共屬性變成公共的，個性屬性仍然壓在各個模塊中。

》數據組成與格式

數據組成與格式包括：數據類型，如int，char，boolean等；長度精度等信息。組成格式，如2位字母，6位數字等。

》派生數據的計算方法

領域類中，還可能涉及一些並不是直接輸入的屬性，他們的值是經過計算得出的，例如訂單的總金額等。所以咱們還須要爲這些屬性生成規則。一般經過決策表或決策樹的形式來描述他們。

1.3.2.2 常見盲區

與結構需求相關的，還有一些相關的盲區。

》數據結構的特色

對於一個領域類而言，不一樣的屬性它們的重要性，穩定性，週期性都會影響到具體的開發決策，例如：主要字段與次要字段，穩定字段和不穩定字段，即時記錄與歷史記錄。

》數據使用特色