第 3 章建立需求模型

第3章建立需求模型 Prepared by S. F. Chang

系統分析階段概述P123 系統分析階段的整體目的在於了解所提議成立的專案，同時確認它能夠支援企業需求，且為後續的系統開發打好基礎。在此階段，你運用各種模型及文件工具來預見並描述所提議的系統。 • 系統分析的活動 • 系統分析階段包含三個主要活動: 建立需求模型、建立企業模型(即建立資料與處理工作模型)，及考量開發策略。 • 建立需求模型(requirements modeling #)，其中包括了發現事實來描述目前的系統並指出新系統的需求，例如: 輸出、輸入、處理工作、績效及安全等需求。輸出(outputs #)係指由系統產生的電子或列印的資訊。

系統分析階段概述P124 輸入(inputs #)係指需要輸入到系統的資料，不論是以人工或是以自動化的方式來進行。處理工作(processes #)則是指用來將資料轉化為有用的資訊的邏輯規則。績效(performance #)則是指系統的特質，如速度、資料量、容量、可靠性及穩定性。安全(security #)則是指用來保護系統及其資料免於內部或外部威脅的各種硬體、軟體、及流程控制。 • 建立資料與處理工作模型即是運用傳統結構化分析技術，以圖形來表示系統資料及處理工作，而繼續模型建立的流程。在結構化分析中，視資料及處理工作為個別的元件。

系統分析階段概述P124 • 在開發策略中，你將要考量各種開發的方式並準備轉入SDLC的系統設計階段。 • 系統分析階段的交付標的或產出是一份系統需求文件(system requirement document #) ，這份文件是新系統的整體設計藍圖。除此之外，系統分析階段中的每一個活動各自有產出及一個或多個里程碑。 • 系統分析技巧 • 為了正確地建立新系統的模型，你必須具備良好的分析技巧和人際技巧。 • 分析技巧使你能夠明辨問題所在、評估關鍵因素，並開發出有用的解決方案。

系統分析階段概述P124 • 人際技巧對一個必須與組織內各層級的人合作，並需在使用者互相衝突的需求間求得平衡，並做有效溝通的分析師而言，實在是非常的重要。 • 團隊導向方法及技巧 • 許多IT經理試圖提高使用者在開發過程中的參與度，使用者的高度參與往往會造成較好的溝通、更快的開發時間，及更滿意的使用者。 • 許多公司現在是用小組方式來開發資訊系統。例如，聯合應用系統開發(JAD, joint application development #)方法，就是一種用來發現事實及建立需求模型的團隊導向的技術。

系統分析階段概述P125 • 另一種廣泛使用的使用者導向方法是快速應用系統開發(RAD, rapid application development #)。 RAD是完整SDLC的精簡版本，其中使用者隨時參與每一個步驟。 • 相較於JAD一般只著重在發現事實及需求確認，RAD對整個系統開發工作的全程提供一個快捷的方法，其中包括規劃、設計、建構，及切換。

聯合應用系統開發方法P125 • 使用者參與 • 使用者在資訊系統中有重大的關聯，而且他們應該在開發過程中完全參與。 • 在開發的過程中，IT人員會從使用者那裏收集資訊、定義系統需求，並建構新系統。在過程中的各階段，IT人員可能會要求使用者複閱其設計、提供意見，並提出修改的要求。 • IT專業人員現在已體認到成功的系統必須是使用者導向的，而使用者需要參與系統開發的每一階段，不論是正式或非正式地。

聯合應用系統開發方法P126 • 在JAD團隊方式中對於使用者參與有一個廣受採用的策略，其中涉及一個由使用者、經理人，及IT專家組成的特別工作小組。他們一同工作以取得各種資訊、討論企業需求，及定義出新系統的需求。 • JAD參與者及其角色 • JAD 小組通常每隔幾天或幾週開一次會，地點可能是在公司的會議室，也可以到公司外任意的地點。不管是用什麼形式，JAD成員必須不被其日常的業務干擾。其目的在於分析現行系統、設法找出潛在的解決方案，及對新系統的需求達成共識。

聯合應用系統開發方法P127 一般JAD成員及其角色

聯合應用系統開發方法P128 • JAD的優缺點 • 缺點︰與傳統方法相比較，JAD成本較高且如果小組相對於專案規模顯得太大時也可能變得繁複。 • 優點︰ • JAD讓主要的使用者有機會在需求模型建立的過程中有效的參與，讓使用者們比較會對其結果產生歸屬感而支持新系統。 • 當運用得當時，JAD可以產生更精確的系統需求描述、對共同目標更加了解，以及對新系統的成功提供更強的保證。

快速應用系統開發P128 • 快速應用系統開發(RAD)是一種能夠加快資訊系統開發速度，且產生一個能夠運作的資訊系統的一種以團隊為基礎的系統開發技術。 • 如JAD一殷，RAD也採用團隊方法，但是更為深入。相較於JAD是一套需求模型，RAD的最後產出則是一個新的資訊系統。 • RAD是一套完整的方法論，其中包括一個與傳統SDLC各階段相對應的四階段生命週期。許多公司採用RAD來降低成本及系統開發時間，並提升成功的機率。 • RAD非常仰賴雛型的建立及使用者的參與。 RAD的過程允許使用者儘早能夠檢視一個可運作的模型、判定它是否能滿足其需求、並建議必要的變更。 • 專案小組採用CASE工具來建立雛型，並且產生一系列的文件。

快速應用系統開發P129 • RAD各階段及其活動 RAD模型包含四大階段: 需求規劃、使用者設計、建構及切換。 • 需求規劃階段(requirement planning phase)結合了SDLC中系統規劃及系統分析階段的所有元素。 (****參考下兩頁之插圖) • 在使用者設計階段(user design phase)期間，使用者與系統分析師互動，並產生能夠代表所有系統處理工作、輸出，及輸入的模型及雛型。 RAD團隊或次團隊通常混合使用JAD技術及CASE工具來轉化使用者需求成為可運作的模型。使用者設計是一個允許使用者去了解、修改，並最後認可一個符合其需求的可運作系統模型的連續互動的過程。

快速應用系統開發P129 • 建構階段(construction phase)著重在與SDLC相似的程式及應用系統開發的工作。然而在RAD中，在實際的螢幕畫面或報表在開發時，使用者持續地參與並仍然可以建議做修改或改善。 • 切換階段(cutover phase)與SDLC中建置階段的最後任務相似，包括資料轉換、測試、轉換到新系統，及使用者培訓。與傳統的方法比較，其整體的過程是壓縮了。其結果是新系統更快地被打造、交付，並開始運作。

圖1-27 SDLC的各階段及其交付標的 p36 系統申請相似於RAD的需求規劃階段階段1: 系統規劃相似於RAD的使用者設計階段階段2: 系統分析初步調查報告相似於RAD的建構階段及切換階段階段3: 系統設計 Stop 系統需求文件停止開發專案階段4: 系統建置系統設計規格 Stop 停止開發專案階段5: 系統運行與支援功能完備的資訊系統 Stop 停止開發專案運行的資訊系統

圖3-7 RAD模型中的四階段為需求規劃、使用者設計、建構，及切換需求規劃任務: .使用者、經理人，及lT人員對業務需求、專案範圍及系統需求獲致協議 .獲得繼續推動的授權任務: .程式及應用系統開發 .編碼 .單元、整合及系統測試使用者設計建構任務: .與使用者互動 .發展模型及雛型 .實施密集的JAD形式的會議任務: .資料轉換 .全面測試 .系統轉換 .使用者培訓切換

快速應用系統開發P130 • RAD目標 • 所有RAD方法的主要目標是藉由使用者在系統開發每一階段的參與來減少開發的費用及時間。因為它是一個連續的過程，當設計演化中，RAD 容許開發小組快速地做出必要的修改。 • 除了使用者參與之外，一個成功的RAD小組也必須要有IT資源技術、及管理者的支持。

快速應用系統開發P131 • RAD的優缺點與傳統結構化分析方法相較RAD有其優點及缺點: • 優點︰系統可以在節省大量成本之下快速地被開發出來。 • 缺點︰ • RAD強調系統本身的機制而不注重公司的策略性業務需要，其風險在於短期內系統可能運作良好，但是公司及系統的長期目標不見得相符。 • 加速的週期時間，可能導致無暇兼顧品質、一致性，及設計標準。然而，若是一個企業組織了解可能的危機，RAD可以是一個誘人的替代方法

建立模型的工具及技巧P131 模型可以幫助使用者、管理者，及IT專業人員了解系統的設計。在建立需求模型時你可以使用各種工具來描述業務流程、需求，及使用者與系統間的互動。 • CASE工具 • CASE工具可以提供強力的模型建立功能。 • 系統分析師交替地使用模型建立及發現事實，首先他們將發現事實的結果建入模型，然後再研究此模型以決定是否需要額外的發現事實工作。 • 為了協助他們了解系統需求，系統分析師經常使用能夠提供企業導向概觀的功能分解圖，及能夠展示出人們如何與該系統互動的統一建模語言。

建立模型的工具及技巧P132 • 功能分解圖 • 功能分解圖(FDD, functional decomposition diagram #)是一種由上而下展示企業功能與流程的方法，FDD也被稱為結構圖(structure chart #)。使用FDD分析師能夠展示出企業功能並且將它們分解為更低層的功能及流程。 (參考圖3-9) (亦稱為HIPO圖，即HierarchicalInputProcessOutput的縮寫) • FDD可以在系統開發的許多階段被使用。在建立需求模型的階段，分析師用FDD來建立企業功能的模型，並展示它們是如何地被分解成更低一層的處理單元，這些處理單元在應用系統開發時可轉換為程式模組。

本圖節錄自「電子商城購物網站系統」，陳宗興策劃，知城數位公司出版本圖節錄自「電子商城購物網站系統」，陳宗興策劃，知城數位公司出版

本圖節錄自「餐飲業網站訂位管理系統」，陳宗興策劃，知城數位公司出版本圖節錄自「餐飲業網站訂位管理系統」，陳宗興策劃，知城數位公司出版

建立模型的工具及技巧P133 • 統一建模語言 • 統一建模語言(UML, Unified Modeling Language #)是一種廣受採用於將系統設計視覺化及建立文件的方法。 • UML採用物件導向設計的觀念，但它獨立於任何特定的程式語言，被用來描繪企業流程和需求。 • UML提供幾種圖形工具和技術，例如: 使用情況圖及次序圖。 • 使用情況圖(use case diagram #)以視覺化的方式來表達使用者和資訊系統之間的互動。在使用情況圖中，使用者變成一個演員(actor)以描述他在與系統互動時扮演的特定角色。

建立模型的工具及技巧P134 • 因為使用情況描繪使用者眼中的系統，在描述交易時則可以使用一般的企業術語。 (如圖3-10圖3-12)

學籍系統的使用情況圖P135

建立模型的工具及技巧P134 • 次序圖(sequence diagram #)顯示出當物件之間有交易發生時的時序。下圖為一個信用卡核驗成功的次序圖。

系統需求查核清單P136 在建立需求模型時，系統開發人員必須指出並描述所有的系統需求。所謂系統需求(system requirement #)是一些為使資訊系統能夠滿足企業需求，且為使用者所接受而必須具備的特性或特質。因此，系統需求便成為一個系統完成後其整體被接受程度的標竿。系統需求可分為五大類: 輸出、輸入、處理工作、績效，及控制。各類別的系統需求實例詳述如下︰ • 輸出 • 此網站必須每四小時回報一次線上使用量，在尖峰時段則需每小時回報。

系統需求查核清單P137 • 此業務聯繫系統必須為每個業務代表產生一份每日的備忘清單。 • 此進貨系統必須能夠提供最新的規格給供應商。 • … • 輸入 • 部門的主管必須用另一個獨立的螢幕輸入加班鐘點數。 • 每張輸入表單須包含日期、時間、產品編號、客戶代號及數量。 • 資料輸入螢幕除了背景顏色可以由使用者改變之外，其餘必須標準化。 • …

系統需求查核清單P137 • 處理工作 (功能) • 學生學籍系統必須在每學期末計算GPA。 • 薪資系統年終作業的最後一個步驟是更新員工薪資、紅利及福利，並產生國稅局所需的稅務資料。 • 錄影帶出租系統應該制止有逾期未還影帶的客戶再借影片。 • … • 績效 • 此系統必須同時供25位使用者上線。 • 反應時間不可超過4秒。 • 學生學籍系統必須在註冊結束後5小時產生班級名單。 • …

系統需求查核清單P138 • 控制 • 系統必須在作業系統層次及應用系統層次提供登入安全機制。 • 員工資料記錄只能由人力資源部門的專人做新增、修改及刪除。 • 所有的交易必須留下可供稽查的紀錄。 • …

未來成長、成本，及利益P138 除了以上所列之系統需求外，系統分析師必須考慮決定系統如何處理未來的成長及需求的規模彈性，以及包括了所有未來的運行及支援的總取得成本。 • 規模彈性 • 所謂規模彈性(scalability)是指系統能夠處理未來業務量及交易增加的能力。因為一個有彈性的系統有較長的有效壽命，所以對於先前的投資會有較好的回報。 • 為了評估規模彈性，你需要有關目前及未來所有輸出、輸入，及處理工作的工作量及成長率的資訊。

未來成長、成本，及利益P138 • 例如，在建立一個處理客戶訂單的網站時，你必須知道上網客戶的估計數量、上線活動的尖峰時段、每筆交易所需資料項目之數量及型態，以及用來取得及更新客戶檔案的方法。 • 總取得成本 • 除了直接成本之外，系統開發者必須找出並記錄所有構成總取得成本(TCO, total cost of ownership)的間接費用，這對於一個正在對數個方案做評選的發展小組而言尤其重要。例如︰使用者的支援及故障期間生產力的損失等皆屬於間接成本。

發現事實P139 到目前，你已經了解了系統需求的種類、規模彈性，以及總取得成本等觀念，下一步就是開始收集資訊。在建立需求模型的期間，你將會使用各種發現事實的技術，其中包括訪談、文件查閱、觀察、調查及問卷、抽樣，以及研究。 • 誰來做、做什麼、在哪裏做、何時做、如何做、為什麼要做? • 發現事實會牽涉到五個熟悉的問題: 誰來做、做什麼、在哪裹做、何時做、如何做(who, what, where, when, and how)。而針對這些問題你同時必須逐一地再問另一個重要的問題:為什麼要做(why)。

發現事實P142 圖3-15 在建立需求模型期間，當注意力由目前的系統轉向新提議的系統時，ㄧ些問題的例子。

發現事實P142 • 訪談 • 所謂訪談(interview #)是一個有計畫的會談，藉由它，你可以從其他人口中獲得資訊。你必須具有規劃、執行及記錄一個成功訪談的技術。 • 每個訪談均會包含以下七個步驟(依照順序): • 決定訪談對象 • 設定訪談目標 • 發展訪談問題 • 準備訪談工作 • 實際從事訪談 • 記錄訪談文件 • 評估訪談結果

發現事實P144 • 第1步驟: 決定訪談對象 • 為能準確地了解系統，你必須問對人，而且問對問題。在初步調查期間，你主要是與中階管理層或部門主管交談。現在到了系統分析階段，你或許需要與組織內各個階層的人做訪談。 • 雖然你可以從先前查看的正式組織圖中選擇訪談的對象，你也應該同時考慮存在於組織中的非正式架構。在非正式的架構中，有些人比實際組織圖中顯示的更具有影響力或知識。 • 群組訪談可以節省時間並有機會觀察受訪者的互動，當然群組訪談也有一些問題，可能有某個人會主導交談，有高階經理人出現可能會妨礙低階層員工暢所欲言。

發現事實P144 • 第2步驟: 設定訪談目標 • 一個訪談的目標依訪談對象所扮演的角色而定。上層的管理人能夠提供你較廣的視野而對系統的整體做了解。而對於業務及程序的細節，則是向每日實際在該系統中工作的人員詢問較好。 • 在系統分析階段的初期，訪談的內容通常是一般性的問題。然而在發現事實的工作進行之後，訪談就逐漸著重在特定的議題上。訪談的目標也隨著調查工作各階段的轉換而變化。

發現事實P145 • 第3步驟: 發展訪談問題 • 建立一個標準的訪談問題清單幫助你不偏離主題，並避免不必要的一些漫談。 • 訪談應該由不同型態的問題組成: 開放式、封閉式，或是區間回應式。當你對問題作陳述時，應該避免會誘致特定回應的誘導式問題。 • 開放式問題鼓勵自發的且非結構性的反應。這種問題適用在當你要去了解一個較大的程序，或想獲得受訪者的觀點、態度或建議時 (就像考試的申論題) ，例如: 這項工作是如何被執行的? 你為什麼用這種方式執行? 。

發現事實P146 • 封閉式問題限制了回應的內容。要更特定的資訊或是需要查驗事實的時候，你可以用封閉式的問題(就像考試的簡答題或填充題) ，例如: 在此部門中共有幾部個人電腦? 在他們送出報表前你是否做核閱? • 區間回應問題是封閉式問題的一種，它要求受訪者由對特定問題做限定的回應或以數值量表的方式來評估某些事物，例如: 你認為此問題的嚴重性如何:低、中或高? 系統當機發生的頻率對你而言是: 從不、偶爾、經常、總是? • 第4步驟: 準備訪談工作 • 在訪談前一天發一封e-mail或打電話提醒。 • 對受訪者而言，訪談會打斷其例行工作，因此你應該將訪談限制在一個小時以內。

發現事實P146 • 向部門主管打聲招呼當你要訪談他手下的員工時。 • 你應該在會談前幾天就把基本問題的清單送一份給受訪者，尤其是當你需要一些細節的資訊時，如此他可以充分的準備並減少做說明的時間。 • 如果你有一些問題牽涉到文件或表單，可要求受訪者在開會時準備一些樣本。 • 對於訪談的最佳地點有兩派說法。有些分析師認為訪談應該在受訪者的辦公室進行，而有些人則認為一個中立地點，如: 會議室較佳。

發現事實P147 • 支持在受訪者辦公室進行訪談的人相信︰受訪者在會談中會感到比較舒服，另外一個支持的理由是︰辦公室是受訪者最容易取得會談中可能需要的各種文件的地方。 • 支持中立地帶的人強調儘量降低干擾，所以對方才能完全地集中精神，此外，不受中斷的面談比較節省時間。 • 第5步驟: 實際從事訪談 • 當實際訪談時，首先你應該介紹自己，描述一下本專案，並解說此次訪談的目標。 • 與受訪者建立一個和善的關係非常重要，尤其在第一次會談時更是如此。 • 在訪談中的主要任務就是傾聽回答。

發現事實P149 • 有研究指出，在會談中最長的間斷時間一般是3~5秒。在這個時間之後，其中一人就會開始發言。 • 在訪談之後，你應該彙整訪談的會議記錄並取得參與者的確認。 • 第6步驟: 記錄訪談文件 • 雖然在訪談中做筆記有優點，但是應該儘可能的減少。雖然你應該寫下一些，以便會後做提醒之用，但是你應該避免抄下所有的對話。花太多的時間抄寫會使別人分心而且使得和善的關係難以建立。

發現事實P149 • 你必須預留緊隨著訪談之後的時間，來記錄所發現的事實並評估所得到的資訊。因此，儘量不要安排連續的訪談。 • 有研究指出有50%的會談，在30分鐘之後被完全遺忘。因此，你應該用筆記來立即記錄所得到的事實，而不至於忘了它們。 • 雖然有許多人在錄音機出現時感到不自在，但是錄音機仍是有用的訪談工具。在使用錄音機之前，你應該告知受訪者，並且告訴他們你在做完筆錄之後會將錄音帶消磁。 • 縱使有錄音機協助，你仍應仔細傾聽受訪者的回應，如此你才能問出好的接續問題。 • 在訪談之後，記得送一份備忘錄給受訪者，對他的時間及合作表示感謝。

發現事實P150 • 第7步驟: 評估訪談結果 • 除了記錄下訪談中所發現的事實之外，也要試著找出其中可能的偏頗之處。例如，一個受訪者試圖保護其領域或功能時，可能會提供不完整的答案或是持保留態度。 • 不成功的訪談 • 無論你為訪談做的準備多麼好，有些訪談還是不成功。主要理由之一可能是，你與受訪者未能好好地相處。這種情況可能由幾種因素造成。例如，一個誤會或個性上的衝突，可能對訪談有不利的影響，或受訪者可能害怕新系統將取消或改變他的職務。 • 受訪者可能對你的開放式問題僅僅給予簡短或不完全的答覆，如果是這樣，你應當嘗試使用封閉式問題或區間式回應的問題。

其他發現事實的技術P152 • 文件查閱 • 文件查閱(document review)可幫助你了解目前的系統是如何運作的。要記住，系統文件有時是過時的，一些表格可能改變或停止使用。 • 你應當取得幾份實際表格和目前還在使用的操作文件。 • 觀察 • 觀看運行中的系統可以給你另一種見解及對系統程序更佳的體認。 • 親自觀察還使你得以驗證訪談中的說法並判斷程序是否真的如其所述的方式運作。

其他發現事實的技術P152 • 親自觀察還能提供一些益處，例如︰ • 基於對實際操作、親自觀察的建議，往往較能夠被接受。 • 觀察還能夠提供檢驗或引進未來變更所需的知識，並能幫助與將使用新系統的操作人員建立關係。 • 在預先規劃你的觀察工作時，可預先備妥一份含有你想觀察的具體任務和想問的問題的核對清單。在你準備這個清單時要考慮下列問題: • 充分提問問題以保證你對現有系統的運作有完整的了解。其中一個主要目標是指認出標準操作程序中沒有列出的情況之處理方法，例如，如果員工遺失了工時卡，薪資處理系統將發生什麼情況? 如果一名員工開始工作的時間遲了10分鐘，但是隨後又加班工作20分鐘，處理的程序如何?

其他發現事實的技術P153 • 觀察一個交易的所有步驟，並且注意到所有相關的文件、輸入、輸出，以及處理工作。 • 審查每一個有關的表格、紀錄，和報表。確認每一個資訊服務項目的目的。 • 考量與使用該系統的每一個人和下列問題: 那個人從其他人員取得什麼資訊? 這個人的工作產生什麼資訊? 這些資訊如何傳遞? .... • 與收到現有報表的人員交談，查明這些報告是否完整、及時、準確，並以有用的形式提出。詢問該資訊是否可以取消或改進，以及人們是否想要獲得其他額外的資訊。 • 所謂霍桑效應，這項研究的目的是決定工作環境中的不同變化如何影響員工的生產力。結論是︰無論何時，只要工作人員知道他們受到觀察，生產率就會提高。

其他發現事實的技術P153 • 要記住，正常的運作並不總是像你的觀察所顯示的那麼平順。運作也有可能因為工作人員在觀察期間神經緊張而比較不順利。如有可能，訪談工作人員及其主管，討論你的規劃和目的，以幫助建立良好的工作關係。 • 問卷及調查 • 在那些希望能從大量人員獲得意見投入的系統開發專案中，問卷調查可能是一個有價值的工具。問卷(questionnaire)，有時也稱為調查(survey)，是能夠發給許多個人的一份包含有許多標準問題的文件。圖3-21表示含有幾種不同問答格式的問卷樣本。

其他發現事實的技術P156 • 你在設計問卷時，還要記住下面一些觀念︰ • 保持問卷的簡潔，且便於回答者使用。 • 以合邏輯的順序安排問題，題目由簡易到複雜排列。 • 少使用不容易製表的開放型問題。 • 少使用能夠引起關於職務安全的憂慮或其他負面因素的問題。 • … • 儘可能在最後定稿並發給大群組之前，在一個小型測試群組中檢驗問卷。 • 抽樣 • 抽樣技術包括︰系統抽樣、分層抽樣和隨機抽樣。

其他發現事實的技術P157 假設你有一個200個客戶的名單，他們抱怨報表中有錯誤，而你要檢驗一下其中20個代表性的客戶樣本。 • 系統抽樣(systematic sample)就每十個客戶選擇一個以供考察。 • 如果你想要確保樣本在地理位置上的平均分佈，你可以採用分層抽樣(stratified sample)，從四個郵遞區號中的每一個各選五個客戶。 • 隨機抽樣(random sample)就是任意選擇20個客戶。 • 當使用訪談或問卷調查時，你也應該考量抽樣。

其他發現事實的技術P158 • 研究 • 研究可能包括網際網路、IT雜誌，和書籍來取得一些背景資訊、技術材料，和關於產業趨勢消息。此外，你還可以參加專業會議、研討會，以及與其他IT專業人士討論。 • 研究方式也可以包括現場參訪(site visits)，其目的是觀察在某個地點使用中的系統。對單獨一個現場的參訪很少能給予你真實的情況。所以，你應當儘量要求參訪多個安裝地點。 • 在參訪現場之前，正像你為訪談做準備那樣，也要為它做好準備工作。

第 3 章建立需求模型