協(xié)商與建模需求規(guī)約與驗(yàn)證需求管理-Read課件

制作者程麗軟件工程第二章需求工程制作者程麗軟件工程第二章需求工程1本章介紹以下內(nèi)容可行性分析需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗(yàn)證需求管理本章介紹以下內(nèi)容可行性分析2課程的任務(wù)、目的和基本要求掌握可行性分析的方法掌握需求工程的定義及六個(gè)階段掌握軟件需求內(nèi)容掌握需求獲取的方法與策略掌握需求分析原則掌握需求規(guī)約的原則掌握需求規(guī)約的內(nèi)容了解需求驗(yàn)證過程了解需求管理相關(guān)概念

課程的任務(wù)、目的和基本要求掌握可行性分析的方法3接下來介紹可行性分析需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗(yàn)證需求管理接下來介紹可行性分析4可行性研究的任務(wù)可行性研究的具體步驟系統(tǒng)流程圖成本－效益分析方案的選擇和折衷可行性分析的結(jié)論可行性研究的文檔可行性分析可行性研究的任務(wù)可行性分析5提出問題

→有無解決的辦法

→是否值得去做可行性研究的目的提出問題可行性研究的目的6可行性研究的任務(wù)技術(shù)可行性確定技術(shù)風(fēng)險(xiǎn)，項(xiàng)目實(shí)現(xiàn)的可能性經(jīng)濟(jì)可行性考慮投入—產(chǎn)出，市場(chǎng)前景，經(jīng)營(yíng)策略社會(huì)可行性考慮合同、責(zé)任、侵權(quán)、用戶組織的管理模式及規(guī)范問題可行性研究的任務(wù)技術(shù)可行性7可行性研究的步驟確定項(xiàng)目規(guī)模和目標(biāo)研究正在運(yùn)行的系統(tǒng)－系統(tǒng)流程圖建立新系統(tǒng)的高層邏輯模型－簡(jiǎn)單數(shù)據(jù)流圖導(dǎo)出和評(píng)價(jià)各種方案推薦可行的方案編寫可行性研究報(bào)告，交使用部門審查可行性研究的步驟確定項(xiàng)目規(guī)模和目標(biāo)8用圖形符號(hào)描述項(xiàng)目處理流程、范圍和功能

處理輸入/輸出連接換頁(yè)連接數(shù)據(jù)流文檔聯(lián)機(jī)存儲(chǔ)磁盤顯示人工輸入人工操作輔助操作通信鏈路系統(tǒng)流程圖用圖形符號(hào)描述項(xiàng)目處理流程、范圍和功能系統(tǒng)流程圖9工資處理過程：每月末教師把他們當(dāng)月實(shí)際授課時(shí)數(shù)登記在課時(shí)表上，由各系匯總后交給財(cái)務(wù)科。職工把他們當(dāng)月完成承包任務(wù)的情況登記在任務(wù)表上，匯總后交給財(cái)務(wù)科。會(huì)計(jì)根據(jù)這些原始數(shù)據(jù)計(jì)算每名教職工的工資，編制工資表、工資明細(xì)表。然后，把記有每名教職工工資總額的工資表報(bào)送銀行，由銀行把錢打到每名教職工的工資存折上，同時(shí)把工資明細(xì)表發(fā)給每名教職工。例子：人工系統(tǒng)計(jì)算工資和編制報(bào)表工資處理過程：例子：人工系統(tǒng)計(jì)算工資和編制報(bào)表10教師課時(shí)表任務(wù)表職工工資支付系統(tǒng)工資表工資明細(xì)表銀行教師職工教師課時(shí)表任務(wù)表職工工資支付系統(tǒng)工資表工資明細(xì)表銀行教師職工11成本效益分析效益表現(xiàn)有形效益：無形效益：貨幣的時(shí)間價(jià)值、投資回收期、純收入從性質(zhì)上、心理上進(jìn)行衡量成本效益分析效益表現(xiàn)有形效益：無形效益：貨幣的時(shí)間價(jià)值、投資12貨幣的時(shí)間價(jià)值

F=P*(1+n*i)(不計(jì)復(fù)利)P=F/(1+n*i)i----利率

P---現(xiàn)在值（元）

n----年數(shù)

F---將來值（元）成本效益分析貨幣的時(shí)間價(jià)值成本效益分析13成本效益分析投資回收期使累計(jì)的經(jīng)濟(jì)效益等于最初投資費(fèi)用所需的時(shí)間投資回收期越短，就越快獲得利潤(rùn)純收入整個(gè)生存周期之內(nèi)的累計(jì)經(jīng)濟(jì)效益（折合成現(xiàn)在值）與投資之差成本效益分析投資回收期14一個(gè)系統(tǒng)可以有多個(gè)可行的實(shí)現(xiàn)方案，每個(gè)方案對(duì)成本、時(shí)間、人員、技術(shù)、設(shè)備都有不同的要求，不同方案開發(fā)出來的系統(tǒng)在功能、性能方面也會(huì)有所不同。因此要在多個(gè)可行的實(shí)現(xiàn)方案中作出選擇。由于系統(tǒng)的功能和性能受到多種因素的影響，某些因素之間相互關(guān)聯(lián)和制約。如，為達(dá)到高的精度就可能導(dǎo)致長(zhǎng)的執(zhí)行時(shí)間，為達(dá)到高可靠性就會(huì)導(dǎo)致高的成本等等。因此，在必要時(shí)應(yīng)進(jìn)行折衷。方案的選擇和折衷一個(gè)系統(tǒng)可以有多個(gè)可行的實(shí)現(xiàn)方案，每個(gè)方案對(duì)成本、時(shí)間、人員15可行性分析的結(jié)論可以立即開始進(jìn)行需要推遲到某些條件（例如資金、人力、設(shè)備等）落實(shí)之后才能開始進(jìn)行需要對(duì)開發(fā)目標(biāo)進(jìn)行某些修改之后才能開始進(jìn)行因?yàn)槟撤N原因（如，技術(shù)不成熟、經(jīng)濟(jì)上不合算等）不能進(jìn)行可行性分析的結(jié)論可以立即開始進(jìn)行16可行性研究的文檔在可行性研究后提交的文檔，包括引言可行性研究前提對(duì)現(xiàn)有系統(tǒng)的分析所建議的系統(tǒng)可選擇的其它系統(tǒng)方案投資及效益分析社會(huì)因素方面的可行性分析結(jié)論可行性研究的文檔在可行性研究后提交的文檔，包括17接下來介紹可行性分析需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗(yàn)證需求管理接下來介紹可行性分析18軟件需求工程細(xì)分為需求獲取需求分析與協(xié)商系統(tǒng)建模需求規(guī)約需求驗(yàn)證需求管理需求工程軟件需求工程細(xì)分為需求工程19需求獲取系統(tǒng)分析人員與用戶交流，對(duì)現(xiàn)有系統(tǒng)觀察，對(duì)任務(wù)進(jìn)行分析，確定系統(tǒng)或產(chǎn)品的范圍，與系統(tǒng)或產(chǎn)品有關(guān)的人員及特征，系統(tǒng)的技術(shù)環(huán)境，系統(tǒng)功能，應(yīng)用于每個(gè)需求的領(lǐng)域限制，一組描述不同運(yùn)行條件下系統(tǒng)或產(chǎn)品使用狀況的應(yīng)用場(chǎng)景。需求獲取系統(tǒng)分析人員與用戶交流，對(duì)現(xiàn)有系統(tǒng)觀察，對(duì)任務(wù)進(jìn)行20需求分析與協(xié)商

