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

軟體工程,第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）：使用案例也是一種情境式的需求抽取技術，它首次出現在Objectory方法中，現在已經變成UML符號表示法用來描述物件導向式系統模型的基本功能。在它們最簡單的形式裡，使用案例可以辨識出互動的類型和互動中的行動者（actor）。,列印文章的使用案例,民族誌法,民族誌法（ethnography）是一種觀察的技術，可以用來瞭解社會與組織的需求。分析人員必須將自己融入在使用系統的工作環境中，觀察與記錄日常的實際工作。民族誌法的價值在於它能夠找出隱含的系統需求，實際反映員工的使用程序，而不是一般正規的程序。民族誌法對於發現下列這2種需求特別有效：從實際的工作方式衍生的需求 從合作及瞭解其他人員活動所衍生的需求民族誌法可以和雛形法合併使用。民族誌法會通知雛形的開發程序，使雛形的循環動作減少。,使用民族誌法和雛形法進行需求分析,7.3 需求確認,需求確認（requirement validation）主要是想確定需求是否真正定義出顧客想要的系統。需求確認的過程與分析有重疊，因為它也是要找出需求的問題。需求確認是很重要的程序，因為如果需求文件有錯誤，等到開發期間或甚至系統上線時才發現的話，可能會導致很多工作要重做而浪費成本。,在需求確認程序期間，必須對需求文件裡列出的需求執行下列幾項檢查：,確實性檢查（validity check）：有時候使用者可能想要讓系統執行某個功能，但是在仔細思考和分析後，可能會發現他需要額外的功能，或甚至是不同的功能。同一個系統通常會有不同需求的關係人，任何需求都必須與所有的關係人群組取得妥協。一致性檢查（consistency check）：在文件中的需求不能相互衝突；也就是說，同一個系統功能不能有相互矛盾的限制條件或功能描述。完整性檢查（completeness check）：需求文件中定義的需求必須包含系統使用者想要的所有功能和限制。實現性檢查（realism check）：利用對現有技術的瞭解，檢查需求是否能夠真正的被實作出來。這些檢查也應該將系統開發的預算和時程考慮進去。可驗證性（verifiability）：為了減少客戶和承包商之間可能發生的爭議，系統需求應該以能夠驗證的方式來撰寫。這表示應該要設計一組測試，證明交付系統能符合每個指定需求。,目前有多種需求確認技術，可以個別或聯合使用：,需求審查（requirements review）：由審查小組有系統的分析每項需求，下一節將探討它的過程。雛形法（prototyping）：在使用這種確認方式時，必須向終端使用者與客戶展示一個可執行的系統模型。他們可以用此模型來體驗，確認是否符合他們的真正需求。產生測試案例（test-case generation）：需求應該要能夠接受測試。如果能讓需求測試成為確認程序的一部分，通常可以發現需求上的問題。如果很難或不可能設計出這樣的測試，通常表示這個需求很難實作，最好重新考慮是否要變更需求。,需求審查,需求審查（requirements review）是一項人工的程序，包含來自客戶和承包商的人員，共同檢查需求文件中是否有異常或遺漏。審查程序可以採用和程式檢驗一樣的方法，也可以組織成比較大型的活動，讓不同人員檢查文件的各部分。需求審查可以是正式或非正式的。,7.4 需求管理,大型軟體系統的需求一直在變動中，其中一個原因是因為這些系統通常是用來解決棘手的問題。因為這種問題無法完整的定義，所以軟體的需求就不會是完整的。在系統安裝上線後，還是一定會有新需求出現。對使用者和客戶而言，他們很難預料新系統對組織會有什麼影響。等使用者對系統有經驗之後，他們可能會發現新的需求和不同的優先順序。,需求的演進,持久和短暫的需求,從演進的觀點來看，需求可分成2類：持久的需求（enduring requirement）：這些是指非常穩定的需求，它們衍生自組織的核心活動，並且直接與系統的領域有關。比如說，醫院領域的需求一定會與病人、醫生、護士和治療有關，這些需求可以衍生自領域模型，模型中顯示描述此應用領域特質的實體和關係。短暫的需求（volatile requirement）：這些是指可能會隨著系統開發過程或在系統上線運作時而改變的需求。比如說，政府的健保政策會導致需求改變。,需求管理的規劃,識別需求：每一項需求必須能夠唯一的被識別，以便讓其他需求交叉參考並因此而評估可追蹤性。變更管理的程序：這是一組用來評估變更的影響與成本的活動。在下一節將詳細介紹。建立可追蹤性的策略：這些策略是用來定義需求之間的關係、需求與系統設計之間的關係，以及這些記錄應該如何維護。CASE工具的支援：需求管理是牽涉到處理與需求有關的大量資訊。支援的工具種類從專門的需求管理系統，到試算表和簡單的資料庫系統都有。,可追蹤性（traceability）是需求規格的一種性質，代表是否能很容易的找到相關的需求。可能需要維護的可追蹤性資訊有下列3種：來源的可追蹤性：這類資訊會連結需求與提出需求的專案關係人，以及提出這些需求的根本原因。當有變更被提出時，便可以利用這項資訊找出專案關係人，詢問他們對此變更的看法。需求的可追蹤性：這類資訊會連結在需求文件中相互依存的需求。這項資訊可以用來評估，這項變更可能會影響到多少個需求，還有後續的需求變更範圍。設計的可追蹤性：這類資訊會連結需求與實作這些需求的設計模組，這項資訊可以用來評估提出的這項需求變更，對於系統設計和實作上的影響。,需求管理需要一些自動化功能的支援，這部份的CASE工具應該在規劃階段來選擇。你會需要具有以下功能的工具：儲存需求（requirements storage）：這些需求應該保存在安全且有管制的資料儲存體中，讓與需求工程程序有關的所有人員都能夠存取。變更管理（change management）：如果有現成的工具能夠支援（圖7.13），就可以簡化變更管理的程序。可追蹤性管理（traceability management）：支援可追蹤性的工具必須能夠找出相關的需求。有些工具使用自然語言處理技術，來找出需求之間的可能關係。,需求變更管理,變更管理程序有3個主要階段：問題分析與制定變更的規格：這項程序是從辨識需求問題開始，有時候也可以從某個特定的變更提案開始。這個階段會對問題或變更提案進行分析，檢查其有效性，然後產生更確定的需求變更提案。變更分析與成本預估：這個階段會利用可追蹤性資訊和系統需求的知識來評估變更的影響，然後針對需求文件的修改和系統設計與實作階段，評估該變更的所需成本。變更的實作：這個階段將修改需求文件，必要時連系統設計與實作部份都一起修改。需求文件的內容架構應該盡量有彈性，使變更不會導致文件大量重寫或重組。,