需求工程行程 (Requirements Engineering Processes)

Presentation on theme: "需求工程行程 (Requirements Engineering Processes)"— Presentation transcript:

1 需求工程行程 (Requirements Engineering Processes)
用以發現(discover)、分析(analyze)及驗證(validate)系統需求的行程

2 主題 可行性分析(feasibility studies)
需求引出及分析(requirements elicitation and analysis ) 需求驗證(requirements validation) 需求管理(requirements management)

3 需求工程行程 (Requirements Engineering Processes)
RE (Requirement Engineering)使用的行程(process)會因應用領域(application domain)、參與人員(people involved)及發展需求(developing the requirements)的組織(organisation)而有很大的差異 所有行程共通(common)的典型活動(generic activities) 需求擷取(elicitation) 需求分析(analysis) 需求確認(validation) 需求管理(management)

4 需求工程行程 (Requirements Engineering Process)

5 需求工程 (Requirements Engineering)

6 可行性分析 (Feasibility Studies)
可行性研究用以決定所提出的系統是否有價值(worthwhile) 它是一項短期的聚焦研究(short focused study)，用以檢查下列幾個重點 該系統對組織的整體目標是否有貢獻？ 該系統是否可利用現有技術(technology)，在預算內(within budget)完成？ 此系統是否可和其它現有系統整合 (integrated)？

7 可行性分析的實作 (Feasibility Study Implementation)
依據對資訊的評估(需要的是什麼？)做資訊收集及報告撰寫 向該組織的人員中提出下列問題 若缺少該系統，會有什麼問題？ 目前有哪些行程問題？ 所提出的系統會有何幫助？ 有哪些整合上的問題(integration problems)？ 是否需要新的技術？若是，會是哪些技術？ 所提出的系統需支援哪些功能(facilities)？

8 引出及分析 (Elicitation and Analysis)
有時稱為引出(elicitation)需求或發現(discovery)需求 包括技術人員與客戶共同合作以找出應用領域(application domain)、應提供的服務及系統營運上的限制(operational constraints) 可能牽涉到使用者(end-users)、經理人員 (managers)、負責維護的工程師(engineers involved in maintenance)、領域專家(domain experts)及工會(trade unions)等，這些人員稱為「專案關係人」(stakeholders) Stakeholders：賭金保管人

9 需求分析的問題 (Problems of Requirements Analysis)
專案關係人(stakeholders)並不真正知道他們所要的是什麼？ 專案關係人會以自己的辭彙(terms)來表達需求 不同的專案關係人可能會提出互相衝突的需求(conflicting requirements)

10 組織(organisational)及策略(political)因素也可能影響系統需求
分析過程中若有需求遭變更可能會出現新的專案關係人，以及造成商業環境的改變(business environment change)

11 需求分析程序 (Requirements Analysis Process)

12 行程活動 (Process Activities)
領域理解(domain understanding) 需求蒐集(requirements collection) 分類(classification) 衝突解決(conflict resolution) 訂優先權(prioritisation) 需求查核(requirements checking)

13 系統模型 (System Models) 需求分析可能牽涉到造成不同模型(different models)的三種結構化活動(structuring activities) 劃分(partitioning) 確認(identify) 實體(entities)間的結構相關性 抽象化(abstraction) 找出實體間的共通性(generalities) 投射(projection) 提出從不同角度觀看同一問題的方法

14 觀點導向引出 (Viewpoint-Oriented Elicitation)
專案關係人代表觀察問題(或問題觀點，problem viewpoints)的不同方法 當缺少單一正確方法(single correct way)分析系統需求時，此種多重觀點的分析(multi-perspective analysis)顯得十分重要

15 銀行ATM系統 (Banking ATM System)
此範例使用可提供自動化銀行服務(automated banking services)的自動櫃員機系統(auto-teller system)做說明 在此以非常簡化的系統做說明，它可向該銀行客戶提供若干服務，並提供其它銀行客戶一些有限度的服務

16 提供以下服務 提取現金(cash withdrawal) 傳送訊息(message passing)以要求某項服務
要求對帳單(ordering a statement) 轉帳(transferring funds)

