軟件工程原理與實(shí)踐（碩士）課件 5 軟件需求工程

高級(jí)軟件工程

SoftwareEngineering軟件需求工程問(wèn)題需求創(chuàng)新和產(chǎn)品定位很難用戶提不出需求I'mnotsure,butI'llknowitwhenIseeit需求經(jīng)常變化，項(xiàng)目沒(méi)有時(shí)限開(kāi)發(fā)人員不得不大量返工，因?yàn)樾枨笕毕葜钡介_(kāi)發(fā)后期才發(fā)現(xiàn)系統(tǒng)測(cè)試白費(fèi)了，因?yàn)闇y(cè)試者并未明白產(chǎn)品要做什么功能都實(shí)現(xiàn)了，但由于產(chǎn)品的低性能、使用不方便或其它因素用戶不滿意維護(hù)費(fèi)用相當(dāng)高，因?yàn)榭蛻舻脑S多增強(qiáng)要求未在需求獲取階段提出202-需求獲取01-相關(guān)概念03-需求分析304-需求定義和驗(yàn)證05-需求管理軟件需求需求系統(tǒng)必須符合的條件或能力軟件需求（FURPS+）用戶對(duì)目標(biāo)軟件系統(tǒng)在功能(F)、非功能需求(URPS)、設(shè)計(jì)約束等方面的期望。關(guān)注What!系統(tǒng)輸出功能非功能需求、設(shè)計(jì)約束輸入功能需求－－用例建模Use-Case2規(guī)約-簡(jiǎn)要描述-事件流Use-Case3規(guī)約-簡(jiǎn)要描述-事件流Actor1UseCase2UseCase3UseCase1

Actor2Actor3Use-Case1規(guī)約-簡(jiǎn)要描述-事件流系統(tǒng)DetermineNeedTakeOrderSetupPaymentDeliverOrderFillOrder非功能需求Functionality

FeatureSetCapabilitiesGeneralitySecurityUsability

HumanFactorsAestheticsConsistencyDocumentationReliability

Frequency/SeverityofFailureRecoverabilityPredictabilityAccuracyMTBFPerformance

SpeedEfficiencyResourceUsageThroughputResponseTimeSupportability

TestabilityExtensibilityAdaptabilityMaintainabilityCompatibilityConfigurabilityServiceabilityInstallabilityLocalizabilityRobustnessFURPS的“URPS”設(shè)計(jì)約束一項(xiàng)需求允許多種設(shè)計(jì)方案設(shè)計(jì)是在這多種方案中做出選擇沒(méi)有選擇的需求就是一個(gè)設(shè)計(jì)約束它和其它需求不同將它放在軟件需求的單獨(dú)一節(jié)中將每個(gè)設(shè)計(jì)約束的源標(biāo)識(shí)出來(lái)記錄每個(gè)設(shè)計(jì)約束的原理舉例必須要有某一種算法必須要用數(shù)據(jù)庫(kù)軟件需求的層次項(xiàng)目前景文檔Vision軟件需求規(guī)約SoftwareRequirementSpec用戶需求StakeholderNeeds軟件概要需求軟件詳細(xì)需求8系統(tǒng)需求/業(yè)務(wù)需求軟件需求從用戶/系統(tǒng)需求到軟件需求分解和精化9案例1ATM機(jī)系統(tǒng)中的系統(tǒng)需求“系統(tǒng)應(yīng)當(dāng)防止銀行卡被盜刷”可以被細(xì)化為哪些軟件需求？單筆取款和全天取款金額有限制卡長(zhǎng)時(shí)間無(wú)操作吞卡存取款時(shí)進(jìn)行短信提醒密碼輸入錯(cuò)誤多次后鎖定讀卡器能夠識(shí)別銀行卡真?zhèn)沃讣y識(shí)別用戶身份與監(jiān)控聯(lián)網(wǎng)，識(shí)別周圍是否有人系統(tǒng)內(nèi)部網(wǎng)絡(luò)訪問(wèn)限制IP等案例2電水壺控制系統(tǒng)中的用戶需求“當(dāng)水壺中的水溫低于100攝氏度時(shí)，加熱裝置應(yīng)當(dāng)一直處于工作狀態(tài)”應(yīng)如何轉(zhuǎn)變?yōu)檐浖枨螅侩[含的（想當(dāng)然）假設(shè)：水的沸點(diǎn)永遠(yuǎn)是100攝氏度問(wèn)題：當(dāng)假設(shè)不滿足時(shí)（如高原上）水可能被燒干真實(shí)意圖：將水燒開(kāi)的同時(shí)避免燒干→當(dāng)水壺中的水溫低于沸點(diǎn)時(shí)，加熱裝置應(yīng)當(dāng)一直處于工作狀態(tài)需求工程發(fā)現(xiàn)、獲取、組織、分析、編寫和管理需求的系統(tǒng)方法，讓客戶和項(xiàng)目組之間達(dá)成共識(shí)。項(xiàng)目前景文檔需求獲取項(xiàng)目干系人需求需求定義軟件需求規(guī)約需求驗(yàn)證軟件需求基線術(shù)語(yǔ)表需求分析分析模型需求管理1002-需求獲取01-相關(guān)概念03-需求分析1104-需求定義和驗(yàn)證05-需求管理需求工程發(fā)現(xiàn)、獲取、組織、分析、編寫和管理需求的系統(tǒng)方法，讓客戶和項(xiàng)目組之間達(dá)成共識(shí)。項(xiàng)目前景文檔需求獲取項(xiàng)目干系人需求需求定義軟件需求規(guī)約需求驗(yàn)證軟件需求基線術(shù)語(yǔ)表需求分析分析模型需求管理12獲取需求的難點(diǎn)和誤區(qū)難點(diǎn)：用戶提不出需求難點(diǎn)：需求常常有二義性誤區(qū)：分析員自認(rèn)為比用戶更理解問(wèn)題誤區(qū)：只重視功能需求干系人分析員??難點(diǎn)1：用戶提不出需求需求的來(lái)源CustomerUsersProblemDomain領(lǐng)域?qū)＜覙I(yè)界分析員

