第4章 理解需求

1、第四章 理解需求王美紅軟 件 工 程1.用戶在軟件需求分析過程中重要嗎?請說明理由2.軟件需求分析是軟件工程過程中交換意見最頻繁的步驟,為什么交換意見的途徑會經(jīng)常阻塞？問題軟 件 工 程為什么需求工程非常困難？ 客戶說不清楚需求 需求自身不斷變動 分析人員或客戶理解有誤軟 件 工 程軟 件 工 程主要內(nèi)容 需求工程的概念 需求工程的任務(wù) 啟動需求工程過程 導(dǎo)出需求 開發(fā)用例軟 件 工 程4.1 需求工程需求工程（Requirement Engineering, RE)是指致力于不斷理解需求的大量任務(wù)和技術(shù)。需求工程在設(shè)計和構(gòu)造之間建立起聯(lián)系的橋梁。軟 件 工 程軟件需求軟件需求包括三個不同的層

2、次:業(yè)務(wù)需求用戶需求功能需求也包括非功能需求。軟 件 工 程需求分析的三個層次l業(yè)務(wù)需求:l反映了組織機構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求。l用戶需求: l文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)。l功能需求:l定義了開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。軟 件 工 程軟件學(xué)院 軟件工程導(dǎo)論需求的層次需求的層次軟 件 工 程4.1 需求工程 把所有與需求直接相關(guān)的活動通稱為需求工程。 需求工程中的活動可分為兩大類:一類屬于需求開發(fā)另一類屬于需求管理。軟 件 工 程需求工程的結(jié)構(gòu)圖需求工程的結(jié)構(gòu)圖軟 件 工 程4.1 需求工程 需求工程通過執(zhí)行七個不同的活動來

3、完成：起始導(dǎo)出精化協(xié)商規(guī)格說明確認(rèn)1. 管理軟 件 工 程4.1 需求工程 1. 起始： 軟件工程是詢問一些似乎與項目無直接關(guān)系的問題 泛談起始，有各種各樣的情況 目的是對問題、方案需求方、期望方案的本質(zhì)、客戶和開發(fā)人員之間初步的交流和合作的效果建立基本的諒解軟 件 工 程4.1 需求工程 2. 導(dǎo)出 詢問客戶、用戶和其他人，系統(tǒng)或產(chǎn)品的目標(biāo)是什么？想要實現(xiàn)什么？系統(tǒng)和產(chǎn)品任何滿足業(yè)務(wù)的要求，最終系統(tǒng)和產(chǎn)品如何用于日常工作？ 非常困難：范圍問題、理解問題、異變問題軟 件 工 程4.1 需求工程 3. 精化 將起始和導(dǎo)出階段獲得的信息進行擴展和提煉 是一個分析建模動作 精化的最終結(jié)果：一個分析模

4、型，定義了問題的信息域、功能域和行為域軟 件 工 程4.1 需求工程 4. 協(xié)商 需求工程師必須通過協(xié)商的過程調(diào)節(jié)各種沖突 按優(yōu)先級討論沖突 識別和分析風(fēng)險 粗略“估算”開發(fā)工作量，并評估每項需求對項目成本和交付時間的影響 使用迭代，刪除、細化或修改需求，以便各方達到一定的滿意度軟 件 工 程4.1 需求工程 5. 規(guī)格說明(specification) 把前面的成果用文字或其它方式明示出來。 可以是一份寫好的文檔，一套圖形化的模型，一個形式化的數(shù)學(xué)模型，一組使用場景，一個原型或上述各項的任意組合軟 件 工 程4.1 需求工程 6. 確認(rèn)： 要檢查規(guī)格說明以保證： 所有的系統(tǒng)需求已被無歧義地說

5、明；不一致性、疏漏和錯誤已被檢測出并被糾正；工作產(chǎn)品符合為過程、項目和產(chǎn)品建立的標(biāo)準(zhǔn)。 由第三方（通常為評審組）完成軟 件 工 程4.1 需求工程 7. 需求管理 用于幫助項目組在項目進展中標(biāo)識、控制和跟蹤需求以及變更需求的一組活動。 解決方法：特征跟蹤表、來源跟蹤表、依賴跟蹤表、子系統(tǒng)跟蹤表、接口跟蹤表等。軟 件 工 程4.2 建立根基 1. 確定共利益者 直接或間接從正在開發(fā)的系統(tǒng)中獲益的人 比如業(yè)務(wù)操作管理人員、產(chǎn)品管理人員、市場營銷人員、內(nèi)部或外部客戶、最終用戶、顧問、產(chǎn)品工程師、軟件工程師、支持和維護工程師以及其他人員軟 件 工 程4.2 建立根基 2.識別多種觀點 需求工程師就是把

