需求工程程序

1、Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1需求工程程序 l發現、分析以及確認系統需求的程序Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 2本章目的 l描述一些主要的需求工程活動l介紹數種需求擷取與分析的技術l描述需求確認的重要性l討論需求管理的角色以及如何支援需求工程的其他活動Ian Sommerville 2000 Software Engineering, 6th edition. Chap

2、ter 6 Slide 3本章內容 l可行性研究 l需求擷取與分析 l需求確認 l需求管理 Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 4需求工程程序lRE 使用的程序會根據應用領域、參與人員以及發展需求的組織有很大的差異l然而，下列幾項通用活動則是所有程序共通的需求擷取需求分析需求確認需求管理Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 5需求工程程序Ian Sommerville 2000 So

3、ftware Engineering, 6th edition. Chapter 6 Slide 6可行性研究l可行性研究可決定提出的系統是否有價值l它是一項短暫活動，著重於檢查下列幾個重點此系統對組織的整體目標是否有貢獻？此系統是否可以利用目前的技術、在有限的成本以及時程限制下製作完成？此系統是否可以和其他現有系統做整合？Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 7可行性研究實作l依據對資訊的評估(需要什麼)、資訊的收集以及報表的撰寫l詢問組織中的人員下列問題若系統無法實現，組織會如何處理？

4、目前的程序有哪問題？提議的系統有何幫助？有哪些整合上的問題？是否需要新的技術？需要哪些技能？提議的系統必須支援哪些功能？Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 8擷取與分析l有時候稱為需求擷取或發現需求l它包括讓技術人員與客戶一起合作找出相關的應用領域、應該提供的服務以及系統的操作限制等l還可能牽涉到終端使用者、經理人員、負責維護的工程師、領域專家或是工會等。這些都稱為專案關係人(stakeholders)Ian Sommerville 2000 Software Engineering,

5、6th edition. Chapter 6 Slide 9需求分析的問題l專案關係人不知道他們真正要什麼l專案關係人會以自己的辭彙來表示需求l不同專案關係人可能會產生互相衝突的需求l組織和政治的因素可能也會影響系統的需求l分析過程中若需求遭變更可能會出現新的專案關係人，而造成商業環境的變更Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 10需求分析程序Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 11

6、程序活動l瞭解領域 (Domain understanding)l收集需求 (Requirements collection)l分類 (Classification)l解決衝突 (Conflict resolution)l排列優先順序 (Prioritisation)l檢查需求 (Requirements checking)Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 12系統模型l在需求分析活動中可能會產生不同模型l需求分析可能牽涉到造成這些不同模型的三種結構化活動分割(Partitioning

7、)。識別實體之間的結構化關係(部分關係)抽象化(Abstraction)。識別出各實體的一般化投射(Projection)。識別出觀察問題的不同方法l系統模型將在第 7 章做介紹Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 13觀點式擷取法l專案關係人代表觀察問題或問題觀點的不同方法l這種多重觀點的分析非常重要，因為分析系統需求時沒有唯一正確的方法Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 14銀行

8、 ATM 系統l此範例使用可以提供自動化銀行服務的自動櫃員機系統做說明l這裡使用非常簡化的系統，它可以向擁有此系統的銀行客戶提供幾項服務，以及提供其他銀行的客戶某些有限的服務l提供的服務包括有提取現今、傳送訊息(傳送要求某項服務的訊息)、要求對帳單以及轉帳等Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 15自動櫃員機的觀點l銀行客戶l其他銀行的代表l硬體與軟體的維護工程師l行銷部門l銀行經理與櫃檯人員l資料庫管理師保全人員l通訊工程師l人事部門Ian Sommerville 2000 Softwa

9、re Engineering, 6th edition. Chapter 6 Slide 16觀點的類型l資料來源或消化處 (Data sources or sinks)負責產生或使用資料的觀點，分析過程包括辨識產出或消耗的資料以及視資料來源與消化處為合法的假設l表示架構 (Representation frameworks)此觀點可被視為是一種特殊的系統模型。使用單一表示方式可能會漏掉某些需求。這種觀點尤其適用於即時系統l服務接收者 (Receivers of services)系統外部以及從系統接收到服務的觀點，大部分適用於互動式系統Ian Sommerville 2000 Softwar