競(jìng)爭(zhēng)信息新需求Bug報(bào)告

變更請(qǐng)求運(yùn)營(yíng)數(shù)據(jù)需求規(guī)范業(yè)務(wù)計(jì)劃個(gè)人目標(biāo)業(yè)務(wù)模型AnalystPartnersKANO模型舉例：空調(diào)基本型需求：制冷、制熱期望型需求：節(jié)能、除濕興奮型需求：凈化空氣、遠(yuǎn)程操控挑戰(zhàn)如何獲得基本型需求？不能遺漏！用戶認(rèn)為沒(méi)必要說(shuō)How:領(lǐng)域?qū)＜摇⒏?jìng)爭(zhēng)產(chǎn)品分析、行業(yè)調(diào)研分析等如何獲得期望型需求？用戶談?wù)摰耐ǔＪ瞧谕托枨驢ow:采用訪談、問(wèn)卷、開(kāi)會(huì)、觀察等方法收集項(xiàng)目干系人的需求如何獲得興奮型需求？用戶不知道How:創(chuàng)新！項(xiàng)目干系人需求的獲取技術(shù)訪談焦點(diǎn)小組會(huì)議引導(dǎo)式研討會(huì)（FacilitatedWorkshops）如JointApplicationDevelopment，JAD群體創(chuàng)新技術(shù)如頭腦風(fēng)暴法、思維導(dǎo)圖等群體決策技術(shù)如一致同意、大多數(shù)原則、相對(duì)多數(shù)原則、獨(dú)裁等問(wèn)卷調(diào)查觀察原型法標(biāo)桿對(duì)照（Benchmarking）系統(tǒng)交互圖（ContextDiagrams）文件分析甲乙方經(jīng)驗(yàn)影響需求獲取策略開(kāi)發(fā)人員的經(jīng)驗(yàn)用戶的經(jīng)驗(yàn)低高低高“Fuzzyproblem”“CatchUp”“Mature”“Selling/Teaching”難點(diǎn)2：需求常常有二義性如何消除二義性？舉例：ActivateHeatPump自然語(yǔ)言規(guī)約Ifthetemperaturedifferenceexceeds2degreesformorethan2seconds,thenthepumpshallactivateforatleast2secondsinnomorethan2seconds.形式化規(guī)約21可理解性Understandability二義性AmbiguityThesweetspot

