需求工程過程

1、需求工程程序蔡進(jìn)義Chin-Yi Tsai (Matt)cyt.tw5/cyt 1Review功能性需求非功能性需求領(lǐng)域需求使用者需求系統(tǒng)需求 軟體需求文件2Review3Review需求的完整性與一致性完整它們應(yīng)該包含所有需求功能的描述一致系統(tǒng)功能描述中不應(yīng)該有衝突或矛盾的地方4Review需求產(chǎn)生衝突太空船系統(tǒng)為了減輕重量，系統(tǒng)使用的晶片數(shù)量必須減少為了減少電力的消耗，必須使用低電力的晶片然而，若使用低電力的晶片可能需要更多的晶片數(shù)量。這時(shí)候，哪一個(gè)需求是最重要的需求？5需求工程程序 發(fā)現(xiàn)、分析以及確認(rèn)系統(tǒng)需求的程序6本章目的 描述一些主要的需求工程活動(dòng)介紹數(shù)種需求擷取與分析的技術(shù)描述需求

2、確認(rèn)的重要性討論需求管理的角色以及如何支援需求工程的其他活動(dòng)7本章內(nèi)容 可行性研究 需求擷取與分析 需求確認(rèn) 需求管理 8需求工程程序RE 使用的程序會(huì)根據(jù)應(yīng)用領(lǐng)域、參與人員以及發(fā)展需求的組織有很大的差異然而，下列幾項(xiàng)通用活動(dòng)則是所有程序共通的需求擷取需求分析需求確認(rèn)需求管理9需求工程程序10可行性研究可行性研究可決定提出的系統(tǒng)是否有價(jià)值它是一項(xiàng)短暫活動(dòng)，著重於檢查下列幾個(gè)重點(diǎn)此系統(tǒng)對(duì)組織的整體目標(biāo)是否有貢獻(xiàn)？此系統(tǒng)是否可以利用目前的技術(shù)、在有限的成本以及時(shí)程限制下製作完成？此系統(tǒng)是否可以和其他現(xiàn)有系統(tǒng)做整合？11可行性研究實(shí)作依據(jù)對(duì)資訊的評(píng)估(需要什麼)、資訊的收集以及報(bào)表的撰寫詢問組織中的

3、人員下列問題若系統(tǒng)無法實(shí)現(xiàn)，組織會(huì)如何處理？目前的程序有哪問題？提議的系統(tǒng)有何幫助？有哪些整合上的問題？是否需要新的技術(shù)？需要哪些技能？提議的系統(tǒng)必須支援哪些功能？12擷取與分析有時(shí)候稱為需求擷取或發(fā)現(xiàn)需求它包括讓技術(shù)人員與客戶一起合作找出相關(guān)的應(yīng)用領(lǐng)域、應(yīng)該提供的服務(wù)以及系統(tǒng)的操作限制等還可能牽涉到終端使用者、經(jīng)理人員、負(fù)責(zé)維護(hù)的工程師、領(lǐng)域?qū)＜一蚴枪?huì)等。這些都稱為專案關(guān)係人(stakeholders)13專案關(guān)係人不知道他們真正要什麼專案關(guān)係人會(huì)以自己的辭彙來表示需求不同專案關(guān)係人可能會(huì)產(chǎn)生互相衝突的需求組織和政治的因素可能也會(huì)影響系統(tǒng)的需求分析過程中若需求遭變更可能會(huì)出現(xiàn)新的專案關(guān)係人

