软件工程原理与实践（硕士）课件 5 软件需求工程

高级软件工程

SoftwareEngineering软件需求工程问题需求创新和产品定位很难用户提不出需求I'mnotsure,butI'llknowitwhenIseeit需求经常变化，项目没有时限开发人员不得不大量返工，因为需求缺陷直到开发后期才发现系统测试白费了，因为测试者并未明白产品要做什么功能都实现了，但由于产品的低性能、使用不方便或其它因素用户不满意维护费用相当高，因为客户的许多增强要求未在需求获取阶段提出202-需求获取01-相关概念03-需求分析304-需求定义和验证05-需求管理软件需求需求系统必须符合的条件或能力软件需求（FURPS+）用户对目标软件系统在功能(F)、非功能需求(URPS)、设计约束等方面的期望。关注What!系统输出功能非功能需求、设计约束输入功能需求－－用例建模Use-Case2规约-简要描述-事件流Use-Case3规约-简要描述-事件流Actor1UseCase2UseCase3UseCase1

Actor2Actor3Use-Case1规约-简要描述-事件流系统DetermineNeedTakeOrderSetupPaymentDeliverOrderFillOrder非功能需求Functionality

FeatureSetCapabilitiesGeneralitySecurityUsability

HumanFactorsAestheticsConsistencyDocumentationReliability

Frequency/SeverityofFailureRecoverabilityPredictabilityAccuracyMTBFPerformance

SpeedEfficiencyResourceUsageThroughputResponseTimeSupportability

TestabilityExtensibilityAdaptabilityMaintainabilityCompatibilityConfigurabilityServiceabilityInstallabilityLocalizabilityRobustnessFURPS的“URPS”设计约束一项需求允许多种设计方案设计是在这多种方案中做出选择没有选择的需求就是一个设计约束它和其它需求不同将它放在软件需求的单独一节中将每个设计约束的源标识出来记录每个设计约束的原理举例必须要有某一种算法必须要用数据库软件需求的层次项目前景文档Vision软件需求规约SoftwareRequirementSpec用户需求StakeholderNeeds软件概要需求软件详细需求8系统需求/业务需求软件需求从用户/系统需求到软件需求分解和精化9案例1ATM机系统中的系统需求“系统应当防止银行卡被盗刷”可以被细化为哪些软件需求？单笔取款和全天取款金额有限制卡长时间无操作吞卡存取款时进行短信提醒密码输入错误多次后锁定读卡器能够识别银行卡真伪指纹识别用户身份与监控联网，识别周围是否有人系统内部网络访问限制IP等案例2电水壶控制系统中的用户需求“当水壶中的水温低于100摄氏度时，加热装置应当一直处于工作状态”应如何转变为软件需求？隐含的（想当然）假设：水的沸点永远是100摄氏度问题：当假设不满足时（如高原上）水可能被烧干真实意图：将水烧开的同时避免烧干→当水壶中的水温低于沸点时，加热装置应当一直处于工作状态需求工程发现、获取、组织、分析、编写和管理需求的系统方法，让客户和项目组之间达成共识。项目前景文档需求获取项目干系人需求需求定义软件需求规约需求验证软件需求基线术语表需求分析分析模型需求管理1002-需求获取01-相关概念03-需求分析1104-需求定义和验证05-需求管理需求工程发现、获取、组织、分析、编写和管理需求的系统方法，让客户和项目组之间达成共识。项目前景文档需求获取项目干系人需求需求定义软件需求规约需求验证软件需求基线术语表需求分析分析模型需求管理12获取需求的难点和误区难点：用户提不出需求难点：需求常常有二义性误区：分析员自认为比用户更理解问题误区：只重视功能需求干系人分析员??难点1：用户提不出需求需求的来源CustomerUsersProblemDomain领域专家业界分析员

竞争信息新需求Bug报告

