软件工程 需求工程程序.pptVIP

軟體工程 第7章 需求工程程序 學習目標 瞭解主要的需求工程活動以及它們之間的關係 瞭解數種需求抽取與分析的技術 瞭解需求確認的重要性，以及在此程序中如何進行需求審查 瞭解需求管理的必要性，以及它如何支援其他需求工程活動 需求工程程序 目的是建立與維護一份系統需求文件。 這個程序整體上可分為4個高階的需求工程子程序，包括評估系統對企業是否真的有用（可行性研究）、找出需求（抽取與分析）、將需求轉換成某種標準格式（制定規格），以及檢查需求真的有成功定義出客戶所要的系統（需求的確認）等。 需求工程程序圖 需求工程程序的螺旋狀模型 7.1 可行性研究 任何新系統的需求工程程序，都應該從可行性研究開始。可行性研究的輸入資料是一組初步的企業需求、系統的一份大綱描述，以及系統打算如何支援企業流程。 可行性研究的輸出結果，則是一份建議是否值得繼續進行需求工程和系統開發程序的報告。 可行性研究（feasibility study）是一項很短的活動，主要是研究下面幾個問題的答案： 此系統對組織的整體目標是否有貢獻？ 此系統是否可以利用目前的技術，在規定的成本及時間限制下實作完成？ 此系統是否可以與其他現有系統整合？ 7.2 需求抽取與分析 在可行性研究之後，需求工程程序的下一個階段是需求抽取與分析（requirements elicitation and analysis）。在這項活動中，軟體工程師會與客戶和終端使用者一起工作，找出此系統的應用領域、應該提供的服務、要求的執行效能及硬體限制等。 需求抽取與分析可能會牽涉到組織中許多不同部門的人員。專案關係人（stakeholder）這個名詞是指直接或間接被系統所影響的任何人或群組。 需求抽取與分析程序 發現需求（requirements discovery）：與系統的專案關係人進行互動，收集他們的需求。在這項活動過程中也會找出關係人的領域需求與相關文件。 需求分類和組織（requirements classification and organisation）：此活動將雜亂無章的需求依照相關性分組，組織成幾組關係密切的叢集。 排列需求優先順序與協調（requirements prioritisation and negotiation）：當有許多專案關係人時，需求無可避免的會發生衝突。這項活動主要是為需求安排優先順序，發現衝突並經由協調來解決這些衝突。 製作需求文件（requirements documentation）：將需求記錄成文件，當作螺旋狀下一圈的輸入。此時產生的可能是正規化或非正規化的需求文件。 發現需求 發現需求這個階段是從已提議和現有的系統中收集資訊，接著從這些資訊精鍊出使用者和系統需求的過程。 在發現需求階段的資訊來源包括文件、系統關係人與類似系統的規格等。 你可以透過訪談和觀察與系統關係人互動，而且也許會使用情境法和雛形法來協助發現需求。 觀點 需求工程的觀點（viewpoint）導向方法是透過觀點來組織抽取程序與需求本身。 觀點可以用來當作一種分類關係人與需求其他來源的方式。觀點可以分成3大類： 互動者觀點（interactor viewpoint）：表達與系統直接互動的人員或其他系統的觀點。例如在銀行的ATM系統中，銀行客戶與銀行的帳戶資料庫就是互動者觀點。 間接觀點（indirect viewpoint）：表達那些自己沒有直接使用系統、但是對需求有影響的關係人的觀點。例如在銀行的ATM系統中，銀行的管理階層和保全人員就算是間接觀點。 領域觀點（domain viewpoint）：代表會影響系統需求的領域特性和限制。例如在銀行的ATM系統中，銀行跨行之間的標準就是一種領域觀點。 訪談：與系統關係人的正式訪談或非正式訪談，都是大部分需求工程程序的一部分。在這些訪談過程中，需求工程小組會訪問關係人一些問題，關於他們現在所使用的系統與即將開發的系統。需求就是從這些問題的回答推導出來的。訪談可能的形式有兩種： 限定的訪談：關係人所回答的是一些事先定義好的問題。 開放式訪談：沒有事先定義問題和議程。需求工程小組會與關係人一起討論某些議題，因而更瞭解關係人的需求。 情境：人們通常會發現透過真實生活的例子會比抽象描述容易瞭解。他們能夠瞭解並評論在某個情境（scenario）下他們會如何與軟體系統互動。需求工程師也可以從這些討論中取得有用的資訊，來制定出實際的系統需求。 情境法對於在需求大綱中加入詳細資訊時特別有用。它們可以用來描述實際的互動情形，每個情境會涵蓋一或多個可能的互動情形。 情境法一開始是描述互動情形的大概，然後在抽取階段加入詳細的資訊，建立成完整的互動情形描述。 使用案例（use-case）：使用案例也是一種情境式的需求抽取技