4、，而造成商業(yè)環(huán)境的變更需求分析的問題14需求分析程序15程序活動(dòng)瞭解領(lǐng)域 (Domain understanding)收集需求 (Requirements collection)分類 (Classification)解決衝突 (Conflict resolution)排列優(yōu)先順序 (Prioritisation)檢查需求 (Requirements checking)16系統(tǒng)模型在需求分析活動(dòng)中可能會(huì)產(chǎn)生不同模型需求分析可能牽涉到造成這些不同模型的三種結(jié)構(gòu)化活動(dòng)分割(Partitioning)。識(shí)別實(shí)體之間的結(jié)構(gòu)化關(guān)係(部分關(guān)係)抽象化(Abstraction)。識(shí)別出各實(shí)體的一般化投射(Pr

5、ojection)。識(shí)別出觀察問題的不同方法17觀點(diǎn)式擷取法專案關(guān)係人代表觀察問題或問題觀點(diǎn)的不同方法這種多重觀點(diǎn)的分析非常重要，因?yàn)榉治鱿到y(tǒng)需求時(shí)沒有唯一正確的方法18銀行 ATM 系統(tǒng)此範(fàn)例使用可以提供自動(dòng)化銀行服務(wù)的自動(dòng)櫃員機(jī)系統(tǒng)做說明這裡使用非常簡(jiǎn)化的系統(tǒng)，它可以向擁有此系統(tǒng)的銀行客戶提供幾項(xiàng)服務(wù)，以及提供其他銀行的客戶某些有限的服務(wù)提供的服務(wù)包括有提取現(xiàn)今、傳送訊息(傳送要求某項(xiàng)服務(wù)的訊息)、要求對(duì)帳單以及轉(zhuǎn)帳等19自動(dòng)櫃員機(jī)的觀點(diǎn)銀行客戶其他銀行的代表硬體與軟體的維護(hù)工程師行銷部門銀行經(jīng)理與櫃檯人員資料庫管理師保全人員通訊工程師人事部門20觀點(diǎn)的類型資料來源或消化處 (Data s

6、ources or sinks)負(fù)責(zé)產(chǎn)生或使用資料的觀點(diǎn)，分析過程包括辨識(shí)產(chǎn)出或消耗的資料以及視資料來源與消化處為合法的假設(shè)表示架構(gòu) (Representation frameworks)此觀點(diǎn)可被視為是一種特殊的系統(tǒng)模型。使用單一表示方式可能會(huì)漏掉某些需求。這種觀點(diǎn)尤其適用於即時(shí)系統(tǒng)服務(wù)接收者 (Receivers of services)系統(tǒng)外部以及從系統(tǒng)接收到服務(wù)的觀點(diǎn)，大部分適用於互動(dòng)式系統(tǒng)21外部觀點(diǎn)很自然的可以將終端使用者視為系統(tǒng)服務(wù)的接收者這些觀點(diǎn)可以很自然的構(gòu)築需求的擷取很容易決定觀點(diǎn)是否合理這些觀點(diǎn)和服務(wù)可以用來構(gòu)築非功能需求22以方法為主的分析需求分析中廣泛運(yùn)用的方法，依據(jù)

7、某個(gè)結(jié)構(gòu)化方法的應(yīng)用來瞭解系統(tǒng)這些方法有不同的強(qiáng)調(diào)處，有些是特別為需求擷取而設(shè)計(jì)，有些則與設(shè)計(jì)方法比較接近這裡使用觀點(diǎn)式方法(viewpoint-oriented method, VORD)為例，它也可以用來說明觀點(diǎn)的使用方式23VORD 方法24VORD 程序模型識(shí)別觀點(diǎn)找出接收系統(tǒng)服務(wù)的觀點(diǎn)，以及辨識(shí)出提供給各個(gè)觀點(diǎn)的特定服務(wù)建構(gòu)觀點(diǎn) 將相關(guān)的觀點(diǎn)組成階層架構(gòu)，共通的服務(wù)放在階層架構(gòu)的上層，下層觀點(diǎn)則繼承自上層觀點(diǎn)觀點(diǎn)文件修飾已辨識(shí)出的觀點(diǎn)和服務(wù)的描述 對(duì)應(yīng)觀點(diǎn)與系統(tǒng)將分析轉(zhuǎn)換為物件導(dǎo)向式的設(shè)計(jì)25VORD 標(biāo)準(zhǔn)格式觀點(diǎn)範(fàn)本服務(wù)範(fàn)本文件：觀點(diǎn)名稱文件：服務(wù)名稱屬性：觀點(diǎn)資訊的屬性原理：觀點(diǎn)

8、資訊的屬性事件：事件情境是描述系統(tǒng)針對(duì)觀點(diǎn)事件如何回應(yīng)規(guī)格：關(guān)於服務(wù)規(guī)格服務(wù)：服務(wù)描述文件觀點(diǎn)：可收到的服務(wù)上的觀點(diǎn)名稱子VPs：子觀點(diǎn)名稱非功能需求：非功能需求上的限制性服務(wù)供應(yīng)者：系統(tǒng)物件上可提供的服務(wù)26識(shí)別觀點(diǎn)27觀點(diǎn)服務(wù)資訊28觀點(diǎn)資料與控制資訊 29觀點(diǎn)階層架構(gòu) 30顧客觀點(diǎn)和提取現(xiàn)金範(fàn)本31情境法 (Scenarios)情境用來描述系統(tǒng)實(shí)際的使用方式這個(gè)方法有助於需求擷取，因?yàn)橛眠@個(gè)方法比抽象敘述更容易得到系統(tǒng)的需求情境法對(duì)概略的需求描述加入詳細(xì)資訊尤其有幫助32情境描述情境開頭的系統(tǒng)狀態(tài)描述 情境中正常的事件流程描述可能發(fā)生的問題以及解決方法的描述同一時(shí)間可能發(fā)生的其他活動(dòng)情境