变更请求运营数据需求规范业务计划个人目标业务模型AnalystPartnersKANO模型举例：空调基本型需求：制冷、制热期望型需求：节能、除湿兴奋型需求：净化空气、远程操控挑战如何获得基本型需求？不能遗漏！用户认为没必要说How:领域专家、竞争产品分析、行业调研分析等如何获得期望型需求？用户谈论的通常是期望型需求How:采用访谈、问卷、开会、观察等方法收集项目干系人的需求如何获得兴奋型需求？用户不知道How:创新！项目干系人需求的获取技术访谈焦点小组会议引导式研讨会（FacilitatedWorkshops）如JointApplicationDevelopment，JAD群体创新技术如头脑风暴法、思维导图等群体决策技术如一致同意、大多数原则、相对多数原则、独裁等问卷调查观察原型法标杆对照（Benchmarking）系统交互图（ContextDiagrams）文件分析甲乙方经验影响需求获取策略开发人员的经验用户的经验低高低高“Fuzzyproblem”“CatchUp”“Mature”“Selling/Teaching”难点2：需求常常有二义性如何消除二义性？举例：ActivateHeatPump自然语言规约Ifthetemperaturedifferenceexceeds2degreesformorethan2seconds,thenthepumpshallactivateforatleast2secondsinnomorethan2seconds.形式化规约21可理解性Understandability二义性AmbiguityThesweetspot

如何减少需求的二义性？用形式化方法，基于数学的方法定义需求用足够详细的、准确的文字描述用法语更好增加术语表用UML等半形式化的语言来建模与分析界面原型需求评审……获取常用术语定义项目用到的术语有助于避免误解记录于单独的术语表文件中术语表Glossary获取常用术语尽早开始在项目过程中持续进行CourseAclassofferedbytheuniversity.CourseOfferingAspecificofferingforacourse,includingdaysoftheweekandtimes.GradeThegradeforthestudentinacourse.ReportCardAllthegradesforallcoursestakenbyastudentinagivensemester.RosterAllthestudentsenrolledinaparticularcourseoffering.TranscriptThehistoryofthegradesforallcoursesforaparticularstudent.界面原型界面原型界面原型为静态的包括主要界面和界面上的主要元素开发的几种方法图纸（在纸上手绘）位图（采用绘图工具，如Visio）可执行代码，即交互式的电子界面原型采用界面原型工具，如Axure、Sketch、Zeplin或直接编程，如采用HTML或编程语言02-需求获取01-相关概念03-需求分析2504-需求定义和验证05-需求管理需求工程发现、获取、组织、分析、编写和管理需求的系统方法，让客户和项目组之间达成共识。项目前景文档需求获取项目干系人需求需求定义软件需求规约需求验证软件需求基线术语表需求分析分析模型需求管理26需求分析对需求进行分析，并进行可视化建模，形成分析模型关注What,NotHow分析建模方法面向对象分析结构化分析……分析模型分析模型是平台无关模型结构化分析模型数据流图（DFD）控制流图（CFD）数据字典（DD）实体—关系图（ERD）状态变迁图（STD）加工说明（PSPEC）控制说明（CSPEC）面向对象分析模型用例图活动图类图时序图通信图状态机图基于用例（Use-Case）

的需求分析Use-Case2规约-简要描述-事件流Use-Case3规约-简要描述-事件流Actor1UseCase2UseCase3UseCase1