17 ATM 觀點 (Autoteller Viewpoints)
銀行客戶(bank customers) 其它銀行代表(representatives of other banks) 軟硬體維護工程師(hardware and software maintenance engineers) 行銷部門(marketing department) 銀行經理及櫃檯人員(bank managers and counter staff) 資料庫管理者及系統安全人員(database administrators and security staff ) 通訊工程師(communications engineers) 人事部門(personnel department)

18 觀點類別 (Types of Viewpoint)
資料來源及消耗點(data sources or sinks) 觀點負責產生(produce)或者消耗(consume)資料 分析部分包括檢查(check) 資料的產生及消耗 資料來源(source)與消耗處(sink)的假設為有效的(valid)

19 呈現架構(representation frameworks)
觀點可被視為是一種特別型態的系統模型(particular types of system model) 使用單一表示方式(single representation)可能會漏失某些需求的發現(discover requirements) 此觀點(viewpoint)方式尤其適用於即時系統(real-time systems)

20 服務接受者(receivers of services)
位於系統之外並從系統接收服務的觀點 大部分適用於互動式系統(interactive systems)

21 外部觀點 (External Viewpoints)
使用者(end-users)可視為系統服務的接收者(receivers) 觀點可以很自然的方法來結構化需求的擷取(structure requirements elicitation) 很容易決定觀點是否有效(valid) 觀點和服務也可用來結構化非功能需求(non-functional requirements)

22 方法為基礎的分析 (Method-Based Analysis)
為需求分析時常被廣泛使用的方法 依據結構化方法的應用(application of a structured method)來瞭解系統 方法各有不同的強調處，有些是特別為需求擷取(requirements elicitation)而設計，有些則與設計方法(design method)比較接近 在此使用觀點式方法(viewpoint-oriented method，VORD)為例，它也可用以說明觀點的使用方式

23 VORD方法

24 VORD程序模型 (Process Model)
確認觀點(viewpoint identification) 找出能接收系統服務的觀點，以及找出提供給每個觀點的服務 觀點結構(viewpoint structuring) 將相關的觀點組成階層架構，共通服務(common services)放在階層架構的上層，下層觀點則繼承自上層觀點

25 觀點文件(viewpoint documentation)
詳細描述標示出(identified)的觀點和服務 觀點-系統對應(viewpoint-system mapping) 將分析轉換(transform)為物件導向式設計

26 VORD標準格式 (Standard Forms)

27 觀點標示 (Viewpoint Identification)

28 觀點(viewpoint) 開戶人(account holder)、經理、外國用戶(foreign customer)、銀行出納員(bank teller)等 服務(service) 現金提款(cash withdrawal)、訂單陳述(order statement)、交易(transactions)等

29 觀點服務資訊 (Viewpoint Service Information)

30 觀點資料與控制 (Viewpoint Data/Control)

31 觀點階層 (Viewpoint Hierarchy)

32 用戶/提取現金範本 (Customer/Cash Withdrawal Templates)

33 情境 (Scenarios) 情境用來描述系統實際的使用方式
此方法有助於需求擷取(requirements elicitation)，因為此方法比抽象敘述(abstract statement)更容易得到系統需求 情境法對將概略的需求描述(outline requirements description)加入詳細資訊 (detail)尤其有幫助

34 情境描述 (Scenario Descriptions)
描述情境開頭的系統狀態(state) 描述情境中正常事件的流程(flow of events) 描述可能發生的問題以及解決方法 描述其他同時發生的活動 描述情境完成後(completion of the scenario)的系統狀態

35 事件情境 (Event Scenarios)
事件情境法可用來描述系統如何回應(respond)某些特殊事件，例如「開始交易」事件(start transaction) VORD使用下列幾個慣用的圖形(diagrammatic convention)來表示事件情境 資料提供與轉送(data provided and delivered) 控制資訊(control information) 例外處理(exception processing) 下個預期事件(the next expected event) Convention：常規

36 事件情境-啟動交易 (Event Scenario - Start Transaction)

37 資料及控制分析的表示符號 (Notation for Data and Control Analysis)
橢圓符號(ellipses)表示由哪個觀點提供資料以及資料要傳遞給哪個觀點 控制資訊由每個方塊(box)的上方進入或離開 資料由每個方塊的右邊離開 例外狀況(exception)則出現在方塊的下方 下個事件的名稱標示在粗邊方塊(box with thick edges)

