軟件需求重點(diǎn)

2023/2/11Chapter1TheEssentialSoftwareRequirement

Instructor:ZhangyiEmail:SR_homework@163.com2023/2/12需求分析就是分析軟件用戶的需求是什么.如果投入大量的人力，物力,財(cái)力,時(shí)間,開(kāi)發(fā)出的軟件卻沒(méi)人要,那所有的投入都是徒勞.如果費(fèi)了很大的精力,開(kāi)發(fā)一個(gè)軟件,最后卻不滿足用戶的要求,從而要重新開(kāi)發(fā)過(guò)。這種返工是讓人痛心疾首的.——相信大家都有體會(huì)1.為什么要需求分析2023/2/13需求分析之所以重要,就因?yàn)椋核哂袥Q策性,方向性,策略性的作用,它在軟件開(kāi)發(fā)的過(guò)程中，具有舉足輕重的地位.在一個(gè)大型軟件系統(tǒng)的開(kāi)發(fā)中,它的作用要遠(yuǎn)遠(yuǎn)大于程序設(shè)計(jì).因此，一定要對(duì)需求分析具有足夠的重視.1.為什么要需求分析2023/2/14需求分析的任務(wù)就是——解決“做什么”的問(wèn)題,就是要全面地理解用戶的各項(xiàng)要求。并準(zhǔn)確地表達(dá)所接受的用戶需求.2.需求分析的任務(wù)2023/2/15需求分析階段的工作,可以分為四個(gè)方面:問(wèn)題識(shí)別分析與綜合制訂規(guī)格說(shuō)明評(píng)審.3.需求分析的過(guò)程2023/2/16需求工程需求開(kāi)發(fā)需求管理獲取分析編寫(xiě)規(guī)約確認(rèn)軟件需求工程的組成：2023/2/17簡(jiǎn)言之就是——分析軟件用戶的需求,細(xì)致的進(jìn)行、調(diào)查,把用戶“做什么”的要求，最終轉(zhuǎn)換為一個(gè)完全的、精細(xì)的軟件邏輯模型。并寫(xiě)出軟件的需求規(guī)格說(shuō)明。準(zhǔn)確地表達(dá)用戶的要求.什么是需求分析？2023/2/181.1.2LevelsofRequirementsBusinessrequirementsUserrequirementsFunctionalrequirements(nonfunctional)2023/2/191.2.2RequirementsManagementRequirementsManagement變更控制建議變更分析影響作出決策交流合并測(cè)量需求的穩(wěn)定性版本控制確定需求文檔版本確定單個(gè)需求文檔版本需求跟蹤定義對(duì)其它需求的連接鏈定義對(duì)其它系統(tǒng)元素的連接需求狀態(tài)跟蹤定義需求狀態(tài)跟蹤需求每一個(gè)狀態(tài)2023/2/1101.4優(yōu)秀的團(tuán)隊(duì)遇到糟糕的需求常見(jiàn)的與需求相關(guān)的風(fēng)險(xiǎn)：用戶參與不足用戶需求擴(kuò)展有歧義的需求鍍金問(wèn)題過(guò)于抽象的需求忽略了某類用戶不準(zhǔn)確的計(jì)劃2023/2/1111.6CharacteristicsofExcellentRequirementsRequirementStatementCharacteristicsRequirementsSpecificationCharacteristics2023/2/1121.6.1RequirementStatementCharacteristicsComplete

Correct

Feasible

Necessary

Prioritized

Unambiguous

Verifiable2023/2/1131.6.2RequirementsSpecificationCharacteristicsComplete

Consistent

Modifiable

——變化是永恒的，不變是不存在的。

Traceable

2023/2/114Chapter2RequirementsfromtheCustomer’sPerspective

Instructor:ZhangyiEmail:SR_homework@163.com2023/2/115WhoIstheCustomer?Acustomer:

isanindividualororganizationwhoderiveseitherdirectorindirectbenefitfromaproduct.

2023/2/116了解客戶、最終用戶、間接用戶1.基本概念“用戶”是一種泛稱，它可細(xì)分為:“客戶”（customer）

“最終用戶”（theenduser）

“間接用戶”（或稱為關(guān)系人）。掏錢買軟件的用戶稱為客戶，而真正操作軟件的用戶叫最終用戶?？蛻襞c最終用戶可能是同一個(gè)人也可能不是同一個(gè)人。間接用戶既不掏錢買該軟件產(chǎn)品，也不使用該軟件，但是它可能對(duì)軟件產(chǎn)品有很大的影響。2023/2/1172023/2/11819

Instructor:ZhangyiEmail:SR_homework@163.comChapter3GoodPracticesforRequirementsEngineering20*213.9ARequirementsDevelopmentProcess

獲取分析編寫(xiě)規(guī)約驗(yàn)證更正并減少誤差重新評(píng)估證實(shí)重寫(xiě)圖3-1需求開(kāi)發(fā)是一個(gè)迭代的過(guò)程*22Chapter4TheRequirementsAnalyst

