软件工程实践者的研究方法义.pptx

《软件工程实践者的研究方法义.pptx》由会员分享，可在线阅读，更多相关《软件工程实践者的研究方法义.pptx（71页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、第4章 理解需求第1页/共71页主要内容v需求工程v建立根基v导出需求v开发用例v构建需求模型v协商需求v确认需求v小结第2页/共71页需求工程v需求工程帮助软件工程师更好地理解他们将要解决的问题。其中所包含的一系列任务有助于理解软件将如何影响业务、客户想要什么以及最终用户将如何和软件交互。v软件工程师和项目共利益者都将参与需求工程。第3页/共71页需求工程v在设计和开发某个一流的计算机软件时，如果软件解决的问题不对，那么即使软件再精巧也满足不了任何人的要求。这就是在设计和开发一个基于计算机的系统之前，理解客户需求的重要性。第4页/共71页需求工程v理解问题的需求是软件工程师所面对的最困难的任

2、务之一。v客户难道不知道需要什么？v最终用户难道对给他们带来实际收益的特征和功能没有清楚的认识？v很多情况下的确是这样的。甚至即使用户和最终用户清楚地知道他们的要求，这些要求也会在项目的实施过程中改变。第5页/共71页需求工程v需求工程是指致力于不断理解需求的大量任务和技术。从软件过程的角度来看，需求工程是一个软件工程动作，开始于沟通并持续至建模。v需求工程在设计和构造之间建立起联系的桥梁。有人认为开始于项目共利益者，即在那里定义业务需求，刻画用户场景，描述功能和特性，识别项目约束条件。另外一些人可能会建议从宽泛的系统定义开始，此时软件只是更大的系统范围中的一个构件。但是不管起始点在哪里，横跨

3、这个桥梁将把我们带到项目之上更高的层次：由软件团队检查将要进行的软件工作的内容，必须提交设计和构建需要的特定要求，完成指导工作顺序的优先级定义以及将深切影响随后设计的信息、功能和行为。第6页/共71页需求工程任务v需求工程为以下工作提供了良好的机制：理解客户需要什么，分析要求，评估可行性，协商合理的方案，无歧义地详细说明方案，确认规格说明，管理需求以至将这些需求转化为可运行系统。需求工程过程通过执行七个不同的活动来完成：起始、导出、精化、协商、规格说明、确认和管理。第7页/共71页起始v通常都是当确定了商业要求或发现了潜在的新市场、新服务时项目才开始。业务领域的共利益者定义业务用例，确定市场的

4、宽度和深度，进行粗略的可行性分析，并确定项目范围的工作说明。v在项目起始阶段，软件工程师会询问一些似乎与项目无直接关系的问题。目的是对问题、方案需求方、期望方案的本质、客户和开发人员之间初步的交流和合作的效果建立基本的谅解。第8页/共71页导出v系统或产品的目标是什么？v想要实现什么？v系统和产品如何满足业务的要求，最终系统或产品如何用于日常工作？v而实际上导出需求却是异常的困难。第9页/共71页导出v范围问题：系统的边界不清楚，或客户/用户的说明带有多余的技术细节，这些细节可能会混淆而不是澄清系统的整体目标。v理解问题：客户/用户并不完全确定需要什么，对其计算环境的能力和限制所知甚少，对问题

5、域没有完整的认识，与系统工程师在沟通上有问题，省略那些他们认为是“明显的”信息，确定的需求和其他客户/用户的需求相冲突，需求说明有歧义或不可测试。v易变问题：需求随时间变化。第10页/共71页精化v精化是一个分析建模动作，由一系列的建模和求精任务构成。当描述最终用户如何与系统交互的用户场景创建和求精时，就会发生精化动作，每个用户场景被分解为精炼分析类最终用户可见的业务域实体。应该定义每个分析类的属性，确定每个类所需要的服务，确定类之间的关联和协作关系，并完成各种UML图作为补充。v精化的最终结果是形成一个精确的需求模型，用以说明软件的功能、特征和信息的各个方面。第11页/共71页协商v需求工程

6、师必须通过协商过程来调解客户提出的过高的目标要求和相互冲突的需求。应该让客户、用户和其他共利益者对各自的需求排序，然后按优先级讨论冲突。识别和分析与每项需求相关联的风险；粗略“估算”开发工作量，并用于评估需求对项目成本和交付时间的影响；使用迭代的方法、删除、组合或修改需求，以便相关各方均能达到一定的满意度。第12页/共71页规格说明v一个规格说明可以是一份写好的文档、一套图形化的模型、一个形式化的数学模型，一组使用场景、一个原型或上述各项的任意组合。v在开发规格说明时保持灵活性有时是必要的，对大型系统而言，文档最好采用自然语言描述和图形化模型来编写。而对于技术环节明确的较小产品或系统，使用场景