38 例外描述 (Exception Description)
此例中，例外包括 逾時(timeout) 客戶未在限定時間內(within the allowed time limit)輸入PIN 無效卡(invalid card) 無法辨識卡片，卡片會被退回 遺失卡(stolen card) 卡片已被申報遺失，機器會扣留此卡片

39 使用案例 (Use Cases) 使用個案(use-cases)是UML (Unified Modelling Language)中以情境為基礎(scenario based technique)的技術，用以標示情境中的行為者(actors) 行為者(actor)是與軟體互動的人或設備 (device)

40 每個情境可用以回答下列問題 行為者(actor)要執行的主要任務(main tasks)是什麼？ 行為者(actor)會獲得(acquire)、產生(produce)或改變(change)什麼系統資訊(system information)？

41 行為者(actor)會告知(inform)系統關於環境變化(environmental changes)的訊息嗎？
行為者(actor)期望被告知(inform)非預期的變化(unexpected changes)嗎？

42 應有一些使用個案(use-cases)來描述與系統所有可能的互動(all possible interactions)
順序圖(sequence diagrams)可藉由顯示系統中處理事件的順序(sequence of event processing)在使用個案(use-cases)中加入詳細資訊(detail)

43 借閱使用案例 (Lending Use-Case)

44 圖書館使用案例 (Library Use-Cases)

45 目次管理案例 (Catalogue Management Use Case)

46 上圖顯示對圖書館藏書的取用(acquire)及編目(catalogue)牽涉的相互作用(interaction)
兩個類別的物件：圖書館項目(Library Item)及目錄(Catalog) 從上到下的行動順序(sequence of actions)，在行為者(actors)和物件(objects)間箭頭(arrows)上的標籤(labels)顯示操作(operation)的名稱 當一本書被購買時，新操作(New operation)被關於在項目上的目錄和獲得操作製定 一旦書可以用，目錄項目操作(catalog item operation)會被作用在該項目上(Item)

47 統一塑模語言 (Unified Modeling Language，UML)
使用者模型觀點(user model view) 這種觀點是從使用者(在UML中稱為”行為者”(actors))角度來看一個系統(產品) 結構模型觀點(structural model view) 從內部系統來看資料(data)和功能(functionality) 亦即，模型化(model)靜態結構(類別(classes)、物件(objects)和關連relationships)) 行為模型觀點(behavioral model view) 此部分的分析模型代表系統的動態(dynamic)或行為(behavioral)特性(aspects)

48 實作模型觀點(implementation model view)
當系統將被建立(built)時，描述系統的結構(structure)和行為(behavioral)特性 環境模型觀點(environment model view) 當系統將被實作(implement)時，描述環境的結構(structure)和行為(behavioral)特性

49 需求驗證 (Requirements Validation)
用來展示需求是否定義了顧客真正想要的系統 需求錯誤會造成很高的成本(error costs are high)，所以驗證(validation)十分重要 在系統交付(delivery)後再修正需求錯誤(fix a requirements error)的成本可能會比修正實作錯誤(implementation error)的成本高出100倍之多

50 需求查核 (Requirements Checking)
有效性(validity) 系統提供的功能是否能夠支援客戶的最大需求(customer’s needs)？ 一致性(consistency) 是否有任何需求彼此衝突(conflicts)？ 完整性(completeness) 是否包含客戶所需的所有功能？

51 可實現性(realism) 需求是否可在可用的預算和技術下實作(implemented)完成？ 可驗證性(verifiability) 需求是否可被檢驗(checked)？

52 需求驗證技術 (Requirements Validation Techniques)
需求檢討法(requirements reviews) 系統的人為分析需求(systematic manual analysis of the requirements) 原型法(prototyping) 使用可執行的系統模型(executable model)來檢查需求 測試實例法(test-case generation) 為需求發展測試案例(develop test)以檢查其測試性(check testability) 自動化一致分析法(automated consistency analysis) 檢查結構化需求描述的一致性

53 需求審查 (Requirements Reviews)
在擬定(formulate)需求定義時需定期審查(regular reviews) 客戶(client)和承包商(contractor staff)的人員都應該參與審查 審查可以是正式的(有完整的文件)或非正式的 開發者、客戶和使用者間若有良好的溝通可以提早解決問題