Instructor:ZhangyiEmail:SR_homework@163.com*23TheRequirementsAnalyst需求分析員：——又叫：系統(tǒng)分析員需求工程師需求經(jīng)理分析員*244.1

TheRequirementsAnalystRole需求分析員：

——是對(duì)軟件項(xiàng)目設(shè)計(jì)的需求進(jìn)行收集、分析、記錄和驗(yàn)證等工作的主要承擔(dān)者?！怯脩羧后w和軟件開(kāi)發(fā)團(tuán)隊(duì)之間進(jìn)行需求溝通的橋梁。

——是收集和傳播的中心角色。*25

4.1.1TheAnalyst'sTasks1）定義業(yè)務(wù)需求2）確定項(xiàng)目承擔(dān)者和用戶類別3）獲取需求4）分析需求5）編制需求規(guī)格說(shuō)明書(shū)6）為需求建模7）主持對(duì)需求的驗(yàn)證8）引導(dǎo)對(duì)需求的優(yōu)先級(jí)劃分9）管理需求*264.1.3EssentialAnalystKnowledge需求分析員：——掌握需求開(kāi)發(fā)和需求管理的知識(shí)——理解項(xiàng)目管理、風(fēng)險(xiǎn)管理和質(zhì)量工程。——掌握領(lǐng)域知識(shí)也是必要的*274.2

如何培養(yǎng)需求分析員需求分析員：

——是培養(yǎng)出來(lái)的，而不是訓(xùn)練出來(lái)的。

——主要是面向人，而不是面向“軟件技術(shù)”的。4.2.1從用戶轉(zhuǎn)為分析員4.2.2從開(kāi)發(fā)人員轉(zhuǎn)為分析員4.2.3應(yīng)用領(lǐng)域?qū)＜?023/2/128Chapter5EstablishingtheProductVisionandProjectScope

Instructor:Zhangyi

Email:SR_homework@163.com2023/2/129EstablishingtheProductVisionandProjectScopeBusinessrequirements:

在確定詳細(xì)的功能需求之前，必須很好地解決項(xiàng)目的視圖和范圍問(wèn)題。

——代表了需求鏈中最高層的抽象：

——為軟件系統(tǒng)定義了項(xiàng)目視圖和范圍?！?/p>

必須根據(jù)用戶需求來(lái)考慮，且要與業(yè)務(wù)需求所設(shè)定的目標(biāo)相一致。

Functionalrequirements:

2023/2/130作為軟件工程師，為了開(kāi)發(fā)相關(guān)的軟件系統(tǒng)，必須進(jìn)行領(lǐng)域分析，并可能有相當(dāng)多的工作。將有以下的工作價(jià)值：快速開(kāi)發(fā)：

——能更有效地與相關(guān)人員進(jìn)行交流，從而更快的確定需求。優(yōu)化系統(tǒng):

——了解領(lǐng)域的細(xì)節(jié)，有助于保證所采納的解決方案能更有效的解決客戶的問(wèn)題。少犯錯(cuò)誤，并遵循領(lǐng)域規(guī)則和標(biāo)準(zhǔn)。擴(kuò)展預(yù)測(cè)：

——有了領(lǐng)域知識(shí)，就可以洞察新興趨勢(shì)，并注意到進(jìn)一步開(kāi)發(fā)的機(jī)會(huì)。有助于創(chuàng)建適應(yīng)性更強(qiáng)的系統(tǒng)。2023/2/1315.1DefiningtheVision

throughBusinessRequirements項(xiàng)目視圖：——描述了產(chǎn)品所涉及的各個(gè)方面和最終所具有的功能。

項(xiàng)目范圍：——描述了產(chǎn)品應(yīng)包括的部分和不應(yīng)包括的部分。——說(shuō)明了在包括的部分與不包括的部分之間的界線。2023/2/1325.2VisionandScopeDocument——業(yè)務(wù)機(jī)遇的描述、項(xiàng)目的視圖和目標(biāo)、產(chǎn)品適用范圍和局限性的陳述、客戶的特點(diǎn)、項(xiàng)目?jī)?yōu)先級(jí)別和項(xiàng)目成功因素的描述。

項(xiàng)目視圖和范圍文檔，包括：

——是一個(gè)相對(duì)簡(jiǎn)短的文檔。

2023/2/133——確定了通過(guò)某一接口與系統(tǒng)相連的外部實(shí)體

——有時(shí)，稱為“端點(diǎn)”?！约?，外部實(shí)體和系統(tǒng)之間的數(shù)據(jù)流和物流關(guān)聯(lián)圖（0層DFD）：——我們把關(guān)聯(lián)圖，作為結(jié)構(gòu)化分析方法，形成數(shù)據(jù)流圖的最高抽象層。

5.3TheContextDiagram2023/2/134——可以把關(guān)聯(lián)圖，寫(xiě)入項(xiàng)目視圖和范圍文檔。——或軟件需求規(guī)格說(shuō)明中——或者作為系統(tǒng)數(shù)據(jù)流模型的一部分TheContextDiagram35Chapter6FindingtheVoiceoftheCustomerInstructor:Zhangyi