如何減少需求的二義性？用形式化方法，基于數(shù)學(xué)的方法定義需求用足夠詳細(xì)的、準(zhǔn)確的文字描述用法語(yǔ)更好增加術(shù)語(yǔ)表用UML等半形式化的語(yǔ)言來(lái)建模與分析界面原型需求評(píng)審……獲取常用術(shù)語(yǔ)定義項(xiàng)目用到的術(shù)語(yǔ)有助于避免誤解記錄于單獨(dú)的術(shù)語(yǔ)表文件中術(shù)語(yǔ)表Glossary獲取常用術(shù)語(yǔ)盡早開(kāi)始在項(xiàng)目過(guò)程中持續(xù)進(jìn)行CourseAclassofferedbytheuniversity.CourseOfferingAspecificofferingforacourse,includingdaysoftheweekandtimes.GradeThegradeforthestudentinacourse.ReportCardAllthegradesforallcoursestakenbyastudentinagivensemester.RosterAllthestudentsenrolledinaparticularcourseoffering.TranscriptThehistoryofthegradesforallcoursesforaparticularstudent.界面原型界面原型界面原型為靜態(tài)的包括主要界面和界面上的主要元素開(kāi)發(fā)的幾種方法圖紙（在紙上手繪）位圖（采用繪圖工具，如Visio）可執(zhí)行代碼，即交互式的電子界面原型采用界面原型工具，如Axure、Sketch、Zeplin或直接編程，如采用HTML或編程語(yǔ)言02-需求獲取01-相關(guān)概念03-需求分析2504-需求定義和驗(yàn)證05-需求管理需求工程發(fā)現(xiàn)、獲取、組織、分析、編寫和管理需求的系統(tǒng)方法，讓客戶和項(xiàng)目組之間達(dá)成共識(shí)。項(xiàng)目前景文檔需求獲取項(xiàng)目干系人需求需求定義軟件需求規(guī)約需求驗(yàn)證軟件需求基線術(shù)語(yǔ)表需求分析分析模型需求管理26需求分析對(duì)需求進(jìn)行分析，并進(jìn)行可視化建模，形成分析模型關(guān)注What,NotHow分析建模方法面向?qū)ο蠓治鼋Y(jié)構(gòu)化分析……分析模型分析模型是平臺(tái)無(wú)關(guān)模型結(jié)構(gòu)化分析模型數(shù)據(jù)流圖（DFD）控制流圖（CFD）數(shù)據(jù)字典（DD）實(shí)體—關(guān)系圖（ERD）狀態(tài)變遷圖（STD）加工說(shuō)明（PSPEC）控制說(shuō)明（CSPEC）面向?qū)ο蠓治瞿Ｐ陀美龍D活動(dòng)圖類圖時(shí)序圖通信圖狀態(tài)機(jī)圖基于用例（Use-Case）

的需求分析Use-Case2規(guī)約-簡(jiǎn)要描述-事件流Use-Case3規(guī)約-簡(jiǎn)要描述-事件流Actor1UseCase2UseCase3UseCase1