54 審查查核 (Review Checks) 驗證性(verifiability)
需求是否真能進行測試(realistically testable)？ 理解性(comprehensibility) 需求是否能夠適當的被理解(properly understood)？ 追溯性(traceability) 需求的來源(origin)是否清楚的記錄？ 調適性(adaptability) 需求是否可調整改變，而不會造成其它系統需求太大的影響？

55 自動化一致性檢查 (Automated Consistency Checking)

56 需求管理 (Requirements Management)
需求管理是在需求工程行程及系統開發期間管理需求變更(managing changing requirements)的程序 需求通常是不完整(incomplete)且不一致的(inconsistent) 當商業需求改變或是對正在開發的系統有更精確瞭解時，有可能會出現新的需求(new requirements) 不同觀點會不同的需求，而這些需求通常會彼此矛盾

57 需求變更 (Requirements Change)
不同觀點的需求，其優先順序在開發過程中可能會改變 系統的客戶可能會以商業的觀點(business perspective)來指定需求，而這些需求可能會與使用者需求(end-user requirements)產生衝突 在開發過程中系統的商業(business)和技術環境(technical environment)可能會改變

58 需求演進 (Requirements Evolution)

59 長久性及易變性需求 (Enduring and Volatile Requirements)
長久性需求(enduring requirements) 從用戶組織(customer organisation)的核心活動(core activity)可得到的穩定的需求(stable requirements) 例如，醫院總有醫生和護士。這些需求可從領域模型(domain model)而得 易變性需求(volatile requirements) 系統開發期間或系統開始運作後可能發生需求的改變 以醫院為例，政府健保政策的需求可能隨時改變 Enduring：耐久的

60 需求分類 (Classification of Requirements)
易變的需求(mutable requirements) 因系統環境而造成的需求改變 衍生性需求(emergent requirements) 在瞭解系統發展後所出現新的需求 因果性需求(consequential requirements) 引進電腦系統後所產生的需求 相容性需求(compatibility requirements) 相依(depend)於其它系統或組織流程的需求 Mutable：易變的 Emergent：突現的

61 需求管理規劃 (Requirements Management Planning)
在需求工程行程間(requirements engineering process)，需規畫下列事項 需求標示(requirements identification) 如何逐一標示每項個別需求(requirements are individually identified) 變動管理行程(change management process) 分析需求變更(requirements change)後產生的行程

62 追溯性策略(traceability policies)
關於所維護之需求間關係(requirements relationships)的資訊 CASE工具支援(CASE tool support) 有助於管理需求變更時所需的支援工具

63 可追蹤性 (Traceability) 可追蹤性是指需求(requirements)、來源(sources)及系統設計(system design)間的關係 來源追溯(source traceability) 將需求與提出該需求的關係人(stakeholders)做連結 需求追溯(requirements traceability) 將相依的需求(dependent requirements)做連結(links) 設計追溯(design traceability) 將需求(requirements)和設計(design)做連結

64 追溯矩陣 (A Traceability Matrix)

65 U R 顯示排(row)的需求所使用到對應欄(column)的設備
在需求間有些其他更弱的關係(other weaker relationship) 例如：他們可用以定義相同子系統(sub-system)的部分元件(parts)

66 CASE工具支援 (CASE Tool Support)
需求儲存庫(requirements storage) 需求需在一個安全的資料儲存庫被妥善管理 變動管理(change management) 變更管理的行程是一個工作流程，其中每個階段(stage)都可被定義，而且這些階段間的資訊流(information flow)也可部分地自動化(partially automated) 追溯管理(traceability management) 可自動擷取需求間的連結(links)關係

67 需求變更管理 (Requirements Change Management)
應將此管理應用到所有提出的變更需求中 主要階段 問題分析(problem analysis) 討論需求的問題並提出變更 變動分析及成本估算(change analysis and costing) 評估變更對其它需求的影響 改變實作(change implementation) 修改需求文件和其它文件以反映變更

68 需求變更管理 (Requirements Change Management)

69 參考資料 Ian Sommerville, Software Engineering, 7th ed., Addison-Wesley，2004.