需求工程笔记整理

最新推荐文章于 2023-03-17 09:30:00 发布

-madongyu-

最新推荐文章于 2023-03-17 09:30:00 发布

阅读量1k

点赞数 4

分类专栏：学习笔记文章标签：学习笔记

本文链接：https://blog.csdn.net/madonghyu/article/details/102526832

版权

学习笔记专栏收录该内容

0 篇文章 0 订阅

订阅专栏

考试复习整理~~~

文章目录

第一章需求工程导论（略）
第二章需求基础（略）
第三章需求工程过程（略）
第四章需求获取概述
第五章确定项目的前景和范围
第六章涉众分析与硬数据采样（略）
第七章基于用例/场景模型展开的用户需求获取
第八章需求获取方法之面谈（略）
第九章需求获取方法之原型（略）
第十章需求获取方法之观察与文档审查（略）
第十一章需求分析概述
第十二章过程建模
第十三章数据建模
第十四章面向对象建模
第十五章需求规格说明（略）
第十六章需求验证（略）
第十七章需求管理（略）

第一章需求工程导论（略）

需求工程、软件工程、系统工程的联系与区别
需求工程的定义

需求工程是所有需求开发活动的综合，它获取整理需求信息、
分析需求问题、记录需求、验证需求的正确性、管理需求。
需求工程的基本活动
需求工程师的任务

需求工程师是涉众和开发者之间的桥梁
完成需求工程基本活动
协调管理应用领域的业务需求、用户需求、期望与约束和计算机领域的规模与复杂度、功能与非功能需求

第二章需求基础（略）

需求的定义

解决问题所需要的条件或能力
解系统和需求规格说明(含义)

解系统 = 软件解决方案 + 软件系统

软件解决方案 = 需求规格说明(文档)
需求是有层次性的
- 业务需求、用户需求、系统需求含义及关联
  - 业务需求：描述软件系统的目标和效益，适合决策者
  - 用户需求：描述了软件系统的具体任务，适合使用系统的各类用户
  - 系统需求：关注软件系统的功能，适合软件开发者。
  - 其中业务需求和用户需求可以从现实中获得，系统需求通过前面两者分析转换获得
- 问题与描述:业务需求+用户需求
- 需求规格说明书:系统需求
需求(软件需求)类别
- 功能需求：和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。
- 性能需求：系统整体或系统组成部分应该拥有的性能特征，例如CPU使用率、内存使用率等。
- 数据需求：软件系统中非常重要的知识内容（可以在表达功能需求是进行描述）
- 质量属性、对外接口和约束
优秀的需求的特性

• 完备性 • 正确性 • 可行性 • 必要性 • 无歧义 • 可验证

第三章需求工程过程（略）

需求工程过程的概念

过程是一组相关活动的集成，通过这些活动的执行，可以完成一项
任务或者达到一个目标

需求工程过程是软件开发中跟需求有关的活动的集成，从用户面临的问题出发，经过获取、分析和建模，形成问题的解决方案，并将该方案转化为需求规格说明文档

需求工程活动是跟需求有关的活动，分为需求开发和需求管理
- 需求开发：
  - 活动:需求获取、需求分析、需求规格说明、需求验证
  - 每个需求工程活动完成的任务（摘抄自定义）：
    1. 需求获取
      - 需求获取是从人、文档或者环境当中获取需求的过程
      - 需求工程师必须要利用各种方法和技术来获取需求
      - 需求获取和需求分析是交织在一起的(交替进行);
    2. 需求分析
      - 通过建模来整合各种需求信息，以使得人们更好的理解问题
      - 为问题定义出一个需求集合，这个集合能够为解决问题形成一个有效的解决方案
      - 检查需求当中存在的错误、遗漏、不一致等各种缺陷，并加以修正
    3. 需求规格说明
      - 所有需求都被编写成文档，主要目的是为了相关人员之间交流需求信息
    4. 需求验证
      - 确保需求规格说明文档能正确、准确的反映用户的意图
      - 确保文档的高质量
        文档内每条需求都正确、准确的反映了用户的意图
        文档记录的需求集在整体上具有完整性和一致性
        文档的组织方式和需求的书写方式具有可读性和可修改性
    5. 需求管理
      - 保证需求作用在整个软件生命周期中的持续、稳定和有效发挥
  - 成果(文档)：
    1. 项目前景和范围文档:定义系统业务需求(业务流程图)
    2. 用户需求文档:定义各用户的用户需求(用例图)
    3. 需求规格说明文档:
      - 系统规格说明:定义整个系统的需求(系统需求)，包括软件需求、硬件需求、其他需求(安全需求等)
      - 软件规格说明:定义软件需求(数据流图、模块结构图、实体关系图、数据字典等);