9、完成後的系統(tǒng)狀態(tài)描述33事件情境法 事件情境法可以用來描述系統(tǒng)如何回應(yīng)某些特殊事件，例如開始交易事件VORD 使用下列幾個(gè)慣用的圖形來表示事件情境欲提供與交付的資料控制資訊例快處理下一個(gè)預(yù)期的事件34事件情境開始交易35資料與控制分析的表示符號(hào)由觀點(diǎn)提供的資料以及要交給觀點(diǎn)的資料以橢圓表示進(jìn)入或離開方塊的控制資訊表示在每個(gè)方塊的上方離開此方塊的資料表示在每個(gè)方塊的右邊 例外狀況則出現(xiàn)在方塊的下方預(yù)期發(fā)生的下一個(gè)事件名稱則以灰底顏色顯示在方塊中36例外狀況描述大部分的方法都不包含描述例外狀況的工具此例中，例外狀況有逾時(shí)：客戶可能在限定的時(shí)間內(nèi)輸入錯(cuò)誤的PIN，卡片會(huì)被退回。無效卡：無法辨識(shí)卡片，

10、卡片也會(huì)被退回。遺失卡：卡片被辨識(shí)出為遺失卡，機(jī)器會(huì)自動(dòng)收回此卡片。37使用個(gè)案 使用個(gè)案是 UML 中以情境為主的技術(shù)，它可以識(shí)別互動(dòng)中的行為者，以及描述互動(dòng)本身利用一組使用個(gè)案來描述系統(tǒng)中所有可能的互動(dòng)利用順序圖在使用個(gè)案中加入詳細(xì)資訊，顯示系統(tǒng)處理事件的順序38借書使用個(gè)案 39圖書館使用個(gè)案 40目錄管理順續(xù)圖41社會(huì)與組織因素軟體系統(tǒng)常被用於社會(huì)和組織環(huán)境中，這些都會(huì)影響或甚至主導(dǎo)系統(tǒng)的需求社會(huì)與組織的因素不只是單一的觀點(diǎn)，而是會(huì)影響到所有觀點(diǎn)好的分析師必須對(duì)這些因素很敏感，但是目前並沒有有系統(tǒng)的方法來追蹤他們的分析42民族誌法 (Ethnography)社會(huì)學(xué)家花許多時(shí)間來觀察與分

11、析人們是如何工作人們不需要解釋或清楚的說明他們的工作可以觀察到重要的社會(huì)與組織因素民族誌的研究指出人們的工作通常會(huì)比簡(jiǎn)單的系統(tǒng)模型更多且更複雜43民族誌法使用的範(fàn)例有航管系統(tǒng)的研究合併民族誌法與雛形法雛形開發(fā)可以針對(duì)民族誌法分析出來的問題進(jìn)行研究民族誌法的問題是，它研究的一些實(shí)際工作可能包含一些毫無相關(guān)的歷程記錄44民族誌法和雛形法45民族誌法的範(fàn)圍人們實(shí)際工作時(shí)的需求，而不是指程序定義所建議的工作需求從合作及瞭解其他人員活動(dòng)所衍生的需求 46需求確認(rèn)用來確定需求是否定義了顧客真正想要的系統(tǒng) 需求錯(cuò)誤造成的成本非常高，所以確認(rèn)的動(dòng)作很重要在系統(tǒng)交付之後修正需求錯(cuò)誤的成本可能會(huì)比修護(hù)實(shí)作的錯(cuò)誤高

12、出100倍之多47需求檢查確實(shí)性：系統(tǒng)提供的功能是否能夠支援客戶的需求？一致性：是否有任何需求產(chǎn)生衝突？完整性：是否包含客戶所需的所有功能？實(shí)現(xiàn)性：需求是否可以在有限的預(yù)算和可用技術(shù)下實(shí)作完成？可驗(yàn)證性：需求是否可以接受檢查？48需求確認(rèn)技術(shù)需求審查 有系統(tǒng)的人為分析需求雛形法 使用可執(zhí)行的系統(tǒng)模型來檢查需求，參見第 8 章測(cè)試案例產(chǎn)生法為需求發(fā)展測(cè)試案例以檢查其測(cè)試性自動(dòng)化一致性分析 檢查結(jié)構(gòu)化需求描述的一致性49需求審查在擬定需求定義時(shí)必須定期的進(jìn)行審查客戶和承包商的人員都應(yīng)該參與審查審查可以是正式的 (有完整的文件)或非正式的。開發(fā)者、客戶和使用者之間若有良好的溝通便可以提早解決問題50

