笔记 | 软件工程05：需求分析

大家好，欢迎来到IT知识分享网。

1 需求分析

#需求分析

1.1 需求分析概述

1. 初步软件需求存在的问题：不具体，不清晰，关系不明朗，存在潜在缺陷，没有区分不同软件需求（有必要鉴别不同软件需求项的重要性差别，区分不同软件需求的开发优先级）
2. 分析软件需求的任务：基于初步软件需求，进一步精化和分析软件需求，确定软件需求优先级，建立软件需求模型，发现和解决软件需求缺陷，形成高质量的软件需求模型和软件需求规格说明书
   
   
3. 软件需求的不同视角表示：
   1. 用例视角：具有哪些功能、功能间有何关系、功能与利益相关方有何关系，UML提供了[[【笔记】软件工程05：需求分析#1.2.3 用例图描述| 用例图]]来分析和描述用例视角的软件需求模型
   2. 行为视角：用例是如何通过业务领域中一组对象以及它们间的交互来达成的，UML提供了交互图、状态图来描述行为视角的软件需求模型
   3. 结构视角：业务领域有哪些重要的领域概念以及它们之间具有什么样的关系，UML提供了类图来描述和分析业务领域的概念模型
   4. 

1.1.1 软件需求和需求工程

1.1.1.1 软件开发的本质

1.1.1.2 软件系统的利益相关方

软件利益相关方会站在自身的角度对软件提出要求

1.1.1.3 何为软件需求

1.1.1.4 软件需求的类别

1.1.1.5 软件需求的特点

如何从利益相关者获取完整、清晰和一致软件需求是一项挑战！

1.1.1.6 软件需求的质量要求

1.1.1.7 软件需求的重要性

软件的价值所在，软件开发的基础和前提，软件验收的标准和依据

1.1.1.8 何为需求工程

1.1.1.9 需求工程的一般性过程

1.1.1.10 需求工程的特点

1.1.1.11 需求工程的方法学——抽象

1.1.1.12 需求工程的方法学——建模

1.1.1.13 需求工程的方法学——分析

1.1.2 结构化需求分析方法学

1.1.2.1 基本思想

1.1.2.2 数据流图

Data Flow Diagram(简称DFD)：描述输入数据流到输出数据流的变换(即加工)过程，用于对系统的功能建模。

1.1.2.3 画分层数据流图的步骤

注：每个层次画在独立的数据流图中，加工个数可大致控制在“7加减2”的范围中

1.1.3 面向对象需求分析方法学

1.1.3.1 基本思想

1.1.3.2 面向对象的核心概念

对象 (Object)，类 (Class)，继承 (Inheritance)，多态 (Polymorphism)，覆盖（Override），重载(Overload)，消息 (Message)，聚合 (Aggregation)和组合(Composition)

1. 对象
   
   
2. 类
   
   
3. 消息
   
   
4. 继承
   
   • 单继承：一个类拥有一个父类
   • 多集成：一个类可以拥有多个父类

   
   

5. 多态
   
   
6. 覆盖
   1. 子类增加或重新定义所继承的属性或方法，从而用新定义的属性和方法来覆盖所继承的、来自父类中的属性或方法
   2. 
7. 重载
   1. 一个类中有多个同名操作，但它们在操作数或操作数类型上有区别，系统根据实参引用不同方法
   2. 
8. 聚合(Aggregation)和组合(Composition)
   
   

1.1.3.3 面向对象需求分析步骤

1.1.3.4 面向对象需求分析方法的优势和特色

1.1.4 需求工程的CASE工具（CASE：计算机辅助软件工程）

1.1.5 需求工程的输出和评审

1.1.5.1 需求工程的输出软件需求制品

• 软件需求模型：抽象和直观地表示软件需求
• 软件需求文档：完整和详尽地记录软件需求。
  • 软件需求文档的内容包括：
    • 系统和文档概述
    • 软件功能性需求
    • 软件质量方面的需求
    • 软件开发的约束性需求
    • 软件需求的优先级
  • 软件需求文档的描述方式：
    • 
• 软件原型：直观地展示软件需求

1.1.5.2 确认和验证初步软件需求

输出的软件制品：

1.1.5.3 评审初步软件需求

1.1.5.4 软件需求可行性分析

1.2 软件需求获取

1.2.1 获取软件需求的方法

1.2.1.1 软件需求从何而来

软件开发者也可以充当软件的利益相关方

1.2.1.2 获取软件需求的方式

1.2.1.3 获取软件需求的方法

1.2.1.4 获取软件需求的过程

1.2.2 明确问题及软件解决方案

1.2.2.1 软件的目的

每一个软件都试图去解决特定领域中的问题，并提供基于软件的问题解决方案。

软件需求必须服从和服务于软件欲解决的问题，只有这样软件需求才有意义和价值。

明确软件要解决的问题，清晰地界定软件欲解决什么样的问题：与特定领域及其业务相关联，或提高业务工作效率，或解决业务瓶颈问题，或提升业务服务水平和质量等等

1.2.3 导出和构思软件需求

1.2.3.1 识别软件的利益相关方

1.2.3.2 导出软件的功能性需求

需求工程师可以通过与利益相关方的交互，听取他们对软件的期望和要求，从他们那里导出软件需求

采用多种方法来导出软件需求，包括：与用户或客户的面谈、分析业务资料、观察业务流程、进行问卷调查、软件原型等。

1.2.3.3 导出和构思软件的非功能性需求

1.2.4 描述初步的软件需求

1.2.5 确认和验证初步软件需求

1.3 描述需求的方式

1.3.1 自然语言描述

1. 描述软件的功能性需求（软件系统需要对老人在家的状况进行分析，以判断是否出现突发异常情况。一旦出现异常情况，就需要通知老人家属和医生）、质量需求（老人通过语音方式与系统进行交互，系统正确理解老人语音指令的比率应达到90%以上）和开发约束需求（客户端App软件须运行在Android 4.4及以上版本的操作系统）等
2. 不足：不具体，不直观，不准确，有二义

1.3.2 软件原型描述

1. 直观、可展示和可操作，但无描述软件需求的具体细节

1.3.3 用例图描述

1. 描述软件系统的边界以及软件外部使用者所观察到的系统功能，“观察到”是指外部使用者与系统存在交互，即信息输入和输出
2. 用例图的构成

• 执行者：系统之外的实体，他们使用软件系统功能、与软件系统交换信息，可以是一类用户，也可以是其他软件系统或物理设备。执行者是UML中的类， 代表一类用户或者外部实体，而非具体的对象实例。执行者通常对应于软件系统的利益相关方
• 用例：核心是功能。表示执行者为达成一项相对独立、完整的业务目标而要求软件系统完成的功能
• 执行者与用例间的关系：

1.3.3.1 用例建模过程

1. 第⼀步：找到所有的参与者和用例
   • 识别出参与者并做简单的描述
   
   注意事项：
   
   • 识别出用例并做简单的介绍，寻找用例的方法：
   用例的命名：
   
   注意事项：
   
   
   
   
   
   
   
   
   
   
2. 第⼆步：编写用例
   • 列出用例
   用例的全部生命周期：
   
   用例概述的例子(概述时既包括了主成功场景，也有候选场景):
   
   详细用例归约例子：
   
   用例文档模板：
   
   
   
   
   
   
   
   
   
   

1.3.3.2 用例建模时注意事项

1. 不要把用例定义成功能分解
   
   

1.3.3.3 用例间的关系

1. 包括包含(Include)，扩展(Extend)，继承(Inherit)三种关系
2. 包含关系
   
   
3. 扩展关系：按基用例中指定的扩展条件，把扩展用例的行为插入到由基用例中的扩展点定义的位置，基用例是可单独存在的，在扩展用例中定义的行为如果离开基用例是没意义的，一个用例可以被多个用扩展，而一个扩展用例也可以扩展多个用例
   
   
4. 继承关系：如果A与B相似，但A的动作序列是通过改写B的部分动作或者扩展B的动作而获得的，则称用例A继承用例B

1.3.3.4 扩展与包含关系的区别

1. 包含：因为子用况被提出，基用况并非一个完整的用况，所以include关系中的基用况必须和子用况一起使用才够完整，子用况也必然被执行。由基用况指向子用况

2. 扩展：新用况在原用况（基用况）基础上增加了新步骤。基用况是完整的，即使没有子用况参与。只有当扩展点被激活时，子用况才会执行。由子用况指向基用况

1.3.3.5 扩展与继承有何本质区别

1.3.4 边界框

表示整个软件系统或子系统的边界，边界框内的用例构成了系统或子系统的内容，如用例。外面的是系统之外的执行者。

注意画图的时候不要把这个漏掉了

示例：“空巢老人看护软件”的用例图

1.3.5 交互图描述

1. UML交互图的的作用：刻画对象间的消息传递，分析如何通过交互协作完成功能
   理解：
   – 用例的功能实现方式
   – 软件系统在某种使用场景下对象间的交互协作流程
   – 软件系统的某个复杂操作的逻辑实现模型
   
   
   
   
2. 二类交互图（表达能力相同，二类图可以相互转换）

1.3.5.1 顺序图

1. 描述对象间的消息交互序列：

• 纵向：时间轴，对象及其生命线(虚线)，活跃期(长条矩形)
• 横向：[[【笔记】需求分析补充知识#1 对象间的消息传递 | 对象间的消息传递]] 注意：[[【笔记】需求分析补充知识#^f01848 | 消息图元的表示]]

2. 顺序图的表达方式：
   
   
3. [[【笔记】需求分析补充知识#^0e4a11 | 顺序图中的绘画技巧]]

1.3.6 类图和对象图

均在描述系统的静态结构

1.3.6.1 类图

1. 图的构成:

• 结点：表示系统中的类（或接口）及其属性和操作
• 边：类之间的关系

2. [[【笔记】需求分析补充知识#4 类图的UML表示| 类的UML表示]]：
   
   
3. 一种特殊的类：接口
   不包含操作实现部分的特殊类， 包括供给接口和需求接口
   
   
   
4. 类间的关系
5. 画类图的注意事项
   
   

1.3.6.2 对象图

对象图示例：

1.3.7 状态图

车票对象的状态图示例：

状态图的基本概念：

状态的表示：

迁移的表示：

状态图示例：

复合状态的概念：

状态图绘制原则：

1.4 分析软件需求过程

1.4.1 分析和确立软件需求优先级

1.4.1.1 分析软件需求重要性

1.4.1.2 分析软件需求优先级

1.4.1.3 确定用例分析和实现的次序

1.4.2 分析和建立软件需求模型

1.4.2.1 分析和建立软件需求模型的具体步骤

1.4.2.2 分析和建立用例的交互模型——对象类

1. 软件需求用例的处理通常涉及三种不同类对象
   1. 边界类
   2. 控制类
   3. 实体类

• 什么是边界类：（理解：获取外部数据的职责）
  
  
• 什么是控制类：（理解：充当现实世界中领导者的角色）
  
  
• 什么是实体类：（理解：实际打工干活的类）
  
  

1.4.2.3 分析和建立用例的交互模型——消息传递

1. 确定消息的名称
   
   
2. 确定消息的传递信息
   
   

1.4.2.4 分析和建立用例的交互模型——绘制用例交互图

用例交互图的工作流程：

1.4.2.5 分析和建立分析类模型的步骤

• 确定分析类
• 确定分析类的职责
• 确定分析类的属性
• 确定分析类之间的关系
• 绘制分析类图
• 确定分析类
  
  
• 确定分析类的职责
  
  
• 确定分析类的属性
  
  
• 确定分析类之间的关系
  
  
• 绘制分析类图
  
  

1.4.2.6 分析和建立软件需求的状态模型

1.5 软件需求文档化及评审

1.5.1 软件需求规格说明书

1.5.1.1 软件需求文档模板

1.5.1.2 撰写软件需求文档的注意事项

1.5.1.3 分析软件需求的输出

1.5.2 评审软件需求

1.5.2.1 软件需求评审的步骤

1.5.2.2 评审内容

1.5.2.3 如何解决软件需求问题