Actor2Actor3Use-Case1規(guī)約-簡(jiǎn)要描述-事件流系統(tǒng)Actor和UseCaseActor和系統(tǒng)交互的系統(tǒng)外的某些人或某些東西：最終用戶外界軟件系統(tǒng)外界硬件設(shè)備UsecaseActor想使用系統(tǒng)去做的事ActorUseCaseCourseRegistrationSystem的用例圖SelectCoursestoTeachProfessorStudentBillingSystemRegistrarViewGradesAlterCourseSelectionsGetClassListforaCourseCloseRegistrationSubmitGradesRegisterforCoursesCourseCatalogSystemRequestCourseCatalogUse-CaseSpecificationsNameBriefdescriptionFlowofEventsRelationshipsActivitydiagramsUse-CasediagramsSpecialrequirementsPre-conditionsPost-conditionsOtherdiagramsUse-CaseSpecifications...Use-CaseModelActorsUseCases事件流（基本流和備選流）一個(gè)基本流HappydayscenarioSuccessfulscenariofromstarttofinish多個(gè)備選流RegularvariantOddcasesExceptional(error)flows事件流舉例：基本流BasicFlow1.采購(gòu)員在初始申購(gòu)單中添加申購(gòu)子項(xiàng)。2.采購(gòu)員輸入供應(yīng)商、交貨地點(diǎn)、最終價(jià)格、返利、加價(jià)和費(fèi)用明細(xì)。3.采購(gòu)員增加、刪除和修改申購(gòu)單（包括第1、2步）直到滿意為止。4.采購(gòu)員在輸入所有必要信息后，保存并完成申購(gòu)單。5.系統(tǒng)檢驗(yàn)申購(gòu)單，分配申購(gòu)單號(hào)，設(shè)置申購(gòu)單和申購(gòu)單子項(xiàng)狀態(tài)為“未提交”6.采購(gòu)員提交申購(gòu)單。7.系統(tǒng)設(shè)置申購(gòu)單狀態(tài)為“待審批”，通知采購(gòu)經(jīng)理審批申購(gòu)單。備選流AlternativeFlows1-3a退出：1)系統(tǒng)提示用戶保存。2)用戶選擇不保存，系統(tǒng)放棄臨時(shí)信息，申購(gòu)單狀態(tài)不變。4a.申購(gòu)單信息不完整：系統(tǒng)提示不能保存，回到步驟3?；顒?dòng)圖（ActivityDiagram）作補(bǔ)充ActivityStateSynchronizationBar(Fork)GuardConditionSynchronizationBar(Join)DecisionConcurrentThreadsTransitionSelectCourse[addcourse]CheckScheduleCheckPre-requisitesAssigntoCourseResolveConflictsUpdateScheduleDeleteCourse[checkscompleted][checksfailed][deletecourse]帶泳道的活動(dòng)圖用例圖的優(yōu)化：UseCase間的關(guān)系Include包含Extend擴(kuò)展Generalization泛化<<include>><<extend>>02-需求獲取01-相關(guān)概念03-需求分析3804-需求定義和驗(yàn)證05-需求管理需求工程發(fā)現(xiàn)、獲取、組織、分析、編寫和管理需求的系統(tǒng)方法，讓客戶和項(xiàng)目組之間達(dá)成共識(shí)。項(xiàng)目前景文檔需求獲取項(xiàng)目干系人需求需求定義軟件需求規(guī)約需求驗(yàn)證軟件需求基線術(shù)語(yǔ)表需求分析分析模型需求管理39定義軟件需求定義FURPS+定義Functionality需求定義Usability需求定義Reliability需求定義Performance需求定義Supportability需求定義+需求定義Functionality需求功能性（Functionality）：特性、功能和安全性Trendinginformationwillbechartedwithalinegraphshowingtimeonthexaxis,andnumberofdefectsfoundontheyaxis.PrintStatus

ReportOperatorProject

Manager概要功能需求詳細(xì)功能需求Feat63-thedefecttrackingsystemwillprovidetrendinginformationtohelptheprojectmanagerassessprojectstatus定義Usability需求易用性（Usability）：用戶學(xué)習(xí)和操作軟件的容易程度。包含人的因素、美觀、用戶界面的一致性、聯(lián)機(jī)幫助、向?qū)?、用戶文檔和培訓(xùn)材料等方面。典型易用性需求舉例普通用戶所需的培訓(xùn)時(shí)間為1天，高級(jí)用戶所需的培訓(xùn)時(shí)間為2小時(shí)用戶應(yīng)在平均3~5分鐘內(nèi)完成選課操作符合公認(rèn)的易用性標(biāo)準(zhǔn)（如IBM的CUA標(biāo)準(zhǔn)和Microsoft的GUI標(biāo)準(zhǔn)）系統(tǒng)應(yīng)提供在線幫助文件菜單中的功能要定義快捷鍵，即Ctrl鍵和其他鍵同時(shí)按下易學(xué)易用!討論：請(qǐng)為微信寫一條易用性需求定義Reliability需求可靠性（Reliability）：軟件無(wú)故障執(zhí)行一段時(shí)間的概率。典型的可靠性指標(biāo)可用性Availability