Email:SR_homework@163.com36FindingtheVoiceoftheCustomer軟件需求的成功和軟件開(kāi)發(fā)的成功:

——都取決于開(kāi)發(fā)者是否盡可能地采納客戶的意見(jiàn)?！脩粜枨?。

37FindingtheVoiceoftheCustomer為了征求客戶的意見(jiàn)，必須采取以下幾步：?明確項(xiàng)目用戶需求的來(lái)源。?明確使用該產(chǎn)品的不同類型的用戶。?與產(chǎn)品不同用戶類的代表進(jìn)行溝通。?遵從項(xiàng)目的最終決策者的意見(jiàn)。386.1SourcesofRequirements軟件需求的典型來(lái)源：1.訪問(wèn)并與有潛力的用戶探討2.把對(duì)目前的或競(jìng)爭(zhēng)產(chǎn)品的描述，寫(xiě)成文檔3.系統(tǒng)需求規(guī)格說(shuō)明4.對(duì)當(dāng)前系統(tǒng)的問(wèn)題分析，并增強(qiáng)要求5.市場(chǎng)調(diào)查和用戶問(wèn)卷調(diào)查6.觀察正在工作的用戶7.用戶工作的情景分析8.事件和響應(yīng)396.3FindingUserRepresentatives

用戶代表:

———

在獲取用戶需求時(shí),要挑選合適的用戶，來(lái)代表各類用戶的需求。

———

即：選擇用戶代表用戶代表：必須參加整個(gè)軟件開(kāi)發(fā)

在用戶代表的參與下，廣泛了解不同用戶類和不同的專業(yè)層次的需求。

406.4用戶代言人用戶代言人:———每一個(gè)工程項(xiàng)目，都包括為數(shù)不多的關(guān)鍵參與者，這些參與者來(lái)自相關(guān)的某方面用戶團(tuán)體，并提供客戶的需求。——我們稱這些人為：——用戶代言人或項(xiàng)目協(xié)調(diào)者用戶代言人，可能是軟件公司的一員用戶代言人：必須對(duì)應(yīng)用領(lǐng)域有徹底的了解，并在軟件方面具有足夠的經(jīng)驗(yàn)。416.4.2

對(duì)用戶代言人的要求表6.2用戶代言人可能的活動(dòng)423《用戶需求說(shuō)明書(shū)》與《軟件需求規(guī)格說(shuō)明書(shū)》的主要區(qū)別與聯(lián)系前者主要采用自然語(yǔ)言（和應(yīng)用域術(shù)語(yǔ)）來(lái)表達(dá)用戶需求，其內(nèi)容相對(duì)于后者而言比較粗略，不夠詳細(xì)。后者是前者的細(xì)化，更多地采用計(jì)算機(jī)語(yǔ)言和圖形符號(hào)來(lái)刻畫(huà)需求，產(chǎn)品需求是軟件系統(tǒng)設(shè)計(jì)的直接依據(jù)。