7、可能就足够了。第13页/共71页确认v确认将对需求工程的工作产品进行质量评估。需求确认要检查规格说明以保证：所有的系统需求已被无歧义地说明；不一致性、疏漏和错误已被检测出并被纠正；工作产品符合为过程、项目和产品建立的标准。v正式技术评审是最主要的需求确认机制。确认需求的评审小组包括软件工程师、客户、用户和其他共利益者，他们检查系统规格说明，查找内容或解释上的错误，以及可能需要进一步解释澄清的地方、丢失的信息、不一致性、冲突的需求或不现实的需求。第14页/共71页需求确认检查表v需求说明清晰吗？有没有可能造成误解？v需求的来源（如人员、规则、文档）弄清了吗？需求的最终说明是否已经根据或对照最初来

8、源检查过？v需求是否用定量的术语界定？v其他哪些需求与此需求相关？是否已经使用交叉索引或其他机制清楚地加以说明了？v需求是否违背某个系统领域的约束？v需求是否可以测试？如果可以，能否说明测试检验了需求？v对已经创建的任何系统模型，需求是否可跟踪？v对整体系统/产品目标，需求是否可跟踪？v规格说明的构造方式是否有助于理解、引用和翻译成更技术性的工作产品？v对已创建的规格说明是否建立了索引？v和系统性能、行为及运行特征相关的需求的说明是否清楚？哪些需求是隐含出现的？第15页/共71页需求管理v基于计算机的系统其需求会变更，而且变更的要求贯穿于系统的整个生存期。v需求管理是用于帮助项目组在项目进展中

9、标识、控制和跟踪需求以及变更需求的一组活动。v需求管理从标识开始。每个需求被赋予唯一的标识符。一旦需求被标识，便开始建立跟踪表，每个跟踪表将标识的需求与系统或其环境的一个或多个方面相关联。第16页/共71页建立根基v在理想情况下，利益相关者和软件工程师在同一个小组中工作。在这种情况下，需求工程就只是和组里熟悉的同事进行有意义的交谈。但实际情况往往不是这样。v客户可能正在不同的城市或国家，对于想要什么可能仅有模糊的想法，对于将要构建的系统可能存在不同的意见，技术知识可能很有限，可能仅有有限的时间与需求工程师沟通。软件开发团队经常被迫在这种环境的限制下工作。第17页/共71页确认利益相关者v利益相

10、关者可定义为“直接或间接从正在开发的系统中获益的人”。可以确定如下几个容易理解的利益相关者：业务操作管理人员、产品管理人员、市场营销人员、内部和外部客户、最终用户、顾问、产品工程师、软件工程师、支持和维护工程师以及其他人员。每个共利益者对系统都有不同的考虑，当系统成功开发后所能获得的利益也不相同，同样地，当系统开发失败时所面临的风险也不同。第18页/共71页确认利益相关者v在开始阶段，需求工程师应该创建一个人员列表，列出那些有助于诱导出需求的人员。最初的人员列表将随着接触的共利益者人数增多而增加，因为每个共利益者都将被询问“你认为我还应该和谁交谈”。第19页/共71页识别多种观点v因为存在很多

11、不同的利益相关者，所以系统需求调研也将从很多不同的视角展开。v这些参与者中的每一个人都将为需求工程贡献信息。当从多个角度收集信息时，所形成的需求可能存在不一致性或相互矛盾。需求工程师的工作就是把所有共利益者提供的信息分类，分类的方法应该便于决策制定者为系统选择一个内部一致的需求集合。第20页/共71页协同合作v需求工程师的工作是标识公共区域（即所有共利益者都同意的需求）和矛盾区域或不一致区域（即某个共利益者提出的需求和其他共利益者的需求相矛盾）。v很多情况下，共利益者的协作是提供他们各自关于需求的观点，而一个有力的“项目领导者”可能要对删减哪些需求做出最终判断。第21页/共71页基于“优先点”

12、的投票方案v所有的共利益者都会分配到一定数量的优先点，这些优先点可以适用于很多需求。每个共利益者在一个需求列表上，通过向每个需求分配一个或多个优先点来表明该需求的相对重要性（从他或她的个人观点）。优先点用过之后就不能再次使用，一旦某个共利益者的优先点用完，他就不能再对需求实施进一步的操作。所有共利益者在每项需求上的优先点总数显示了该需求的综合重要性。第22页/共71页首次提问v第一组与环境无关的问题集中于客户和其他共利益者、整体目标、收益。v谁是这项工作的最初提出者？v谁将使用该解决方案？v成功的解决方案将带来什么样的经济收益？v对于这个解决方案你还需要其他资源吗？第23页/共71页首次提问v

