软件工程之需求工程

第七章 需求工程 需求工程的概念: 在开始任何技术工作之前，关注于一系列需求工程任务都是个好主意。这 些任务有助于你理解软件将如何影响业、客户想要什么以及最终用户将如何和软件交互。 需求工程的步骤： 需求工程首先是 起始阶段 （定义将要解决的问题的范围和性质);然后是 获取 （帮助利益相关者定义需要什么);接下来是 细化 (精确定义和修改基本需求)。当利益相关者提出问题后，就要进行 协商 （如何定义优先次序?什么是必需的?何时需要?）最后， 以某种形式明确说明问题 ， 再经过评审或确认以保证我们和利益相关者对于问题的理解是一致的。 需求工程的质量保证措施： 利益相关者评审需求工程的工作产品，以确保你所理解的正是他们真正想要的。需要提醒大家的是:即使参与各方均认可，事情也会有变化，而且变化可能贯穿整个项目实施过程。 1 需求工程(Requirement Engineering，RE） 需求工程是指致力于不断理解需求的大量任务和技术。从软件过程的角度来看，需求工程是一个软件工程动作，开始于沟通并持续到建模活动。它必须适用于过程、项目、产品和人员的需要。 需求工程包括七项明确的任务:起始，获取，细化，协商，规格说明，确认和管理。注意，这些需求工作中的一些任务会并行发生，并且要全部适应项目的要求。 2 需求工程建立根基 2.1 确认利益相关者：利益相关者定义为“直接或间接地从正在开发的系统中获益的人。 2.2 识别多重观点：因为存在很多不同的利益相关者，所以系统需求调研也将从很多不同的视角开展。 2.3 协同合作：合作精神 2.4 首次提问：在项目开始时的提问应该是“与环境无关的”[Gau89]。第一组与环境 无关的问题集中于客户和其他利益相关者以及整体目标和收益。 3 获取需求 3.1 协作收集需求 3.2 质量功能部署 3.3 使用场景 3.4 获取工作产品 3.5 敏捷获取需求 3.6 面向服务的方法 4 开发用例 5 构建分析模型 分析模型的作用是为基于计算机的系统提供必要的信息、功能和行为域的说明。 随着软件工程师更多地了解将要实现的系统以及其他相关利益者更多地了解他们到底需要什么，模型应能够动态变更。随着分析模型的演化，某些元素将变得相对稳定，为后续设计任务提供稳固的基础。 5.1 分析模型的元素 5.1.1 基于场景的元素： 需求模型的基于场景的元素通常是正在开发的模型的第一部分。如下图是获取需求并用用例进行表述的UML 活动图°，图中给出了最终基于场景的三层详细表达。 5.1.2 基于类的元素 基于类的元素。每个使用场景都意味着当一个参与者和系统交互时所操作的一组对象，这些对象被分成类——具有相似属性和共同行为的事物集合。例如，可以用UML类图描绘SafeHome安全功能的Sensor类。 行为元素。 基于计算机的系统行为能够对所选择的设计和所采用的实现方法产生深远的影响。 因此，需求分析模型必须提供描述行为的建模元素。状态图是一种表现系统行为的方法，该方法描绘系统状态以及导致系统改变状态的事件。状态是任何可以观察到的行为模式。另外，状态图还指明了在某个特殊事件后采取什么动作（例如激活处理) 。简化sensor类的UML状态图如下所示： 5.2 分析模式 任何有一些软件项目需求工程经验的人都开始注意到，在特定的应用领域内某些事情在所有的项目中重复发生R。这些分析模式[Fow97]在特定应用领域内提供一些解决方案（如类、能、行为)，在为许多应用项目建模时都可以重复使用。 分析模式提高了抽象分析模型的开发速度，通过提供可重复使计模式和可靠的通用问题解决方案，分析模式有利于把分析模型转化为设计模型。用的分析模型捕获具体问题的主要需求，例如关于优点和约束的说明。其次，通过建议的设计模式和可靠的通用问题解决方案，分析模式有利于把分析模型转化为设计模型。 5.3 敏捷需求工程 敏捷需求工程的意图是把利益相关者的思想传递给软件团队，而不是生成扩展的分析工作产品。在许多情况下，需求未被预定义，但可作为每次产品迭代开发的开始。当敏捷团队深人地理解了产品的关键特性时，与下一个产品的增量相关的用户故事(第5章）便可得到精炼敏捷过程鼓励尽早定义和实施优先级最高的产品特性，这样能尽早生成并测试工作原型。 5.4 自适应系统的需求 自适应系统能自我调整配置、增加功能、自我保护并从失效中恢复，而且，在完成这些活动时，其内部复杂性是对用户隐藏的[Qur09]。自适应需求阐明了自适应系统的各种必备的变化性。 6 避免常见错误 软件团队实施需求工程时必须避免的三个相关错误即对特性、灵活性和性能的过分偏好。主要是各方面都要平衡到。