背诵

系统分析和需求工程

需求获取

需求获取方法

• 用户访谈：1对1-3,有代表性的用户。其形式包括结构化和非结构化两种。结构化是指事先准备好一系列问题，有针对地进行；而非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。包括准备访谈、主持访谈和访谈的后续工作。
  • 优点是灵活，应用范围广；
  • 缺点是记录困难，时间有限，对系统分析师要求高（ 沟通技巧 、领域知识 、丰富的经验 ）。
• 问卷调查：用户多，无法一一访谈。关键在于制作好的调查表，
  • 优点是广撒网，代价小，信息真实（允许匿名），结果好统计；
  • 缺点是缺乏灵活性。用户不重视，无法对问题进行展开回答并了解细节
• 采样：从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。样本数量=0.25*(可信度因子/错误率)²
  • 优点：是提高了数据收集的效率降低了成本，减少数据收集偏差（使用了数理统计原理）；
  • 缺点：样本规模的确定依赖于期望的可信度和已有的先验知识，很大程度上取决于系统分析师的主观因素。 对系统分析师个人的经验和能力依赖性很强
• 情节串联板：一系列图片，通过这些图片来讲故事。
  • 优点是给用户直观的演示，交互性强，生动；
  • 缺点是花费时间多，效率低（ 需求获取的速度大大降低 ）。
• 联合需求计划( JRP ) : 是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，它是联合应用开发（JAD） 的一部分。用小组工作会议来代替大量独立的访谈
  • 优势：用户参与度高、消除分歧（ 各方对需求不明确 ）
  • 成本较高、需要有较高议组织能力

需求分析

需求分析的工作：把杂乱无章的用户要求和期望转化为用户需求

需求分析的任务

1. 绘制系统上下文范围关系图
2. 创建用户界面原型
3. 分析需求的可行性
4. 确定需求的优先级
5. 为需求建立模型
6. 创建数据字典
7. 使用QFD（质量功能部署）

方法的对比

SA方法关注于功能的分层和分解，这非常符合人们自上而下、逐步分解问题直到可解决的自然思考方式。SA方法本身隐含着几个基本假设，即问题域是可定义的、问题域是有限的、通过有限的步骤总可以将复杂问题分解到可解决的程度。
OOA方法则遵循完全不同的思维方式，它基于抽象、信息隐藏、功能独立和模块化这些基本理念对系统进行分析。OOA方法首先对问题域的事物的“外在表象”进行观测，然后在逻辑世界中模拟出一个对应的逻辑对象，“断定”该对象和现实事物是一致的。随后，观测到的对象被记录入对象集合，观测到的行为和表象被记录入对象关系模型和对象行为模型。

数据流图

DFD是SA 方法中的重要工具，是表达系统内数据的流动并通过数据流描述系统功能的一种方法

DFD的主要作用

1. DFD 是理解和表达用户需求的工具，是需求分析的手段。由于DFD 简明易懂，不需要任何计算机专业知识就可以理解它，因此，系统分析师可以通过DFD 与用户进行交流。
2. DFD 概括地描述了系统的内部逻辑过程，是需求分析结果的表达工具，也是系统设计的重要参考资料，是系统设计的起点。
3. DFD 作为一个存档的文字材料，是进一步修改和充实开发计划的依据。

数据字典

数据字典是在DFD 的基础上，对 DFD 中出现的所有命名元素都加以定义，使得每个图形元素的名字都有一个确切的解释。DFD 和数据字典等工具相配合，就可以从图形和文字两个方面对系统的逻辑模型进行完整的描述。数据字典中一般有6 类条目，分别是数据元素、数据结构、数据流、数据存储、加工逻辑和外部实体

状态转换图

STD 通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为。STD 还指出了作为特定事件的结果将执 行哪些动作

业务系统是数据驱动的，适合使用DFD 。

控制系统是事件驱动的，适合行为STD

用例模型

第一步：识别参与者【参与者：用户、组织、外部系统、时间】
第二步：合并需求获得用例
第三步：细化用例描述
第四步：调整用例模型(可选步骤) 【关系包括：包含关系、扩展关系、泛化关系】

用例关系

包含关系【使用关系】：从多个用例中提取公共行为，提取出来的公共用例称为抽象用例，而把原始用例称为基本用例

扩展关系：一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例。

泛化关系：当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。子用例继承了父用例所有的结构、行为和关系。

分析模型

建立流程

第一步：定义概念类
第二步：确定类之间的关系
第三步：为类添加职责
第四步：建立交互图
第五步：分析模型的详细程度问题

类之间的关系

关联关系。关联提供了不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起

依赖关系。两个类A 和 B , 如果B 的变化可能会引起A 的变化，则称类A 依 赖于类B 。

泛化关系。泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系

聚合关系（共享聚合）。 表示类之间的整体与部分的关系。 整体与部分生命周期可以不同。