- 需求管理：
需求工程活动是互相交织、并发、迭代和递增的

第四章需求获取概述

需求获取常见困难
- 用户和开发人员的背景不同，立场不同
- 普通用户缺乏概括性、综合性的表述能力
- 用户存在认知困境
- 用户越俎代庖
- 缺乏用户参与
需求获取的活动和过程
- 需求获取活动
  - 研究应用背景，建立初始的知识框架
  - 根据获取的需要，采用必要的获取方法和技巧
  - 先行确定获取的内容和主题，设定场景
  - 分析用户的高（深）层目标，理解用户的意图
  - 进行涉众分析，针对涉众的特点开展工作
- 需求获取过程
需求获取的内容：
- 需求：业务需求和用户需求
- 问题域描述：描述现实世界的业务运行情况(事物、事件…)
- 环境与约束：解系统运行的环境和约束。
获取信息的来源：涉众、硬数据、相关产品、重要文档、相关技术标准和法规
获取信息的方法：传统方法、集体获取方法、原型方法、模型方法
获取信息的成果:获取笔录、正式文档

第五章确定项目的前景和范围

确定项目前景与范围阶段的活动
- 过程
确定项目前景与范围阶段的方法（问题分析和目标分析，简单情况下使用问题分析）
- 问题分析
  - 过程
  - 获取问题
  - 明确问题
  - 发现业务需求
  - 定义问题解决方案及系统特性
业务需求、解决方案、系统特性的含义
- 业务需求：问题的反面（描述了软件系统的目标和效益，适合与决策者–by 第一章）
- 解决方案：用于解决问题
- 系统特性：解决方案所具有的功能特性
  - 明确实现该解决方案系统需要具备的功能。
  - 一个特性内聚于一个目标和任务，反应了系统与外界一次有价值的完整交互过程
  - 系统特性描述了用户可以使用系统完成的(工作)任务
定义系统边界：会画系统用例图和上下文图
- 确定系统边界—用例图
  整个系统边界 = 每个问题对应的解决方案的边界的合并
- 确定系统边界—上下文图
  先确定每个问题的解决方案的边界

第六章涉众分析与硬数据采样（略）

涉众的概念
- 所有对软件系统的开发和应用具有发言权和决定权的人
- 所有能够影响软件系统的实现或者会被实现后的软件系统所影响的关键个人和团体称为涉众
涉众分析过程
过滤非关键涉众的依据：分析一个涉众类别的任务或他们与外界的交互活动，如果这些属于项目范围，服务于系统目标（业务需求）的实现，那么该涉众类别属于关键类别，反之亦然。
识别涉众的方法
- 先膨胀后收缩
- 检查列表
- 涉众网络
涉众描述的内容
- 个人特征
  - 技能
  - 身体能力
  - 生活方式
- 工作特征
  - 任务
  - 使用状况
  - 技能和经验（新手～专家）
- 地理和社会特征（少数情况下）
涉众评估的作用
- 在发生资源紧缺或者需求冲突时，优先级高的涉众会受到特别优待
硬数据定义、分类和常用采样技术
- 定义/类型
  - 定量硬数据
  - 定性硬数据
- 采样方法
  - 随机抽样
  - 分层抽样

第七章基于用例/场景模型展开的用户需求获取

用例概念：系统与外界交互的行为序列（相关场景集合的叙述性的文本描述）
场景概念：行为或者事件序列的描述
用例和场景的关系：一个用例是多个场景的集合
用例图（要求会画）
- 概念
- 用途
用例描述（要求会写用户需求用例描述）
- 概念
- 用途

第八章需求获取方法之面谈（略）

概念：面对面的会见
- 被认为是最具有丰富内容的交流方式
- 实践当中应用最为广泛的需求获取方法之一
过程：
类型：
- 结构化面谈
- 半结构化面谈
- 非结构化面谈

第九章需求获取方法之原型（略）

概念：用来探索和论证软件系统功能的物件
优点：能够及早解决系统开发中的不确定性，从而减少软件项目失败的风险
风险：成本失控

第十章需求获取方法之观察与文档审查（略）

第十一章需求分析概述

需求分析的任务（建立分析模型，创建解决方案）
模型、建模的概念
- 模型是对事物的抽象，帮助人们在创建一个事物之前可以对该事物有更好的理解
- 建立模型的过程被称为建模
两种世界和三种模型
- 计算世界和计算模型
- 问题世界(现实世界)与业务模型
- 软件(分析)模型: 介于计算模型和业务模型二者之间的模型形式
常用的需求分析方法（技术）
- 结构化分析
  - 数据流图
  - 实体关系图
- 面向对象分析
  - 类图
  - 活动图