6、所有共利益者提供的信息（包括不一致或者矛盾的需求）分類，分類的方法應(yīng)該便于決策制定者為系統(tǒng)選擇一個內(nèi)部一致的需求集合。軟 件 工 程 3. 協(xié)作 如何協(xié)作？ 需求工程師的主要任務(wù)是標(biāo)識公共區(qū)域和矛盾區(qū)域 一個有效的方法是使用“優(yōu)先點”，所有共利益者都分配一定數(shù)量的優(yōu)先點4.2 建立根基軟 件 工 程4.2 建立根基 4. 首次提問 “與環(huán)境無關(guān)”第一組與環(huán)境無關(guān)的問題集中于客戶和其他共利益者、整體目標(biāo)、收益： 誰是這項工作的最初提出者？ 誰將使用該解決方案 成功的解決方案將帶來什么樣的經(jīng)濟效益？ 存在別的解決方法嗎？ 軟 件 工 程4.2 建立根基 下列一組有軟件開發(fā)組更好地理解問題，并允許客

7、戶表達其他對解決方案的看法： 如何描述由某成功的解決方案產(chǎn)生的“良好的”輸出？ 該解決方案強調(diào)了什么問題？ 能向我們展示（或描述）解決方案的使用環(huán)境嗎？ 存在影響解決方案的特殊性能問題或約束嗎？ 軟 件 工 程4.2 建立根基 最后一組問題關(guān)注與溝通活動本身的效率： 你是回答這些問題的最合適人選嗎？你的回答是“正式的”嗎？ 你的提問和你解決的問題相關(guān)嗎？ 我的問題是否太多了？ 還有其他人員可以提供更多的信息嗎？ 還有我應(yīng)該問的其他問題嗎？軟 件 工 程4.2 建立根基 導(dǎo)出需求的方法： 訪談 面向數(shù)據(jù)流自頂向下求精 協(xié)同需求獲取 快速建立軟件原型 質(zhì)量功能部署 用戶場景 軟 件 工 程4.2

8、建立根基 訪談?wù)皆L談事先準(zhǔn)備好的具體問題非正式訪談自由問答可借助：調(diào)查表再針對性訪問情景分析技術(shù)(對用戶將來使用目標(biāo)系統(tǒng)解決某個具體問題的方法和結(jié)果進行分析)軟 件 工 程編號提出問題1您在哪個部門工作？您在哪個部門工作？2出版業(yè)務(wù)流程是什么？出版業(yè)務(wù)流程是什么？3您每日都處理哪些文件、數(shù)據(jù)、報表？您每日都處理哪些文件、數(shù)據(jù)、報表？4工作中手工處理特別麻煩的事情是什么？工作中手工處理特別麻煩的事情是什么？5工作中手工處理什么問題解決不了？影響效率的問題工作中手工處理什么問題解決不了？影響效率的問題有哪些？有哪些？6您認(rèn)為提高工作效率，節(jié)省工作時間，減輕工作強度您認(rèn)為提高工作效率，節(jié)省工作時間

9、，減輕工作強度可采取哪些辦法？可采取哪些辦法？軟 件 工 程編號提出問題7您的部門需要成本核算和統(tǒng)計的內(nèi)容有哪些？您的部門需要成本核算和統(tǒng)計的內(nèi)容有哪些？8您的部門采用計算機管理工作情況如何？您的部門采用計算機管理工作情況如何？9如何改進業(yè)務(wù)流程使之更合理？如何改進業(yè)務(wù)流程使之更合理？10哪些問題是目前傳統(tǒng)手工方法根本無法解決的？哪些問題是目前傳統(tǒng)手工方法根本無法解決的？11出版社計算機管理信息系統(tǒng)需要解決什么問題？出版社計算機管理信息系統(tǒng)需要解決什么問題？軟 件 工 程軟件需求調(diào)查表的編寫方法與實例軟 件 工 程4.2 建立根基 面向數(shù)據(jù)流自頂向下求精數(shù)據(jù)決定了需要的處理和算法，是需求分析的

10、出發(fā)點需求分析的目標(biāo)之一是在可行性研究得到的高層數(shù)據(jù)流圖基礎(chǔ)上，把數(shù)據(jù)流和數(shù)據(jù)存儲定義到元素級通過對未知數(shù)據(jù)和其需要的算法的請教，深入認(rèn)識系統(tǒng)分析員借助數(shù)據(jù)流圖、數(shù)據(jù)字典和IPO圖向用戶解釋輸入數(shù)據(jù)是怎么一步步轉(zhuǎn)變成輸出數(shù)據(jù)的。軟 件 工 程與用戶溝通需求的方法圖 面向數(shù)據(jù)流自頂向下求精過程軟 件 工 程4.2 建立根基 協(xié)同需求獲取 面向團隊的需求獲取方法 共利益者和開發(fā)人員的團隊共同完成：確認(rèn)問題，為解決方案的要素提供建議，協(xié)商不同的方法，以及說明初步的解決方案需求集合。軟 件 工 程4.2 建立根基 一些基礎(chǔ)原則： 會議由軟件工程師和客戶（連同其他的共利益者）共同舉辦和參與 制定籌備和參