兩者之間可能并不存在一一影射關(guān)系，因?yàn)檐浖_(kāi)發(fā)商會(huì)根據(jù)產(chǎn)品發(fā)展戰(zhàn)略、企業(yè)當(dāng)前狀況適當(dāng)?shù)卣{(diào)整產(chǎn)品需求，例如用戶需求可能被分配到軟件的數(shù)個(gè)版本中。軟件開(kāi)發(fā)人員應(yīng)當(dāng)依據(jù)《軟件需求規(guī)格說(shuō)明書(shū)》來(lái)開(kāi)發(fā)當(dāng)前產(chǎn)品。Chapter7

HearingtheVoiceoftheCustomerInstructor:ZhangyiEmail:SR_homework@163.comHearingtheVoiceoftheCustomer——需求獲取

——是軟件工程的核心任務(wù)

——是在問(wèn)題及其最終解決方案之間架設(shè)橋梁的第一步。

——一旦理解了需求，分析者、開(kāi)發(fā)者和客戶就能探索出描述這些需求的多種解決方案7.2需求獲取討論會(huì)討論會(huì)：

——把用戶和開(kāi)發(fā)人員聯(lián)系起來(lái)，是明確需求的有效方法。需求獲取討論會(huì)

是獲取需求的有效方法需求獲取討論會(huì)中：如果參與者過(guò)多，就會(huì)減慢進(jìn)度。例如：一個(gè)需求獲取研討會(huì)，12位參與者對(duì)不必要的細(xì)節(jié)進(jìn)行激烈的討論，并且在每個(gè)使用實(shí)例如何工作的問(wèn)題上難以達(dá)成一致意見(jiàn)。當(dāng)把工作人員減少到只有6個(gè)人時(shí)，進(jìn)度馬上加快了，而這6個(gè)人代表了客戶、系統(tǒng)設(shè)計(jì)者、開(kāi)發(fā)者和可視化設(shè)計(jì)者等主要工程角色。如果參與者過(guò)少，也會(huì)造成問(wèn)題。最好的方法：選擇一些用戶代言人7.4需求獲取中的注意事項(xiàng)在需求獲取的過(guò)程中，

可能會(huì)發(fā)現(xiàn)以前的產(chǎn)品范圍定義存在誤差，不是太大就是太小。如果范圍太大:

此時(shí)獲取過(guò)程，將會(huì)拖延。如果范圍太大:以致不能提供一個(gè)令人滿意的產(chǎn)品需求的獲取，應(yīng)該把重點(diǎn)放在“做什么”。7.6HowDoYouKnowWhenYou’reDone?下列的提示，可能標(biāo)志需求獲取的過(guò)程完成：

①如果用戶不能想出更多的使用實(shí)例，也許你就完成了收集需求的工作。

②如果用戶提出新的使用實(shí)例，但你可以從其它使用實(shí)例的相關(guān)功能需求中，獲得這些新的使用實(shí)例，這時(shí)也許你就完成了收集需求的工作。③如果用戶開(kāi)始重復(fù)原先討論過(guò)的問(wèn)題，此時(shí)，也許你就完成了收集需求的工作。

④如果所提出的新需求，比你已確定的需求的優(yōu)先級(jí)都低時(shí)，也許你就完成了收集需求的工作。⑤如果用戶提出對(duì)將來(lái)產(chǎn)品的要求，而不是現(xiàn)在我們討論的特定產(chǎn)品，也許你就完成了收集需求的工作。Chapter8

UnderstandingUserRequirementsInstructor:Zhangyi

Email:SR_homework@163.com8.1用例法使用實(shí)例：

——為表達(dá)用戶需求,提供了一種方法，而這一方法必須與系統(tǒng)的業(yè)務(wù)需求相一致。

一個(gè)使用實(shí)例

——描述了系統(tǒng)和一個(gè)外部“執(zhí)行者”的交互順序，這體現(xiàn)執(zhí)行者完成一項(xiàng)任務(wù),并給某人帶來(lái)益處。

——執(zhí)行者：是指一個(gè)人，或另一個(gè)軟件應(yīng)用，或一個(gè)硬件，或其它一些與系統(tǒng)交互以實(shí)現(xiàn)某些目標(biāo)的實(shí)體。

8.1.1用例和使用場(chǎng)景一個(gè)單一的使用實(shí)例：

——

可能包括：

——完成某項(xiàng)任務(wù)的許多相關(guān)任務(wù)和交互順序。——因此，一個(gè)使用實(shí)例，是相關(guān)的用法說(shuō)明的集合，并且一個(gè)說(shuō)明是使用實(shí)例的例子?！谑褂脤?shí)例中，一個(gè)說(shuō)明被視為事件的普通過(guò)程，也叫作主過(guò)程、基本過(guò)程，普通流，或“滿意之路”。——在描述普通過(guò)程時(shí)，列出執(zhí)行者和系統(tǒng)之間相互交互或?qū)υ挼捻樞??！?dāng)結(jié)束時(shí)，執(zhí)行者達(dá)到了預(yù)期的目的。

——圖8.1化學(xué)品跟蹤管理系統(tǒng)用例圖（局部）——圖8.2描述用例主要和分支過(guò)程會(huì)話流的UML活動(dòng)圖編寫(xiě)與使用用例相聯(lián)系的功能需求文檔方法有：

1.僅利用使用實(shí)例的方法2.利用使用實(shí)例和SRS相結(jié)合的方法3.僅利用軟件需求規(guī)格說(shuō)明的方法8.1.4用例與功能性求8.1.5用例的益處

——該方法以任務(wù)為中心和以用戶為中心?！绕鹗褂靡怨δ転橹行牡姆椒?，使用實(shí)例方法可以使用戶更清楚地認(rèn)識(shí)到，新系統(tǒng)允許他們做什么。——使用實(shí)例有助于分析者和開(kāi)發(fā)者理解用戶的業(yè)務(wù)和應(yīng)用領(lǐng)域。

——有了使用實(shí)例，所得到的功能需求，明確規(guī)定了用戶執(zhí)行的特定任務(wù)?！诩夹g(shù)方面，使用實(shí)例，揭示了業(yè)務(wù)和應(yīng)用領(lǐng)域以及它們之間的責(zé)任?！绻櫣δ苄枨蟆⒃O(shè)計(jì)、編碼和測(cè)試以至到它們父類的使用實(shí)例。

——那么，這就很容易看出整個(gè)系統(tǒng)中，業(yè)務(wù)過(guò)程的各級(jí)關(guān)聯(lián)變化。54

Chapter10DocumentingtheRequirements

Instructor:Zhangyi

Email:SR_homework@163.com55DocumentingtheRequirements需求開(kāi)發(fā)的最終成果是：

——客戶和開(kāi)發(fā)小組對(duì)將要開(kāi)發(fā)的產(chǎn)品，達(dá)成一致協(xié)議。