结构化分析方法
- 基本思想：把现实世界描述为数据在信息系统中的流动，以及数据流动过程中数据向信息的转化
- 核心技术
  - 数据流图
  - 实体关系图
  - 状态转移图
面向对象分析方法
- 基本思想：认为系统是对象的集合，这些对象互相协作，共同完成系统任务
- 核心技术
前期和后期需求阶段的活动
- 前期
  - 背景分析
  - 问题分析
  - 目标分析
  - 业务分析
  - 确定系统边界
- 后期
  - 需求建模
  - 需求细化
  - 确定需求优先级
  - 需求协商

第十二章过程建模

结构化分析的主要方法是过程建模和数据建模，其中过程建模是其核心
过程建模的概念和主要技术
- 概念：分析需求获取活动获得的信息，发现系统的功能及其与外界的交互，建立能够实现系统功能的过程分解结构，形成系统的过程模型，并用图形的方式将过程模型描述出来
- 主要技术
  - 上下文图
  - 数据流图
  - 数据字典
  - 微规格说明
微规格说明和数据字典概念、内容、作用
- 微规格说明
  - 概念：是一些用来描述过程处理逻辑的技术，主要有：
    - 结构化自然语言
    - 行为图
    - 决策表
  - 作用：描述层次结构最低层次中的原始过程的处理逻辑
- 数据字典
  - 概念：是一个储存库，包含软件使用和产生的所有数据对象的描述
  - 作用：对数据流图中涉及的数据流和数据存储进行详细的说明
  - 内容
    - 数据项
    - 数据结构
    - 数据流
    - 数据存储
    - 处理过程
上下文图、0层图、N层图的概念和作用
- 上下文图
  - 概念：将整个系统看成是一个过程，这个过程实现系统的所有功能
  - 作用：适合于描述系统的应用环境，定义系统的应用环境，定义系统的边界
- 0层图
  - 概念：在数据流图的层次结构中，位于上下文图下面一层的就是0层图
  - 作用：作为整个系统的功能概括
- N层图
  - 概念：对N-1层图的可以分解的过程分解后产生的揭示更多细节的数据流图称作N层图
  - 作用：
功能分解图的概念和作用
会画数据流图DFD和实体联系图ERD，会撰写数据字典和微规格说明（应用题）

第十三章数据建模

数据模型和数据建模的概念
- 数据模型
  - 概念：
    - 描述数据的定义、结构和关系等特性的模型
    - 说明了问题域和解系统共享的事物、对共享事物的描述和共享事物之间的关系
    - 能够反映企业业务的核心知识
- 数据建模
  - 概念：建立数据模型的过程被称为数据建模
数据建模技术包括实体联系图和类图
实体(进程实体、概念实体)、属性、联系、联系的度数、联系的基数等术语的理解
建立数据模型:会画ER图

第十四章面向对象建模

面向对象分析是90年代之后的主流分析方法，它以UML为基础，综合使用了多种不同的分析技术，主要有：
- 对象模型 (领域模型):类图
- 用例模型:用例图
- 行为模型:交互图(顺序图、通信图)、状态图、活动图
对象
- 定义：对象模拟了现实世界中的事物
- 描述内容（独立可确认和有明确的角色）：
  - 标识:唯一的标识自己，引用
  - 状态:对象的特征描述，包括对象的属性和属性的取值
  - 行为:对象在其状态发生改变或者接收到外界消息时所采取的行动
- 对象之间的关系
  - 链接：
    - 对象之间的物理或业务联系，链接的对象互相协作完成任务；
    - 链接通常是单向的，当然也有双向的链接存在
  - 导航和可见性：
    - 由a指向b的链接除了包含假设和期望因素之外，还意味着a能够在链接的指引下，正确的找到并将消息发送给b，即a可以导航到b
    - 由a指向b的链接使得b对a可见，或者说a拥有b的可见性
    - a拥有b的可见性可以理解成:a能请求b协助完成a的任务
类
- 概念：
  - 类是具有相同状态和行为的同一类对象的集合
  - 每个类都有能够唯一标识自己的名称，包含属性和行为方法
  - 对象是类的实例
- 产生
  - 对象分类
  - 抽象
  - 封装
- 类之间的关系
  - 关联：指出了类与类之间的某种语义联系
  - 聚合:部分与整体的关系
  - 组合:部分与整体的关系，部分不能单独存在
  - 继承：如果一个类A 继承了类 B，那么A 就自然具有B的全部属性和行为方法，同时A也会拥有一些自己特有的属性和行为方法，这些特有部分是B 所不具备的
  - 多态
    - 广义多态：一个对象在相似情景下表现出不同的形态（重载，范型）
    - 狭义多态：多个对象在同一情景中表现出相同形态的现象