需求獲取結(jié)束后，分析活動(dòng)對(duì)需求進(jìn)行分類組織，分析每個(gè)需求與其它需求的關(guān)系，檢查需求的一致性、重疊和遺漏的情況，并根據(jù)用戶的需要對(duì)需求進(jìn)行排序。在需求獲取階段，經(jīng)常出現(xiàn)以下問題：用戶提出的要求超出軟件系統(tǒng)可以實(shí)現(xiàn)的范圍或?qū)崿F(xiàn)能力；不同的用戶提出了相互沖突的需求需求分析與協(xié)商需求獲取結(jié)束后，分析活動(dòng)對(duì)需求進(jìn)行分類組織，21系統(tǒng)建模建模工具的使用在用戶和系統(tǒng)分析人員之間建立了統(tǒng)一的語言和理解的橋梁，同時(shí)系統(tǒng)分析人員借助建模技術(shù)對(duì)獲取的需求信息進(jìn)行分析，排除錯(cuò)誤和彌補(bǔ)不足，確保需求文檔正確反映用戶的真實(shí)意圖。常用的分析和建模方法有面向數(shù)據(jù)流方法、面向數(shù)據(jù)結(jié)構(gòu)方法和面向?qū)ο蟮姆椒āＯ到y(tǒng)建模建模工具的使用在用戶和系統(tǒng)分析人員之間建立了統(tǒng)一的22需求規(guī)約軟件需求規(guī)約是分析任務(wù)的最終產(chǎn)物，通過建立完整的信息描述、詳細(xì)的功能和行為描述、性能需求和設(shè)計(jì)約束的說明、合適的驗(yàn)收標(biāo)準(zhǔn)，給出對(duì)目標(biāo)軟件的各種需求。需求規(guī)約作為用戶和開發(fā)者之間的一個(gè)協(xié)議，在之后的軟件工程各個(gè)階段發(fā)揮重要作用。需求規(guī)約軟件需求規(guī)約是分析任務(wù)的最終產(chǎn)物，通過建立完整的信23需求驗(yàn)證作為需求開發(fā)階段工作的復(fù)查手段，需求驗(yàn)證對(duì)功能的正確性、完整性和清晰性，以及其它需求給予評(píng)價(jià)。為保證軟件需求定義的質(zhì)量，評(píng)審應(yīng)以專門指定的人員負(fù)責(zé)，并按規(guī)程嚴(yán)格進(jìn)行。需求驗(yàn)證作為需求開發(fā)階段工作的復(fù)查手段，需求驗(yàn)證對(duì)功能的正24在實(shí)際的開發(fā)過程中，獲取、分析、建模、編寫規(guī)約和驗(yàn)證這些需求開發(fā)活動(dòng)不會(huì)是線性地、順序地完成。實(shí)際上，這些活動(dòng)是交叉的、遞增的和反復(fù)的。在實(shí)際的開發(fā)過程中，獲取、分析、建模、編寫規(guī)約和驗(yàn)證這些需求25需求管理需求工程包括獲取、分析、規(guī)定、驗(yàn)證和管理軟件需求，而“軟件需求管理”則是對(duì)所有相關(guān)活動(dòng)的規(guī)劃和控制。換句話說，需求管理就是：一種獲取、組織并記錄系統(tǒng)需求的系統(tǒng)化方案，以及一個(gè)使用戶與項(xiàng)目團(tuán)隊(duì)對(duì)不斷變更的系統(tǒng)需求達(dá)成并保持一致的過程。需求管理需求工程包括獲取、分析、規(guī)定、驗(yàn)證和管理軟件需求，26接下來介紹可行性分析需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗(yàn)證需求管理接下來介紹可行性分析27軟件需求包括功能需求性能需求用戶或人的因素環(huán)境需求界面需求文檔需求數(shù)據(jù)需求資源使用需求安全保密要求可靠性需求軟件成本消耗與開發(fā)進(jìn)度需求其他非功能性要求軟件需求包括功能需求數(shù)據(jù)需求28需求獲取方法與策略建立順暢的通信途徑訪談與調(diào)查觀察用戶操作流程組成聯(lián)合小組用況（UseCase）需求獲取方法與策略建立順暢的通信途徑29建立順暢的通信途徑建立分析所需要的通信途徑，以保證能順利地對(duì)問題進(jìn)行分析。建立順暢的通信途徑建立分析所需要的通信途徑，以保證能順利地30訪談與調(diào)查在具體的實(shí)踐中，通常采用折衷的方法，即適當(dāng)?shù)赜?jì)劃好面談，但不要過于詳細(xì)，允許有一定的靈活性。一般按照如下原則進(jìn)行準(zhǔn)備：所提問的問題應(yīng)該循序漸進(jìn)，從整體的方面開始提問，接下來的問題應(yīng)有助于對(duì)前面的問題更好的理解和細(xì)化；不要限制用戶對(duì)問題的回答，這有可能會(huì)引出原先沒有注意的問題；提問和回答在匯總后應(yīng)能夠反映用戶需求的全貌。訪談與調(diào)查在具體的實(shí)踐中，通常采用折衷的方法，即適當(dāng)?shù)赜?jì)劃31例：“賽艇比賽成績(jī)計(jì)算系統(tǒng)”的第一次面談的準(zhǔn)備計(jì)劃初次與Dartchurch航行俱樂部的航行秘書（DR）接觸，面談?dòng)嘘P(guān)事宜。(在電話交談時(shí)，了解到他們希望得到的是一個(gè)“價(jià)廉”的，基于PC的系統(tǒng)，以用于計(jì)算賽艇比賽成績(jī))時(shí)間：2005-6-5地點(diǎn)：對(duì)方場(chǎng)地主要問題確定基本問題。確定DR的角色――還涉及其它人員嗎？調(diào)查財(cái)物方面事宜。系統(tǒng)（大致上）是如何運(yùn)作的？當(dāng)前存在的問題是什么？他們都希望做些什么？例：“賽艇比賽成績(jī)計(jì)算系統(tǒng)”的第一次面談的準(zhǔn)備計(jì)劃初次與D32觀察用戶操作流程到用戶的實(shí)際工作環(huán)境中對(duì)用戶的工作流程進(jìn)行觀察，了解用戶實(shí)際的操作環(huán)境、操作過程和操作要求，對(duì)照用戶提交的問題陳述，對(duì)用戶需求可以有更全面、更細(xì)致的認(rèn)識(shí)。觀察用戶操作流程到用戶的實(shí)際工作環(huán)境中對(duì)用戶的工作流程進(jìn)行33組成聯(lián)合小組便利的應(yīng)用規(guī)約技術(shù)(FacilitatedApplicationSpecificationTechniques,FAST)：打破用戶（需方）和開發(fā)者（供方）的界限，共同組成一個(gè)聯(lián)合小組，發(fā)揮各自的長(zhǎng)處，共同負(fù)責(zé)項(xiàng)目的推進(jìn)，這樣有助于發(fā)揮各自優(yōu)勢(shì)并增進(jìn)解和協(xié)調(diào)組成聯(lián)合小組便利的應(yīng)用規(guī)約技術(shù)(FacilitatedA34FAST基本原則在中立的地點(diǎn)舉行由開發(fā)者和用戶出席的會(huì)議；建立準(zhǔn)備和參與會(huì)議的規(guī)則；建議一個(gè)足夠正式的議程以便可以進(jìn)行自由的交流；一個(gè)“協(xié)調(diào)者”(他可以是用戶、開發(fā)者或其他外人)來控制會(huì)議；使用一種“定義機(jī)制”(它可以是工作表、圖表、墻上膠黏紙或墻板)；目標(biāo)是標(biāo)識(shí)問題、提出解決方案的要素、商議不同的方法、以及在有利于完成目標(biāo)的氛圍中刻畫出初步的需求。FAST基本原則在中立的地點(diǎn)舉行由開發(fā)者和用戶出席的會(huì)議；35FAST會(huì)議步驟1) 當(dāng)舉行了開發(fā)者和用戶之間的初步訪談后，確定一個(gè)FAST會(huì)議的時(shí)間地點(diǎn)，并在會(huì)議日之前將產(chǎn)品請(qǐng)求發(fā)布給所有的與會(huì)者。2) 要求每個(gè)FAST出席者會(huì)前列出一組圍繞系統(tǒng)環(huán)境的對(duì)象，以及對(duì)這些對(duì)象的操作或?qū)ο笾g的交互功能，并開發(fā)出約束列表(如，成本、規(guī)模大小、權(quán)重)和性能標(biāo)準(zhǔn)列表(如，速度、精度)。這些列表可以不是窮盡的，但是，希望每套列表反映的是每個(gè)人對(duì)系統(tǒng)的感覺。3) 進(jìn)行FAST會(huì)議時(shí)，當(dāng)團(tuán)隊(duì)的每個(gè)成員提出單個(gè)列表后，整個(gè)團(tuán)隊(duì)將創(chuàng)建一個(gè)組合的列表，該組合列表刪去冗余項(xiàng)，并加入在表達(dá)過程中出現(xiàn)的新思想。在建好所有主題的組合列表后，開始討論活動(dòng)?？s短、加長(zhǎng)或重新組合列表以適當(dāng)?shù)胤从硨⒈婚_發(fā)的產(chǎn)品。FAST會(huì)議步驟1) 當(dāng)舉行了開發(fā)者和用戶之間的初步訪談后36FAST會(huì)議步驟(續(xù))4) 一旦創(chuàng)建了意見一致的列表，應(yīng)該將團(tuán)隊(duì)分為更小的小組，每個(gè)小組力圖為每個(gè)列表中的一個(gè)或多個(gè)項(xiàng)開發(fā)出小型的規(guī)約（即對(duì)包含在列表中的單詞或短語的精細(xì)化）。每個(gè)小組然后將他們開發(fā)的每個(gè)小規(guī)約提交給所有的FAST出席者討論，進(jìn)行添加、刪除或進(jìn)一步的精化等工作。（在所有討論過程中，團(tuán)隊(duì)可能提出某些不能在會(huì)議過程中解決的問題，此時(shí)要保留問題列表以使這些思想在以后的活動(dòng)中產(chǎn)生作用。）5) 在小規(guī)約完成后，每個(gè)FAST的出席者提出一個(gè)針對(duì)產(chǎn)品的確切標(biāo)準(zhǔn)列表，并將該列表提交給團(tuán)隊(duì)，然后創(chuàng)建一個(gè)意見一致的確定的標(biāo)準(zhǔn)列表。這個(gè)列表作為需求獲取的結(jié)果，為需求分析和建模提供基礎(chǔ)信息。FAST會(huì)議步驟(續(xù))4) 一旦創(chuàng)建了意見一致的列表，應(yīng)37用況（UseCase）當(dāng)需求作為非正式會(huì)議、Fast的一部分而收集起來之后，分析員就可以創(chuàng)建一組標(biāo)識(shí)一串待建造系統(tǒng)的使用場(chǎng)景。創(chuàng)建用況模型的主要步驟如下：確定誰會(huì)直接使用該系統(tǒng)，即參與者（Actor）選取其中一個(gè)參與者定義該參與者希望系統(tǒng)做什么，參與者希望系統(tǒng)作的每件事將成為一個(gè)用況對(duì)每件事來說，何時(shí)參與者會(huì)使用系統(tǒng)，通常會(huì)發(fā)生什么，這就是用況的基本過程描述該用況的基本過程用況（UseCase）當(dāng)需求作為非正式會(huì)議、Fast的一38接下來介紹可行性分析需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗(yàn)證需求管理接下來介紹可行性分析39需求分析原則1．必須能夠表示和理解問題的信息域2．必須能夠定義軟件將完成的功能3．必須能夠表示軟件的行為(作為外部事件的結(jié)果)4．必須劃分描述數(shù)據(jù)、功能和行為的模型，從而可以分層次地揭示細(xì)節(jié)5．分析過程應(yīng)該從要素信息移向細(xì)節(jié)信息需求分析原則1．必須能夠表示和理解問題的信息域40為什么要引入信息域？所有的軟件應(yīng)用程序均可被稱為數(shù)據(jù)處理。如：工資系統(tǒng)的批處理軟件，開發(fā)控制汽車發(fā)動(dòng)機(jī)油流的實(shí)時(shí)嵌入式軟件。將數(shù)據(jù)從一種形式變換為另一種形式對(duì)事件的處理也不例外。例如，壓力傳感器檢測(cè)壓力是否超過安全值，并發(fā)送警報(bào)到監(jiān)控軟件，警報(bào)信號(hào)是一個(gè)事件，該事件控制系統(tǒng)的行為。因此，數(shù)據(jù)(數(shù)值、字符、圖象、聲音等)和控制(事件)二者均駐留于問題的信息域內(nèi)。為什么要引入信息域？所有的軟件應(yīng)用程序均可被稱為數(shù)據(jù)處理。如41信息域信息域：包括信息內(nèi)容、信息流、以及信息結(jié)構(gòu)。信息內(nèi)容表示了單個(gè)數(shù)據(jù)和控制對(duì)象，目標(biāo)軟件所有處理的信息集合由它們構(gòu)成。例如，數(shù)據(jù)對(duì)象“工資”是一組重要數(shù)據(jù)體的組合：領(lǐng)款人的姓名、凈付款數(shù)、付款總額、扣除額等等信息域信息域：包括信息內(nèi)容、信息流、以及信息結(jié)構(gòu)。42信息流表示了數(shù)據(jù)和控制在系統(tǒng)中流動(dòng)時(shí)的變化方式，輸入對(duì)象被變換為中間信息(數(shù)據(jù)和/或控制)，然后進(jìn)一步被變換為輸出信息結(jié)構(gòu)表示了各種數(shù)據(jù)和控制項(xiàng)的內(nèi)部組織數(shù)據(jù)或控制項(xiàng)將被組織為n維表還是樹形結(jié)構(gòu)？在結(jié)構(gòu)的語境內(nèi)，什么信息是和其他信息相關(guān)的？信息包含在單個(gè)結(jié)構(gòu)中，還是使用不同的結(jié)構(gòu)？在某信息結(jié)構(gòu)中的信息如何和在另一個(gè)結(jié)構(gòu)中的信息相關(guān)？信息域信息流表示了數(shù)據(jù)和控制在系統(tǒng)中流動(dòng)時(shí)的變化方式，輸入對(duì)象被變43抽象、分解與多視點(diǎn)分析問題抽象方法要求分析人員在分析過程中捕捉用戶描述或問題本身固有的一般-特殊關(guān)系首先關(guān)注一般問題的解決途徑，進(jìn)而指導(dǎo)特殊問題的解決方法。抽象、分解與多視點(diǎn)分析問題抽象方法要求分析人員在分析過程中44問題分解的目的是要能以層次化的方式對(duì)問題進(jìn)行分解和不斷細(xì)化。較大規(guī)?；蜉^為復(fù)雜的問題可以被分解為若干子問題進(jìn)行理解和分析分解可以逐級(jí)進(jìn)行，直至子問題被分解為一個(gè)容易分析理解的部分例如橫向分解縱向分解問題分解的目的是要能以層次化的方式對(duì)問題進(jìn)行分解和不斷細(xì)化。45需求協(xié)商協(xié)商的過程就是討論需求沖突，找出每個(gè)人都滿意的折衷方案協(xié)商不是簡(jiǎn)單的邏輯或技術(shù)上的爭(zhēng)論要注意組織和行政方面的因素①不一致的目標(biāo)②責(zé)任的喪失或轉(zhuǎn)移③組織文化④組織管理態(tài)度和士氣⑤部門差異需求協(xié)商協(xié)商的過程就是討論需求沖突，找出每個(gè)人都滿意的折衷46通常會(huì)議是解決沖突最快的方式參加者應(yīng)該包括發(fā)現(xiàn)沖突、遺漏或重疊的分析員，以及可以解決發(fā)現(xiàn)的問題的項(xiàng)目相關(guān)人員會(huì)議應(yīng)該討論那些非正式討論不能解決的問題通常會(huì)議分為三個(gè)階段：敘述階段討論階段決策階段通常會(huì)議是解決沖突最快的方式47需求建模在軟件需求分析階段，所創(chuàng)建的模型，要著重于描述系統(tǒng)要做什么，而不是如何去做目標(biāo)軟件的模型不應(yīng)涉及軟件實(shí)現(xiàn)細(xì)節(jié)需求建模在軟件需求分析階段，所創(chuàng)建的模型，要著重于描述系統(tǒng)48常用的分析方法：面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法(SA)面向數(shù)據(jù)結(jié)構(gòu)的分析方法面向?qū)ο蟮姆治龇椒?OOA)常用的分析方法：49接下來介紹可行性分析需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗(yàn)證需求管理接下來介紹可行性分析50需求規(guī)約的原則1．從現(xiàn)實(shí)中分離功能，即描述要“做什么”而不是“怎樣實(shí)現(xiàn)”。2．要求使用面向處理的規(guī)約語言（或稱系統(tǒng)定義語言），討論來自環(huán)境的各種刺激可能導(dǎo)致系統(tǒng)做出什么樣的功能性反應(yīng)，來定義一個(gè)行為模型，從而得到“做什么”的規(guī)約。3．如果被開發(fā)軟件只是一個(gè)基于計(jì)算機(jī)的系統(tǒng)中的一個(gè)元素，那么整個(gè)大系統(tǒng)也包括在規(guī)格說明的描述之中。4．規(guī)約必須包括系統(tǒng)運(yùn)行環(huán)境。需求規(guī)約的原則1．從現(xiàn)實(shí)中分離功能，即描述要“做什么”而不51需求規(guī)約的原則(續(xù))5．規(guī)約必須是一個(gè)認(rèn)識(shí)模型，而不是設(shè)計(jì)或?qū)崿F(xiàn)的模型。6．規(guī)約必須是可操作的，以便能夠利用它決定對(duì)于任意給定的測(cè)試用例，已提出的解決方案是否都能滿足規(guī)約。7．規(guī)約必須允許不完備性并允許擴(kuò)充。8．規(guī)約必須局部化和松散耦合。它所包括的信息必須局部化，這樣當(dāng)信息被修改時(shí)，只要修改某個(gè)單個(gè)的段落（理想情況）。同時(shí)，規(guī)約應(yīng)被松散地構(gòu)造（即松耦合），以便能夠很容易地加入和刪去一些段落。需求規(guī)約的原則(續(xù))5．規(guī)約必須是一個(gè)認(rèn)識(shí)模型，而不是設(shè)計(jì)52需求規(guī)約Ⅰ.引言A.系統(tǒng)參考文獻(xiàn)B.整體描述C.軟件項(xiàng)目約束Ⅱ.信息描述A.信息內(nèi)容表示B.信息流表示：ⅰ數(shù)據(jù)流ⅱ控制流Ⅲ.功能描述A.功能劃分B.功能描述：ⅰ處理說明ⅱ限制∕局限ⅲ性能需求ⅳ設(shè)計(jì)約束ⅴ支撐圖C.控制描述ⅰ控制規(guī)約ⅱ設(shè)計(jì)約束Ⅳ.行為描述A.系統(tǒng)狀態(tài)B.事件和響應(yīng)Ⅴ.檢驗(yàn)標(biāo)準(zhǔn)A.性能范圍B.測(cè)試種類C.期望的軟件響應(yīng)D.特殊的考慮Ⅵ.參考書目Ⅶ.附錄需求規(guī)約Ⅰ.引言A.系統(tǒng)參考文獻(xiàn)B.整體描述C.軟件項(xiàng)53引言陳述軟件目標(biāo)，在基于計(jì)算機(jī)的系統(tǒng)語境內(nèi)進(jìn)行描述。信息描述給出軟件必須解決問題的詳細(xì)描述，記錄信息內(nèi)容和關(guān)系、流和結(jié)構(gòu)。功能描述描述解決問題所需的每個(gè)功能。其中包括，為每個(gè)功能說明一個(gè)處理過程；敘述設(shè)計(jì)約束；敘述性能特征；用一個(gè)或多個(gè)圖形來形象地表示軟件的整體結(jié)構(gòu)和軟件功能與其他系統(tǒng)元素間的相互影響。需求規(guī)約引言需求規(guī)約54行為描述描述作為外部事件和內(nèi)部產(chǎn)生的控制特征的軟件操作。檢驗(yàn)標(biāo)準(zhǔn)描述檢驗(yàn)系統(tǒng)成功的標(biāo)志。即對(duì)系統(tǒng)進(jìn)行什么樣的測(cè)試，得到什么樣的結(jié)果，就表示系統(tǒng)已經(jīng)成功實(shí)現(xiàn)了。它是“確認(rèn)測(cè)試”的基礎(chǔ)。參考書目包含了對(duì)所有和該軟件相關(guān)的文檔的引用，其中包括其他的軟件工程文檔、技術(shù)參考文獻(xiàn)、廠商文獻(xiàn)以及標(biāo)準(zhǔn)。附錄包含了規(guī)約的補(bǔ)充信息，表格數(shù)據(jù)、算法的詳細(xì)描述、圖表以及其他材料。需求規(guī)約行為描述需求規(guī)約55需求描述我們的研究表明，家庭安全系統(tǒng)的市場(chǎng)正以每年40％的比率增長(zhǎng)，我們希望能進(jìn)入該市場(chǎng)，并試圖建造基于微處理器的家庭安全系統(tǒng)，該系統(tǒng)將保護(hù)和/或識(shí)別一系列出人意料之外的“情況”，如非法進(jìn)入、火警、水災(zāi)或其他。該產(chǎn)品，暫時(shí)稱為SafeHome，產(chǎn)品將使用合適的傳感器來檢測(cè)各種情況，具體使用時(shí)房主可按需要編程，并且當(dāng)系統(tǒng)檢測(cè)到情況時(shí)，會(huì)自動(dòng)地給監(jiān)控機(jī)構(gòu)撥打電話。需求描述我們的研究表明，家庭安全系統(tǒng)的市場(chǎng)正以每年40％的比56提出話題列表為SafeHome描述的對(duì)象可能包括：若干煙霧檢測(cè)器若干窗口和門傳感器若干運(yùn)動(dòng)檢測(cè)器一個(gè)警報(bào)器一個(gè)事件(啟動(dòng)某傳感器)一個(gè)控制模板一個(gè)顯示器一串電話號(hào)碼一次電話撥號(hào)等等。提出話題列表為SafeHome描述的對(duì)象可能包括：57提出話題列表服務(wù)的列表可能包括：設(shè)置警報(bào)器設(shè)置監(jiān)控傳感器電話撥號(hào)控制面板編程讀顯示器(注意，服務(wù)作用于對(duì)象)系統(tǒng)的制造成本必須低于200萬美元，界面必須是友好的，以及必須是和標(biāo)準(zhǔn)電話線接口)性能標(biāo)準(zhǔn)應(yīng)該在一秒鐘之內(nèi)識(shí)別傳感器事件應(yīng)該實(shí)現(xiàn)事件優(yōu)先級(jí)模式。