-可用時(shí)間百分比(xx.xx%)、使用小時(shí)數(shù)、維護(hù)訪問(wèn)權(quán)、降級(jí)模式操作等。平均故障間隔時(shí)間(MTBF)-通常表示為小時(shí)數(shù)，但也可表示為天數(shù)、月數(shù)或年數(shù)。平均修復(fù)時(shí)間(MTTR)-系統(tǒng)在發(fā)生故障后可以暫停運(yùn)行的時(shí)間。精確度-指出系統(tǒng)輸出要求具備的精密度（分辨率）和精確度（按照某一已知的標(biāo)準(zhǔn)）。最高缺陷率-通常表示為bugs/KLOC或bugs/function-point。按照小bug、大bug和嚴(yán)重bug來(lái)分類。不要宕機(jī)!討論：請(qǐng)為電梯控制軟件寫一條可靠性需求定義Performance需求性能（Performance）：軟件運(yùn)行的速度或效率。典型的性能指標(biāo)：響應(yīng)時(shí)間(平均、最長(zhǎng))：網(wǎng)頁(yè)的載入和顯示應(yīng)在2秒之內(nèi)吞吐量：每秒能處理的請(qǐng)求數(shù)為1000數(shù)據(jù)容量：數(shù)據(jù)庫(kù)應(yīng)支持?jǐn)?shù)據(jù)存儲(chǔ)700GB，且每年按30%的速度遞增。并發(fā)量：系統(tǒng)可支持1000個(gè)并發(fā)用戶。資源利用情況（內(nèi)存、磁盤、網(wǎng)絡(luò)帶寬等）：網(wǎng)絡(luò)帶寬為30MBbps，服務(wù)器內(nèi)存為32G。速度要快!討論：請(qǐng)為12306火車購(gòu)票系統(tǒng)寫一條性能需求定義Supportability需求可支持性（Supportability）：軟件易于修改和維護(hù)的能力。包括可測(cè)試性、可擴(kuò)展性、可適應(yīng)性、可維護(hù)性、兼容性、可配置性、可服務(wù)性、可安裝性，或是否可本地化（國(guó)際化）等。支持性需求舉例：編程語(yǔ)言采用Java，數(shù)據(jù)庫(kù)操作語(yǔ)言采用標(biāo)準(zhǔn)SQL符合GoogleJava編程規(guī)范應(yīng)有統(tǒng)一的出錯(cuò)處理與報(bào)告機(jī)制修改方便!討論：請(qǐng)為交我辦APP寫一條可支持需求FURPS+設(shè)計(jì)約束（designconstraints）：規(guī)定或約束了系統(tǒng)的設(shè)計(jì)的需求；實(shí)現(xiàn)需求（implementationrequirements）：規(guī)定或約束了系統(tǒng)的編碼或構(gòu)建，如所需標(biāo)準(zhǔn)、編程語(yǔ)言、數(shù)據(jù)庫(kù)完整性策略、資源限制和操作環(huán)境；接口需求（interfacerequirements）：規(guī)定了系統(tǒng)必須與之交互操作的外部軟件或硬件，以及對(duì)這種交互操作所使用的格式、時(shí)間或其他因素的約束；物理需求（physicalrequirements.）：規(guī)定了系統(tǒng)必須具備的物理特征，可用來(lái)代表硬件要求，如物理網(wǎng)絡(luò)配置需求。討論：請(qǐng)為交我辦APP寫一條設(shè)計(jì)約束討論功能需求：后臺(tái)任務(wù)管理器能以不少于60秒的固定時(shí)間間隔來(lái)提供狀態(tài)信息性能需求：系統(tǒng)必須支持1000個(gè)并發(fā)用戶，用戶響應(yīng)時(shí)間在3秒之內(nèi)。易用性需求：系統(tǒng)的用戶界面友好。這些需求寫得如何？如果不好，如何更好地表達(dá)?1.后臺(tái)任務(wù)管理器應(yīng)該在制定的UI區(qū)域顯示狀態(tài)信息。1.1后臺(tái)任務(wù)處理開(kāi)始以后，BTM應(yīng)該以每60秒(上下加減5秒)的頻率來(lái)更新消息。1.2在后臺(tái)處理期間，消息應(yīng)該保持持續(xù)可見(jiàn)。1.3BTM應(yīng)該顯示后臺(tái)任務(wù)完成的百分比。1.4后臺(tái)任務(wù)結(jié)束時(shí)，BTM應(yīng)該顯示“完成”的消息。1.5如果后臺(tái)任務(wù)延時(shí)，BTM應(yīng)該顯示一個(gè)消息。概要需求：前景文檔（Vision）簡(jiǎn)介Introduction定位Positioning2.1商機(jī)2.2問(wèn)題說(shuō)明2.3產(chǎn)品定位干系人和用戶描述StakeholderandUserDescriptions產(chǎn)品概述ProductOverview產(chǎn)品特性ProductFeatures約束Constraints質(zhì)量范圍QualityRanges優(yōu)先級(jí)PrecedenceandPriority其它產(chǎn)品需求OtherProductRequirements文檔需求DocumentationRequirements1. 簡(jiǎn)介2. 整體說(shuō)明3. 具體需求3.1 功能3.2 易用性3.3 可靠性3.4 性能3.5 可支持性3.6 設(shè)計(jì)約束3.7 聯(lián)機(jī)用戶文檔和幫助系統(tǒng)需求3.8 購(gòu)買的構(gòu)件3.9 接口3.10 許可需求3.11 法律、版權(quán)及其他聲明3.12 適用的標(biāo)準(zhǔn)4. 支持信息索引、附錄等采用傳統(tǒng)技術(shù)詳細(xì)需求：SRS文檔1.引言1.1Purpose1.2Scope1.3Definitions,Acronyms,andAbbreviations1.4References1.5Overview2.綜述2.1Use-CaseModelSurvey2.2AssumptionsandDependencies3.具體需求3.1Use-Case報(bào)告