Actor2Actor3Use-Case1规约-简要描述-事件流系统Actor和UseCaseActor和系统交互的系统外的某些人或某些东西：最终用户外界软件系统外界硬件设备UsecaseActor想使用系统去做的事ActorUseCaseCourseRegistrationSystem的用例图SelectCoursestoTeachProfessorStudentBillingSystemRegistrarViewGradesAlterCourseSelectionsGetClassListforaCourseCloseRegistrationSubmitGradesRegisterforCoursesCourseCatalogSystemRequestCourseCatalogUse-CaseSpecificationsNameBriefdescriptionFlowofEventsRelationshipsActivitydiagramsUse-CasediagramsSpecialrequirementsPre-conditionsPost-conditionsOtherdiagramsUse-CaseSpecifications...Use-CaseModelActorsUseCases事件流（基本流和备选流）一个基本流HappydayscenarioSuccessfulscenariofromstarttofinish多个备选流RegularvariantOddcasesExceptional(error)flows事件流举例：基本流BasicFlow1.采购员在初始申购单中添加申购子项。2.采购员输入供应商、交货地点、最终价格、返利、加价和费用明细。3.采购员增加、删除和修改申购单（包括第1、2步）直到满意为止。4.采购员在输入所有必要信息后，保存并完成申购单。5.系统检验申购单，分配申购单号，设置申购单和申购单子项状态为“未提交”6.采购员提交申购单。7.系统设置申购单状态为“待审批”，通知采购经理审批申购单。备选流AlternativeFlows1-3a退出：1)系统提示用户保存。2)用户选择不保存，系统放弃临时信息，申购单状态不变。4a.申购单信息不完整：系统提示不能保存，回到步骤3。活动图（ActivityDiagram）作补充ActivityStateSynchronizationBar(Fork)GuardConditionSynchronizationBar(Join)DecisionConcurrentThreadsTransitionSelectCourse[addcourse]CheckScheduleCheckPre-requisitesAssigntoCourseResolveConflictsUpdateScheduleDeleteCourse[checkscompleted][checksfailed][deletecourse]带泳道的活动图用例图的优化：UseCase间的关系Include包含Extend扩展Generalization泛化<<include>><<extend>>02-需求获取01-相关概念03-需求分析3804-需求定义和验证05-需求管理需求工程发现、获取、组织、分析、编写和管理需求的系统方法，让客户和项目组之间达成共识。项目前景文档需求获取项目干系人需求需求定义软件需求规约需求验证软件需求基线术语表需求分析分析模型需求管理39定义软件需求定义FURPS+定义Functionality需求定义Usability需求定义Reliability需求定义Performance需求定义Supportability需求定义+需求定义Functionality需求功能性（Functionality）：特性、功能和安全性Trendinginformationwillbechartedwithalinegraphshowingtimeonthexaxis,andnumberofdefectsfoundontheyaxis.PrintStatus

ReportOperatorProject

Manager概要功能需求详细功能需求Feat63-thedefecttrackingsystemwillprovidetrendinginformationtohelptheprojectmanagerassessprojectstatus定义Usability需求易用性（Usability）：用户学习和操作软件的容易程度。包含人的因素、美观、用户界面的一致性、联机帮助、向导、用户文档和培训材料等方面。典型易用性需求举例普通用户所需的培训时间为1天，高级用户所需的培训时间为2小时用户应在平均3~5分钟内完成选课操作符合公认的易用性标准（如IBM的CUA标准和Microsoft的GUI标准）系统应提供在线帮助文件菜单中的功能要定义快捷键，即Ctrl键和其他键同时按下易学易用!讨论：请为微信写一条易用性需求定义Reliability需求可靠性（Reliability）：软件无故障执行一段时间的概率。典型的可靠性指标可用性Availability