提出話題列表服務(wù)的列表可能包括：58產(chǎn)生小規(guī)約SafeHome中的對(duì)象“控制面板”的小規(guī)約可能是：安裝在墻紙上。大小大約為9×5英寸。包含標(biāo)準(zhǔn)的12鍵鍵盤和特殊鍵。包含LCD顯示，操作如草圖所示(未在此給出)。所有的客戶交互通過鍵盤發(fā)生，鍵盤被用于啟動(dòng)或關(guān)閉系統(tǒng)。連接提供交互指南、回顯等的軟件到所有的傳感器。產(chǎn)生小規(guī)約SafeHome中的對(duì)象“控制面板”的小規(guī)約可能是59撰寫完整規(guī)約在小規(guī)約完成后，每個(gè)FAST的出席者提出一個(gè)針對(duì)產(chǎn)品/系統(tǒng)的確切標(biāo)準(zhǔn)列表將該列表提交給團(tuán)隊(duì)創(chuàng)建一個(gè)意見一致的確定標(biāo)準(zhǔn)列表一個(gè)或多個(gè)參與者(或外來者)被賦予撰寫完整的規(guī)約草案的任務(wù)(用來自FAST會(huì)議的結(jié)果為輸入)。撰寫完整規(guī)約在小規(guī)約完成后，每個(gè)FAST的出席者提出一個(gè)針對(duì)60需求工程的指導(dǎo)性原則在開始建立分析模型前先理解問題。開發(fā)原型，使得用戶能夠了解將如何發(fā)生人機(jī)交互。記錄每個(gè)需求的起源及原因。使用多個(gè)需求視圖。給需求賦予優(yōu)先級(jí)。努力刪除含糊性。需求工程的指導(dǎo)性原則在開始建立分析模型前先理解問題。61需求驗(yàn)證需求驗(yàn)證目的是要檢驗(yàn)需求是否能夠反映用戶的意愿需求驗(yàn)證需求驗(yàn)證目的是要檢驗(yàn)需求是否能夠反映用戶的意愿62需求驗(yàn)證評(píng)審人員評(píng)審時(shí)往往需要檢查以下內(nèi)容：系統(tǒng)定義的目標(biāo)是否與用戶的要求一致；系統(tǒng)需求分析階段提供的文檔資料是否齊全；文檔中的描述是否完整、清晰、準(zhǔn)確地反映了用戶要求；被開發(fā)項(xiàng)目的數(shù)據(jù)流與數(shù)據(jù)結(jié)構(gòu)是否確定且充足；主要功能是否已包括在規(guī)定的軟件范圍之內(nèi)，是否都已充分說明；設(shè)計(jì)的約束條件或限制條件是否符合實(shí)際；開發(fā)的技術(shù)風(fēng)險(xiǎn)是什么；是否詳細(xì)制定了檢驗(yàn)標(biāo)準(zhǔn)，它們能否對(duì)系統(tǒng)定義是否成功進(jìn)行確認(rèn)。