3.1.1<UseCase1> 3.1.2...3.2補(bǔ)充說(shuō)明

3.2.1易用性需求

3.2.2…4.支持信息索引、附錄、用戶界面原型等采用Use-Case技術(shù)50需求驗(yàn)證原型確認(rèn)拋棄型原型確認(rèn)演進(jìn)型原型確認(rèn)需求評(píng)審評(píng)審需求文檔（Vision和SRS等），及時(shí)發(fā)現(xiàn)缺陷，尋找改進(jìn)的契機(jī)，同時(shí)從評(píng)審反饋中獲得知識(shí)，補(bǔ)充了正規(guī)的交流和培訓(xùn)機(jī)制，幫助團(tuán)隊(duì)建立對(duì)產(chǎn)品的共同理解需求評(píng)審方法審查小組評(píng)審走查結(jié)對(duì)編程同級(jí)桌查輪查臨時(shí)評(píng)審正式化程度需求評(píng)審的輸入和輸出輸入待評(píng)審的需求文檔Checklist輸出評(píng)審結(jié)論通過(guò)有條件通過(guò)不通過(guò)缺陷清單軟件需求基線02-需求獲取01-相關(guān)概念03-需求分析5404-需求定義和驗(yàn)證05-需求管理需求工程發(fā)現(xiàn)、獲取、組織、分析、編寫和管理需求的系統(tǒng)方法，讓客戶和項(xiàng)目組之間達(dá)成共識(shí)。項(xiàng)目前景文檔需求獲取項(xiàng)目干系人需求需求定義軟件需求規(guī)約需求驗(yàn)證軟件需求基線術(shù)語(yǔ)表需求分析分析模型需求管理55需求管理1）定義需求優(yōu)先級(jí)和需求基線2）需求變更控制3）需求跟蹤1）建立需求基線，即確定項(xiàng)目范圍Feature1:Thesystemmust...Feature2:Thesystemmust...Feature3:Thesystemmust...Feature4:Thesystemmust...Featuren:Thesystemmust...Howdowedeterminepriority?Wheredowesetthebaseline?Howdoweknowwhattheneedsare?TimeProjectStartDateTargetReleaseDate使用需求屬性排列特性的優(yōu)先級(jí)FeatureReqt.10ApprovedLowHighFeatureReqt.13ProposedMed.LowFeatureReqt.40ApprovedHighMandatory $$$$$$成本工作量風(fēng)險(xiǎn)狀態(tài)重要性

其他屬性包括穩(wěn)定性、技術(shù)難度等58迭代的特性Release1:LogonRegisterforCoursesInterfacetoCourseCatalogDatabaseMaintainStudentInformationMaintainProfessorInformationRelease2:SubmitStudentGradesViewGradesSelectCoursestoTeach舉例：選課系統(tǒng)的特性優(yōu)先級(jí)需求沖突與協(xié)商

需求沖突源于不同干系人對(duì)于待開(kāi)發(fā)的軟件系統(tǒng)的不同看法和利益訴求數(shù)據(jù)沖突：數(shù)