《软件工程实践者的研究方法(第七版)讲义》由会员分享，可在线阅读，更多相关《软件工程实践者的研究方法(第七版)讲义（71页珍藏版）》请在金锄头文库上搜索。
1、软件工程第4章 理解需求主要内容v需求工程v建立根基v导出需求v开发用例v构建需求模型v协商需求v确认需求v小结需求工程v需求工程帮助软件工程师更好地理解他们 将要解决的问题。其中所包含的一系列任 务有助于理解软件将如何影响业务、客户 想要什么以及最终用户将如何和软件交互 。v软件工程师和项目共利益者都将参与需求 工程。需求工程v在设计和开发某个一流的计算机软件时， 如果软件解决的问题不对，那么即使软件 再精巧也满足不了任何人的要求。这就是 在设计和开发一个基于计算机的系统之前 ，理解客户需求的重要性。需求工程v理解问题的需求是软件工程师所面对的最 困难的任务之一。v客户难道不知道需要什么？v
2、最终用户难道对给他们带来实际收益的特 征和功能没有清楚的认识？v很多情况下的确是这样的。甚至即使用户 和最终用户清楚地知道他们的要求，这些 要求也会在项目的实施过程中改变。需求工程v需求工程是指致力于不断理解需求的大量任务和技术。 从软件过程的角度来看，需求工程是一个软件工程动作 ，开始于沟通并持续至建模。v需求工程在设计和构造之间建立起联系的桥梁。有人认 为开始于项目共利益者，即在那里定义业务需求，刻画 用户场景，描述功能和特性，识别项目约束条件。另外 一些人可能会建议从宽泛的系统定义开始，此时软件只 是更大的系统范围中的一个构件。但是不管起始点在哪 里，横跨这个桥梁将把我们带到项目之上更高
3、的层次： 由软件团队检查将要进行的软件工作的内容，必须提交 设计和构建需要的特定要求，完成指导工作顺序的优先 级定义以及将深切影响随后设计的信息、功能和行为。需求工程任务v需求工程为以下工作提供了良好的机制： 理解客户需要什么，分析要求，评估可行 性，协商合理的方案，无歧义地详细说明 方案，确认规格说明，管理需求以至将这 些需求转化为可运行系统。需求工程过程 通过执行七个不同的活动来完成：起始、 导出、精化、协商、规格说明、确认和管 理。起始v通常都是当确定了商业要求或发现了潜在 的新市场、新服务时项目才开始。业务领 域的共利益者定义业务用例，确定市场的 宽度和深度，进行粗略的可行性分析，并
4、确定项目范围的工作说明。v在项目起始阶段，软件工程师会询问一些 似乎与项目无直接关系的问题。目的是对 问题、方案需求方、期望方案的本质、客 户和开发人员之间初步的交流和合作的效 果建立基本的谅解。导出v系统或产品的目标是什么？v想要实现什么？v系统和产品如何满足业务的要求，最终系 统或产品如何用于日常工作？v而实际上导出需求却是异常的困难。导出v范围问题：系统的边界不清楚，或客户/用户的 说明带有多余的技术细节，这些细节可能会混淆 而不是澄清系统的整体目标。v理解问题：客户/用户并不完全确定需要什么， 对其计算环境的能力和限制所知甚少，对问题域 没有完整的认识，与系统工程师在沟通上有问题 ，省
5、略那些他们认为是“明显的”信息，确定的需 求和其他客户/用户的需求相冲突，需求说明有 歧义或不可测试。v易变问题：需求随时间变化。精化v精化是一个分析建模动作，由一系列的建模和求 精任务构成。当描述最终用户如何与系统交互的 用户场景创建和求精时，就会发生精化动作，每 个用户场景被分解为精炼分析类最终用户可 见的业务域实体。应该定义每个分析类的属性， 确定每个类所需要的服务，确定类之间的关联和 协作关系，并完成各种UML图作为补充。v精化的最终结果是形成一个精确的需求模型，用 以说明软件的功能、特征和信息的各个方面。 协商v需求工程师必须通过协商过程来调解客户 提出的过高的目标要求和相互冲突的需
6、求 。应该让客户、用户和其他共利益者对各 自的需求排序，然后按优先级讨论冲突。 识别和分析与每项需求相关联的风险；粗 略“估算”开发工作量，并用于评估需求对 项目成本和交付时间的影响；使用迭代的 方法、删除、组合或修改需求，以便相关 各方均能达到一定的满意度。规格说明v一个规格说明可以是一份写好的文档、一 套图形化的模型、一个形式化的数学模型 ，一组使用场景、一个原型或上述各项的 任意组合。v在开发规格说明时保持灵活性有时是必要 的，对大型系统而言，文档最好采用自然 语言描述和图形化模型来编写。而对于技 术环节明确的较小产品或系统，使用场景 可能就足够了。确认v确认将对需求工程的工作产品进行质
7、量评估。需 求确认要检查规格说明以保证：所有的系统需求 已被无歧义地说明；不一致性、疏漏和错误已被 检测出并被纠正；工作产品符合为过程、项目和 产品建立的标准。v正式技术评审是最主要的需求确认机制。确认需 求的评审小组包括软件工程师、客户、用户和其 他共利益者，他们检查系统规格说明，查找内容 或解释上的错误，以及可能需要进一步解释澄清 的地方、丢失的信息、不一致性、冲突的需求或 不现实的需求。需求确认检查表v需求说明清晰吗？有没有可能造成误解？v需求的来源（如人员、规则、文档）弄清了吗？需求的最终说明是否 已经根据或对照最初来源检查过？v需求是否用定量的术语界定？v其他哪些需求与此需求相关？是
8、否已经使用交叉索引或其他机制清楚 地加以说明了？v需求是否违背某个系统领域的约束？v需求是否可以测试？如果可以，能否说明测试检验了需求？v对已经创建的任何系统模型，需求是否可跟踪？v对整体系统/产品目标，需求是否可跟踪？v规格说明的构造方式是否有助于理解、引用和翻译成更技术性的工作 产品？v对已创建的规格说明是否建立了索引？v和系统性能、行为及运行特征相关的需求的说明是否清楚？哪些需求 是隐含出现的？需求管理v基于计算机的系统其需求会变更，而且变 更的要求贯穿于系统的整个生存期。v需求管理是用于帮助项目组在项目进展中 标识、控制和跟踪需求以及变更需求的一 组活动。v需求管理从标识开始。每个需求
9、被赋予唯 一的标识符。一旦需求被标识，便开始建 立跟踪表，每个跟踪表将标识的需求与系 统或其环境的一个或多个方面相关联。建立根基v在理想情况下，利益相关者和软件工程师 在同一个小组中工作。在这种情况下，需 求工程就只是和组里熟悉的同事进行有意 义的交谈。但实际情况往往不是这样。v客户可能正在不同的城市或国家，对于想 要什么可能仅有模糊的想法，对于将要构 建的系统可能存在不同的意见，技术知识 可能很有限，可能仅有有限的时间与需求 工程师沟通。软件开发团队经常被迫在这 种环境的限制下工作。确认利益相关者v利益相关者可定义为“直接或间接从正在开 发的系统中获益的人”。可以确定如下几个 容易理解的利益
10、相关者：业务操作管理人 员、产品管理人员、市场营销人员、内部 和外部客户、最终用户、顾问、产品工程 师、软件工程师、支持和维护工程师以及 其他人员。每个共利益者对系统都有不同 的考虑，当系统成功开发后所能获得的利 益也不相同，同样地，当系统开发失败时 所面临的风险也不同。确认利益相关者v在开始阶段，需求工程师应该创建一个人 员列表，列出那些有助于诱导出需求的人 员。最初的人员列表将随着接触的共利益 者人数增多而增加，因为每个共利益者都 将被询问“你认为我还应该和谁交谈”。识别多种观点v因为存在很多不同的利益相关者，所以系 统需求调研也将从很多不同的视角展开。v这些参与者中的每一个人都将为需求工
11、程 贡献信息。当从多个角度收集信息时，所 形成的需求可能存在不一致性或相互矛盾 。需求工程师的工作就是把所有共利益者 提供的信息分类，分类的方法应该便于决 策制定者为系统选择一个内部一致的需求 集合。协同合作v需求工程师的工作是标识公共区域（即所 有共利益者都同意的需求）和矛盾区域或 不一致区域（即某个共利益者提出的需求 和其他共利益者的需求相矛盾）。v很多情况下，共利益者的协作是提供他们 各自关于需求的观点，而一个有力的“项目 领导者”可能要对删减哪些需求做出最终判 断。基于“优先点”的投票方案v所有的共利益者都会分配到一定数量的优 先点，这些优先点可以适用于很多需求。 每个共利益者在一个需
12、求列表上，通过向 每个需求分配一个或多个优先点来表明该 需求的相对重要性（从他或她的个人观点 ）。优先点用过之后就不能再次使用，一 旦某个共利益者的优先点用完，他就不能 再对需求实施进一步的操作。所有共利益 者在每项需求上的优先点总数显示了该需 求的综合重要性。首次提问v第一组与环境无关的问题集中于客户和其 他共利益者、整体目标、收益。v谁是这项工作的最初提出者？v谁将使用该解决方案？v成功的解决方案将带来什么样的经济收益？v对于这个解决方案你还需要其他资源吗？首次提问v下一组问题有助于软件开发组更好地理解 问题，并允许客户表达其对解决方案的看 法。v如何描述由某成功的解决方案产生的“良好的
13、”输出？v该解决方案强调了什么问题？v能向我们展示（或描述）解决方案的使用环 境吗？v存在影响解决方案的特殊性能问题或约束吗 ？首次提问v最后一组问题关注于沟通活动本身的效率 。v你是回答这些问题的合适人选吗？你的回答 是“正式的”吗？v我的提问和你想解决的问题相关吗？v我的问题是否太多了？v还有其他人员可以提供更多的信息吗？v还有我应该问的其他问题吗？首次提问v这些问题将有助于“打破坚冰”，并有助于 交流的开始，而且这样的交流对需求导出 的成功至关重要。但是，会议形式的问与 答并非一定是会取得成功的好方法。事实 上，Q&A会议应该仅仅用于首次接触，然 后就应该用需求诱导形式（包括问题求解 、
14、协商和规格说明）取代。导出需求v导出需求是与问题求解、精化、谈判和规 格说明等方面的元素结合在一起的。为了 鼓励合作，一个包括利益相关者和开发人 员的团队共同完成如下任务：确认问题， 为解决方案的要素提供建议，商讨不同的 方法并描述初步的需求解决方案。协同需求收集v提出面向团队的需求收集方法是为了鼓励 合作，即一个包括共利益者和开发人员的 团队共同完成如下任务：确认问题，为解 决方案的要素提供建议，协商不同的方法 ，以及说明初步的解决方案需求集合。协同需求收集会议的基本原则v会议由软件工程师和其他的利益相关者共同举办 和参与。v制定筹备和参与会议的规则。v建议拟定一个会议议程，这个议程既要足够
15、正式 ，使其涵盖所有的重要点；但也不能太正式，以 鼓励思想的自由交流。v由一个“调解人”(可以是客户、开发人员或其他 人)控制会议。v采用“方案论证手段”。v目的是识别问题，提出要解决方案的要素，协商 不同的方法以及在有利于完成目标的氛围中确定 一套解决需求问题的初步方案。 协同需求收集v在需求的起始阶段，基本问题和问题的答 案确定了问题的范围和对解决方案的整体 理解。除了这些最初的会议之外，共利益 者要写一个12页的“产品要求”。此外还 要选择会议地点、时间和日期，并选举“调 解人”。来自开发组和其他共利益者组织的 代表被邀请出席会议，在会议召开之前应 将产品要求分发给所有的与会者。Safe
16、Home实例1协同需求收集v在召开会议评审产品要求的前几天，要求 每个与会者列出构成系统周围环境的对象 、由系统产生的其他对象以及系统用来完 成功能的对象。此外，要求每个与会者列 出服务操作或与对象交互的服务（过程或 功能）列表。最后，还要开发约束列表（ 如成本、规模大小、业务规则）和性能标 准（如速度、精确度）。这些列表不要求 完美无缺，但要反映每个人对系统的理解 。SafeHome实例2协同需求收集v这些对象列表可以用大的纸张钉在房间的 墙上或用便签纸贴在墙上或写在墙板上。 或者，列表也可以贴在内部网站的电子公 告牌上或聊天室中，便于会议前的评审。 理想情况下，应该能够分别操作每个列表 项，以便于合并列表、删除项以及加入新 项。在本阶段，严禁批评和争论。协同需求收集v当某个话题域的各个列表被提出后，小组 将生成一个组合列表。该组合列表将删除 冗余项，并加入在讨论过程中出现的一些 新的想法，但是不删除任何东西。在所有 话题域的组合列表都生成后，主持人开始 讨论协调。组合列表可能会缩短、加长或 重新措词，以求更恰当地反映即将开发的 产品/系统，目标是为每个话题域（对象、
