軟件需求重點

2023/2/11Chapter1TheEssentialSoftwareRequirement

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

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

獲取分析編寫規(guī)約驗證更正并減少誤差重新評估證實重寫圖3-1需求開發(fā)是一個迭代的過程*22Chapter4TheRequirementsAnalyst

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

TheRequirementsAnalystRole需求分析員：

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

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

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

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

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

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

Instructor:Zhangyi

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

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

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

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

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

Functionalrequirements:

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

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

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

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

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

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

項目視圖和范圍文檔，包括：

——是一個相對簡短的文檔。

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

——有時，稱為“端點”?！约?，外部實體和系統(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)圖，寫入項目視圖和范圍文檔。——或軟件需求規(guī)格說明中——或者作為系統(tǒng)數(shù)據(jù)流模型的一部分TheContextDiagram35Chapter6FindingtheVoiceoftheCustomerInstructor:Zhangyi

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

——都取決于開發(fā)者是否盡可能地采納客戶的意見?！脩粜枨蟆?/p>

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

用戶代表:

———

在獲取用戶需求時,要挑選合適的用戶，來代表各類用戶的需求。

———

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

UnderstandingUserRequirementsInstructor:Zhangyi

Email:SR_homework@163.com8.1用例法使用實例：

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

一個使用實例

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

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

8.1.1用例和使用場景一個單一的使用實例：

——

可能包括：

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

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

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

——該方法以任務(wù)為中心和以用戶為中心?！绕鹗褂靡怨δ転橹行牡姆椒ǎ褂脤嵗椒梢允褂脩舾宄卣J(rèn)識到，新系統(tǒng)允許他們做什么。——使用實例有助于分析者和開發(fā)者理解用戶的業(yè)務(wù)和應(yīng)用領(lǐng)域。

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

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

Chapter10DocumentingtheRequirements

Instructor:Zhangyi

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

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

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

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

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

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

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

建立圖形化模型方法

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

●

編寫形式化規(guī)格說明

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

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

·需求協(xié)議

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

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

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

客戶和營銷部門：●

項目經(jīng)理：●

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

測試小組：●

軟件維護和支持人員：●

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

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

59

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

●必須具有綜合性

●

必須包括所有的需求

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

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

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

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

——必須通過項目中，所定義的變更控制過程，來更改基準(zhǔn)軟件需求規(guī)格說明?！浖枨笠?guī)格說明：60●

完整性●

一致性●

必要性●

明確性●

可驗證性●

可更改性●

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

——如：3.2.2

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

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

規(guī)格說明?！扔泻锰?，也有壞處。

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

Chapter11APictureIsWorth1024Words

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

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

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

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

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

——一種方法，是把在運行時，可識別的特性與那些不可識別的特性區(qū)分開。

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

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

——包括：速度、吞吐量、處理能力、定時……例如：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——用戶以不適合為理由拒絕了開發(fā)的整個產(chǎn)品——他們發(fā)現(xiàn)界面和潛在的需求都存在問題——利用軟件原型，可以減少客戶對產(chǎn)品不滿意的風(fēng)險例如，一個飛機原型,可能是真實飛機的雛形?！停梢韵谛枨罄斫馍系牟町??！脩敉ǔ８敢鈬L試建立有趣的原型。——一個軟件原型，通常僅僅是真實系統(tǒng)的一部分或一個模型，并且有時它可能根本不能完成任何有用的事。2023/2/18013.1Prototyping:WhatandWhy

一個軟件原型：

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

明確并完善需求

——原型，作為一種需求工具，它初步實現(xiàn)所理解的系統(tǒng)的一部分。●

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

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

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

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

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

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

——建立一個原型，有助于說明和糾正它們。

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

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

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

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

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

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

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

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

——最合適的方法，是建立拋棄型原型?！停蓭椭脩艉烷_發(fā)者。

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

13.4ThrowawayPrototypes2023/2/185進化型原型：

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

——是一種廉價、快速，并且不涉及高技術(shù)的方法——它可以把一個系統(tǒng)某部分，是如何實現(xiàn)的呈現(xiàn)在用戶面前?！獣嬖停?/p>

——有助于判斷用戶和開發(fā)者，在需求上是否達(dá)成共識?！梢允乖陂_發(fā)產(chǎn)品代碼前，對各種可能的解決方案進行試驗性的嘗試。

——書面原型：

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

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

2023/2/187——書面原型：

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

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

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

——不管你建立原型的工具多么高效，在紙張上勾畫界面是最快的?！獣嬖停?/p>

——方便了原型的快速反復(fù)性，而在需求開發(fā)中反復(fù)性是一個關(guān)鍵的成功因素?！獙τ诰枨?，是一種優(yōu)秀的技術(shù)。

13.6PaperandElectronicPrototypes

2023/2/188——電子原型

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

——這些工具包括：

——編程語言

——腳本語言

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

2023/2/18913.9PrototypingSuccessFactors

上一頁下一頁軟件原型法：

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

——可以縮短開發(fā)進度

——增加用戶的滿意程度

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

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

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

在項目計劃中，應(yīng)包括原型風(fēng)險?！裼媱濋_發(fā)多個原型，因為你很少能一次成功?！癖M快并且廉價地建立拋棄型原型?！裨趻仐壭驮椭?，不應(yīng)含有：代碼注釋、輸入數(shù)據(jù)有效性檢查、保護性編碼技術(shù)，或者錯誤處理的代碼。●對于已經(jīng)理解的需求，不要建立原型。●不能隨意地增加功能?！癫灰獜乃皆偷男阅芡茰y最終產(chǎn)品的性能?！裨谠推聊伙@示和報表中，使用合理的模擬數(shù)據(jù)。●不要期望原型可以代替需求文檔。91Chapter14SettingRequirementsPrioritiesInstructor:ZhangyiEmail:SR_homework@163.com92SettingRequirementsPriorities設(shè)定優(yōu)先級:

——有助于項目經(jīng)理解決沖突、安排階段性交付，并且，做出必要的取舍?！旅鎸⒂懻撛O(shè)定需求優(yōu)級的重要性——并且提出一個基于價值、費用和風(fēng)險的設(shè)定優(yōu)先級方案9314.3設(shè)定優(yōu)先級的等級

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

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

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

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