需求驗(yàn)證評(píng)審人員評(píng)審時(shí)往往需要檢查以下內(nèi)容：63接下來介紹可行性分析需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗(yàn)證需求管理接下來介紹可行性分析64需求管理需求管理是一組用于幫助項(xiàng)目組在項(xiàng)目進(jìn)展中的任何時(shí)候去標(biāo)識(shí)、控制和跟蹤需求的活動(dòng)需求跟蹤有兩種方式，正向跟蹤與逆向跟蹤正向跟蹤：以用戶需求為切入點(diǎn)，檢查《需求規(guī)約》中的每個(gè)需求是否都能在后繼工作產(chǎn)品中找到對(duì)應(yīng)點(diǎn)逆向跟蹤：檢查設(shè)計(jì)文檔、代碼、測(cè)試用況等工作產(chǎn)品是否都能在《需求規(guī)約》中找到出處需求管理需求管理是一組用于幫助項(xiàng)目組在項(xiàng)目進(jìn)展中的任何時(shí)候去65作業(yè)教材45頁(yè)，第3題教材61頁(yè)：2、8、9（第一問）作業(yè)教材45頁(yè)，第3題66ThankYou!ThankYou!67制作者程麗軟件工程第二章需求工程制作者程麗軟件工程第二章需求工程68本章介紹以下內(nèi)容可行性分析需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗(yàn)證需求管理本章介紹以下內(nèi)容可行性分析69課程的任務(wù)、目的和基本要求掌握可行性分析的方法掌握需求工程的定義及六個(gè)階段掌握軟件需求內(nèi)容掌握需求獲取的方法與策略掌握需求分析原則掌握需求規(guī)約的原則掌握需求規(guī)約的內(nèi)容了解需求驗(yàn)證過程了解需求管理相關(guān)概念