组合聚集（ 组合关系 ），表示类之间的整体与部分的关系 。 整体与部分生命周期相同。

实现关系。实现关系将说明和实现联系

需求定义

需求定义：把这些需求形成文档，作为系统后续开发的基础

有两种需求定义的方法， 分别是严格定义方法和原型方法

• 严格定义方法：需求的严格定义建立在以下的基本假设之上：

  • 所有需求都能够被预先定义。
  • 开发人员与用户之间能够准确而清晰地交流。
  • 采用图形(或文字)可以充分体现最终系统。

• 原型方法，迭代的循环型开发方式，需要注意的问题

  • 并非所有的需求都能在系统开发前被准确地说明。
  • 项目干系人之间通常都存在交流上的困难，原型提供了克该服困难的一个手段。
  • 需要实际的、可供用户参与的系统模型。有合适的系统开发环境。
  • 有合适的系统开发环境
  • 反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。

需求规格说明书

内容：范围；引用文件；需求；合格性规定；需求可追踪性；尚未解决的问题；注解；附录。

作用（自己编的）：

• 并作为验收依
• 开发用于验证系统的测试用例；
• 项目经理使用它作为制定项目计划
• 为下一步的系统设计提供指导

需求验证

其活动是为了确定以下几个方面的内容：

• S R S 正确地描述了预期的、满足项目千系人需求的系统行为和特征。

• S R S 中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。

• 需求是完整的和高质量的。

• 需求的表示在所有地方都是一致的。

• 需求为继续进行系统设计、实现和测试提供了足够的基础

需求变更

需求变更流程

需求跟踪

需求跟踪是将单个需求和其他系统元素之间的依赖关系和逻辑联系建立跟踪，这些元素包括各种类型的需求、业务规则、系统架构和构件、源代码、测试用例，以及帮助文件等。

正向跟踪是指检查SRS 中的每个需求是否都能在后继工作成果中找到对应点；

反向跟踪也称为逆向跟踪，是指检查设计文档、代码、测试用例等工作成果是否都能在SRS 中找到出处

UML

静态图

类图	类图描述一组类、接口、协作和它们之间的关系	类图给出了系统的静态设计视图 活动类的类图给出了系统的静态进程视图
对象图	对象图描述一组对象及它们之间的关系。 对象图描述了在类图中所建立的事物实例的静态快照	给出系统的静态设计视图或静态进程视图
构件图	构件图描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构	表示系统的静态设计实现视图
组合结构图	组合结构图描述结构化类（例如，构件或类）的内部结构 ， 包括结 构化类与系统其余部分的交互点
部署图	描述对运行时的处理节点及在其中生存的构件的配置
制品图	描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合
包图	描述由模型本身分解而成的组织单元，以及它们之间的依赖关系

交互图 ， 交互图专注于系统的动态视图，

顺序图	它由一组对象或参与者以及它们之间可能发送的消息构成。强调消息的时间次序
通信图 协作图	它强调收发消息的对象或参与者的结构组织	顺序图强调的是时序， 通信图强调的是对象之间的组织结构
定时图	强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序
交互概览图	交互概览图是活动图和顺序图的混合物

其他 动态视图

状态图	状态图描述一个状态机，它由状态、转移、事件和活动组成， 它对于接口、类或协作的行为建模尤为重要， 而且它强调事件导致的对象行为	对反应式系统建模
活动图	活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流 它对系统的功能建模和业务流程建模特别重要 强调对象间的控制流程

(5)用例图(Use Case Diagram)。用例图描述一组用例、参与者及它们之间的关系。
用例图给出系统的静态用例视图。这些图在对系统的行为进行组织和建模时是非常重要的。
(6)顺序图(Sequence Diagram,序列图)。顺序图是一种交互图(interaction diagram),交互图展现了一种交互，它由一组对象或参与者以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图。
(7)通信图(Communication Diagram)。通信图也是一种交互图，它强调收发消息的对象或参与者的结构组织。顺序图和通信图表达了类似的基本概念，但它们所强调的概念不同，顺序图强调的是时序，通信图强调的是对象之间的组织结构(关系)。在UML
1.X版本中，通信图称为协作图(Collaboration Diagram)。
(8)定时图(Timing Diagram,计时图)。定时图也是一种交互图，它强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序。

(9)状态图(State Diagram)。状态图描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这非常有助于对反应式系统建模。
(10)活动图(Activity Diagram)。活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模和业务流程建模特别重要，并强调对象间的控制流程。
(11)部署图(Deployment Diagram)。部署图描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图。
(12)制品图(Artifact Diagram)。制品图描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品图通常与部署图一起使用。制品也给出
了它们实现的类和构件。
(13)包图(Package Diagram)。包图描述由模型本身分解而成的组织单元，以及它
们之间的依赖关系。
(14)交互概览图(Interaction Overview Diagram)。交互概览图是活动图和顺序图的
混合物。