11、與會議的規(guī)則。 建議擬定一個會議議程，這個議程既要足夠正式，使其涵蓋所有的重要點；但也不能太正式，以鼓勵思維的自由交流軟 件 工 程4.2 建立根基 由一個“主持人”（可以是客戶、開發(fā)人員或其他外人）控制會議。 使用某種“定義機制”（可以是工作表、活動掛圖、不干膠貼紙或電子公告牌、聊天室或虛擬論壇） 目的是識別問題，提出解決問題的要素，協(xié)商不同的方法以及在有利于完成目標(biāo)的氛圍中刻畫初步解決方案的需求問題。軟 件 工 程4.2 建立根基簡易的應(yīng)用規(guī)格說明技術(shù)面向團隊的需求收集法，提倡用戶與開發(fā)者密切合作，共同標(biāo)識問題，提出解決方案要素，商討不同方案并指定基本需求。軟 件 工 程4.2 建立根基簡

12、易的應(yīng)用規(guī)格說明技術(shù)典型過程：初步訪談，初步確定待解決的問題的范圍和解決方案開發(fā)者和用戶分別寫出“產(chǎn)品需求”，要求每位與會者在開會的前幾天認(rèn)真審查產(chǎn)品需求，希望能準(zhǔn)確地表達出每個人對目標(biāo)系統(tǒng)的認(rèn)識。會議上為每個議題首先創(chuàng)建組合列表，然后創(chuàng)建一張意見一致的列表(對象、服務(wù)、約束和性能)分小組，為每張列表的項目制定小型規(guī)格說明合并展示小型規(guī)格說明，并討論。每個與會者制定一套確認(rèn)標(biāo)準(zhǔn)，并提交討論，最后創(chuàng)建出一件一致的確認(rèn)標(biāo)準(zhǔn)。由一到多名與會者起草軟件需求規(guī)格說明書。軟 件 工 程與用戶溝通需求的方法 快速建立軟件原型是最準(zhǔn)確、最有效、最強大的需求分析技術(shù)構(gòu)造原型的要點是：應(yīng)該事先用戶能看得見的功能（

13、如屏幕演示或打印報表），省略目標(biāo)系統(tǒng)的“隱含”功能（例如，修改文件）快速原型的特性：快速、容易修改軟 件 工 程與用戶溝通需求的方法快速建立軟件原型可借助方法和工具：第四代技術(shù)（數(shù)據(jù)庫查詢和報表語言、程序和應(yīng)用系統(tǒng)生成器及其他非常高級的非過程語言）可重用的軟件構(gòu)件形式化規(guī)格說明和原型環(huán)境軟 件 工 程4.2 建立根基 質(zhì)量功能部署（Quality Function Development, QFD）是把顧客或市場的要求轉(zhuǎn)化為設(shè)計要求、零部件特性、工藝要求、生產(chǎn)要求的多層次演繹分析方法。QFD于70年代初起源于日本三菱重工的神戶造船廠應(yīng)付大量的資金支出和嚴(yán)格的政府法規(guī)，取得了很大的成功。他們用矩

14、陣的形式將顧客需求和政府法規(guī)同如何實現(xiàn)這些要求的控制因素聯(lián)系起來。軟 件 工 程4.2 建立根基 QFD步驟步驟關(guān)鍵顧客需求產(chǎn)品特性 關(guān)鍵產(chǎn)品特性部件特性關(guān)鍵部件特性過程特性 1. 過程特性生產(chǎn)特性軟 件 工 程4.2 建立根基 質(zhì)量屋 是QFD的核心 質(zhì)量屋是一種確定顧客需求和相應(yīng)產(chǎn)品或服務(wù)性能之間聯(lián)系的圖示方法。 各階段質(zhì)量屋不同軟 件 工 程圖 質(zhì)量屋矩陣軟 件 工 程圖 蠟燭產(chǎn)品的質(zhì)量屋軟 件 工 程4.2 建立根基 QFD對需求的分類： 常規(guī)需求： 也稱普通需求，包含客戶對項目的最基本需求，是客戶對整個項目最為關(guān)心的部分。 期望需求： 客戶可能沒有表達明確或沒有明確提出的需求，但是會

