《軟件需求與可視化模型》閱讀筆記

“需求關注的是要建什麼，設計關注的則是它如何起作用”。遺憾的是，這種嚴格的定義存在一個問題：“一個層面的需求是對另一個層面的設計”。不要用“什麼”與“如何作用”的關係來區別“需求”和“設計”，這種方式不好。
   需求是企業需要在解決方案中實現的，可以包括功能性需求、非功能性需求、業務規則，甚至包括許多人傳統上所稱的設計。功能性需求是一個解決方案所提供的行爲或功能而不加任何限定詞。業務規則表示在修改功能性需求時必須滿足的條件語句，包括但不限於什麼時候該功能可以用以及允許誰執行該功能。非功能性需求是任何不屬於功能性的需求（包括業務規則）。


RML模型分爲：
目標模型。（解決方案的目標，業務目標模型界定目標）
人員模型。（正在使用解決方案的人員，組織結構圖界定人員範圍）
系統模型。（系統本身的結構，生態系統圖界定系統範圍）
數據模型。（正在處理的數據，業務數據圖界定數據範圍）
統稱爲OPSD。


數據操作只能是創建、更新、使用、移動、複製或銷燬。


業務問題：阻止達成業務目標的問題
業務目標：在解決業務問題時具體指定可度量的目標
產品概念：企業爲達成業務目標而決定實現的實際解決方案的願景，通常用主要功能列表來描述願景
成功標準：實際度量的業務目標，用來決定該項目是否成功，或者與解決方案有關的其他度量


可以把幾乎每一個業務問題分類爲增加收入或是降低成本。
產品概念包括理想中的主要特性。產品概念可以描述解決方案的許多方面，包括軟件、硬件和業務流程。
指導原則可以是解決方案中市場期望的條款或者干係人的目的條款。


組織結構圖有三個層面：部門，角色，人員。
可以用顏色來強調組織結構圖以提供更多的信息。可以使用顏色來區別對項目有特殊類型影響的不同羣體。同時建議使用一些可視化的差異，如不同的色調、圖案或邊界，爲的是方便那些看不出顏色的讀者或者打印黑白圖表。
確認項目干係人，從最基本的層次，可以查看組織結構圖中的每一個方框，並提出下面這些問題：
這個人或角色是不是一個系統用戶？
這個組、角色或人對系統是否有任何的需求？
這個組、角色或人是否會受到我們正在做的系統的影響？
他們參與了過程的哪一部分？
有沒有無人執行的流程？


創建組織結構圖的步驟：定位現有的組織結構圖-》確定級別-》完成組織的結構圖
組織結構圖何時使用：只要有內部用戶出現在層次結構，就要使用組織結構圖；何時不用：對於純粹的消費者項目，組織結構圖可能不合適。


生態系統圖顯示了系統間的交互作用和它們之間關係的性質。
如果描述接口性質需要更多的詳細內容但受到生態系統圖的空間限制，可以使用系統接口表記錄每一個接口。
創建生態系統圖的步驟：確認系統-》確認接口-》畫出總圖
確認系統的過程中，問以下問題：
哪個系統或哪些系統用於處理流程或系統流程中的每一步？
在數據流圖中，哪些系統運行修改數據的流程？在哪個系統中數據是上線的？
哪個系統或哪些系統在業務數據圖中創建、更新、使用、刪除、移動或複製每個業務數據對象？


應該總是使用生態系統圖，在任何項目中該圖應該是創建的第一組模型。唯一的例外是，解決方案是一個完全獨立的系統，不與任何其他系統進行交互。


業務數據圖（BDD）是概念性的數據模型，從企業干係人的角度顯示業務數據對象，而ERD（實體關係圖）顯示對象在數據庫架構中的實際實現。
創建BDD的步驟：確定業務數據對象-》關聯業務數據對象-》添加基數
主要有三種方法來發現哪些對象應該在BDD中：聽取主題專家的意見，看看其他視覺模型，看看現有系統的數據模型。
創建BDD時，不要想象成設計一個數據庫。你只構建BDD以反映企業干係人如何想象數據，並把數據設計的任務交給數據庫架構師去做。
BDD幫助你從視覺上把企業干係人談論的話題聯繫在一起；不僅可以幫助你瞭解業務術語，而且可以幫助你簡明地定義語言以闡明需求；從企業干係人的角度而不是技術團隊的角度展開業務數據對象；通過BDD一看就知道哪些對象是相關的。


BDD是否使用卻決於是否涉及到數據庫；BDD顯示關係，但不顯示對關係有更多限制的所有業務規則。