13、審查檢查可驗(yàn)證性(Verifiability)：需求是否如敘述情形一樣能夠真的進(jìn)行測(cè)試？可瞭解性(Comprehensibility)：系統(tǒng)的採購人員或直接使用者是否能夠適當(dāng)?shù)牟t解這些需求？可追蹤性(Traceability)：是否清楚的記錄需求來源？可調(diào)適性(Adaptability)：需求是否可調(diào)整改變，而不會(huì)造成其他系統(tǒng)需求太大的影響？51自動(dòng)化需求一致性檢查 52需求管理需求管理是在需求工程程序及系統(tǒng)開發(fā)期間管理需求變更的程序需求通常是不完整且不一致的在程序期間，當(dāng)商業(yè)需求改變或是對(duì)正在開發(fā)的系統(tǒng)有更好的瞭解，就會(huì)出現(xiàn)新的需求不同觀點(diǎn)會(huì)不同的需求，而這些需求通常會(huì)產(chǎn)生矛盾53需求變更不

14、同觀點(diǎn)產(chǎn)生的需求，其優(yōu)先順序在開發(fā)過程中會(huì)有所改變系統(tǒng)的客戶可能會(huì)以商業(yè)的觀點(diǎn)來指定需求，而這些觀點(diǎn)可能會(huì)與終端使用者的需求產(chǎn)生衝突系統(tǒng)的商業(yè)和技術(shù)環(huán)境在開發(fā)的過程中也會(huì)有所改變54需求演化 55持久和短暫的需求 持久需求(Enduring requirements)：指非常穩(wěn)定的需求，來自組織的核心活動(dòng)。例如，醫(yī)院通常會(huì)有醫(yī)生和護(hù)士。這些需求可能是從領(lǐng)域模型而來短暫需求(Volatile requirements)：系統(tǒng)開發(fā)期間或系統(tǒng)開始運(yùn)作之後可能發(fā)生改變的需求。若以醫(yī)院為例，政府的健保政策可能就會(huì)有隨時(shí)改變的需求56需求分類易變的需求 (Mutable requirements)因組織的

15、營(yíng)運(yùn)環(huán)境改變而造成的需求改變新出現(xiàn)的需求 (Emergent requirements)顧客在系統(tǒng)開發(fā)期間瞭解系統(tǒng)的發(fā)展之後所出現(xiàn)的新需求隨之發(fā)生的需求 (Consequential requirements)引進(jìn)電腦系統(tǒng)之後所造成的需求相容需求 (Compatibility requirements)根據(jù)某個(gè)特殊系統(tǒng)或組織中商業(yè)流程而來的需求57需求管理規(guī)劃 在需求工程程序期間，你必須規(guī)劃：需求識(shí)別 如何識(shí)別每一項(xiàng)個(gè)別的需求變更管理程序分析需求變更時(shí)的程序追蹤策略有關(guān)需求之間的關(guān)係、且需要進(jìn)行維護(hù)的大量資訊支援的 CASE 工具幫助管理需求變更時(shí)所需的支援工具58可追蹤資訊(Traceabi

16、lity)可追蹤資訊是指需求、需求來源以及系統(tǒng)設(shè)計(jì)之間的關(guān)係來源可追蹤資訊 將需求與提出這些需求的專案關(guān)係人做一個(gè)連結(jié)需求可追蹤資訊將相依的需求做連結(jié)設(shè)計(jì)可追蹤資訊 將需求和設(shè)計(jì)做連結(jié)59可追蹤矩陣 需求代碼1.11.21.32.12.22.33.13.21.1UR1.2URU1.3RR2.1RUU2.2U2.3RU3.1R3.2R60CASE工具的支援儲(chǔ)存需求需求必須在一個(gè)安全的資料儲(chǔ)存處接受管理變更管理變更管理的程序是一個(gè)工作流程，每一個(gè)階段都可以進(jìn)行定義，而這階段之間的資訊流也可以部分自動(dòng)化可追蹤性管理可自動(dòng)擷取需求之間的連結(jié)關(guān)係61需求變更管理應(yīng)該將所有提出的變更套用至需求中主要階段問題分析：討論需求的問題並且提出變更變更分析與成本預(yù)估：評(píng)估變更對(duì)其他需求的影響變更實(shí)作：修