-可用时间百分比(xx.xx%)、使用小时数、维护访问权、降级模式操作等。平均故障间隔时间(MTBF)-通常表示为小时数，但也可表示为天数、月数或年数。平均修复时间(MTTR)-系统在发生故障后可以暂停运行的时间。精确度-指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准）。最高缺陷率-通常表示为bugs/KLOC或bugs/function-point。按照小bug、大bug和严重bug来分类。不要宕机!讨论：请为电梯控制软件写一条可靠性需求定义Performance需求性能（Performance）：软件运行的速度或效率。典型的性能指标：响应时间(平均、最长)：网页的载入和显示应在2秒之内吞吐量：每秒能处理的请求数为1000数据容量：数据库应支持数据存储700GB，且每年按30%的速度递增。并发量：系统可支持1000个并发用户。资源利用情况（内存、磁盘、网络带宽等）：网络带宽为30MBbps，服务器内存为32G。速度要快!讨论：请为12306火车购票系统写一条性能需求定义Supportability需求可支持性（Supportability）：软件易于修改和维护的能力。包括可测试性、可扩展性、可适应性、可维护性、兼容性、可配置性、可服务性、可安装性，或是否可本地化（国际化）等。支持性需求举例：编程语言采用Java，数据库操作语言采用标准SQL符合GoogleJava编程规范应有统一的出错处理与报告机制修改方便!讨论：请为交我办APP写一条可支持需求FURPS+设计约束（designconstraints）：规定或约束了系统的设计的需求；实现需求（implementationrequirements）：规定或约束了系统的编码或构建，如所需标准、编程语言、数据库完整性策略、资源限制和操作环境；接口需求（interfacerequirements）：规定了系统必须与之交互操作的外部软件或硬件，以及对这种交互操作所使用的格式、时间或其他因素的约束；物理需求（physicalrequirements.）：规定了系统必须具备的物理特征，可用来代表硬件要求，如物理网络配置需求。讨论：请为交我办APP写一条设计约束讨论功能需求：后台任务管理器能以不少于60秒的固定时间间隔来提供状态信息性能需求：系统必须支持1000个并发用户，用户响应时间在3秒之内。易用性需求：系统的用户界面友好。这些需求写得如何？如果不好，如何更好地表达?1.后台任务管理器应该在制定的UI区域显示状态信息。1.1后台任务处理开始以后，BTM应该以每60秒(上下加减5秒)的频率来更新消息。1.2在后台处理期间，消息应该保持持续可见。1.3BTM应该显示后台任务完成的百分比。1.4后台任务结束时，BTM应该显示“完成”的消息。1.5如果后台任务延时，BTM应该显示一个消息。概要需求：前景文档（Vision）简介Introduction定位Positioning2.1商机2.2问题说明2.3产品定位干系人和用户描述StakeholderandUserDescriptions产品概述ProductOverview产品特性ProductFeatures约束Constraints质量范围QualityRanges优先级PrecedenceandPriority其它产品需求OtherProductRequirements文档需求DocumentationRequirements1. 简介2. 整体说明3. 具体需求3.1 功能3.2 易用性3.3 可靠性3.4 性能3.5 可支持性3.6 设计约束3.7 联机用户文档和帮助系统需求3.8 购买的构件3.9 接口3.10 许可需求3.11 法律、版权及其他声明3.12 适用的标准4. 支持信息索引、附录等采用传统技术详细需求：SRS文档1.引言1.1Purpose1.2Scope1.3Definitions,Acronyms,andAbbreviations1.4References1.5Overview2.综述2.1Use-CaseModelSurvey2.2AssumptionsandDependencies3.具体需求3.1Use-Case报告

3.1.1<UseCase1> 3.1.2...3.2补充说明

3.2.1易用性需求

3.2.2…4.支持信息索引、附录、用户界面原型等采用Use-Case技术50需求验证原型确认抛弃型原型确认演进型原型确认需求评审评审需求文档（Vision和SRS等），及时发现缺陷，寻找改进的契机，同时从评审反馈中获得知识，补充了正规的交流和培训机制，帮助团队建立对产品的共同理解需求评审方法审查小组评审走查结对编程同级桌查轮查临时评审正式化程度需求评审的输入和输出输入待评审的需求文档Checklist输出评审结论通过有条件通过不通过缺陷清单软件需求基线02-需求获取01-相关概念03-需求分析5404-需求定义和验证05-需求管理需求工程发现、获取、组织、分析、编写和管理需求的系统方法，让客户和项目组之间达成共识。项目前景文档需求获取项目干系人需求需求定义软件需求规约需求验证软件需求基线术语表需求分析分析模型需求管理55需求管理1）定义需求优先级和需求基线2）需求变更控制3）需求跟踪1）建立需求基线，即确定项目范围Feature1:Thesystemmust...Feature2:Thesystemmust...Feature3:Thesystemmust...Feature4:Thesystemmust...Featuren:Thesystemmust...Howdowedeterminepriority?Wheredowesetthebaseline?Howdoweknowwhattheneedsare?TimeProjectStartDateTargetReleaseDate使用需求属性排列特性的优先级FeatureReqt.10ApprovedLowHighFeatureReqt.13ProposedMed.LowFeatureReqt.40ApprovedHighMandatory $$$$$$成本工作量风险状态重要性

其他属性包括稳定性、技术难度等58迭代的特性Release1:LogonRegisterforCoursesInterfacetoCourseCatalogDatabaseMaintainStudentInformationMaintainProfessorInformationRelease2:SubmitStudentGradesViewGradesSelectCoursestoTeach举例：选课系统的特性优先级需求冲突与协商

需求冲突源于不同干系人对于待开发的软件系统的不同看法和利益诉求数据冲突：数