第4章-理解需求课件

第四章 理解需求王美红软 件 工 程1.用户在软件需求分析过程中重要吗?请说明理由2.软件需求分析是软件工程过程中交换意见最频繁的步骤,为什么交换意见的途径会经常阻塞？问题软 件 工 程为什么需求工程非常困难？客户说不清楚需求需求自身不断变动分析人员或客户理解有误软 件 工 程软 件 工 程主要内容需求工程的概念需求工程的任务启动需求工程过程导出需求开发用例软 件 工 程4.1 需求工程需求工程（Requirement Engineering,RE)是指致力于不断理解需求的大量任务和技术。需求工程在设计和构造之间建立起联系的桥梁。软 件 工 程软件需求软件需求包括三个不同的层次:1.业务需求2.用户需求3.功能需求也包括非功能需求。软 件 工 程需求分析的三个层次l业务需求:l反映了组织机构或客户对系统、产品高层次的目标要求。l用户需求:l文档描述了用户使用产品必须要完成的任务。l功能需求:l定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。软 件 工 程软件学院 软件工程导论需求的层次需求的层次软 件 工 程4.1 需求工程把所有与需求直接相关的活动通称为需求工程。需求工程中的活动可分为两大类:一类属于需求开发另一类属于需求管理。软 件 工 程需求工程的结构图需求工程的结构图软 件 工 程4.1 需求工程需求工程通过执行七个不同的活动来完成：1.起始2.导出3.精化4.协商5.规格说明6.确认7.管理软 件 工 程4.1 需求工程1.起始：软件工程是询问一些似乎与项目无直接关系的问题泛谈起始，有各种各样的情况目的是对问题、方案需求方、期望方案的本质、客户和开发人员之间初步的交流和合作的效果建立基本的谅解软 件 工 程4.1 需求工程2.导出询问客户、用户和其他人，系统或产品的目标是什么？想要实现什么？系统和产品任何满足业务的要求，最终系统和产品如何用于日常工作？非常困难：范围问题、理解问题、异变问题软 件 工 程4.1 需求工程3.精化将起始和导出阶段获得的信息进行扩展和提炼是一个分析建模动作精化的最终结果：一个分析模型，定义了问题的信息域、功能域和行为域软 件 工 程4.1 需求工程4.协商需求工程师必须通过协商的过程调节各种冲突按优先级讨论冲突识别和分析风险粗略“估算”开发工作量，并评估每项需求对项目成本和交付时间的影响使用迭代，删除、细化或修改需求，以便各方达到一定的满意度软 件 工 程4.1 需求工程5.规格说明(specification)把前面的成果用文字或其它方式明示出来。可以是一份写好的文档，一套图形化的模型，一个形式化的数学模型，一组使用场景，一个原型或上述各项的任意组合软 件 工 程4.1 需求工程6.确认：要检查规格说明以保证：所有的系统需求已被无歧义地说明；不一致性、疏漏和错误已被检测出并被纠正；工作产品符合为过程、项目和产品建立的标准。由第三方（通常为评审组）完成软 件 工 程4.1 需求工程7.需求管理用于帮助项目组在项目进展中标识、控制和跟踪需求以及变更需求的一组活动。解决方法：特征跟踪表、来源跟踪表、依赖跟踪表、子系统跟踪表、接口跟踪表等。软 件 工 程4.2 建立根基1.确定共利益者直接或间接从正在开发的系统中获益的人比如业务操作管理人员、产品管理人员、市场营销人员、内部或外部客户、最终用户、顾问、产品工程师、软件工程师、支持和维护工程师以及其他人员软 件 工 程4.2 建立根基2.识别多种观点需求工程师就是把所有共利益者提供的信息（包括不一致或者矛盾的需求）分类，分类的方法应该便于决策制定者为系统选择一个内部一致的需求集合。软 件 工 程3.协作如何协作？需求工程师的主要任务是标识公共区域和矛盾区域一个有效的方法是使用“优先点”，所有共利益者都分配一定数量的优先点4.2 建立根基软 件 工 程4.2 建立根基4.首次提问“与环境无关”第一组与环境无关的问题集中于客户和其他共利益者、整体目标、收益：谁是这项工作的最初提出者？谁将使用该解决方案成功的解决方案将带来什么样的经济效益？存在别的解决方法吗？软 件 工 程4.2 建立根基下列一组有软件开发组更好地理解问题，并允许客户表达其他对解决方案的看法：如何描述由某成功的解决方案产生的“良好的”输出？该解决方案强调了什么问题？能向我们展示（或描述）解决方案的使用环境吗？存在影响解决方案的特殊性能问题或约束吗？软 件 工 程4.2 建立根基最后一组问题关注与沟通活动本身的效率：你是回答这些问题的最合适人选吗？你的回答是“正式的”吗？你的提问和你解决的问题相关吗？我的问题是否太多了？还有其他人员可以提供更多的信息吗？还有我应该问的其他问题吗？软 件 工 程4.2 建立根基导出需求的方法：访谈面向数据流自顶向下求精协同需求获取快速建立软件原型质量功能部署用户场景软 件 工 程4.2 建立根基访谈正式访谈事先准备好的具体问题非正式访谈自由问答可借助：调查表再针对性访问情景分析技术(对用户将来使用目标系统解决某个具体问题的方法和结果进行分析)软 件 工 程某出版社系统调查表编号提出问题1您在哪个部门工作？您在哪个部门工作？2出版业务流程是什么？出版业务流程是什么？3您每日都处理哪些文件、数据、报表？您每日都处理哪些文件、数据、报表？4工作中手工处理特别麻烦的事情是什么？工作中手工处理特别麻烦的事情是什么？5工作中手工处理什么问题解决不了？影响效率的问题工作中手工处理什么问题解决不了？影响效率的问题有哪些？有哪些？6您认为提高工作效率，节省工作时间，减轻工作强度您认为提高工作效率，节省工作时间，减轻工作强度可采取哪些办法？可采取哪些办法？软 件 工 程某出版社系统调查表编号提出问题7您的部门需要成本核算和统计的内容有哪些？您的部门需要成本核算和统计的内容有哪些？8您的部门采用计算机管理工作情况如何？您的部门采用计算机管理工作情况如何？9如何改进业务流程使之更合理？如何改进业务流程使之更合理？10哪些问题是目前传统手工方法根本无法解决的？哪些问题是目前传统手工方法根本无法解决的？11出版社计算机管理信息系统需要解决什么问题？出版社计算机管理信息系统需要解决什么问题？软 件 工 程软件需求调查表的编写方法与实例软 件 工 程4.2 建立根基面向数据流自顶向下求精数据决定了需要的处理和算法，是需求分析的出发点需求分析的目标之一是在可行性研究得到的高层数据流图基础上，把数据流和数据存储定义到元素级通过对未知数据和其需要的算法的请教，深入认识系统分析员借助数据流图、数据字典和IPO图向用户解释输入数据是怎么一步步转变成输出数据的。软 件 工 程与用户沟通需求的方法图 面向数据流自顶向下求精过程软 件 工 程4.2 建立根基 协同需求获取面向团队的需求获取方法共利益者和开发人员的团队共同完成：确认问题，为解决方案的要素提供建议，协商不同的方法，以及说明初步的解决方案需求集合。软 件 工 程4.2 建立根基一些基础原则：会议由软件工程师和客户（连同其他的共利益者）共同举办和参与制定筹备和参与会议的规则。建议拟定一个会议议程，这个议程既要足够正式，使其涵盖所有的重要点；但也不能太正式，以鼓励思维的自由交流软 件 工 程4.2 建立根基由一个“主持人”（可以是客户、开发人员或其他外人）控制会议。使用某种“定义机制”（可以是工作表、活动挂图、不干胶贴纸或电子公告牌、聊天室或虚拟论坛）目的是识别问题，提出解决问题的要素，协商不同的方法以及在有利于完成目标的氛围中刻画初步解决方案的需求问题。软 件 工 程4.2 建立根基简易的应用规格说明技术面向团队的需求收集法，提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。软 件 工 程4.2 建立根基简易的应用规格说明技术典型过程：初步访谈，初步确定待解决的问题的范围和解决方案开发者和用户分别写出“产品需求”，要求每位与会者在开会的前几天认真审查产品需求，希望能准确地表达出每个人对目标系统的认识。会议上为每个议题首先创建组合列表，然后创建一张意见一致的列表(对象、服务、约束和性能)分小组，为每张列表的项目制定小型规格说明合并展示小型规格说明，并讨论。每个与会者制定一套确认标准，并提交讨论，最后创建出一件一致的确认标准。由一到多名与会者起草软件需求规格说明书。软 件 工 程与用户沟通需求的方法快速建立软件原型是最准确、最有效、最强大的需求分析技术构造原型的要点是：应该事先用户能看得见的功能（如屏幕演示或打印报表），省略目标系统的“隐含”功能（例如，修改文件）快速原型的特性：快速、容易修改软 件 工 程与用户沟通需求的方法快速建立软件原型可借助方法和工具：第四代技术（数据库查询和报表语言、程序和应用系统生成器及其他非常高级的非过程语言）可重用的软件构件形式化规格说明和原型环境软 件 工 程4.2 建立根基 质量功能部署（Quality Function Development,QFD）是把顾客或市场的要求转化为设计要求、零部件特性、工艺要求、生产要求的多层次演绎分析方法。QFD于70年代初起源于日本三菱重工的神户造船厂应付大量的资金支出和严格的政府法规，取得了很大的成功。他们用矩阵的形式将顾客需求和政府法规同如何实现这些要求的控制因素联系起来。软 件 工 程4.2 建立根基QFD步骤步骤1.关键顾客需求产品特性 2.关键产品特性部件特性3.关键部件特性过程特性 4.过程特性生产特性软 件 工 程4.2 建立根基质量屋是QFD的核心 质量屋是一种确定顾客需求和相应产品或服务性能之间联系的图示方法。各阶段质量屋不同软 件 工 程图 质量屋矩阵软 件 工 程图 蜡烛产品的质量屋软 件 工 程4.2 建立根基QFD对需求的分类：常规需求：也称普通需求，包含客户对项目的最基本需求，是客户对整个项目最为关心的部分。期望需求：客户可能没有表达明确或没有明确提出的需求，但是会让客户提升对项目的满意度。意外需求：也称兴奋需求，如果实现会给客户带来惊喜，但是如果无法实现也不会受到客户责备。软 件 工 程4.2 建立根基QFD通过客户访谈和观察、调查以及检查历史数据为需求手机活动获取原始数据。然后将这些数据翻译成需求表客户意见表，并由客户评审。接下来使用各种图表、矩阵和评估方法抽取期望的需求并努力导出令人兴奋的需求。软 件 工 程4.2 建立根基用户场景通常被称为用例，它提供了系统将如何被使用的描述关注用户将如何使用该功能软 件 工 程4.2 建立根基导出工作产品对于大多数系统而言，工作产品包括：必要性和可行性陈述系统或产品范围的界限说明参与需求导出的客户、用户和其他共利益者的列表系统技术环境的说明需求列表以及每个需求适用的领域限制一系列使用场景，有助于深入了解系统或产品在不同运行环境下的使用任何能够更好地定义需求的原型软 件 工 程4.3 开发用例用例讲述了能表达主体场景的故事：最终用户（扮演多种可能角色中的一个）如何在一特定环境下和系统交互。软 件 工 程4.3 开发用例（续）撰写用例的第一步：定义各类故事中所包含的“参与者”参与者代表了系统运行时，人（或设备）所扮演的角色，在使用系统时，每个参与者都有一个或多个目标。参与者是角色而非最终用户。软 件 工 程4.3 开发用例（续）这些问题有助于我们抽象出系统的参与者：系统开发完成之后，有哪些人会使用这个系统？系统需要从哪些人或其他系统中获得数据？系统会为哪些人或其他系统提供数据？系统会与哪些其他系统相关联？系统是由谁来维护和管理的？软 件 工 程4.3 开发用例（续）撰写用例的第二步：开发用例谁是主要参与者、次要参与者？参与者的目标是什么？故事开始前有什么前提条件？参与者完成的主要工作或功能是什么？按照故事所描述的还可能需要考虑什么异常？参与者的交互中有什么可能的变化？软 件 工 程4.3 开发用例（续）参与者将获得、产生或改变哪些系统信息？参与者必须通知系统外部环境的改变吗?参与者希望从系统获取什么信息？参与者希望能够得知意料之外的变更吗？软 件 工 程软 件 工 程HVAC:供热通风与空气调节软 件 工 程4.3 开发用例SafeHome参与者：房主系统管理员传感器和监控子系统软 件 工 程图：SafeHome控制面板软 件 工 程图：SafeHome住宅安全功能的用例图软 件 工 程软 件 工 程软 件 工 程4.5 构建需求模型分析模型的目的是为基于计算机的系统 提供必要的信息、功能和行为域的说明。分析模型是任意给定时刻的需求快照（更新）软 件 工 程需求模型的元素表达模式选择一种或多种需求模型的特定元素取决于将要使用的分析建模方法软 件 工 程需求模型的元素软 件 工 程4.6 协商需求协调过程的目的是保证所开发的项目计划，在满足利益相关者要求的同时反应软件团队所处真实世界的限制（如时间、人员、预算）最好能利益相关者和软件团队“双赢”软 件 工 程4.7 确认需求模型元素创建后，需要检查一致性、是否有遗漏以及歧义性。每项需求都和系统或产品的整体目标一致吗？所有的需求都已经在相应的抽象层上说明了吗？需求是真正必需的，还是另外加上去的，有可能不是系统目标所必需的特性吗？每项需求都有界定且无歧义吗？每项需求都有归属吗？-一个明确的人软 件 工 程4.7 确认需求有需求与其他需求冲突吗？在系统或产品所处的技术环境下每个需求都能够实现吗？一旦实现后，没想需求是可测试的吗？需求模型恰当地反映了将要构建系统的信息、功能和行为吗？需求模型是否已经使用合适的方式“分割”，能够逐步地揭示详细的信息系统吗？已经使用了需求模式简化需求模型吗？所有的模式都已经恰当地确认了吗？所有的模式都和客户的需求一致吗？软 件 工 程作业4.1 为什么大量的软件开发人员没有足够重视需求工程？以前有没有什么情况让你可以跳过需求工程？4.2 想出三个以上在需求起始阶段可以要问利益相关者的“与情景无关的问题”