——這一協(xié)議綜合了業(yè)務(wù)需求、用戶需求和軟件功能需求。

——而使用用例文檔，則只包含了用戶需求。

——必須應(yīng)用文檔把他們表示出來(lái)。

——即：編寫(xiě)軟件需求規(guī)格說(shuō)明56編寫(xiě)軟件需求規(guī)格說(shuō)明，有三種方法：●

用好的結(jié)構(gòu)化和自然語(yǔ)言編寫(xiě)文本型文檔●

建立圖形化模型方法

模型：可以描繪轉(zhuǎn)換過(guò)程、系統(tǒng)狀態(tài)和它們之間的變化、數(shù)據(jù)關(guān)系、邏輯流或?qū)ο箢惡退鼈兊年P(guān)系。

●

編寫(xiě)形式化規(guī)格說(shuō)明

這可以通過(guò)使用數(shù)學(xué)上精確的形式化邏輯語(yǔ)言來(lái)定義需求。DocumentingtheRequirements57——軟件需求規(guī)格說(shuō)明

——也稱：·功能規(guī)格說(shuō)明

·需求協(xié)議

·系統(tǒng)規(guī)格說(shuō)明

——它精確地闡述了一個(gè)軟件系統(tǒng)必須提供的功能和性能，以及所要考慮的限制條件。

——它是一個(gè)軟件系統(tǒng)成功的基礎(chǔ)10.1TheSoftwareRequirementsSpecification58●

客戶和營(yíng)銷部門：●

項(xiàng)目經(jīng)理：●

軟件開(kāi)發(fā)小組：●

測(cè)試小組：●

軟件維護(hù)和支持人員：●

產(chǎn)品發(fā)布組：●

培訓(xùn)人員：不同人員，使用規(guī)格說(shuō)明的目的各不相同：

59

——作為產(chǎn)品需求的最終成果：

●必須具有綜合性

●

必須包括所有的需求

——如果任何所期望的功能或非功能需求，未寫(xiě)入軟件需求規(guī)格說(shuō)明，那么它將不能在產(chǎn)品中出現(xiàn)。

——你必須在開(kāi)始設(shè)計(jì)和構(gòu)造之前，編寫(xiě)出整個(gè)產(chǎn)品的軟件需求規(guī)格說(shuō)明。

——針對(duì)每個(gè)需求的集合，必須有一個(gè)基準(zhǔn)協(xié)議。

——基準(zhǔn)：是指正在開(kāi)發(fā)的軟件需求規(guī)格說(shuō)明，向已通過(guò)評(píng)審的軟件需求規(guī)格說(shuō)明的過(guò)渡過(guò)程。

——必須通過(guò)項(xiàng)目中，所定義的變更控制過(guò)程，來(lái)更改基準(zhǔn)軟件需求規(guī)格說(shuō)明。——軟件需求規(guī)格說(shuō)明：60●

完整性●

一致性●

必要性●

明確性●

可驗(yàn)證性●

可更改性●

可跟蹤性高質(zhì)量需求文檔，所具有的特征：6110.1.1LabelingRequirements——可以采用下列方法：1)序列號(hào)如：UR-9、SRS-432)層次化編碼

——如：3.2.2

3)層次化文本標(biāo)簽62——積極方面：①探索潛在的用戶界面，有助于精化需求。②并使用戶和系統(tǒng)的交互，對(duì)用戶和開(kāi)發(fā)人員更具有實(shí)在性。③用戶界面的演示，也有助于項(xiàng)目計(jì)劃的制定和預(yù)測(cè)?！麡O方面:①屏幕映像和用戶界面機(jī)制是解決方案（設(shè)計(jì)）的描述，而不是需求。②如果完成了用戶界面的設(shè)計(jì)后,才能確定軟件需求規(guī)格說(shuō)明，那么需求開(kāi)發(fā)的過(guò)程,將會(huì)花費(fèi)很長(zhǎng)的時(shí)間。③這將會(huì)使那些只關(guān)心開(kāi)發(fā)時(shí)間的經(jīng)理、客戶或開(kāi)發(fā)人員失去耐心。

把用戶界面的設(shè)計(jì)，編入軟件需求

規(guī)格說(shuō)明。——既有好處，也有壞處。

6310.5TheDataDictionary——數(shù)據(jù)字典定義應(yīng)用程序中，使用的所有數(shù)據(jù)元素和結(jié)構(gòu)的含義、類型、數(shù)據(jù)大小、格式、度量單位、精度以及允許取值范圍的共享倉(cāng)庫(kù)?！獢?shù)據(jù)字典可以把不同的需求文檔和分析模型緊密結(jié)合在一起——如果所有的開(kāi)發(fā)人員在數(shù)據(jù)字典上取得一致意見(jiàn)，那么就可以緩和集成性問(wèn)題?！⒉皇窃诿總€(gè)需求出現(xiàn)的地方定義每一個(gè)數(shù)據(jù)項(xiàng)。——數(shù)據(jù)字典的維護(hù)獨(dú)立于軟件需求規(guī)格說(shuō)明，并且在產(chǎn)品的開(kāi)發(fā)和維護(hù)的任何階段，各個(gè)風(fēng)險(xiǎn)承擔(dān)者都可以訪問(wèn)數(shù)據(jù)字典。64

