软件工程讲义_第四章【荐】.ppt

软件工程 第4章 理解需求 主要内容 需求工程 建立根基 导出需求 开发用例 构建需求模型 协商需求 确认需求 小结 需求工程 需求工程帮助软件工程师更好地理解他们将要解决的问题。其中所包含的一系列任务有助于理解软件将如何影响业务、客户想要什么以及最终用户将如何和软件交互。 软件工程师和项目共利益者都将参与需求工程。 需求工程 在设计和开发某个一流的计算机软件时，如果软件解决的问题不对，那么即使软件再精巧也满足不了任何人的要求。这就是在设计和开发一个基于计算机的系统之前，理解客户需求的重要性。 需求工程 理解问题的需求是软件工程师所面对的最困难的任务之一。 客户难道不知道需要什么？ 最终用户难道对给他们带来实际收益的特征和功能没有清楚的认识？ 很多情况下的确是这样的。甚至即使用户和最终用户清楚地知道他们的要求，这些要求也会在项目的实施过程中改变。 需求工程 需求工程是指致力于不断理解需求的大量任务和技术。从软件过程的角度来看，需求工程是一个软件工程动作，开始于沟通并持续至建模。 需求工程在设计和构造之间建立起联系的桥梁。有人认为开始于项目共利益者，即在那里定义业务需求，刻画用户场景，描述功能和特性，识别项目约束条件。另外一些人可能会建议从宽泛的系统定义开始，此时软件只是更大的系统范围中的一个构件。 但是不管起始点在哪里，横跨这个桥梁将把我们带到项目之上更高的层次：由软件团队检查将要进行的软件工作的内容，必须提交设计和构建需要的特定要求，完成指导工作顺序的优先级定义以及将深切影响随后设计的信息、功能和行为。 需求工程任务 需求工程为以下工作提供了良好的机制：理解客户需要什么，分析要求，评估可行性，协商合理的方案，无歧义地详细说明方案，确认规格说明，管理需求以至将这些需求转化为可运行系统。需求工程过程通过执行七个不同的活动来完成：起始、导出、精化、协商、规格说明、确认和管理。 起始 通常都是当确定了商业要求或发现了潜在的新市场、新服务时项目才开始。业务领域的共利益者定义业务用例，确定市场的宽度和深度，进行粗略的可行性分析，并确定项目范围的工作说明。 在项目起始阶段，软件工程师会询问一些似乎与项目无直接关系的问题。目的是对问题、方案需求方、期望方案的本质、客户和开发人员之间初步的交流和合作的效果建立基本的谅解。 导出 系统或产品的目标是什么？ 想要实现什么？ 系统和产品如何满足业务的要求，最终系统或产品如何用于日常工作？ 而实际上导出需求却是异常的困难。 导出 范围问题：系统的边界不清楚，或客户/用户的说明带有多余的技术细节，这些细节可能会混淆而不是澄清系统的整体目标。 理解问题：客户/用户并不完全确定需要什么，对其计算环境的能力和限制所知甚少，对问题域没有完整的认识，与系统工程师在沟通上有问题，省略那些他们认为是“明显的”信息，确定的需求和其他客户/用户的需求相冲突，需求说明有歧义或不可测试。 易变问题：需求随时间变化。 精化 精化是一个分析建模动作，由一系列的建模和求精任务构成。当描述最终用户如何与系统交互的用户场景创建和求精时，就会发生精化动作，每个用户场景被分解为精炼分析类——最终用户可见的业务域实体。应该定义每个分析类的属性，确定每个类所需要的服务，确定类之间的关联和协作关系，并完成各种UML图作为补充。 精化的最终结果是形成一个精确的需求模型，用以说明软件的功能、特征和信息的各个方面。 协商 需求工程师必须通过协商过程来调解客户提出的过高的目标要求和相互冲突的需求。应该让客户、用户和其他共利益者对各自的需求排序，然后按优先级讨论冲突。识别和分析与每项需求相关联的风险；粗略“估算”开发工作量，并用于评估需求对项目成本和交付时间的影响；使用迭代的方法、删除、组合或修改需求，以便相关各方均能达到一定的满意度。 规格说明 一个规格说明可以是一份写好的文档、一套图形化的模型、一个形式化的数学模型，一组使用场景、一个原型或上述各项的任意组合。 在开发规格说明时保持灵活性有时是必要的，对大型系统而言，文档最好采用自然语言描述和图形化模型来编写。而对于技术环节明确的较小产品或系统，使用场景可能就足够了。 确认 确认将对需求工程的工作产品进行质量评估。需求确认要检查规格说明以保证：所有的系统需求已被无歧义地说明；不一致性、疏漏和错误已被检测出并被纠正；工作产品符合为过程、项目和产品建立的标准。 正式技术评审是最主要的需求确认机制。确认需求的评审小组包括软件工程师、客户、用户和其他共利益者，他们检查系统规格说明，查找内容或解释上的错误，以及可能需要进一步解释澄清的地方、丢失的信息、不一致性、冲突的需求或不现实的需求。 需求确认检查表 需求说明清晰吗？有没有可能造成误解？ 需求的来源（如人员、规则、文档）弄清了吗？需求的最终说明是否