Blog

「軟體需求分析與塑模」- 需求分析人員的職掌

本文收錄於 我的電子書「軟體需求分析與塑模 – 第一章、需求分析概觀」。

針對「需求」作描述、紀錄與分析的人員統稱為「需求分析師 (requirement analyst, RA)」。

而以「企業」或「資訊系統」作為分析的標的來區分,需求分析人員的角色 (role) 可分為兩種:企業分析師 (business analyst, BA) 與資訊系統分析師 (information system analyst, 簡稱 SA)。

BA 涵蓋的分析範疇較 SA 來得廣,自然需較有整體性的架構觀;但相對細節,如對某一資訊系統的畫面操作或單一業務規則 (business rule),則無法來得比 SA 精細。

一般而言,BA 涵蓋的範疇有:

  • 企業策略的規劃。
  • 業務流程的制定與再造 (BPR, Business Process Re-engineering)。
  • 企業的塑模 (business modeling)。
  • 多個資訊系統之間的訊息交換與整合。

而對於資訊系統分析師 SA,一般較僅以單一資訊系統為分析的範疇:

  • 紀錄與描述未來某些活動 (activities) 會由資訊系統實現的作業流程。
  • 界定系統功能與非系統功能需求 (functional and non-functional requirements)。
  • 表單畫面的操作程序。
  • 表單需要的欄位資訊與業務規則的整理。

對於資訊系統的技術議題,SA 係從系統外觀 (把系統當黑箱) 看待系統所提供的服務 (系統功能),以及實現該功能的操作程序、業務邏輯與所需欄位資訊等。所以 SA 一般不會涉及到結構性的設計議題,諸如資料庫的資料模型 (data model) 設計,那是由 SD (System Designer) 所負責;以及程式寫碼的實作議題,那是由 Programmer 負責。

再則 BA/SA 一般並不需具備某一領域 (domain) 的相關知識,那應是由領域專家 (domain expert) 所負責。但BA/SA 需能具備與領域專家溝通的技能,例如了解該領域所常使用的詞彙術語與其意涵。

另 BA/SA 合作的對象除了領域專家外,當然會包括各類開發人員,諸如專案經理 (Project Manager)、SD (System Designer)、Programmer (程式設計師) …等。

而訪談的對象也包括了客戶單位的利益關係人 (stakeholder)、操作人員 (operator) …等。

簡而言之,BA/SA 最大的挑戰在於如何與各類不同角色的人員達成順暢的溝通,並進而引導發掘出其潛在甚或模糊的需求,且得以條理分明地讓開發人員理解而轉成實作的程式。

「軟體需求分析與塑模」- 物件合作

本文收錄於 我的電子書「軟體需求分析與塑模 – 第一章、需求分析概觀」。

實現 (realize) 軟體資訊系統功能,從物件導向 (object-oriented) 的觀點來看待時,系統內部的主要組成元素是「物件」,也可以稱為「個體 (instance)」。可以想像軟體系統內部就是由擔任各種不同職掌的類型物件,為實現某一特定功能,在動態期間 (run-time) 的互動合作來協力完成。

關於物件如何分類 (classify),這就是所謂物件導向結構設計的議題。分類作得好,讓系統具有低耦合 (low coupling) 、高內聚 (high-cohesion)的特性,如此系統的應變更具彈性、延展性,並得以提昇再利用性的高度價值。

參考下圖範例,是利用 UML 循序圖 (sequence diagram) 表達實現「餐飲管理系統」其中「點餐」系統功能的物件合作 (object collaboration) 情形。程式開發人員應該可以很容易對應至程式碼的類別 (class) 與方法 (method) 的實作。

圖例、實現「點餐」系統功能的物件合作循序圖

軟體結構設計是屬於系統的內部結構設計議題,而需求分析則是站在系統外部的觀點來看待系統所提供的服務 (系統功能),這是完全不同的兩種構面,不能混為一談。一般在需求分析階段,是會把系統當成「黑箱 (black blox)」來看待,只專注在外界 (人或外部系統) 如何與系統的溝通互動,至於系統內部如何組織分類與實作,那就會由結構與程式設計師來負責的。

「軟體需求分析與塑模」- 流程與活動

本文收錄於 我的電子書「軟體需求分析與塑模 – 第一章、需求分析概觀」。

實現企業層級系統功能的主要組成元素是「人」,也就是多個不同角色的內部工作者 (internal worker) 在不同的時間點合作接續以完成所屬職掌的工作。

當為了履行一個企業需求,可能需一連串的活動 (activities) 循序接力達成。當然活動的執行需要有特定的參與人員,也就是會有多種不同角色 (role) 或組織 (organization) 參與。這一連串的活動即構成作業流程 (business process)。

Jacobson 為企業流程 (business process) 作了一個簡單的定義:

Put simply, a business process is the set of internal activities performed to serve a customer.
Object Advantage》, Ivar Jacobson, 1994
(簡單地說,企業流程就是要能夠服務客戶的一連串企業內部的活動)

而關於「活動 (activity)」的定義 (from Wiki):

Activity is a major task that must take place in order to fulfill an operation contract.
(活動是一個必須履行的主要工作,為以滿足一個操作上的契約。)