Chapter11APictureIsWorth1024Words

Instructor:ZhangyiEmail:SR_homework@163.com65軟件系統(tǒng)66BasicDFDnotation:RectangleisusedtorepresentanexternalentityAcirclerepresentsaprocessortransformthatisappliedtodataorcontrolAnarrowrepresentsadataflowdirectionThedoublelinerepresentsadatastore6711.4Entity-RelationshipDiagram

實(shí)體聯(lián)系圖：描繪了系統(tǒng)的數(shù)據(jù)關(guān)系

實(shí)體聯(lián)系圖：有助于對(duì)業(yè)務(wù)或系統(tǒng)數(shù)據(jù)組成的理解和交互。

用一個(gè)實(shí)體聯(lián)系圖和一個(gè)數(shù)據(jù)字典，來(lái)記錄數(shù)據(jù)關(guān)系，可以為新的業(yè)務(wù)過(guò)程，提供一個(gè)數(shù)據(jù)組成的概念性框架。6811.5State-TransitionDiagram狀態(tài)轉(zhuǎn)換圖：為狀態(tài)提供了一個(gè)簡(jiǎn)潔、完整、無(wú)二義性的表示。

狀態(tài)轉(zhuǎn)換圖：表示處理結(jié)果可能的狀態(tài)轉(zhuǎn)換。對(duì)于軟件系統(tǒng)中只能存在于特定狀態(tài)的那一部分，可以使用狀態(tài)轉(zhuǎn)換圖來(lái)建模。狀態(tài)轉(zhuǎn)換圖：有助于開(kāi)發(fā)者理解系統(tǒng)的預(yù)期行為。測(cè)試者：可以從轉(zhuǎn)換路徑的狀態(tài)轉(zhuǎn)換圖中獲得測(cè)試用例。用戶：只要稍微學(xué)一些符號(hào)就可以讀懂狀態(tài)轉(zhuǎn)換圖。6911.6DialogMap對(duì)話圖（dialogmap）：一種狀態(tài)轉(zhuǎn)換圖對(duì)話圖在較高的抽象層次上表示用戶界面的設(shè)計(jì)，它展示了系統(tǒng)的對(duì)話元素及這些元素之間的導(dǎo)航連接，但沒(méi)有展示詳細(xì)的屏幕設(shè)計(jì)。在對(duì)話圖中將每個(gè)對(duì)話元素表示為一個(gè)狀態(tài)（用矩形框表示），將每個(gè)允許的導(dǎo)航選項(xiàng)表示為一個(gè)轉(zhuǎn)換（用箭頭表示）。觸發(fā)用戶界面導(dǎo)航的條件表示為轉(zhuǎn)換箭頭上的文本標(biāo)簽。對(duì)話圖是表示用例中所描述的參與者與系統(tǒng)之間的交互的很好的方法。7011.8DecisionTablesandDecisionTrees決策表：應(yīng)用表格的形式進(jìn)行需求表達(dá)。決策樹(shù)：采用一種樹(shù)形結(jié)構(gòu)表達(dá)需求。71Decisiontree判定樹(shù)也是用來(lái)表達(dá)加工邏輯的一種工具。有時(shí)侯它比判定表更直觀。2023/2/172Chapter12BeyondFunctionality–SoftwareQualityAttributesInstructor:ZhangyiEmail:SR_homework@163.com2023/2/173軟件質(zhì)量屬性軟件質(zhì)量屬性或質(zhì)量引述是系統(tǒng)非功能性需求的一部分。非功能需求(none-functionalrequirements):描述系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。包括:產(chǎn)品必須遵循的標(biāo)準(zhǔn)、規(guī)范和合約外部界面的具體細(xì)節(jié)性能要求設(shè)計(jì)或?qū)崿F(xiàn)的約束條件……2023/2/17412.1QualityAttributes質(zhì)量屬性——包括許多產(chǎn)品特性根據(jù)不同的設(shè)計(jì)，可把質(zhì)量屬性分類：

——一種方法，是把在運(yùn)行時(shí)，可識(shí)別的特性與那些不可識(shí)別的特性區(qū)分開(kāi)。

——另一種方法，是把對(duì)用戶很重要的可見(jiàn)特性與對(duì)開(kāi)發(fā)者和維護(hù)者很重要的不可見(jiàn)特性區(qū)分開(kāi)。對(duì)開(kāi)發(fā)者具有重要意義的屬性有：

——使產(chǎn)品易于更改、驗(yàn)證，并易于移植到新的平臺(tái)上，從而可以間接地滿足客戶的需要的屬性。2023/2/175表12.1軟件質(zhì)量屬性2023/2/17612.3性能需求——性能需求：定義了系統(tǒng)必須多好和多快的完成專門的功能。