13、下一组问题有助于软件开发组更好地理解问题，并允许客户表达其对解决方案的看法。v如何描述由某成功的解决方案产生的“良好的”输出？v该解决方案强调了什么问题？v能向我们展示（或描述）解决方案的使用环境吗？v存在影响解决方案的特殊性能问题或约束吗？第24页/共71页首次提问v最后一组问题关注于沟通活动本身的效率。v你是回答这些问题的合适人选吗？你的回答是“正式的”吗？v我的提问和你想解决的问题相关吗？v我的问题是否太多了？v还有其他人员可以提供更多的信息吗？v还有我应该问的其他问题吗？第25页/共71页首次提问v这些问题将有助于“打破坚冰”，并有助于交流的开始，而且这样的交流对需求导出的成功至关重要

14、。但是，会议形式的问与答并非一定是会取得成功的好方法。事实上，Q&A会议应该仅仅用于首次接触，然后就应该用需求诱导形式（包括问题求解、协商和规格说明）取代。第26页/共71页导出需求v导出需求是与问题求解、精化、谈判和规格说明等方面的元素结合在一起的。为了鼓励合作，一个包括利益相关者和开发人员的团队共同完成如下任务：确认问题，为解决方案的要素提供建议，商讨不同的方法并描述初步的需求解决方案。第27页/共71页协同需求收集v提出面向团队的需求收集方法是为了鼓励合作，即一个包括共利益者和开发人员的团队共同完成如下任务：确认问题，为解决方案的要素提供建议，协商不同的方法，以及说明初步的解决方案需求集

15、合。第28页/共71页协同需求收集会议的基本原则v会议由软件工程师和其他的利益相关者共同举办和参与。v制定筹备和参与会议的规则。v建议拟定一个会议议程，这个议程既要足够正式，使其涵盖所有的重要点；但也不能太正式，以鼓励思想的自由交流。v由一个“调解人”(可以是客户、开发人员或其他人)控制会议。v采用“方案论证手段”。v目的是识别问题，提出要解决方案的要素，协商不同的方法以及在有利于完成目标的氛围中确定一套解决需求问题的初步方案。第29页/共71页协同需求收集v在需求的起始阶段，基本问题和问题的答案确定了问题的范围和对解决方案的整体理解。除了这些最初的会议之外，共利益者要写一个12页的“产品要求

16、”。此外还要选择会议地点、时间和日期，并选举“调解人”。来自开发组和其他共利益者组织的代表被邀请出席会议，在会议召开之前应将产品要求分发给所有的与会者。第30页/共71页SafeHome实例1第31页/共71页协同需求收集v在召开会议评审产品要求的前几天，要求每个与会者列出构成系统周围环境的对象、由系统产生的其他对象以及系统用来完成功能的对象。此外，要求每个与会者列出服务操作或与对象交互的服务（过程或功能）列表。最后，还要开发约束列表（如成本、规模大小、业务规则）和性能标准（如速度、精确度）。这些列表不要求完美无缺，但要反映每个人对系统的理解。第32页/共71页SafeHome实例2第33页/

17、共71页协同需求收集v这些对象列表可以用大的纸张钉在房间的墙上或用便签纸贴在墙上或写在墙板上。或者，列表也可以贴在内部网站的电子公告牌上或聊天室中，便于会议前的评审。理想情况下，应该能够分别操作每个列表项，以便于合并列表、删除项以及加入新项。在本阶段，严禁批评和争论。第34页/共71页协同需求收集v当某个话题域的各个列表被提出后，小组将生成一个组合列表。该组合列表将删除冗余项，并加入在讨论过程中出现的一些新的想法，但是不删除任何东西。在所有话题域的组合列表都生成后，主持人开始讨论协调。组合列表可能会缩短、加长或重新措词，以求更恰当地反映即将开发的产品/系统，目标是为每个话题域（对象、服务、约束

18、或性能）提交一个意见一致的列表，在后面的工作中将用到这个列表。第35页/共71页协同需求收集v一旦完成意见一致的列表，团队被分为更小的子团队，每个子团队试图为每个列表中的一个或多个项目编写小规格说明。每个小规格说明是对包含在列表中的单词或短语的精炼。第36页/共71页SafeHome实例3vSafeHome对象控制面板的小规格说明：对象控制面板的小规格说明：控制面板是一个安装在墙上的装置，尺寸控制面板是一个安装在墙上的装置，尺寸大概是大概是95英寸；控制面板和传感器、计算英寸；控制面板和传感器、计算机之间是无线连接；通过一个机之间是无线连接；通过一个12键的键盘键的键盘与用户交互，通过一个与用