課程的任務(wù)、目的和基本要求掌握可行性分析的方法70接下來介紹可行性分析需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗(yàn)證需求管理接下來介紹可行性分析71可行性研究的任務(wù)可行性研究的具體步驟系統(tǒng)流程圖成本－效益分析方案的選擇和折衷可行性分析的結(jié)論可行性研究的文檔可行性分析可行性研究的任務(wù)可行性分析72提出問題

→有無解決的辦法

→是否值得去做可行性研究的目的提出問題可行性研究的目的73可行性研究的任務(wù)技術(shù)可行性確定技術(shù)風(fēng)險(xiǎn)，項(xiàng)目實(shí)現(xiàn)的可能性經(jīng)濟(jì)可行性考慮投入—產(chǎn)出，市場(chǎng)前景，經(jīng)營(yíng)策略社會(huì)可行性考慮合同、責(zé)任、侵權(quán)、用戶組織的管理模式及規(guī)范問題可行性研究的任務(wù)技術(shù)可行性74可行性研究的步驟確定項(xiàng)目規(guī)模和目標(biāo)研究正在運(yùn)行的系統(tǒng)－系統(tǒng)流程圖建立新系統(tǒng)的高層邏輯模型－簡(jiǎn)單數(shù)據(jù)流圖導(dǎo)出和評(píng)價(jià)各種方案推薦可行的方案編寫可行性研究報(bào)告，交使用部門審查可行性研究的步驟確定項(xiàng)目規(guī)模和目標(biāo)75用圖形符號(hào)描述項(xiàng)目處理流程、范圍和功能

處理輸入/輸出連接換頁(yè)連接數(shù)據(jù)流文檔聯(lián)機(jī)存儲(chǔ)磁盤顯示人工輸入人工操作輔助操作通信鏈路系統(tǒng)流程圖用圖形符號(hào)描述項(xiàng)目處理流程、范圍和功能系統(tǒng)流程圖76工資處理過程：每月末教師把他們當(dāng)月實(shí)際授課時(shí)數(shù)登記在課時(shí)表上，由各系匯總后交給財(cái)務(wù)科。職工把他們當(dāng)月完成承包任務(wù)的情況登記在任務(wù)表上，匯總后交給財(cái)務(wù)科。會(huì)計(jì)根據(jù)這些原始數(shù)據(jù)計(jì)算每名教職工的工資，編制工資表、工資明細(xì)表。然后，把記有每名教職工工資總額的工資表報(bào)送銀行，由銀行把錢打到每名教職工的工資存折上，同時(shí)把工資明細(xì)表發(fā)給每名教職工。例子：人工系統(tǒng)計(jì)算工資和編制報(bào)表工資處理過程：例子：人工系統(tǒng)計(jì)算工資和編制報(bào)表77教師課時(shí)表任務(wù)表職工工資支付系統(tǒng)工資表工資明細(xì)表銀行教師職工教師課時(shí)表任務(wù)表職工工資支付系統(tǒng)工資表工資明細(xì)表銀行教師職工78成本效益分析效益表現(xiàn)有形效益：無形效益：貨幣的時(shí)間價(jià)值、投資回收期、純收入從性質(zhì)上、心理上進(jìn)行衡量成本效益分析效益表現(xiàn)有形效益：無形效益：貨幣的時(shí)間價(jià)值、投資79貨幣的時(shí)間價(jià)值

F=P*(1+n*i)(不計(jì)復(fù)利)P=F/(1+n*i)i----利率

P---現(xiàn)在值（元）

n----年數(shù)

F---將來值（元）成本效益分析貨幣的時(shí)間價(jià)值成本效益分析80成本效益分析投資回收期使累計(jì)的經(jīng)濟(jì)效益等于最初投資費(fèi)用所需的時(shí)間投資回收期越短，就越快獲得利潤(rùn)純收入整個(gè)生存周期之內(nèi)的累計(jì)經(jīng)濟(jì)效益（折合成現(xiàn)在值）與投資之差成本效益分析投資回收期81一個(gè)系統(tǒng)可以有多個(gè)可行的實(shí)現(xiàn)方案，每個(gè)方案對(duì)成本、時(shí)間、人員、技術(shù)、設(shè)備都有不同的要求，不同方案開發(fā)出來的系統(tǒng)在功能、性能方面也會(huì)有所不同。因此要在多個(gè)可行的實(shí)現(xiàn)方案中作出選擇。由于系統(tǒng)的功能和性能受到多種因素的影響，某些因素之間相互關(guān)聯(lián)和制約。如，為達(dá)到高的精度就可能導(dǎo)致長(zhǎng)的執(zhí)行時(shí)間，為達(dá)到高可靠性就會(huì)導(dǎo)致高的成本等等。因此，在必要時(shí)應(yīng)進(jìn)行折衷。方案的選擇和折衷一個(gè)系統(tǒng)可以有多個(gè)可行的實(shí)現(xiàn)方案，每個(gè)方案對(duì)成本、時(shí)間、人員82可行性分析的結(jié)論可以立即開始進(jìn)行需要推遲到某些條件（例如資金、人力、設(shè)備等）落實(shí)之后才能開始進(jìn)行需要對(duì)開發(fā)目標(biāo)進(jìn)行某些修改之后才能開始進(jìn)行因?yàn)槟撤N原因（如，技術(shù)不成熟、經(jīng)濟(jì)上不合算等）不能進(jìn)行可行性分析的結(jié)論可以立即開始進(jìn)行83可行性研究的文檔在可行性研究后提交的文檔，包括引言可行性研究前提對(duì)現(xiàn)有系統(tǒng)的分析所建議的系統(tǒng)可選擇的其它系統(tǒng)方案投資及效益分析社會(huì)因素方面的可行性分析結(jié)論可行性研究的文檔在可行性研究后提交的文檔，包括84接下來介紹可行性分析需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗(yàn)證需求管理接下來介紹可行性分析85軟件需求工程細(xì)分為需求獲取需求分析與協(xié)商系統(tǒng)建模需求規(guī)約需求驗(yàn)證需求管理需求工程軟件需求工程細(xì)分為需求工程86需求獲取系統(tǒng)分析人員與用戶交流，對(duì)現(xiàn)有系統(tǒng)觀察，對(duì)任務(wù)進(jìn)行分析，確定系統(tǒng)或產(chǎn)品的范圍，與系統(tǒng)或產(chǎn)品有關(guān)的人員及特征，系統(tǒng)的技術(shù)環(huán)境，系統(tǒng)功能，應(yīng)用于每個(gè)需求的領(lǐng)域限制，一組描述不同運(yùn)行條件下系統(tǒng)或產(chǎn)品使用狀況的應(yīng)用場(chǎng)景。需求獲取系統(tǒng)分析人員與用戶交流，對(duì)現(xiàn)有系統(tǒng)觀察，對(duì)任務(wù)進(jìn)行87需求分析與協(xié)商

