F_第4章软体系统的需求工程(Requirement engineering).pptVIP

第4章軟體系統的需求工程(Requirement engineering) 和春技術學院 資工系 李鴻鵬師 學習重點 軟體系統是軟體工程產物，了解應用領域與軟體系統的關聯。 學習如何描述應用領域的特徵與需求。 學習如何表示軟體系統的功能。 了解軟體系統開發的規格化。 學習需求分析的方法。 4.1 軟體開發專案的確立 近年來企業資訊系統的發展往往會特別談到企業架構(enterprise architecture)與商業程序(business process)，原因是考慮到資訊系統運用的範圍。 早期資訊的使用往往是片段、瑣碎，而且毫無組織，所以看起來好像已經電腦化了，卻沒有真正幫到什麼忙。 現代的資訊應用強調整合，資訊的運用要考量到整個企業的運作。 企業的資訊系統或許是由很多軟體系統所組成、或是經由多次專案開發而建立的，但是這些資訊系統彼此之間應該是互相搭配支援的，跟企業架構相符。 4.1.1 確立與選擇系統開發的專案 企業要評估修改系統或開發新的專案，在評估的過程中通常會考慮下列的因素： 價值鏈分析(value chain analysis) ：由於組織的生產或服務提供的活動來評估價值所在，以及成本的所在，能提供或增加價值的資訊系統應該優先開發。 策略目標的考量：資訊系統應該幫助組織達成策略上的目標與長期的目標。 潛在效益：資訊系統對於組織獲利，效益能持續多久。 需要的資源：組織是否能提供專案開發所需的軟硬體各種資源。 專案大小與時程：參與的人力是否足夠，完成專案所需的時間。 技術與風險：在預期的資源與時程下，完成專案在技術上的困難程度有多少。 在這個階段把各種對於資訊系統開發的需求都拿來評估過後，還需要對可能開發的資訊系統做進一步規劃。 4.1.2 資訊系統的規劃 資訊系統的規劃包括3個主要的步驟 : 第1個步驟是了解目前的狀況 第2個步驟是規劃未來的藍圖 第3個步驟則是排定開發的時程 規劃的方式 由上而下(top-down)的策略：從企業整體的資訊系統需求來規劃，整合各部門的需求，也一併考量整體的發展。 由下而上(bottom-up)的策略：從作業層次與部門的觀點來規劃，成效快成本低，但是很容易忽略了資訊系統的整合性。 詳細地蒐集資料 不管採用那一種規劃方式，都要進行詳細地蒐集資料，包括組織的部門所在的位置、部門的成員、部門的主要功能、組織內的程序、作業使用的資料、以及已經存在的資訊系統等。來了這一堆資料，可以是著建立一些對照表，進行交錯的比對與分析，得到值得參考的結論，常見的矩陣 (matrix)式的對照表包括： 組織的部門對照所執行的功能。 執行的功能對照組織或部門的營運目標。 執行的功能對照程序。 執行的功能對照所使用的資料。 程序對照資訊系統。 所使用的資料對照資訊系統。 資訊系統對照組織或部門的營運目標。 完整的規劃報告 上面的對照表偏向於現況的描述，對於未來的描述同樣可以建立類似的對照表。現況與未來的差異代表組織必須擬定轉變的計畫 (Transition plan)，等到這些資訊都完成蒐集與分析之後，要有一份完整的規劃報告，通常會包含下列的項目： 組織的使命、目標與策略。 相關資訊的匯集。 資訊系統的使命與目標。 資訊系統開發的已知限制。 整體的系統需求與長程的資訊策略。 短程規劃。 結論。 一般在這個階段已經可以開始運用CASE工具來輔助規劃工作的進行。 4.2 軟體專案開發的啟動 軟體專案確立以後，第1個步驟就是進行開發專案的啟動，把一開始需要建立的規則與工作做好，對於後面各階段工作的進行會有很大的幫助。專案的啟動包括下列的工作項目： 組成專案啟動的團隊。 建立與客戶之間的關係。 建立專案啟動計畫。 建立管理的程序。 建立專案管理的環境與專案工作紀錄。 專案規劃的主要項目 有了專案啟動的團隊之後，可以開始進行專案規劃 (Project planning)，得到基準的專案計畫 (Baseline project plan)，記載專案規劃得到的結果。 表4-1列出專案規劃的主要項目。 基準的專案計畫是很重要的文件，就好像是一個基礎的藍圖，後面的工作都要以這個計畫為依歸。 表4-1 專案規劃的主要項目 4.3 軟體系統的規格 所謂的「需求」是怎麼來的？下面列出幾個例子： 假設公司要讓客戶能隨時隨地下單(order)，而且不增加營運成本，要如何達成這樣的目標? 廠房空間有限，在產品的生產組合上應該如何調整，使空間的使用能最有效 ? 快遞公司需要隨時追蹤車隊的位置，同時安排駕駛順利地從一個地點前往另一個地點，要如何達到這樣的目標 ? 網路書店要與內容業者服務合作，在網站經營上需要做什麼樣的搭配才能得到比較好的效果 ? 4.3.1 資訊部門的成員 4.3.2 認識應用系統 (Application systems) 軟