19、户交互，通过一个33的的LCD彩色显示彩色显示器为用户提供反馈信息；软件将提供交互器为用户提供反馈信息；软件将提供交互提示、回显以及类似的功能。提示、回显以及类似的功能。第37页/共71页协同需求收集v然后，每个子团队将他们完成的每个小规格说明提交给所有的与会者讨论，进行添加、删除和进一步细化等工作。在某些情况下，编写小规格说明可能会发现新的对象、服务、约束或性能需求，可以将这些新发现加入到原始列表中。在所有的讨论过程中，团队可能会提出某些在会议上不能解决的问题，将这些问题列表保留起来以便这些意见在以后的工作中发挥作用。第38页/共71页质量功能部署v质量功能部署QFD是一种将客户要求转化成软

20、件技术需求的质量管理技术。QFD强调理解“什么是对客户有价值的”，然后在整个工程活动中部署这些价值。第39页/共71页QFD确认的需求v正常需求：这些需求反映了在和客户开会时确定的针对某产品或系统的目标。如果实现了这些需求，将满足客户。v期望需求：这些需求隐含在产品或系统中，并且可能是非常基础的以至于客户没有显式地说明，但是缺少这些将导致客户明显不满。v令人兴奋的需求：这些需求反映了客户期望之外的特点，但是如果实现这些特点的话将会使客户非常满意。第40页/共71页质量功能部署vQFD通过客户访谈和观察、调查以及检查历史数据（如问题报告）为需求收集活动获取原始数据。然后把这些数据翻译成需求表称为

21、客户意见表，并由客户评审。接下来使用各种图表、矩阵和评估方法抽取期望的需求并努力导出令人兴奋的需求。第41页/共71页用户场景v当收集需求时，系统功能和特点的整体愿景开始具体化。但是在软件团队弄清楚不同类型的最终用户如何使用这些功能和特征之前，很难转移到更技术化的软件工程活动。为实现这一点，开发人员和用户可以创建一系列的场景场景可以识别对将要构建的系统的使用线索。场景通常称为用例，它提供了系统将如何被使用的描述。第42页/共71页导出工作产品v要求和可行性陈述。v系统或产品范围的界限说明。v参与需求导出的客户、用户和其他共利益者的列表。v系统技术环境的说明。v需求列表以及每个需求适用的领域限制

22、。v一系列使用场景，有助于深入了解系统或产品在不同运行环境下的使用。v任何能够更好地定义需求的原型。第43页/共71页开发用例v一个用例捕获一个合同，即说明当对某个共利益者的请求响应时，在各种条件下系统的行为。本质上，用例讲述了能表达主体场景的故事：最终用户如何在一特定环境下和系统交互。这个故事可以是叙述性的文本、任务或交互的概要、基于模板的说明或图表显示。不管形式如何，用例从最终用户的角度描述了软件或系统。第44页/共71页开发用例v撰写用例的第一步是定义各类故事中所包含的“参与者”。参与者是在将要说明的功能和行为环境内使用系统或产品的各类人员（或设备）。参与者是任何与系统或产品通信的事物，

23、且对系统本身而言参与者是外部的。当使用系统时，每个参与者都有一个或多个目标。第45页/共71页开发用例v参与者与最终用户并非一回事。典型的用户可能在使用系统时扮演了许多不同的角色，而参与者表示了一类外部实体（经常是人员，但不限于人员），在用例中他们仅扮演一种角色。例如，考虑一个机床操作员（一个用户），他和生产车间（其中布置了许多机器人和数控机床）内的某个控制计算机交互。在仔细考察需求后，控制计算机的软件需要四种不同的交互模式（角色）：编程模式、测试模式、监测模式和纠错模式。4个参与者可定义为：程序员、测试员、监控员和故障检修员。有些情况下，机床操作员可以扮演所有这些角色，而有些情况下，每个参与

24、者的角色可能由不同的人员扮演。第46页/共71页开发用例v需求导出是一个逐步演化的活动，第一次迭代中并不能确认所有的参与者。在第一次迭代中有可能识别主要的参与者，而对系统了解更多之后，才能识别出次要的参与者。主要参与者直接且经常使用软件，和他们交互可以获取所需的系统功能并导出系统的预期收益。次要参与者支持系统，以便主要参与者能够完成他们的工作。第47页/共71页开发用例v一旦确认了参与者，就可以开发用例。为了开发一个有效用例，可以考虑如下问题：v谁是主要参与者、次要参与者？v参与者的目标是什么？v故事开始前有什么前提条件？v参与者完成的主要工作或功能是什么？v按照故事所描述的还可能需要考虑什么

