【正文】 屬于需求？為什么？ – 系統(tǒng)通過 JDBC與 Oracle數(shù)據(jù)庫 CourseDB建立連接，并使用 TSQL語句從 CourseOffering數(shù)據(jù)表中獲得課程的開設(shè)信息。 2023/1/30 6 主要困難 ： 1. 軟件開發(fā)人員與用戶雙方固有的矛盾 2. 需求具有易變性和難以表述性 3. 需求錯(cuò)誤的高頻性和修復(fù)的高成本性 2023/1/30 7 軟件開發(fā)的目標(biāo)是什么？ ? 開發(fā)高質(zhì)量的軟件； ? 在預(yù)定的時(shí)間和預(yù)算約束下完成； ? 軟件要能夠滿足顧客的需求。 Phil 這并不是我的錯(cuò)！在開發(fā)系統(tǒng)之前，你從來沒有向我提起過有這種需求！ Maria 不管如何，請(qǐng)盡快把這個(gè)功能修改完畢，否則 Sparkle無法支付她的銀行帳單。 ? [例 ]用戶可以通過 Inter隨時(shí)查詢圖書信息和個(gè)人借閱情況，并可以快速查找和瀏覽需要的電子資料； – [功能需求 ]用戶通過 Inter查詢圖書信息； – [功能需求 ]用戶通過 Inter瀏覽個(gè)人借閱情況； – [功能需求 ]用戶通過 Inter查找和瀏覽電子資料； – [非功能需求 ]隨時(shí)、快速 2023/1/30 21 業(yè)務(wù)需求與用戶需求的對(duì)比 ? 針對(duì) Course Registration System ? 業(yè)務(wù)需求 – 由于實(shí)行學(xué)分制管理，學(xué)校領(lǐng)導(dǎo)希望用計(jì)算機(jī)管理學(xué)生選課。 ? 例如： – 即使對(duì)一個(gè)沒有經(jīng)驗(yàn)的用戶，系統(tǒng)也應(yīng)該很容易使用，且是用戶錯(cuò)誤降到最少； ? 修改為： – 對(duì)一個(gè)沒有經(jīng)驗(yàn)的用戶來說，經(jīng)過 2個(gè)小時(shí)的培訓(xùn)就應(yīng)該使用系統(tǒng)的全部功能。 ? 必須在對(duì)話窗口的中間顯示錯(cuò)誤警告，使用紅色的、 14點(diǎn)加粗 Arial字體。 2023/1/30 33 軟件需求的分類 好的需求 vs 壞的需求 2023/1/30 34 好的需求應(yīng)具備的特征 ? 完整性： 每一項(xiàng)需求都必須將所要實(shí)現(xiàn)的功能描述清楚 ? 正確性： 每一項(xiàng)需求都必須準(zhǔn)確地陳述其要開發(fā)的功能； ? 可行性： 每一項(xiàng)需求都必須是在已知系統(tǒng)和環(huán)境的權(quán)能和限制范圍內(nèi)可以實(shí)施的 ? 必要性： 每一項(xiàng)需求都應(yīng)把客戶真正所需要的和最終系統(tǒng)所需遵從的標(biāo)準(zhǔn)記錄下來 ? 劃分優(yōu)先級(jí)： 給每項(xiàng)需求、特性或使用實(shí)例分配一個(gè)實(shí)施優(yōu)先級(jí)以指明它在特定產(chǎn)品中所占的分量 ? 無二義性： 對(duì)所有需求說明的讀者都只能有一個(gè)明確統(tǒng)一的解釋 ? 可驗(yàn)證性： 檢查一下每項(xiàng)需求是否能通過設(shè)計(jì)測(cè)試用例或其它驗(yàn)證方法，如用演示、檢測(cè)等來確定產(chǎn)品是否確實(shí)按需求實(shí)現(xiàn) 2023/1/30 35 產(chǎn)生不合格需求的原因 ? 無足夠用戶參與 ——―我不明白為什么要花那么多功夫收集需求” ——―與其與用戶討論浪費(fèi)時(shí)間，不如寫代碼有意思” ——―我已經(jīng)明白用戶需求了” ? 用戶需求的不斷增加 ——若不斷增加新需求，項(xiàng)目就越來越龐大以致超過其計(jì)劃及預(yù)算范圍 ——開發(fā)中不斷延續(xù)的變更會(huì)使其整體結(jié)構(gòu)日漸紊亂，補(bǔ)丁代碼也使得整個(gè)程序難以理解和維護(hù) 2023/1/30 36 產(chǎn)生不合格需求的原因 ? 模棱兩可的需求 ——諸多讀者對(duì)需求說明產(chǎn)生了不同的理解 ——單個(gè)讀者能用不止一個(gè)方式來解釋某個(gè)需求說明 ——后果：返工，重做一些你認(rèn)為已做好的事情 ? 不必要的特性 ——―畫蛇添足”，開發(fā)人員力圖增加一些“用戶欣賞”但需求規(guī)格說明中并未涉及的新功能 ——客戶可能要求一些看上去很“酷”，但缺乏實(shí)用價(jià)值的功能，而實(shí)現(xiàn)這些功能只能徒耗時(shí)間和成本 2023/1/30 37 產(chǎn)生不合格需求的原因 ? 過于精簡的規(guī)格說明 ——給開發(fā)人員帶來挫折，使他們?cè)诓徽_的假設(shè)前提和極其有限的指導(dǎo)下工作 ——給客戶帶來煩惱，他們無法得到他們所設(shè)想的產(chǎn)品 ? 忽略了用戶分類 ——軟件由不同的人使用其不同的特性 ——使用頻繁程度有所差異 ——使用者受教育程度和經(jīng)驗(yàn)水平也不盡相同 ? 不準(zhǔn)確的計(jì)劃 ——對(duì)需求分析缺乏理解會(huì)導(dǎo)致過分樂觀的估計(jì) ——原因：頻繁的需求變更、遺漏的需求、與用戶交流不夠、質(zhì)量低下的需求規(guī)格說明和不完善的需求分析 2023/1/30 38 [案例分析 2]―他們忙，沒有時(shí)間與你討論需求 …‖ ? Contoso公司的 CEO Gerhard約見軟件開發(fā)小組Cynthia，商討為公司開發(fā)新系統(tǒng)的事情 … Gerhard 我們需要建立一套化學(xué)制品跟蹤信息系統(tǒng)，可以記錄并查詢庫房或某個(gè)實(shí)驗(yàn)室中已有的化學(xué)藥品 … 你們小組能在五個(gè)月內(nèi)開發(fā)出該系統(tǒng)嗎？ Cynthia 我已經(jīng)明白這個(gè)項(xiàng)目的重要性了，但在我制定計(jì)劃前，我們必須收集一些系統(tǒng)的需求。 改正：系統(tǒng)將在 20秒內(nèi)響應(yīng)所有有效的請(qǐng)求。 5．評(píng)審需求規(guī)格說明。 2023/1/30 49 需求狀態(tài)跟蹤 需求工程的總體流程 需求獲取 需求分析 需求規(guī)格說明 (SRS) 需求驗(yàn)證 客戶 (client) 終端用戶 (user) 市場(chǎng)人員 維護(hù)人員 基線 (baseline) 需求管理 需求變更過程 需求變更 項(xiàng)目變更 需求開發(fā) 需求管理 2023/1/30 50 需求開發(fā)所包含的活動(dòng) ? 確定 產(chǎn)品所期望的 用戶類 ? 獲取每個(gè)用戶類的需求 ? 了解實(shí)際用戶 任務(wù)和目標(biāo) 以及這些任務(wù)所支持的 業(yè)務(wù)需求 ? 分析源于用戶的信息以區(qū)別 用戶需求、功能需求、非功能需求、約束條件 、建議解決方法和附加信息 ? 將系統(tǒng)級(jí)的需求分為幾個(gè)子系統(tǒng)，并將需求中的一部份分配給軟件構(gòu)件 ? 了解相關(guān)非功能屬性的重要性 ? 商討實(shí)施 優(yōu)先級(jí) 的劃分 ? 將所收集的用戶需求 編寫成規(guī)格說明和模型 ? 評(píng)審需求規(guī)格說明 ，確保對(duì)用戶需求達(dá)到共同的理解與認(rèn)識(shí)，并在整個(gè)開發(fā)小組接受說明之前將問題都弄清楚 2023/1/30 51 (1) 需求獲取 ? 需求獲取 (Requirement Elicitation)： 通過與用戶的交流，對(duì)現(xiàn)有系統(tǒng)的觀察及對(duì)任務(wù)進(jìn)行分析，從而開發(fā)、捕獲和修訂用戶的需求 – 對(duì)用戶進(jìn)行分類 – 聆聽每一類用戶的需求 – 分析和整理所獲取的需求 – 形成文檔化的描述 – 簽字確認(rèn) 2023/1/30 52 (2) 需求分析 ? 需求分析 (Requirement Analysis)：對(duì)收集到的需求進(jìn)行提煉、分析和審查，為最終用戶所看到的系統(tǒng)建立概念化的分析模型 – 定義系統(tǒng)的邊界 – 建立軟件原型 – 分析需求可行性 – 確定需求優(yōu)先級(jí) – 建立需求分析模型 – 創(chuàng)建數(shù)據(jù)字典 2023/1/30 53 (3) 形成需求規(guī)格說明 ? 需求規(guī)格說明 (Software Requirement Specification, SRS)： – 需求開發(fā)的結(jié)果 – 精確的、形式化的闡述一個(gè)軟件系統(tǒng)必須提供的功能、非功能、所要考慮的限制條件等 – 作為用戶和開發(fā)者之間的一個(gè)契約 – 是用戶、分析人員和設(shè)計(jì)人員之間進(jìn)行理解和交流的手段 2023/1/30 54 (4) 需求驗(yàn)證 ? 需求驗(yàn)證 (Requirement Verification)：以需求規(guī)格說明為輸入，通過評(píng)審、模擬或快速原型等途徑，分析需求規(guī)格的正確性和可行性，發(fā)現(xiàn)存在的錯(cuò)誤或缺陷并及時(shí)更改和補(bǔ)充。但它們對(duì)需求工程師來說卻不是顯而易見的。 ? 具體地說，需求分析是提煉、分析和審查已收集到的需求信息，找出真正的和具體的需求，并確保所有相關(guān)人員都理解其含義。該技術(shù)提供了一種分析方法以明確那些是客戶最為關(guān)注的特性。 ? 軟件需求的物理視圖給出處理功能和數(shù)據(jù)結(jié)構(gòu)的實(shí)際表示形式 。 ? 最底層 DFD中的加工稱為 “基本加工” 。 2．?dāng)?shù)據(jù)流圖的特性 （ 1）抽象性 （ 2）概括性（ 3）層次性 3. 數(shù)據(jù)流圖基本符號(hào) （ 1）源點(diǎn)（ 2）加工（ 3）數(shù)據(jù)流 （ 4）數(shù)據(jù)存儲(chǔ)文件 4．?dāng)?shù)據(jù)流圖的用途 作為交流信息的工具。 2．?dāng)?shù)據(jù)字典的內(nèi)容 （ l）數(shù)據(jù)流 （ 2）數(shù)據(jù)項(xiàng) （ 3）數(shù)據(jù)結(jié)構(gòu) （ 4）數(shù)據(jù)存儲(chǔ) （ 5）處理邏輯 （ 6）外部實(shí)體 3．定義數(shù)據(jù)的方法 對(duì)數(shù)據(jù)自頂向下的分解 2023/1/30 130 數(shù)據(jù)字典 4．?dāng)?shù)據(jù)字典的用途 數(shù)據(jù)字典最重要的用途是作為分析階段的工具。 – 長途電話號(hào)碼由區(qū)號(hào)和市話號(hào)碼組成，其中區(qū)號(hào)可以為 0021~02 0300~0999中的任意一個(gè)數(shù)字串。 2023/1/30 145 2023/1/30 146 需求驗(yàn)證的目的是確保需求規(guī)格說明具有良好（ 例如完整性和正確性 ） 。 3. 驗(yàn)證需求的完整性和有效性 快速原型法 原型系統(tǒng)所顯示的是系統(tǒng)的主要功能而不是性能，因此可以適當(dāng)降低對(duì)接口、可靠性等的要求，還可以節(jié)省文檔等方面的工作，從而可大大降低原型系統(tǒng)的開發(fā)成本 2023/1/30 150 需求評(píng)審 需求評(píng)審就是技術(shù)評(píng)審，是由非軟件開發(fā)人員對(duì)軟件系統(tǒng)進(jìn)行檢查，進(jìn)而發(fā)現(xiàn)系統(tǒng)存在的問題。 ? 只有通過軟件需求分析 ， 才能把軟件功能和性能的總體概念描述為具體的軟件需求規(guī)格說明 ， 進(jìn)而建立軟件開發(fā)的基礎(chǔ) 。 2023/1/30 155 需求開發(fā)的管理 (1)需求來源 (2)需求形式化 (3)需求跟蹤矩陣 (1)編寫測(cè)試計(jì)劃與測(cè)試用例； (2)編寫系統(tǒng)驗(yàn)收標(biāo)準(zhǔn)； (3)通過需求評(píng)審； (4)需求評(píng)審的誤區(qū)。 :指定的需求應(yīng)該是用現(xiàn)有的硬件技術(shù)和軟件技術(shù)基本上可以實(shí)現(xiàn)的。 ? 系統(tǒng)分析員從對(duì)頂層信息的分類開始 ， 沿圖中每條路徑反復(fù)細(xì)化 ， 直到確定了數(shù)據(jù)結(jié)構(gòu)的全部細(xì)節(jié)為止 。 – DD所有的定義應(yīng)是嚴(yán)密的、精確的，不可有半點(diǎn)含混，不可有二義性。 (4) 容易與計(jì)算機(jī)處理相對(duì)照。 – 根據(jù)缺貨記錄進(jìn)行缺貨統(tǒng)計(jì)，將缺貨通知單發(fā)給采購部門，以便采購。 – 收集、排序、選擇、聚集、分析等 – 加工要有名字，通常是動(dòng)詞短語，簡明地描述完成什么事情 – 在分層的數(shù)據(jù)流圖中，加工還應(yīng)編號(hào) – 三種類型：計(jì)算機(jī)自動(dòng)加工、手工加工、人機(jī)協(xié)作的加工 1 錄入訂單 2 審核訂單 2023/1/30 100 DFD的主要元素 (2)：數(shù)據(jù)存儲(chǔ) ? 數(shù)據(jù)存儲(chǔ) (data storage，也稱文件 )：需要在外存儲(chǔ)器上保存的數(shù)據(jù)，它可以是數(shù)據(jù)庫文件或任何形式的數(shù)據(jù)組織。 ? 在需求分析階段 ， 軟件的功能域和信息域都能做進(jìn)一步的分解 。 4. 確定需求的優(yōu)先級(jí) 應(yīng)用分析方法來確定使用實(shí)例、產(chǎn)品特性或單項(xiàng)需求實(shí)現(xiàn)的優(yōu)先級(jí)。 2023/1/30 81 需求研討會(huì) (Workshop) ? 專題討論會(huì)準(zhǔn)備 – 參加會(huì)議人員：主持人、用戶、技術(shù)人員、項(xiàng)目組人員 – 安排日程 – 通常在具有相應(yīng)支持設(shè)備的專用房間進(jìn)行 ? 舉行會(huì)議 – 可能出現(xiàn)人員之間的責(zé)備或沖突，主持人應(yīng)掌握討論氣氛并控制會(huì)場(chǎng) – 最重要的部分是自由討論階段，這種技術(shù)非常符合專題討論會(huì)的氣氛，并且營造一種創(chuàng)造性的和積極的氛圍，同時(shí)可以獲得所有相關(guān)者的意見 – 分配會(huì)議時(shí)間，記錄所有言論 2023/1/30 82 現(xiàn)場(chǎng)觀察 ? 用戶可能無法有效全面的表達(dá)自己的需求，通過面談和會(huì)議也難以獲得完整信息； ? 在這種情況下，現(xiàn)場(chǎng)觀察用戶的工作流程有助于更深入全面了解需求。將答案記錄到紙面上，并指出和記錄下未回答條目和未解決問題； ? Step 4：面談之后，分析總結(jié)面談?dòng)涗洝? 對(duì)獲得的用戶需求信息進(jìn)行分析和綜合，找出錯(cuò)誤和沖突及遺漏的地方，獲得用戶的準(zhǔn)確的需求，進(jìn)而建立軟件系統(tǒng)的邏輯模型或需求模型。 ? 需求工程突出了工程化原則，強(qiáng)調(diào)以系統(tǒng)化、條理化和重復(fù)化的方法進(jìn)行軟件需求的相關(guān)活動(dòng)，從而增強(qiáng)了管理性和降低了需求開發(fā)的成本 2023/1/30 44 需求工程概念 需求工程的任務(wù)： 1．確定待開發(fā)的軟件系統(tǒng)的用戶，并獲取用戶的需求信息。 Gerhard 行了，行了，我們沒有那么多時(shí)間，我來告訴你需求，請(qǐng)馬上開始開發(fā)系統(tǒng)，并