软件工程--实践者的研究方法[基于场景需求建模]

8.1 需求分析

• 需求分析目的是产生软件操作特征的规格说明，指明软件和其他系统元素的接口，建立软件必须满足的约束。
• 需求分析是细化基础要求，这些基础需求在前期需求工程的起始、导出、协商任务中建立的。
• 需求建模是使用文字、图表等综合形式，以相对容易理解的方式描述需求，特别是为了能够直接评审其正确性、完整性和一致性。

需求建模的结果为以下一种或多种模型类型：

• 场景建模：出自各系统“参与者”观点的需求。
• 数据模型：描述问题信息域的模型。
• 面向类的模型：表示面向对象类的模型，其方式为通过类的协作获得系统需求。
• 面向流程的模型：表示系统的功能元素并且描述当前功能元素在系统中运行时怎样进行数据变换的模型。
• 行为模型：描述如何将软件行为看做是外部“事件”后续的模型。

8.1.1 需求分析目标和原理

• 在整个需求分析建模过程中，软件工程师的主要关注点集中在“做什么”而不是“怎么做”方面。
• 具体包括
  • 在特定环境下发生哪些用户交互？
  • 系统处理什么对象？
  • 系统必须执行什么功能？
  • 系统显示什么行为？
  • 定义什么接口？
  • 有什么约束？

总体目标和原理

• 需求分析建立的模型必须实现三个主要目标：
  • 描述客户需要什么；
  • 为软件设计奠定基础；
  • 定义在软件完成后可以被确认的一组需求。
• 需求模型是系统描述和设计之间的桥梁。
• 需求模型的所有元素都可以直接跟踪到设计模型。

三者的关系

• 需求模型（也称分析模型）
• 通常难以清楚地区分需求建模和设计建模活动之间的设计和分析工作
• 需求分析中有系统设计，系统设计中也有部分分析。

8.1.2 分析的经验原则

• 需求分析模型应关注在问题域或业务域内可见的需求，抽象的级别应该相对高一些，”不要陷入细节“。
• 分析模型的每个元素都应能增加对软件需求的整体理解，并提供对信息域、功能和系统行为的深入理解。
• 关于基础结构和其他非功能的模型应推延到设计阶段再考虑。
• 最小化整个系统内的关联。
• 确认分析模型为所有利益相关者都带来价值。
• 尽可能保持模型简洁。

8.1.3 域分析

• 软件域分析是识别、分析和详细说明来自某个特定应用领域的公共需求，特别是那些在该应用领域内被多个项目重复使用的。
• 面向对象的域分析是在某个特定应用领域内，根据通用的对象、类、部件和框架、识别、分析和详细说明公共的、可复用的能力。
• 域分析的目标是：查找或创建那些广泛应用的分析类或分析模式，使其能够复用。

域分析的输入和输出

说明：
域分析是为了领域内复用，形成过程资产价值。

8.1.4 需求建模的方法

• 需求建模的两种方法：
  • 结构化分析方法和面向对象分析方法。
• 结构化分析方法：基本观点认为系统是数据和对数据的加工，建模是为了明确数据在系统中如何流动处理加工和转换。
• 面向对象的分析方法：关注于定义类和影响客户需求的类之间的协作方式。
• UML和统一过程主要是面向对象的。
• 软件团队往往 - 结构化分析方法和面向对象分析方法。中的所有表示手段。问题不是哪一种方法最好，而是怎么组合这些表示手段才能够提供最好的软件需求模型和过渡到软件设计的最有效方法。
• 需