15、讓客戶提升對項目的滿意度。 意外需求： 也稱興奮需求，如果實現(xiàn)會給客戶帶來驚喜，但是如果無法實現(xiàn)也不會受到客戶責(zé)備。軟 件 工 程4.2 建立根基 QFD通過客戶訪談和觀察、調(diào)查以及檢查歷史數(shù)據(jù)為需求手機活動獲取原始數(shù)據(jù)。然后將這些數(shù)據(jù)翻譯成需求表客戶意見表，并由客戶評審。 接下來使用各種圖表、矩陣和評估方法抽取期望的需求并努力導(dǎo)出令人興奮的需求。軟 件 工 程4.2 建立根基 用戶場景 通常被稱為用例，它提供了系統(tǒng)將如何被使用的描述 關(guān)注用戶將如何使用該功能軟 件 工 程4.2 建立根基 導(dǎo)出工作產(chǎn)品 對于大多數(shù)系統(tǒng)而言，工作產(chǎn)品包括： 必要性和可行性陳述 系統(tǒng)或產(chǎn)品范圍的界限說明 參與需求

16、導(dǎo)出的客戶、用戶和其他共利益者的列表 系統(tǒng)技術(shù)環(huán)境的說明 需求列表以及每個需求適用的領(lǐng)域限制 一系列使用場景，有助于深入了解系統(tǒng)或產(chǎn)品在不同運行環(huán)境下的使用 任何能夠更好地定義需求的原型軟 件 工 程4.3 開發(fā)用例 用例講述了能表達主體場景的故事： 最終用戶（扮演多種可能角色中的一個）如何在一特定環(huán)境下和系統(tǒng)交互。軟 件 工 程4.3 開發(fā)用例（續(xù)） 撰寫用例的第一步：定義各類故事中所包含的“參與者” 參與者代表了系統(tǒng)運行時，人（或設(shè)備）所扮演的角色，在使用系統(tǒng)時，每個參與者都有一個或多個目標(biāo)。 參與者是角色而非最終用戶。軟 件 工 程4.3 開發(fā)用例（續(xù)） 這些問題有助于我們抽象出系統(tǒng)的參

17、與者： 系統(tǒng)開發(fā)完成之后，有哪些人會使用這個系統(tǒng)？ 系統(tǒng)需要從哪些人或其他系統(tǒng)中獲得數(shù)據(jù)？ 系統(tǒng)會為哪些人或其他系統(tǒng)提供數(shù)據(jù)？ 系統(tǒng)會與哪些其他系統(tǒng)相關(guān)聯(lián)？ 系統(tǒng)是由誰來維護和管理的？ 軟 件 工 程4.3 開發(fā)用例（續(xù)） 撰寫用例的第二步：開發(fā)用例 誰是主要參與者、次要參與者？ 參與者的目標(biāo)是什么？ 故事開始前有什么前提條件？ 參與者完成的主要工作或功能是什么？ 按照故事所描述的還可能需要考慮什么異常？ 參與者的交互中有什么可能的變化？軟 件 工 程4.3 開發(fā)用例（續(xù)） 參與者將獲得、產(chǎn)生或改變哪些系統(tǒng)信息？ 參與者必須通知系統(tǒng)外部環(huán)境的改變嗎? 參與者希望從系統(tǒng)獲取什么信息？ 參與者希望

18、能夠得知意料之外的變更嗎？軟 件 工 程軟 件 工 程HVAC:供熱通風(fēng)與空氣調(diào)節(jié)軟 件 工 程4.3 開發(fā)用例 SafeHome參與者： 房主 系統(tǒng)管理員 傳感器和監(jiān)控子系統(tǒng)軟 件 工 程圖： SafeHome控制面板軟 件 工 程圖： SafeHome住宅安全功能的用例圖軟 件 工 程軟 件 工 程軟 件 工 程4.5 構(gòu)建需求模型 分析模型的目的是為基于計算機的系統(tǒng) 提供必要的信息、功能和行為域的說明。 分析模型是任意給定時刻的需求快照（更新）軟 件 工 程需求模型的元素 表達模式選擇一種或多種 需求模型的特定元素取決于將要使用的分析建模方法軟 件 工 程需求模型的元素軟 件 工 程4.6 協(xié)商需求 協(xié)調(diào)過程的目的是保證所開發(fā)的項目計劃，在滿足利益相關(guān)者要求的同時反應(yīng)軟件團隊所處真實世界的限制（如時間、人員、預(yù)算） 最好能利益相關(guān)者和軟件團隊“雙贏”軟 件 工 程4.7 確認(rèn)需求 模型元素創(chuàng)建后，需要檢查一致性、是否有遺漏以及歧義性。 每項需求都和系統(tǒng)或產(chǎn)品的整體目標(biāo)一致嗎？ 所有的需求都已經(jīng)在相應(yīng)的抽象層上說明了嗎？ 需求是真正必需的，還是另外加上去的，有可能不是系統(tǒng)目標(biāo)所必需的特性嗎？ 每項需求都有界定且無歧義嗎？ 每項需