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

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

針對「需求」作描述、紀錄與分析的人員統稱為「需求分析師 (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,參閱後述的章節內容。

安裝 ArchLinux @Windows 10 子系統 (WSL)

其實 Windows 10 早在去年就已具有可以在 Windows 環境下執行 Ubuntu 的機制,但還很陽春,效能不佳,問題多多。但從 Windows 10 1803 版本釋出後,WSL (Windows Subsystem for Linux) 已修正諸多問題並大幅提昇執行效能,使其執行原生 Linux 系統於 Windows 10 環境下成為可便利運行的方案。

所以,WSL 到底是什麼?這篇 Arch Wiki 上說明得很清楚:

「Windows 10 包含一個模擬 Linux 內核的子系統,使得 windows 可以運行 Linux 原生應用程序。這個子系統有點像反過來的 Wine,但是它比 Wine 更加底層。默認情況下,此子系統使用 Ubuntu 用戶空間,但是它可以被替換成 Arch。你需要使用一個現有的 Arch 安裝去構建一些軟件包。」

我個人是相當偏好 ArchLinux,因為可以高度客製化。安裝 ArchLinux 於 WSL 下相當簡單,因為國外已經有大神整理成安裝執行包,詳見 Github-ArchWSL。安裝該執行包前,需要先啟動 WSL 功能,使用 Administrator 開啟 PowerShell 命令列視窗,執行下列指令:

> Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

重新啟動,然後下載上述 ArchWSL 安裝包,解壓縮並置於準備安裝的目錄下 (我是設定於 C:\Linux\ArchLinux 目錄下)。再來依照執行 ARCH.exe,靜待安裝過程 (非常快),然後完成。

閱讀全文 »

軟體思維顧問

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

Personal