25、异常？v参与者的交互中有什么可能的变化？v参与者将获得、产生或改变哪些系统信息？v参与者必须通知系统外部环境的改变吗？v参与者希望从系统获取什么信息？v参与者希望得知意料之外的变更吗？第48页/共71页SafeHome实例4第49页/共71页SafeHome实例5第50页/共71页SafeHome实例6第51页/共71页SafeHome实例7第52页/共71页SafeHome实例8第53页/共71页SafeHome实例9第54页/共71页SafeHome实例10第55页/共71页SafeHome实例11第56页/共71页构建需求模型v分析模型的目的是为基于计算机的系统提供必要的信息、功能和行为

26、域的说明。随着软件工程师更多地了解将要实现的系统以及其他利益相关者更多地了解他们到底需要什么，模型将动态地变更。v当需求模型演化时，某些元素将变得相对稳定，为后续设计任务提供稳固的基础。但是，有些模型元素可能是不稳定的，这表明利益相关者仍然没有完全理解系统的需求。第57页/共71页需求模型的元素v有很多不同的方法考察计算机系统的需求。某些软件人员坚持最好选择一个表达模式（如用例）并排斥所有其他模式。有些专业人士则相信使用许多不同的表现模式来描述需求模型是值得的，不同的表达模式促使软件团队从不同的角度考虑需求一种方法更有可能造成需求遗漏、不一致性和歧义性。第58页/共71页基于场景的元素v使用基

27、于场景的方法可以从用户的视角描述系统。例如，基本的用例及其相应的用例图演化成更精细的基于模板的用例。课本图4-3描绘了一张使用用例引发的需求并表达它们的UML活动图。第59页/共71页导出需求的UML活动图课本图4-3 导出需求的UML活动图第60页/共71页基于类的元素v每个使用场景都暗示着当一个参与者和系统交互时所操作的一组对象，这些对象被分成类具有相似属性和共同行为的事物集合。例如：可以用UML类图描绘SafeHome安全功能的传感器Sensor类如课本图4-4所示。除了类图，其他分析建模元素描绘了类相互之间的协作以及类之间的关联和交互。第61页/共71页传感器Sensor的类图课本图4

28、-4 传感器Sensor的类图第62页/共71页行为元素v基于计算机系统的行为能够对所选择的设计和所采用的实现方法产生深远的影响。因此，需求分析模型必须提供描述行为的建模元素。v状态图是一种表现系统行为的方法，该方法描绘系统状态以及导致系统改变状态的事件。状态是任何可以观察到的行为模式。另外，状态图还指明了在某个特殊事件后采取什么动作。第63页/共71页UML状态图表示课本图4-5 UML状态图表示第64页/共71页面向数据流的元素v信息在基于计算机的系统中流动时会被转换，系统接受多种形式的输入；使用函数将其转换；生成多种形式的输出。v我们可以为任何基于计算机的系统创建数据流模型。第65页/共

29、71页分析模式v任何有一些软件项目需求工程经验的人都开始注意到，在特定的应用领域内某些事情在所有的项目中重复发生。分析模式为特定应用领域提供了一些解决方案，在为许多应用项目建模时可以重复使用。v分析模式提高了抽象分析模型的开发速度，通过提供可重复使用的分析模型捕获具体问题的主要需求。v通过建议的设计模式和可靠的通用问题解决方案，分析模式有利于把分析模型转变到设计模型。第66页/共71页协商需求v在一个理想的需求工程情境中，起始、导出和精化工作能确保得到足够详细的客户需求，以开展后续的软件工程步骤。但这几乎不可能发生。实际上，一个或多个利益相关者恐怕得进入到协商的过程中。v最好的协商是争取“双赢”的结果，即利益相关者的“赢”在于获得满足客户大多数需要的系统或产品，而作为软件团队一员的“赢”在于按照实际情况、在可实现的预算时间期限内完成工作。第67页/共71页确认需求v当需求模型的每个元素都已创建时，需要检查一致性、是否有遗漏以及歧义性。模型所表现的需求由利益相关者划分优先级并组合成一个整体，该需求整体将以软件逐步加以实现。需求模型的评审将提出一些问题（课本80-81页）第68页/共71页小结v课本81页第69页/共71页作业P82页 4.9 a 第70页/共71页感谢您的观看！第71页/共71页