10、e Engineering, 6th edition. Chapter 6 Slide 17外部觀點l很自然的可以將終端使用者視為系統服務的接收者l這些觀點可以很自然的構築需求的擷取l很容易決定觀點是否合理l這些觀點和服務可以用來構築非功能需求Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 18以方法為主的分析l需求分析中廣泛運用的方法，依據某個結構化方法的應用來瞭解系統l這些方法有不同的強調處，有些是特別為需求擷取而設計，有些則與設計方法比較接近l這裡使用觀點式方法(viewpoint-orien

11、ted method, VORD)為例，它也可以用來說明觀點的使用方式Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 19VORD 方法Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 20VORD 程序模型l識別觀點找出接收系統服務的觀點，以及辨識出提供給各個觀點的特定服務l建構觀點 將相關的觀點組成階層架構，共通的服務放在階層架構的上層，下層觀點則繼承自上層觀點l觀點文件修飾已辨識出的觀點和服務的描述

12、l對應觀點與系統將分析轉換為物件導向式的設計Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 21VORD 標準格式觀點範本服務範本文件：觀點名稱文件：服務名稱屬性：觀點資訊的屬性原理：觀點資訊的屬性事件：事件情境是描述系統針對觀點事件如何回應規格：關於服務規格服務：服務描述文件觀點：可收到的服務上的觀點名稱子VPs：子觀點名稱非功能需求：非功能需求上的限制性服務供應者：系統物件上可提供的服務Ian Sommerville 2000 Software Engineering, 6th edition.

13、 Chapter 6 Slide 22識別觀點Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 23觀點服務資訊Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 24觀點資料與控制資訊 Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 25觀點階層架構 Ian Sommerville 2000 Software En

14、gineering, 6th edition. Chapter 6 Slide 26顧客觀點和提取現金範本Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 27情境法 (Scenarios)l情境用來描述系統實際的使用方式l這個方法有助於需求擷取，因為用這個方法比抽象敘述更容易得到系統的需求l情境法對概略的需求描述加入詳細資訊尤其有幫助Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 28情境描述l情境開頭的

15、系統狀態描述 l情境中正常的事件流程描述l可能發生的問題以及解決方法的描述l同一時間可能發生的其他活動l情境完成後的系統狀態描述Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 29事件情境法 l事件情境法可以用來描述系統如何回應某些特殊事件，例如開始交易事件lVORD 使用下列幾個慣用的圖形來表示事件情境欲提供與交付的資料控制資訊例快處理下一個預期的事件Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 30

16、事件情境開始交易Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 31資料與控制分析的表示符號l由觀點提供的資料以及要交給觀點的資料以橢圓表示l進入或離開方塊的控制資訊表示在每個方塊的上方l離開此方塊的資料表示在每個方塊的右邊 l例外狀況則出現在方塊的下方l預期發生的下一個事件名稱則以灰底顏色顯示在方塊中Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 32例外狀況描述l大部分的方法都不包含描述例外狀況的工具

17、l此例中，例外狀況有逾時：客戶可能在限定的時間內輸入錯誤的PIN，卡片會被退回。無效卡：無法辨識卡片，卡片也會被退回。遺失卡：卡片被辨識出為遺失卡，機器會自動收回此卡片。Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 33使用個案 l使用個案是 UML 中以情境為主的技術，它可以識別互動中的行為者，以及描述互動本身l利用一組使用個案來描述系統中所有可能的互動l利用順序圖在使用個案中加入詳細資訊，顯示系統處理事件的順序Ian Sommerville 2000 Software Engineering,

18、 6th edition. Chapter 6 Slide 34借書使用個案 Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 35圖書館使用個案 Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 36目錄管理順續圖Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 37社會與組織因素l軟體系統常被用於社會和組織環境中

19、，這些都會影響或甚至主導系統的需求l社會與組織的因素不只是單一的觀點，而是會影響到所有觀點l好的分析師必須對這些因素很敏感，但是目前並沒有有系統的方法來追蹤他們的分析Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 38民族誌法 (Ethnography)l社會學家花許多時間來觀察與分析人們是如何工作l人們不需要解釋或清楚的說明他們的工作l可以觀察到重要的社會與組織因素l民族誌的研究指出人們的工作通常會比簡單的系統模型更多且更複雜Ian Sommerville 2000 Software Engine