——包括：速度、吞吐量、處理能力、定時(shí)……例如：PE-1：

Thetemperaturecontrolcyclemustexecutecompletelyin80milliseconds.

PE-2：

Theinterpretershallparseatleast5000error-freestatementsperminute.

PE-3：

EveryWebpageshalldownloadin15secondsorless.PE-4.AuthorizationofanATMwithdrawalrequestshallnottakemorethan10seconds.

2023/2/177圖12.1選擇的質(zhì)量屬性之間的積極和消極關(guān)系2023/2/178RiskReductionThroughPrototypingChapter13

Instructor:Zhangyi

Email:SR_homework@163.com2023/2/179RiskReductionThroughPrototyping——用戶以不適合為理由拒絕了開(kāi)發(fā)的整個(gè)產(chǎn)品——他們發(fā)現(xiàn)界面和潛在的需求都存在問(wèn)題——利用軟件原型，可以減少客戶對(duì)產(chǎn)品不滿意的風(fēng)險(xiǎn)例如，一個(gè)飛機(jī)原型,可能是真實(shí)飛機(jī)的雛形?！?，可以消除在需求理解上的差異?！脩敉ǔ８敢鈬L試建立有趣的原型?！粋€(gè)軟件原型，通常僅僅是真實(shí)系統(tǒng)的一部分或一個(gè)模型，并且有時(shí)它可能根本不能完成任何有用的事。2023/2/18013.1Prototyping:WhatandWhy

一個(gè)軟件原型：

——是所提出的新產(chǎn)品的部分實(shí)現(xiàn)使用原型有三個(gè)主要目的：●

明確并完善需求

——原型，作為一種需求工具，它初步實(shí)現(xiàn)所理解的系統(tǒng)的一部分?！?/p>

探索設(shè)計(jì)選擇方案

——原型，作為一種設(shè)計(jì)工具，用它可以探索不同的用戶界面技術(shù)，使系統(tǒng)達(dá)到最佳的可用性。●

發(fā)展為最終的產(chǎn)品

——原型，作為一種構(gòu)造工具，是產(chǎn)品最初子集的完整功能實(shí)現(xiàn)。2023/2/181——建立原型的主要原因：

——是為了解決在產(chǎn)品開(kāi)發(fā)的早期階段不確定和二義性的問(wèn)題。

——不確定和二義性的問(wèn)題，使開(kāi)發(fā)者對(duì)產(chǎn)品產(chǎn)生困惑。

——建立一個(gè)原型，有助于說(shuō)明和糾正它們。

——原型，可以使問(wèn)題更具體化。2023/2/18213.2HorizontalPrototypes水平原型

——也叫“行為原型”或“演示性模型”

——水平原型，顯示出用戶界面的正面像，但是它僅包含少量的功能，并沒(méi)有真正實(shí)現(xiàn)所有的功能。

——水平原型，可以使用戶判斷是否有遺漏、錯(cuò)誤或不必要的功能。

——可以使用不同的屏幕設(shè)計(jì)工具或甚至使用紙和鉛筆來(lái)建立水平原型。2023/2/18313.3VerticalPrototypes垂直原型：

——也叫“結(jié)構(gòu)化原型”或“概念性模型”——它實(shí)現(xiàn)了一部分應(yīng)用功能——當(dāng)不能確信所提出的構(gòu)造軟件的方法是否完善——或者當(dāng)需要優(yōu)化算法，評(píng)價(jià)一個(gè)數(shù)據(jù)庫(kù)的圖表或測(cè)試臨界時(shí)間需求時(shí)。

——就要開(kāi)發(fā)一個(gè)垂直原型2023/2/184拋棄型原型：

——在原型達(dá)到預(yù)期目的以后，將它拋棄，所以，可以花最小的代價(jià)，盡快地建立該原型。——拋棄型原型，忽略了很多具體的軟件構(gòu)造技術(shù)?！荒軐仐壭驮椭械拇a，移植到產(chǎn)品系統(tǒng)中?！駝t，將在軟件生存期中遭遇種種麻煩?！?dāng)遇到需求中的不確定性、二義性、不完整性或含糊性時(shí)。

——最合適的方法，是建立拋棄型原型。——原型，可幫助用戶和開(kāi)發(fā)者。

——想象如何實(shí)現(xiàn)需求和發(fā)現(xiàn)需求中的漏洞。——原型，還可以使用戶判斷出需求是否可以完成必要的業(yè)務(wù)過(guò)程。

13.4ThrowawayPrototypes2023/2/185進(jìn)化型原型：