參考下圖範例係利用 UML 活動圖 (activity diagram) 繪製傳統人工「訂購-出貨」作業流程。從該案例可以得知,這一連串從訂購到出貨的活動,會有多個不同組織部門的工作人員參與。當完成這一連串活動後,即滿足主要的企業需求-「訂購商品」。

圖例、傳統人工訂購-出貨作業流程

「軟體需求分析與塑模」- 什麼是系統功能

本文收錄於 我的電子書「軟體需求分析與塑模 – 第一章、需求分析概觀」。

系統 (system) 是由一組互動 (interacting) 或獨立的元件 (component) 所組成的整合體 (integrated whole)。

系統功能 (system functions),即為某一整合體所提供給外界 (參與者或外部系統)的一連串服務 (services)。

把企業 (business) 當成一個整合體,並藉以分析該整合體所提供的功能需求,以及組成該整合體的組成元素。這樣以企業為標的的分析塑模方式,稱為「企業塑模 (business modeling)」。

把資訊系統 (information system) 當成一個整合體,並藉以分析該整合體所提供的系統功能,以及組合該整合體的結構元素。這樣以資訊系統為標的的分析塑模方式,稱為「資訊系統塑模 (information system modeling)」。

把企業或資訊系統當為一個整合體,便可以採用相同的手法,如利用 UML (Unified Modeling Language) 語法,來分析系統需求。

「企業」與「資訊系統」兩者的關係即為,「資訊系統」為組成「企業」內部結構的其中之一的元素 (element)。而當把焦點轉移至資訊系統,探究其中所提供的系統需求 (系統功能)時,則再將「資訊系統」這個結構元素放大,並從「外」的需求分析,與「內」的結構設計來看待資訊系統的分析、設計,乃至於實作了。

參考上節範例,「診療服務」為企業的系統需求,如果企業架構師規劃了三個資訊系統 (組成元素) 的支援,參考如下圖,架構師可以利用 UML 使用案例圖表 (use case diagram) 規劃每一個資訊系統各有其需實現的系統功能,以及資訊系統之間的關係是透過介面 (interface)的連接達成所謂的「SOA (service-oriented architecture)」架構。

圖例、表達資訊系統的系統功能

至於資訊系統是如何實現系統功能,又如何連接其它外部系統,那就是所謂的系統 (這裡就是指資訊系統了) 結構設計與實作的議題了。

「軟體需求分析與塑模」– 企業需求源自於企業價值

本文收錄於 我的電子書「軟體需求分析與塑模 – 第一章、需求分析概觀」。

企業需求要能提供價值 (value),如此才得以讓企業有獲利行為而能永續經營。

「價值」的呈現取決於在創新、成本、效率等因子的調和。這些因子經常是由內部工作者 (internal-worker)、產品、系統、軟體與流程 (process)等所提供並滿足其需求。最終目的當然在於讓企業創造「利潤 (profit)」。

例如,「仁心慈善醫院」是一家企業 (business),其中最主要的核心價值係提供 「醫療」的服務 (service)。為了提供「醫療」這個主要服務,企業內部必然會有多個內部工作者的協同合作,包括「醫師」、「護士」、「藥劑師」、「行政人員」… 等;涵蓋的作業流程可能有「掛號」、「看診」、「住出院」、「領藥」… 等;且為了增進處理效率與節省人力,會導入由 產品/軟硬體 所組成的資訊系統 (information system),成為工作者的協力夥伴。

除了文字陳述紀錄外,可以藉由視覺化的圖形塑模 (visualization diagram modeling),更容易表達焦點。

例如,我們可以使用 UML「使用案例圖 (use case diagram)」表達企業所提供的主要服務 (企業層級的系統功能),以及使用「業務流程圖 (business process diagram)」表達實現 (realize) 企業系統功能的主要組成元素 (內部工作者、資訊系統、主要作業流程)。

圖例、表達企業提供的主要服務

圖例、表達實現企業需求內部的主要組成元素

關於 UML (unified modeling language) 的基本介紹,以及應用在企業與資訊系統需求面的分析 Know-how,參閱後述的章節內容。

在 Gitlab 平台簡單創建 GitBook 電子書的步驟

GitLab 提供了 gitbook儲庫 的範本,只要用戶 Fork 該專案,如此就可以建立屬於自己的 GitBook 文檔網站。不過這方式我不太喜歡,需要修改專案名稱等相關屬性,然後也要編輯「README.md」、「SUMMARY.md」內容,如此就會造成 commit 歷史紀錄一開始較為雜亂。 (雖然也可以清除,但又要額外的步驟。)

除了 Fork 的方式,其實也可以自己手動新增空白的專案,然後再針對 GitLab CI (Continuous Integration) 設定並加入執行的腳本內容即可。 (其實就是 gitbook 儲庫內的 .gitlab-ci.yml 內容)

整理下創建 GitBook 網站@GitLab 平台的步驟:

  1. 新增空白專案
    這應該不用說吧,與 GitHub 新增專案的方式幾乎是一樣。大概就是注意下儲庫的存取改為「Public」,然後預設新增一「README.md」檔案,該檔案也是 GitBook 所必要的檔案。

    新增 GitLab 空白專案

  2. 閱讀全文 »

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal