需求工程程序.pptVIP

需求工程程序 發現、分析以及確認系統需求的程序 本章目的 描述一些主要的需求工程活動 介紹數種需求擷取與分析的技術 描述需求確認的重要性 討論需求管理的角色以及如何支援需求工程的其他活動 本章內容 可行性研究 需求擷取與分析 需求確認 需求管理 需求工程程序 RE 使用的程序會根據應用領域、參與人員以及發展需求的組織有很大的差異 然而，下列幾項通用活動則是所有程序共通的 需求擷取 需求分析 需求確認 需求管理 需求工程程序 可行性研究 可行性研究可決定提出的系統是否有價值 它是一項短暫活動，著重於檢查下列幾個重點 此系統對組織的整體目標是否有貢獻？ 此系統是否可以利用目前的技術、在有限的成本以及時程限制下製作完成？ 此系統是否可以和其他現有系統做整合？ 可行性研究實作 依據對資訊的評估(需要什麼)、資訊的收集以及報表的撰寫 詢問組織中的人員下列問題 若系統無法實現，組織會如何處理？ 目前的程序有哪問題？ 提議的系統有何幫助？ 有哪些整合上的問題？ 是否需要新的技術？需要哪些技能？ 提議的系統必須支援哪些功能？ 擷取與分析 有時候稱為需求擷取或發現需求 它包括讓技術人員與客戶一起合作找出相關的應用領域、應該提供的服務以及系統的操作限制等 還可能牽涉到終端使用者、經理人員、負責維護的工程師、領域專家或是工會等。這些都稱為「專案關係人」(stakeholders) 需求分析的問題 專案關係人不知道他們真正要什麼 專案關係人會以自己的辭彙來表示需求 不同專案關係人可能會產生互相衝突的需求 組織和政治的因素可能也會影響系統的需求 分析過程中若需求遭變更可能會出現新的專案關係人，而造成商業環境的變更 需求分析程序 程序活動 瞭解領域 (Domain understanding) 收集需求 (Requirements collection) 分類 (Classification) 解決衝突 (Conflict resolution) 排列優先順序 (Prioritisation) 檢查需求 (Requirements checking) 系統模型 在需求分析活動中可能會產生不同模型 需求分析可能牽涉到造成這些不同模型的三種結構化活動 分割(Partitioning)。識別實體之間的結構化關係(部分關係) 抽象化(Abstraction)。識別出各實體的一般化 投射(Projection)。識別出觀察問題的不同方法 系統模型將在第 7 章做介紹 觀點式擷取法 專案關係人代表觀察問題或問題觀點的不同方法 這種多重觀點的分析非常重要，因為分析系統需求時沒有唯一正確的方法 銀行 ATM 系統 此範例使用可以提供自動化銀行服務的自動櫃員機系統做說明 這裡使用非常簡化的系統，它可以向擁有此系統的銀行客戶提供幾項服務，以及提供其他銀行的客戶某些有限的服務 提供的服務包括有提取現今、傳送訊息(傳送要求某項服務的訊息)、要求對帳單以及轉帳等 自動櫃員機的觀點 銀行客戶 其他銀行的代表 硬體與軟體的維護工程師 行銷部門 銀行經理與櫃檯人員 資料庫管理師保全人員 通訊工程師 人事部門 觀點的類型 資料來源或消化處 (Data sources or sinks) 負責產生或使用資料的觀點，分析過程包括辨識產出或消耗的資料以及視資料來源與消化處為合法的假設 表示架構 (Representation frameworks) 此觀點可被視為是一種特殊的系統模型。使用單一表示方式可能會漏掉某些需求。這種觀點尤其適用於即時系統 服務接收者 (Receivers of services) 系統外部以及從系統接收到服務的觀點，大部分適用於互動式系統 外部觀點 很自然的可以將終端使用者視為系統服務的接收者 這些觀點可以很自然的構築需求的擷取 很容易決定觀點是否合理 這些觀點和服務可以用來構築非功能需求 以方法為主的分析 需求分析中廣泛運用的方法，依據某個結構化方法的應用來瞭解系統 這些方法有不同的強調處，有些是特別為需求擷取而設計，有些則與設計方法比較接近 這裡使用觀點式方法(viewpoint-oriented method, VORD)為例，它也可以用來說明觀點的使用方式 VORD 方法 VORD 程序模型 識別觀點 找出接收系統服務的觀點，以及辨識出提供給各個觀點的特定服務 建構觀點 將相關的觀點組成階層架構，共通的服務放在階層架構的上層，下層觀點則繼承自上層觀點 觀點文件 修飾已辨識出的觀點和服務的描述 對應觀點與系統 將分析轉換為物件導向式的設計 VORD 標準格式 識別觀點 觀點服務資訊 觀點資料與控制資訊 觀點階層架構 顧客觀點和提取現金範本 情境法 (Scenarios) 情境用來描述系統實際的使用方式 這個方法有助於需求擷取，因為用這個