——在已經(jīng)清楚地定義了需求的情況下，進(jìn)化型原型為產(chǎn)品提供了堅(jiān)實(shí)的構(gòu)造基礎(chǔ)?！M(jìn)化式模型，一開(kāi)始就必須具有健壯性和產(chǎn)品質(zhì)量級(jí)的代碼?！⑦M(jìn)化型原型比建立拋棄型原型，所花的時(shí)間要多?！粋€(gè)進(jìn)化型原型必須設(shè)計(jì)為易于升級(jí)和優(yōu)化的——從測(cè)試和首次使用中獲得的信息，將引起下一次軟件原型的更新，正是這樣不斷增長(zhǎng)并更新，使軟件才能從一系列進(jìn)化型原型，發(fā)展為實(shí)現(xiàn)最終完整的產(chǎn)品?！@種原型提供了快速獲得有用功能的方法。13.5EvolutionaryPrototypes2023/2/186——書(shū)面原型：

——是一種廉價(jià)、快速，并且不涉及高技術(shù)的方法——它可以把一個(gè)系統(tǒng)某部分，是如何實(shí)現(xiàn)的呈現(xiàn)在用戶面前?！獣?shū)面原型：

——有助于判斷用戶和開(kāi)發(fā)者，在需求上是否達(dá)成共識(shí)。——可以使在開(kāi)發(fā)產(chǎn)品代碼前，對(duì)各種可能的解決方案進(jìn)行試驗(yàn)性的嘗試。

——書(shū)面原型：

——使用的工具：是紙張、索引卡、粘貼紙、塑料板、白板和標(biāo)記器。

——在書(shū)面原型中，一個(gè)人可以充當(dāng)計(jì)算機(jī)的角色。13.6PaperandElectronicPrototypes

2023/2/187——書(shū)面原型：

——即，模仿計(jì)算機(jī)的人，就會(huì)把關(guān)于顯示方面的紙張和索引卡給用戶看。

——用戶就可以判斷這些界面是否是所期望的響應(yīng)，并且還可以判斷所顯示的項(xiàng)是否正確。

——如果有錯(cuò)誤，只要用一張新紙或索引卡，重畫(huà)一張就可以了。

——不管你建立原型的工具多么高效，在紙張上勾畫(huà)界面是最快的?！獣?shū)面原型：

——方便了原型的快速反復(fù)性，而在需求開(kāi)發(fā)中反復(fù)性是一個(gè)關(guān)鍵的成功因素。——對(duì)于精化需求，是一種優(yōu)秀的技術(shù)。

13.6PaperandElectronicPrototypes

2023/2/188——電子原型

——如果決定建立一個(gè)電子拋棄型原型，那么就有許多工具可以使用。

——這些工具包括：

——編程語(yǔ)言

——腳本語(yǔ)言

——商品化的建立原型的工具包、屏幕繪圖器和圖形用戶界面構(gòu)筑師。13.6PaperandElectronicPrototypes

2023/2/18913.9PrototypingSuccessFactors

上一頁(yè)下一頁(yè)軟件原型法：

——提供了一套強(qiáng)有力的技術(shù)

——可以縮短開(kāi)發(fā)進(jìn)度

——增加用戶的滿意程度

——生產(chǎn)出高質(zhì)量的產(chǎn)品

——可以減少需求錯(cuò)誤和用戶界面的缺陷。2023/2/19013.9PrototypingSuccessFactors

上一頁(yè)下一頁(yè)建立有效的原型，應(yīng)遵循如下原則：●

在項(xiàng)目計(jì)劃中，應(yīng)包括原型風(fēng)險(xiǎn)?！裼?jì)劃開(kāi)發(fā)多個(gè)原型，因?yàn)槟愫苌倌芤淮纬晒??！癖M快并且廉價(jià)地建立拋棄型原型。●在拋棄型原型中，不應(yīng)含有：代碼注釋、輸入數(shù)據(jù)有效性檢查、保護(hù)性編碼技術(shù)，或者錯(cuò)誤處理的代碼?！駥?duì)于已經(jīng)理解的需求，不要建立原型?！癫荒茈S意地增加功能?！癫灰獜乃皆偷男阅芡茰y(cè)最終產(chǎn)品的性能?！裨谠推聊伙@示和報(bào)表中，使用合理的模擬數(shù)據(jù)?！癫灰谕涂梢源嫘枨笪臋n。91Chapter14SettingRequirementsPrioritiesInstructor:ZhangyiEmail:SR_homework@163.com92SettingRequirementsPriorities設(shè)定優(yōu)先級(jí):

——有助于項(xiàng)目經(jīng)理解決沖突、安排階段性交付，并且，做出必要的取舍。——下面將討論設(shè)定需求優(yōu)級(jí)的重要性——并且提出一個(gè)基于價(jià)值、費(fèi)用和風(fēng)險(xiǎn)的設(shè)定優(yōu)先級(jí)方案9314.3設(shè)定優(yōu)先級(jí)的等級(jí)

——設(shè)定優(yōu)先級(jí)的一般方法是：

——把需求分成三類：高、中、低

——表14.1描述了需求的4種可能。

——每一個(gè)需求的優(yōu)先級(jí)，必須寫(xiě)入軟件需求規(guī)格說(shuō)明或使用實(shí)例的說(shuō)明中。9