20、ering, 6th edition. Chapter 6 Slide 39民族誌法l使用的範例有航管系統的研究l合併民族誌法與雛形法l雛形開發可以針對民族誌法分析出來的問題進行研究l民族誌法的問題是，它研究的一些實際工作可能包含一些毫無相關的歷程記錄Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 40民族誌法和雛形法Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 41民族誌法的範圍l人們實際工作時的需求

21、，而不是指程序定義所建議的工作需求l從合作及瞭解其他人員活動所衍生的需求 Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 42需求確認l用來確定需求是否定義了顧客真正想要的系統 l需求錯誤造成的成本非常高，所以確認的動作很重要在系統交付之後修正需求錯誤的成本可能會比修護實作的錯誤高出100倍之多Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 43需求檢查l確實性：系統提供的功能是否能夠支援客戶的需求？l一

22、致性：是否有任何需求產生衝突？l完整性：是否包含客戶所需的所有功能？l實現性：需求是否可以在有限的預算和可用技術下實作完成？l可驗證性：需求是否可以接受檢查？Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 44需求確認技術l需求審查 有系統的人為分析需求l雛形法 使用可執行的系統模型來檢查需求，參見第 8 章l測試案例產生法為需求發展測試案例以檢查其測試性l自動化一致性分析 檢查結構化需求描述的一致性Ian Sommerville 2000 Software Engineering, 6th edi

23、tion. Chapter 6 Slide 45需求審查l在擬定需求定義時必須定期的進行審查l客戶和承包商的人員都應該參與審查l審查可以是正式的 (有完整的文件)或非正式的。開發者、客戶和使用者之間若有良好的溝通便可以提早解決問題Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 46審查檢查l可驗證性(Verifiability)：需求是否如敘述情形一樣能夠真的進行測試？l可瞭解性(Comprehensibility)：系統的採購人員或直接使用者是否能夠適當的瞭解這些需求？l可追蹤性(Traceabi

24、lity)：是否清楚的記錄需求來源？l可調適性(Adaptability)：需求是否可調整改變，而不會造成其他系統需求太大的影響？Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 47自動化需求一致性檢查 Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 48需求管理l需求管理是在需求工程程序及系統開發期間管理需求變更的程序l需求通常是不完整且不一致的在程序期間，當商業需求改變或是對正在開發的系統有更好的瞭解

25、，就會出現新的需求不同觀點會不同的需求，而這些需求通常會產生矛盾Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 49需求變更l不同觀點產生的需求，其優先順序在開發過程中會有所改變l系統的客戶可能會以商業的觀點來指定需求，而這些觀點可能會與終端使用者的需求產生衝突l系統的商業和技術環境在開發的過程中也會有所改變Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 50需求演化 Ian Sommerville 20

26、00 Software Engineering, 6th edition. Chapter 6 Slide 51持久和短暫的需求 l持久需求(Enduring requirements)：指非常穩定的需求，來自組織的核心活動。例如，醫院通常會有醫生和護士。這些需求可能是從領域模型而來l短暫需求(Volatile requirements)：系統開發期間或系統開始運作之後可能發生改變的需求。若以醫院為例，政府的健保政策可能就會有隨時改變的需求Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 52需求分類

27、l易變的需求 (Mutable requirements)因組織的營運環境改變而造成的需求改變l新出現的需求 (Emergent requirements)顧客在系統開發期間瞭解系統的發展之後所出現的新需求l隨之發生的需求 (Consequential requirements)引進電腦系統之後所造成的需求l相容需求 (Compatibility requirements)根據某個特殊系統或組織中商業流程而來的需求Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 53需求管理規劃 l在需求工程程序期間，你必須規劃：需求識別 如何識別每一項個別的需求變更管理程序 分析需求變更時的程序追蹤策略 有關需求之間的關係、且需要進行維護的大量資訊支援的 CASE 工具 幫助管理需求變更時所需的支援工具Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 54可追蹤資訊(Traceability)l可追蹤資訊是指需求、需求來源以及系統設計之間的關係l來源可追蹤資訊 將需求與提出這些需求的專案關係人做一個連結l需求可追蹤資訊將相依的需求做連結l設計可追蹤資訊 將需求和設計做連結Ian Sommerville 2