需求獲取結(jié)束后，分析活動(dòng)對(duì)需求進(jìn)行分類組織，分析每個(gè)需求與其它需求的關(guān)系，檢查需求的一致性、重疊和遺漏的情況，并根據(jù)用戶的需要對(duì)需求進(jìn)行排序。在需求獲取階段，經(jīng)常出現(xiàn)以下問題：用戶提出的要求超出軟件系統(tǒng)可以實(shí)現(xiàn)的范圍或?qū)崿F(xiàn)能力；不同的用戶提出了相互沖突的需求需求分析與協(xié)商需求獲取結(jié)束后，分析活動(dòng)對(duì)需求進(jìn)行分類組織，88系統(tǒng)建模建模工具的使用在用戶和系統(tǒng)分析人員之間建立了統(tǒng)一的語言和理解的橋梁，同時(shí)系統(tǒng)分析人員借助建模技術(shù)對(duì)獲取的需求信息進(jìn)行分析，排除錯(cuò)誤和彌補(bǔ)不足，確保需求文檔正確反映用戶的真實(shí)意圖。常用的分析和建模方法有面向數(shù)據(jù)流方法、面向數(shù)據(jù)結(jié)構(gòu)方法和面向?qū)ο蟮姆椒āＯ到y(tǒng)建模建模工具的使用在用戶和系統(tǒng)分析人員之間建立了統(tǒng)一的89需求規(guī)約軟件需求規(guī)約是分析任務(wù)的最終產(chǎn)物，通過建立完整的信息描述、詳細(xì)的功能和行為描述、性能需求和設(shè)計(jì)約束的說明、合適的驗(yàn)收標(biāo)準(zhǔn)，給出對(duì)目標(biāo)軟件的各種需求。需求規(guī)約作為用戶和開發(fā)者之間的一個(gè)協(xié)議，在之后的軟件工程各個(gè)階段發(fā)揮重要作用。需求規(guī)約軟件需求規(guī)約是分析任務(wù)的最終產(chǎn)物，通過建立完整的信90需求驗(yàn)證作為需求開發(fā)階段工作的復(fù)查手段，需求驗(yàn)證對(duì)功能的正確性、完整性和清晰性，以及其它需求給予評(píng)價(jià)。為保證軟件需求定義的質(zhì)量，評(píng)審應(yīng)以專門指定的人員負(fù)責(zé)，并按規(guī)程嚴(yán)格進(jìn)行。需求驗(yàn)證作為需求開發(fā)階段工作的復(fù)查手段，需求驗(yàn)證對(duì)功能的正91在實(shí)際的開發(fā)過程中，獲取、分析、建模、編寫規(guī)約和驗(yàn)證這些需求開發(fā)活動(dòng)不會(huì)是線性地、順序地完成。實(shí)際上，這些活動(dòng)是交叉的、遞增的和反復(fù)的。在實(shí)際的開發(fā)過程中，獲取、分析、建模、編寫規(guī)約和驗(yàn)證這些需求92需求管理需求工程包括獲取、分析、規(guī)定、驗(yàn)證和管理軟件需求，而“軟件需求管理”則是對(duì)所有相關(guān)活動(dòng)的規(guī)劃和控制。換句話說，需求管理就是：一種獲取、組織并記錄系統(tǒng)需求的系統(tǒng)化方案，以及一個(gè)使用戶與項(xiàng)目團(tuán)隊(duì)對(duì)不斷變更的系統(tǒng)需求達(dá)成并保持一致的過程。需求管理需求工程包括獲取、分析、規(guī)定、驗(yàn)證和管理軟件需求，93接下來介紹可行性分析需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗(yàn)證需求管理接下來介紹可行性分析94軟件需求包括功能需求性能需求用戶或人的因素環(huán)境需求界面需求文檔需求數(shù)據(jù)需求資源使用需求安全保密要求可靠性需求軟件成本消耗與開發(fā)進(jìn)度需求其他非功能性要求軟件需求包括功能需求數(shù)據(jù)需求95需求獲取方法與策略建立順暢的通信途徑訪談與調(diào)查觀察用戶操作流程組成聯(lián)合小組用況（UseCase）需求獲取方法與策略建立順暢的通信途徑96建立順暢的通信途徑建立分析所需要的通信途徑，以保證能順利地對(duì)問題進(jìn)行分析。建立順暢的通信途徑建立分析所需要的通信途徑，以保證能順利地97訪談與調(diào)查在具體的實(shí)踐中，通常采用折衷的方法，即適當(dāng)?shù)赜?jì)劃好面談，但不要過于詳細(xì)，允許有一定的靈活性。一般按照如下原則進(jìn)行準(zhǔn)備：所提問的問題應(yīng)該循序漸進(jìn)，從整體的方面開始提問，接下來的問題應(yīng)有助于對(duì)前面的問題更好的理解和細(xì)化；不要限制用戶對(duì)問題的回答，這有可能會(huì)引出原先沒有注意的問題；提問和回答在匯總后應(yīng)能夠反映用戶需求的全貌。訪談與調(diào)查在具體的實(shí)踐中，通常采用折衷的方法，即適當(dāng)?shù)赜?jì)劃98例：“賽艇比賽成績(jī)計(jì)算系統(tǒng)”的第一次面談的準(zhǔn)備計(jì)劃初次與Dartchurch航行俱樂部的航行秘書（DR）接觸，面談?dòng)嘘P(guān)事宜。(在電話交談時(shí)，了解到他們希望得到的是一個(gè)“價(jià)廉”的，基于PC的系統(tǒng)，以用于計(jì)算賽艇比賽成績(jī))時(shí)間：2005-6-5地點(diǎn)：對(duì)方場(chǎng)地主要問題確定基本問題。確定DR的角色――還涉及其它人員嗎？調(diào)查財(cái)物方面事宜。系統(tǒng)（大致上）是如何運(yùn)作的？當(dāng)前存在的問題是什么？他們都希望做些什么？例：“賽艇比賽成績(jī)計(jì)算系統(tǒng)”的第一次面談的準(zhǔn)備計(jì)劃初次與D99觀察用戶操作流程到用戶的實(shí)際工作環(huán)境中對(duì)用戶的工作流程進(jìn)行觀察，了解用戶實(shí)際的操作環(huán)境、操作過程和操作要求，對(duì)照用戶提交的問題陳述，對(duì)用戶需求可以有更全面、更細(xì)致的認(rèn)識(shí)。觀察用戶操作流程到用戶的實(shí)際工作環(huán)境中對(duì)用戶的工作流程進(jìn)行100組成聯(lián)合小組便利的應(yīng)用規(guī)約技術(shù)(FacilitatedApplicationSpecificationTechniques,FAST)：打破用戶（需方）和開發(fā)者（供方）的界限，共同組成一個(gè)聯(lián)合小組，發(fā)揮各自的長(zhǎng)處，共同負(fù)責(zé)項(xiàng)目的推進(jìn)，這樣有助于發(fā)揮各自優(yōu)勢(shì)并增進(jìn)解和協(xié)調(diào)組成聯(lián)合小組便利的應(yīng)用規(guī)約技術(shù)(FacilitatedA101FAST基本原則在中立的地點(diǎn)舉行由開發(fā)者和用戶出席的會(huì)議；建立準(zhǔn)備和參與會(huì)議的規(guī)則；建議一個(gè)足夠正式的議程以便可以進(jìn)行自由的交流；一個(gè)“協(xié)調(diào)者”(他可以是用戶、開發(fā)者或其他外人)來控制會(huì)議；使用一種“定義機(jī)制”(它可以是工作表、圖表、墻上膠黏紙或墻板)；目標(biāo)是標(biāo)識(shí)問題、提出解決方案的要素、商議不同的方法、以及在有利于完成目標(biāo)的氛圍中刻畫出初步的需求。FAST基本原則在中立的地點(diǎn)舉行由開發(fā)者和用戶出席的會(huì)議；102FAST會(huì)議步驟1) 當(dāng)舉行了開發(fā)者和用戶之間的初步訪談后，確定一個(gè)FAST會(huì)議的時(shí)間地點(diǎn)，并在會(huì)議日之前將產(chǎn)品請(qǐng)求發(fā)布給所有的與會(huì)者。2) 要求每個(gè)FAST出席者會(huì)前列出一組圍繞系統(tǒng)環(huán)境的對(duì)象，以及對(duì)這些對(duì)象的操作或?qū)ο笾g的交互功能，并開發(fā)出約束列表(如，成本、規(guī)模大小、權(quán)重)和性能標(biāo)準(zhǔn)列表(如，速度、精度)。這些列表可以不是窮盡的，但是，希望每套列表反映的是每個(gè)人對(duì)系統(tǒng)的感覺。3) 進(jìn)行FAST會(huì)議時(shí)，當(dāng)團(tuán)隊(duì)的每個(gè)成員提出單個(gè)列表后，整個(gè)團(tuán)隊(duì)將創(chuàng)建一個(gè)組合的列表，該組合列表刪去冗余項(xiàng)，并加入在表達(dá)過程中出現(xiàn)的新思想。在建好所有主題的組合列表后，開始討論活動(dòng)?？s短、加長(zhǎng)或重新組合列表以適當(dāng)?shù)胤从硨⒈婚_發(fā)的產(chǎn)品。FAST會(huì)議步驟1) 當(dāng)舉行了開發(fā)者和用戶之間的初步訪談后103FAST會(huì)議步驟(續(xù))4) 一旦創(chuàng)建了意見一致的列表，應(yīng)該將團(tuán)隊(duì)分為更小的小組，每個(gè)小組力圖為每個(gè)列表中的一個(gè)或多個(gè)項(xiàng)開發(fā)出小型的規(guī)約（即對(duì)包含在列表中的單詞或短語的精細(xì)化）。每個(gè)小組然后將他們開發(fā)的每個(gè)小規(guī)約提交給所有的FAST出席者討論，進(jìn)行添加、刪除或進(jìn)一步的精化等工作。（在所有討論過程中，團(tuán)隊(duì)可能提出某些不能在會(huì)議過程中解決的問題，此時(shí)要保留問題列表以使這些思想在以后的活動(dòng)中產(chǎn)生作用。）5) 在小規(guī)約完成后，每個(gè)FAST的出席者提出一個(gè)針對(duì)產(chǎn)品的確切標(biāo)準(zhǔn)列表，并將該列表提交給團(tuán)隊(duì)，然后創(chuàng)建一個(gè)意見一致的確定的標(biāo)準(zhǔn)列表。這個(gè)列表作為需求獲取的結(jié)果，為需求分析和建模提供基礎(chǔ)信息。FAST會(huì)議步驟(續(xù))4) 一旦創(chuàng)建了意見一致的列表，應(yīng)104用況（UseCase）當(dāng)需求作為非正式會(huì)議、Fast的一部分而收集起來之后，分析員就可以創(chuàng)建一組標(biāo)識(shí)一串待建造系統(tǒng)的使用場(chǎng)景。創(chuàng)建用況模型的主要步驟如下：確定誰會(huì)直接使用該系統(tǒng)，即參與者（Actor）選取其中一個(gè)參與者定義該參與者希望系統(tǒng)做什么，參與者希望系統(tǒng)作的每件事將成為一個(gè)用況對(duì)每件事來說，何時(shí)參與者會(huì)使用系統(tǒng)，通常會(huì)發(fā)生什么，這就是用況的基本過程描述該用況的基本過程用況（UseCase）當(dāng)需求作為非正式會(huì)議、Fast的一105接下來介紹可行性分析需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗(yàn)證需求管理接下來介紹可行性分析106需求分析原則1．必須能夠表示和理解問題的信息域2．必須能夠定義軟件將完成的功能3．必須能夠表示軟件的行為(作為外部事件的結(jié)果)4．必須劃分描述數(shù)據(jù)、功能和行為的模型，從而可以分層次地揭示細(xì)節(jié)5．分析過程應(yīng)該從要素信息移向細(xì)節(jié)信息需求分析原則1．必須能夠表示和理解問題的信息域107為什么要引入信息域？所有的軟件應(yīng)用程序均可被稱為數(shù)據(jù)處理。如：工資系統(tǒng)的批處理軟件，開發(fā)控制汽車發(fā)動(dòng)機(jī)油流的實(shí)時(shí)嵌入式軟件。將數(shù)據(jù)從一種形式變換為另一種形式對(duì)事件的處理也不例外。例如，壓力傳感器檢測(cè)壓力是否超過安全值，并發(fā)送警報(bào)到監(jiān)控軟件，警報(bào)信號(hào)是一個(gè)事件，該事件控制系統(tǒng)的行為。因此，數(shù)據(jù)(數(shù)值、字符、圖象、聲音等)和控制(事件)二者均駐留于問題的信息域內(nèi)。為什么要引入信息域？所有的軟件應(yīng)用程序均可被稱為數(shù)據(jù)處理。如108信息域信息域：包括信息內(nèi)容、信息流、以及信息結(jié)構(gòu)。信息內(nèi)容表示了單個(gè)數(shù)據(jù)和控制對(duì)象，目標(biāo)軟件所有處理的信息集合由它們構(gòu)成。例如，數(shù)據(jù)對(duì)象“工資”是一組重要數(shù)據(jù)體的組合：領(lǐng)款人的姓名、凈付款數(shù)、付款總額、扣除額等等信息域信息域：包括信息內(nèi)容、信息流、以及信息結(jié)構(gòu)。109信息流表示了數(shù)據(jù)和控制在系統(tǒng)中流動(dòng)時(shí)的變化方式，輸入對(duì)象被變換為中間信息(數(shù)據(jù)和/或控制)，然后進(jìn)一步被變換為輸出信息結(jié)構(gòu)表示了各種數(shù)據(jù)和控制項(xiàng)的內(nèi)部組織數(shù)據(jù)或控制項(xiàng)將被組織為n維表還是樹形結(jié)構(gòu)？在結(jié)構(gòu)的語境內(nèi)，什么信息是和其他信息相關(guān)的？信息包含在單個(gè)結(jié)構(gòu)中，還是使用不同的結(jié)構(gòu)？在某信息結(jié)構(gòu)中的信息如何和在另一個(gè)結(jié)構(gòu)中的信息相關(guān)？信息域信息流表示了數(shù)據(jù)和控制在系統(tǒng)中流動(dòng)時(shí)的變化方式，輸入對(duì)象被變110抽象、分解與多視點(diǎn)分析問題抽象方法要求分析人員在分析過程中捕捉用戶描述或問題本身固有的一般-特殊關(guān)系首先關(guān)注一般問題的解決途徑，進(jìn)而指導(dǎo)特殊問題的解決方法。抽象、分解與多視點(diǎn)分析問題抽象方法要求分析人員在分析過程中111問題分解的目的是要能以層次化的方式對(duì)問題進(jìn)行分解和不斷細(xì)化。較大規(guī)模或較為復(fù)雜的問題可以被分解為若干子問題進(jìn)行理解和分析分解可以逐級(jí)進(jìn)行，直至子問題被分解為一個(gè)容易分析理解的部分例如橫向分解縱向分解問題分解的目的是要能以層次化的方式對(duì)問題進(jìn)行分解和不斷細(xì)化。112需求協(xié)商協(xié)商的過程就是討論需求沖突，找出每個(gè)人都滿意的折衷方案協(xié)商不是簡(jiǎn)單的邏輯或技術(shù)上的爭(zhēng)論要注意組織和行政方面的因素①不一致的目標(biāo)②責(zé)任的喪失或轉(zhuǎn)移③組織文化④組織管理態(tài)度和士氣⑤部門差異需求協(xié)商協(xié)商的過程就是討論需求沖突，找出每個(gè)人都滿意的折衷113通常會(huì)議是解決沖突最快的方式參加者應(yīng)該包括發(fā)現(xiàn)沖突、遺漏或重疊的分析員，以及可以解決發(fā)現(xiàn)的問題的項(xiàng)目相關(guān)人員會(huì)議應(yīng)該討論那些非正式討論不能解決的問題通常會(huì)議分為三個(gè)階段：敘述階段討論階段決策階段通常會(huì)議是解決沖突最快的方式114需求建模在軟件需求分析階段，所創(chuàng)建的模型，要著重于描述系統(tǒng)要做什么，而不是如何去做目標(biāo)軟件的模型不應(yīng)涉及軟件實(shí)現(xiàn)細(xì)節(jié)需求建模在軟件需求分析階段，所創(chuàng)建的模型，要著重于描述系統(tǒng)115常用的分析方法：面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法(SA)面向數(shù)據(jù)結(jié)構(gòu)的分析方法面向?qū)ο蟮姆治龇椒?OOA)常用的分析方法：116接下來介紹可行性分析需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗(yàn)證需求管理接下來介紹可行性分析117需求規(guī)約的原則1．從現(xiàn)實(shí)中分離功能，即描述要“做什么”而不是“怎樣實(shí)現(xiàn)”。2．要求使用面向處理的規(guī)約語言（或稱系統(tǒng)定義語言），討論來自環(huán)境的各種刺激可能導(dǎo)致系統(tǒng)做出什么樣的功能性反應(yīng)，來定義一個(gè)行為模型，從而得到“做什么”的規(guī)約。3．如果被開發(fā)軟件只是一個(gè)基于計(jì)算機(jī)的系統(tǒng)中的一個(gè)元素，那么整個(gè)大系統(tǒng)也包括在規(guī)格說明的描述之中。4．規(guī)約必須包括系統(tǒng)運(yùn)行環(huán)境。需求規(guī)約的原則1．從現(xiàn)實(shí)中分離功能，即描述要“做什么”而不118需求規(guī)約的原則(續(xù))5．規(guī)約必須是一個(gè)認(rèn)識(shí)模型，而不是設(shè)計(jì)或?qū)崿F(xiàn)的模型。6．規(guī)約必須是可操作的，以便能夠利用它決定對(duì)于任意給定的測(cè)試用例，已提出的解決方案是否都能滿足規(guī)約。7．規(guī)約必須允許不完備性并允許擴(kuò)充。8．規(guī)約必須局部化和松散耦合。它所包括的信息必須局部化，這樣當(dāng)信息被修改時(shí)，只要修改某個(gè)單個(gè)的段落（理想情況）。同時(shí)，規(guī)約應(yīng)被松散地構(gòu)造（即松耦合），以便能夠很容易地加入和刪去一些段落。需求規(guī)約的原則(續(xù))5．規(guī)約必須是一個(gè)認(rèn)識(shí)模型，而不是設(shè)計(jì)119需求規(guī)約Ⅰ.引言A.系統(tǒng)參考文獻(xiàn)B.整體描述C.軟件項(xiàng)目約束Ⅱ.信息描述A.信息內(nèi)容表示B.信息流表示：ⅰ數(shù)據(jù)流ⅱ控制流Ⅲ.功能描述A.功能劃分B.功能描述：ⅰ處理說明ⅱ限制∕局限ⅲ性能需求ⅳ設(shè)計(jì)約束ⅴ支撐圖C.控制描述ⅰ控制規(guī)約ⅱ設(shè)計(jì)約束Ⅳ.行為描述A.系統(tǒng)狀態(tài)B.事件和響應(yīng)Ⅴ.檢驗(yàn)標(biāo)準(zhǔn)A.性能范圍B.測(cè)試種類C.期望的軟件響應(yīng)D.特殊的考慮Ⅵ.參考書目Ⅶ.附錄需求規(guī)約Ⅰ.引言A.系統(tǒng)參考文獻(xiàn)B.整體描述C.軟件項(xiàng)120引言陳述軟件目標(biāo)，在基于計(jì)算機(jī)的系統(tǒng)語境內(nèi)進(jìn)行描述。信息描述給出