系统分析师14：需求工程

1 内容概要

2 需求工程概述

• 需求工程：需求开发【含需求分析】和需求管理
• 系统分析：软件需求分析、硬件需求分析、网络需求分析
• 软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望
• 考虑“做什么”，而不考虑“怎么做”，不关注开发平台和程序语言

需求开发【技术维度】

• 需求获取
• 需求分析
• 需求定义（产生SRS，即需求规格说明书）
• 需求验证（形成需求基线【经过评审的SRS】）

需求管理【管理维度】

• 需求管理是对需求基线进行管理
• 变更控制
• 版本控制
• 需求跟踪
• 需求状态跟踪

例1
在软件需求工程中，需求管理贯穿整个过程。需求管理最基本的任务是明确需求，并使项目团队和用户达成共识，即建立（)。

A：需求跟踪说明
B：需求变更管理文档
C：需求分析计划
D：需求基线

解析
需求管理是对需求基线进行管理。需求基线是经过评审的SRS。
答案：D。

例2
下列关于软件需求管理或需求开发的叙述中，正确的是（) 。
A：所谓需求管理是指对需求开发的管理
B：需求管理包括:需求获取、需求分析、需求定义和需求验证
C：需求开发是将用户需求转化为应用系统成果的过程
D：在需求管理中，要求维持对用户原始需求和所有产品构件需求的双向跟踪

解析

• 需求管理是指对需求基线的管理；
• 需求开发包括：需求获取、需求分析、需求定义和需求验证，需求管理包括：变更控制、版本控制、需求跟踪、需求状态跟踪；
• 需求开发是将用户需求转化为系统需求的过程，而不是直接转化为应用系统成果；
• 在需求管理中，要求维持对用户原始需求和所有产品构件需求的双向跟踪。这个叙述是正确的，需求管理的一个重要方面就是确保能够跟踪需求的来源和去向，即从用户需求到系统需求，再到具体的实现和测试。

答案：D。

3 需求分类

在需求分析和管理中，需求可以按照不同的维度进行分类，以便更好地理解和处理这些需求。以下是一些常见的需求分类方法，包括领域需求、业务需求、用户需求和系统需求。

3.1 领域需求（行业共性需求）

• 定义：领域需求是指在特定行业或领域中普遍存在的需求，这些需求通常是行业标准或规范的一部分。
• 特点：
  • 共性：这些需求在同一行业或领域内具有普遍性。
  • 规范性：通常由行业标准或法规规定。
  • 稳定性：相对稳定，不易随时间变化。
• 示例：
  • 金融行业：反洗钱（AML）规则、数据加密要求。
  • 医疗行业：电子病历（EMR）标准、患者隐私保护。
  • 教育行业：课程管理、学生成绩管理。

3.2 业务需求（整体全局）

• 定义：业务需求是指从整体业务流程和战略角度出发的需求，这些需求通常涉及业务的整体目标和关键流程。
• 特点：
  • 全局性：涵盖整个业务流程和战略目标。
  • 战略性：与企业的长期发展和战略目标相关。
  • 复杂性：通常涉及多个部门和业务流程。
• 示例：
  • 供应链管理：订单处理、库存管理、物流配送。
  • 客户关系管理：客户信息管理、销售流程管理、客户服务。

3.3 用户需求（用户视角）

• 定义：用户需求是指从最终用户的角度出发的需求，这些需求关注用户在使用产品或服务时的体验和期望。
• 特点：
  • 用户导向：以用户为中心，关注用户体验和满意度。
  • 多样性：不同用户群体可能有不同的需求。
  • 易用性：关注产品的易用性和用户友好性。
• 示例：
  • 电子商务：用户注册、商品搜索、购物车管理、支付流程。
  • 移动应用：用户界面设计、功能操作、数据同步。

3.4 系统需求（计算机化）

系统需求是指与计算机系统或软件实现相关的具体需求，这些需求通常包括功能需求、性能需求和设计约束。

3.4.1 功能需求

• 定义：功能需求描述系统或软件必须具备的功能或特性，这些需求直接关系到系统的基本功能。
• 特点：
  • 明确性：需求描述通常非常具体和明确。
  • 可测试性：需求通常可以通过测试来验证是否满足。
  • 实现性：需求可以直接转化为系统的设计和实现。
• 示例：
  • 用户登录：用户可以通过用户名和密码登录系统。
  • 数据存储：系统能够存储和管理用户数据。

3.4.2 性能需求（非功能需求）

• 定义：性能需求描述系统或软件在性能方面的要求，这些需求通常涉及系统的响应时间、吞吐量、并发用户数等。
• 特点：
  • 非功能性：这些需求不直接涉及系统的功能，但影响系统的整体性能。
  • 量化性：需求通常可以通过具体的指标来量化。
  • 关键性：性能需求对系统的用户体验和可用性至关重要。
• 示例：
  • 响应时间：系统在用户请求后应在1秒内响应。
  • 并发用户数：系统应支持同时在线的1000个用户。

3.4.3 设计约束（操作系统，数据库）

• 定义：设计约束是指在系统设计和实现过程中必须遵守的限制条件，这些约束通常涉及技术选择、平台限制、法规要求等。
• 特点：
  • 限制性：这些约束限制了系统设计和实现的选择。
  • 强制性：必须遵守，否则可能导致系统无法实现或不符合要求。
  • 多样性：可能涉及多种技术、平台或法规。
• 示例：
  • 操作系统：系统必须运行在Windows操作系统上。
  • 数据库：系统必须使用MySQL数据库。
  • 法规要求：系统必须符合GDPR数据保护要求。

3.5 按QFD分类

QFD（Quality Function Deployment，质量功能展开）是一种系统化的方法，用于将客户需求转化为产品或服务的具体设计要求。QFD通过四个矩阵（也称为“房子”）来实现这一目标，其中最核心的是“质量屋”（House of Quality）。在QFD中，客户需求通常被分为三类：基本需求、期望需求和兴奋需求。

3.5.1 基本需求（明示需求，常规需求）

• 定义：基本需求是客户明确表达的需求，这些需求是产品或服务必须满足的最低标准。如果这些需求没有得到满足，客户会感到不满。
• 特点：
  • 明确性：客户通常会明确提出这些需求。
  • 常规性：这些需求是行业或市场中普遍认可的标准。
  • 必要性：产品或服务必须满足这些需求，否则无法进入市场。
• 示例：
  • 汽车的基本需求：安全气囊、刹车系统、发动机性能等。
  • 软件的基本需求：用户登录、数据存储、基本功能操作等。

3.5.2 期望需求（隐含需求）

• 定义：期望需求是客户虽然没有明确提出，但内心期望产品或服务能够满足的需求。这些需求通常是客户认为理所当然的，但如果得到满足，客户会感到满意。
• 特点：
  • 隐含性：客户通常不会明确提出这些需求，但期望它们能够被满足。
  • 满意度：满足这些需求可以显著提高客户的满意度。
  • 竞争优势：在竞争激烈的市场中，满足这些需求可以成为产品的竞争优势。
• 示例：
  • 汽车的期望需求：舒适的座椅、良好的音响系统、低噪音驾驶等。
  • 软件的期望需求：用户友好的界面、快速响应时间、数据备份功能等。

3.5.3 兴奋需求（多余需求）

• 定义：兴奋需求是超出客户期望的需求，这些需求通常是客户没有预料到的，但如果得到满足，会极大地提升客户的满意度和忠诚度。
• 特点：
  • 多余性：这些需求通常是超出客户预期的，客户可能没有意识到它们的重要性。
  • 惊喜性：满足这些需求会给客户带来惊喜和愉悦感。
  • 差异化：在市场中，满足这些需求可以帮助产品或服务脱颖而出。
• 示例：
  • 汽车的兴奋需求：车载娱乐系统、自动驾驶功能、个性化定制选项等。
  • 软件的兴奋需求：人工智能助手、个性化推荐功能、无缝跨平台体验等。

3.6 PIECES框架

PIECES框架是系统非功能性需求分类的技术

例3
需求的类型多种多样，其中（）通常采取用户访谈和问卷调查等方式，通过使用的场景进行整理。
A:业务需求
B:用户需求
C:功能需求
D:性能需求

解析

• 业务需求是指从整体业务流程和战略角度出发的需求，这些需求通常涉及业务的整体目标和关键流程。业务需求的收集通常通过业务分析、战略规划会议、市场调研等方式进行。
• 用户需求是指从最终用户的角度出发的需求，这些需求关注用户在使用产品或服务时的体验和期望。用户需求的收集通常通过用户访谈、问卷调查、用户反馈、用户行为分析等方式进行。
• 功能需求描述系统或软件必须具备的功能或特性，这些需求直接关系到系统的基本功能。功能需求的收集通常通过需求文档、用例分析、功能设计等方式进行。
• 性能需求描述系统或软件在性能方面的要求，这些需求通常涉及系统的响应时间、吞吐量、并发用户数等。性能需求的收集通常通过性能测试、基准测试、用户反馈等方式进行。

答案：B。

4 需求获取

需求获取方法

• 收集资料：把与系统有关的、对系统开发有益的信息收集起来
• 阅读历史文档：对收集数据性的信息较为有用
• 用户访谈：1对1-3，有代表性的用户，了解主观想法，交互好。成本高，要有领域知识支撑
• 问卷调查：用户多，无法一一访谈，成本低
• 现场观摩：针对较为复杂的流程和操作
• 参加业务实践：有效地发现问题的本质和寻找解决问题的办法
• 联合需求计划(JRP)：高度组织的群体会议，各方参与，了解想法，消除分歧，交互好，成本高
• 情节串联板【原型前身】：一系列图片，通过这些图片来讲故事
• 抽样调查：基于数理统计，降低成本，快速获取。样本大小=a*(可信度系数/可接受的错误)^2，注意：a一般取0.25

例4
详细调查的目标是获取企业业务处理的方法，深入了解系统的处理流程，确定用户需求。详细调查强调科学合理，根据欲获取信息的不同，调查方法也各不相同。若想获取用户对系统的想法和建议等定性特征，则（）方法比较合适;若想获取系统某些较为复杂的流程和操作过程，则（）方法比较合适。
A:抽样调查
B:阅读历史文档
C:开调查会
D:现场观摩

A:抽样调查
B:阅读历史文档
C:开调查会
D:现场观摩

解析

• 开调查会是一种互动性强的方法，能够直接听取用户的意见和建议，了解他们对系统的想法和期望。通过面对面的交流，可以更深入地获取用户的定性反馈。
• 现场观摩是一种直观的方法，通过观察实际操作过程，可以深入了解系统的复杂流程和操作细节。这种方法能够提供更具体、更实际的信息，帮助理解系统的运作方式。

答案：

• 获取用户对系统的想法和建议等定性特征：C
• 获取系统某些较为复杂的流程和操作过程：D

5 需求分析

5.1 结构化需求分析SA

结构化需求分析SA以数据字典为核心，包括行为模型（状态转换图），功能模型（数据流图，DFD），数据模型（E-R图）。

5.1.1 数据流图DFD

示例

5.1.2 数据字典

示例

• 机票=姓名+日期+航班号+起点+终点+费用
• 航班号=“Y7100”…“Y8100”
• 终点=[长沙|上海|北京|西安]

5.1.3 状态转换图STD

在结构化需求分析（Structured Analysis, SA）中，STD 是 状态转换图（State Transition Diagram） 的缩写。STD 是一种用于描述系统或对象在不同状态之间转换的图形化工具。它通过状态和事件来表示系统的行为，帮助分析人员和开发人员理解系统在不同条件下的响应和操作。

状态转换图（STD）的主要元素：

1. 状态（State）：

   • 表示系统或对象在某一时刻的特定情况或条件。
   • 每个状态通常用一个圆圈或矩形表示，内部标注状态的名称。

2. 事件（Event）：

   • 触发状态转换的条件或动作。
   • 事件通常用箭头表示，箭头从当前状态指向目标状态，并在箭头上标注事件的名称。

3. 转换（Transition）：

   • 表示从一个状态到另一个状态的变化。
   • 转换由事件触发，通常在箭头上标注事件名称和可能的条件。

4. 初始状态（Initial State）：

   • 表示系统或对象的起始状态。
   • 通常用一个实心圆表示。

5. 终止状态（Final State）：

   • 表示系统或对象的结束状态。
   • 通常用一个带圆圈的实心圆表示。

示例

5.1.4 E-R图

• 1：1联系
  

• 1：n的联系
  

• m：n的联系
  

• 同一实体集内一对多的联系
  
  示例
  

例5
在结构化分析方法中，用（）表示功能模型，用（）表示行为模型。
A: E-R图
B:用例图
C: DFD
D:对象图

A:通信图
B:顺序图
C:活动图
D:状态转换图

解析
在结构化分析方法中，DFD表示功能模型，状态转换图表示行为模型，E-R图表示数据模型。
答案：C、D。

例6
某医院预约系统的部分需求为：患者可以查看医院发布的专家特长介绍及其就诊时间；系统记录患者信息，患者预约特定时间就诊。用DFD对其进行功能建模时，患者是（)；用E-R图对其进行数据建模时，患者是（）。

A:外部实体
B:加工
C:数据流
D:数据存储

A:实体
B:属性
C:联系
D:弱实体

解析

• 数据流图（DFD）中的元素：
  • 外部实体：表示系统外部的实体，与系统进行交互，提供或接收数据
  • 加工：表示系统内部的处理过程，对数据进行转换或处理
  • 数据流：表示数据在系统内部或系统与外部实体之间的流动
  • 数据存储：表示系统内部的数据存储，如数据库或文件
• 在医院预约系统中，患者是与系统交互的外部实体，他们查看专家信息、预约就诊时间，并向系统提供个人信息。因此，患者在DFD中应表示为外部实体
• 实体-关系图（E-R图）中的元素
  • 实体：表示现实世界中的对象或概念，如患者、医生等
  • 属性：表示实体的特征或属性，如患者的姓名、年龄等
  • 联系：表示实体之间的关系，如患者与预约之间的关系
  • 弱实体：表示依赖于其他实体存在的实体，通常没有唯一标识符
• 在医院预约系统中，患者是一个独立的实体，具有自己的属性和与其他实体（如预约、医生）的关系。因此，患者在E-R图中应表示为实体

答案：A、A。

5.2 面向对象需求分析OOA

5.2.1 相关概念

• 对象：属性（数据）+方法(操作）+对象ID
• 类的分类(实体类/控制类/边界类)
• 继承与泛化：复用机制，一般和特殊的关系
  • 继承是一种复用机制,一个类继承有多个父类,称为【多重继承】
• 封装：隐藏对象的属性和实现细节，仅对外公开接口
• 多态：不同对象收到同样的消息产生不同的结果
• 重载：一个类可以有多个同名而参数类型不同的方法

例7
雇员类含有计算报酬的行为，利用面向对象的（），可以使得其派生类专职雇员类和兼职雇员类计算报酬的行为有相同的名称，但有不同的计算方法。
A:多态性
B:继承性
C:封装性
D:复用性

解析

• 多态性是指同一个接口可以有多种不同的实现方式。在面向对象编程中，多态性允许不同的类以不同的方式实现相同的方法或操作。
• 在雇员类的例子中，计算报酬的行为可以通过多态性来实现。专职雇员类和兼职雇员类可以继承雇员类，并重写计算报酬的方法，使得它们有相同的名称但不同的计算方法。

答案：A。

例8
面向对象技术中，对已有实例的特征稍作改变就可生成其他的实例，这种方式称为（ )。
A:委托
B:代理
C:继承
D:封装

解析

• 继承是指一个类（子类）可以继承另一个类（父类）的属性和方法，并在子类中进行扩展或修改。通过继承，子类可以复用父类的代码，并根据需要添加新的功能或修改已有功能。
• 在面向对象编程中，继承是一种重要的机制，允许开发者通过创建新的类来扩展或修改已有类的功能。例如，专职雇员类和兼职雇员类可以通过继承雇员类，并根据各自的特点进行扩展。

答案：C。

5.2.2 UML

• UML（统一建模语言）：平台无关，语言无关

• 构造块

  • 事物

    • 结构事物：最静态的部分，包括:类、接口、协作、用例、活动类、构件和节点
    • 行为事物：代表时间和空间上的动作，包括:消息、动作次序、连接
    • 分组事物：看成是个盒子,如:包、构件
    • 注释事物：UML模型的解释部分。描述、说明和标注模型的元素

  • 关系

  • 图

• 规则

  • 范围：给一个名字以特定含义的语境
  • 可见性：怎样使用或看见名字
  • 完整性：事物如何正确、一致地相互联系
  • 执行：运行或模拟动态模型的含义是什么

• 公共机制

  • 规格说明：事物语义的细节描述，它是模型真正的核心
  • 修饰：通过修饰来表达更多的信息
  • 公共分类：类与对象、接口与实现
  • 扩展机制：允许添加新的规则

• UML通用机制

  • 类是描述具有相同属性、方法、关系和语义的对象的集合，一个类实现一个或多个接口
  • 接口是指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外的可见的动作
  • 构件是物理上可替换的系统部分，它实现了一个接口集合
  • 包是一种将有组织的元素分组的机制
  • 用例是描述一系列的动作，产生有价值的结果
  • 协作定义了交互的操作，是一些角色和其它事物一起工作，提供一些合作的动作，这些动作比事物的总和要大
  • 节点是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力

例9
UML的事物是对模型中最具有代表性的成分的抽象，（）是模型的静态部分，描述概念或物理元素;(）用来描述、说明和标注模型的任何元素。
A：结构事物
B：分组事物
C：行为事物
D：注释事物

A：分组事物
B：注释事物
C：结构事物
D：行为事物

解析

• 结构事物：最静态的部分，包括:类、接口、协作、用例、活动类、构件和节点
• 行为事物：代表时间和空间上的动作，包括:消息、动作次序、连接
• 分组事物：看成是个盒子,如:包、构件
• 注释事物：UML模型的解释部分。描述、说明和标注模型的元素

答案：A、B。

例10
在UML的通用机制中，(）用于把元素组织成组;（）是系统中遵从一组接口规范且付诸实现的物理的、可替换的软件模块。
A:包
B:类
C:接口
D:构件

A:包
B:类
C:接口
D:构件

解析

• 在UML的通用机制中，用于把元素组织成组的是 包（A）。包是一种用于组织和管理UML模型元素的机制，它可以将相关的元素分组在一起，以便更好地管理和理解模型
• 构件（D）是系统中遵从一组接口规范且付诸实现的物理的、可替换的软件模块。构件是UML中用于表示软件系统中可重用、可替换的模块化单元的概念

答案：A、D。

5.2.3 UML图

• UML2.0包括14种图，分别如下：
  (1)类图(class diagram)。类图描述一组类、接口、协作和它们之间的关系。类图给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图
  (2)对象图（object diagram)。对象图描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。对象图从真实案例或原型案例的角度建立的
  (3)构件图(component diagram)。构件图描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图
  (4)组合结构图(composite structure diagram)。组合结构图描述结构化类（例如，构件或类)的内部结构，包括结构化类与系统其余部分的交互点。组合结构图用于画出结构化类的内部内容
  (5)用例图(use case diagram)。用例图描述一组用例、参与者及它们之间的关系。用例图给出系统的静态用例视图
  (6)顺序图(sequence diagram，序列图)。顺序图是一种交互图(interaction diagram),交互图展现了一种交互，它由一组对象或参与者以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图
  (7)通信图(communication diagram)。通信图也是一种交互图，它强调收发消息的对象或参与者的结构组织
  (8)定时图(timing diagram，计时图)。定时图也是一种交互图，它强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序
  (9)状态图(state diagram)。状态图描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为,这非常有助于对反应式系统建模
  (10)活动图(activity diagram)。活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模和业务流程建模特别重要，并强调对象间的控制流程
  (11)部署图(deployment diagram)。部署图描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图
  (12)制品图(artifact diagram)。制品图描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品图通常与部署图一起使用。制品也给出了它们实现的类和构件
  (13)包图(package diagram)。包图描述由模型本身分解而成的组织单元，以及它们之间的依赖关系
  (14)交互概览图（interaction overview diagram)。交互概览图是活动图和顺序图的混合物

例11
关于用例和类，错误的说法是（ )。
A：两者都属于模型图的构成元素
B：存在抽象用例和抽象类
C：类图描述系统的部分静态视图，用例图描述系统与用户之间的交互视图
D：两者都可以用来描述系统的内部结构

解析

• A：正确。用例和类都是UML模型图的构成元素。
• B：正确。在UML中，确实存在抽象用例和抽象类。抽象用例是指不能直接实例化的用例，通常需要通过扩展或包含关系来实现。抽象类是指不能直接实例化的类，通常作为其他类的基类。
• C：正确。类图描述系统的部分静态视图，展示类、接口、关系等静态结构。用例图描述系统与用户之间的交互视图，展示系统功能和用户角色之间的关系。
• D：错误。用例主要用于描述系统的外部行为和用户交互，而不是系统的内部结构。类图则用于描述系统的内部结构。因此，用例不能用来描述系统的内部结构。

答案：D。

5.2.4 UML 4+1视图

例12
UML采用4+1视图来描述软件和软件开发过程，其中（）描绘了所设计的并发与同步结构;（）表示软件到硬件的映射及分布结构;UML中的类图可以用来表示4+1视图中的 （）。
A:逻辑视图
B:实现视图
C:进程视图
D:部署视图

A:逻辑视图
B:实现视图
C:进程视图
D:部署视图

A:逻辑视图
B:实现视图
C:进程视图
D:部署视图

解析
UML采用4+1视图来描述软件和软件开发过程，

• 进程视图描绘了所设计的并发与同步结构;
• 部署视图表示软件到硬件的映射及分布结构;
• 实现视图表示源代码结构；
• 逻辑视图通过类和对象展现系统功能。
• UML中的类图可以用来表示4+1视图中的逻辑视图。

答案：C、D、A。

5.2.5 OOA模型

OOA（面向对象分析）模型是软件开发过程中用于分析和理解系统需求的重要工具。它通常包括两个主要部分：用例模型和分析模型。以下是对这两个模型的详细描述：

5.2.5.1 用例模型

用例模型用于描述系统的外部行为和用户交互。它主要包括以下步骤：

1. 识别参与者：

   • 确定与系统交互的外部实体，如用户、其他系统或设备。

2. 合并需求获得用例：

   • 将需求文档中的功能需求转化为用例。每个用例代表系统的一个功能或服务。

3. 细化用例描述：

   • 用例名称：简洁地描述用例的功能。
   • 简要说明：用例的简要描述。
   • 事件流：描述用例的正常流程和异常流程。
   • 非功能需求：描述用例的性能、安全等非功能性需求。
   • 前置条件：执行用例前必须满足的条件。
   • 后置条件：用例执行后系统的状态。
   • 扩展点：描述用例中可能的扩展点。
   • 优先级：用例的优先级，用于指导开发顺序。

4. 调整用例模型：

   • 包含关系：一个用例包含另一个用例的行为。
   • 扩展关系：一个用例扩展另一个用例的行为。
   • 泛化关系：一个用例是另一个用例的泛化。

5.2.5.2 分析模型

分析模型用于描述系统的静态结构和动态行为。它主要包括以下步骤：

1. 定义概念类：

   • 识别系统中的关键概念和实体，定义它们的属性和行为。

2. 识别类之间的关系：

   • 依赖关系：一个类依赖于另一个类。
   • 关联关系：类之间的静态关系，表示对象之间的连接。
   • 聚合关系：表示整体与部分的关系，部分可以独立存在。
   • 组合关系：表示整体与部分的关系，部分不能独立存在。
   • 泛化关系：表示类之间的继承关系。
   • 实现关系：表示类实现接口的关系。

3. 为类添加职责：

   • 为每个类定义其职责和行为。

4. 建立交互图：

   • 使用交互图（如顺序图、协作图）描述对象之间的动态交互。

例13
需求分析是一种软件工程活动，它在系统级软件分配和软件设计间起到桥梁的作用。需求分析使得系统工程师能够刻画出软件的（）、指明软件和其他系统元素的接口，并建立软件必须满足的约束。需求分析是发现、求精、建模和规约的过程，包括详细地精化由系统工程师建立并在软件项目计划中精化的软件范围，创建所需数据、信息和（）以及操作行为的模型，此外还有分析可选择的解决方案，并将它们分配到各软件元素中去。
A:功能和性能
B:数据和操作
C:实体和对象
D:操作和对象

A:事件流
B:消息流
C:对象流
D:控制流

解析
需求分析是一种软件工程活动，它在系统级软件分配和软件设计间起到桥梁的作用。需求分析使得系统工程师能够刻画出软件的 功能和性能（A）、指明软件和其他系统元素的接口，并建立软件必须满足的约束。需求分析是发现、求精、建模和规约的过程，包括详细地精化由系统工程师建立并在软件项目计划中精化的软件范围，创建所需数据、信息和 事件流（A）以及操作行为的模型，此外还有分析可选择的解决方案，并将它们分配到各软件元素中去。
答案：A、A。

例14
面向对象系统中有两种基本的复用方式:框架复用和类库复用。下列关于框架和类库的描述不正确的是（ ) 。
A:框架是一个“半成品”的应用程序
B:类库只包含一系列可被应用程序调用的类
C:框架会为一个特定的目的实现一个基本的、可执行的架构
D:类库是框架的一种扩展形式

解析

• A：正确。框架是一个“半成品”的应用程序，它提供了一个基本的结构和一系列可重用的组件，开发人员可以在其基础上进行扩展和定制。
• B：正确。类库只包含一系列可被应用程序调用的类，这些类提供了一些通用的功能，但它们并不提供应用程序的整体结构。
• C：正确。框架会为一个特定的目的实现一个基本的、可执行的架构，开发人员可以在其基础上进行扩展和定制。
• D：错误。类库和框架是两种不同的复用方式。类库是一组可重用的类，而框架是一个“半成品”的应用程序，提供了一个基本的结构和一系列可重用的组件。类库不是框架的扩展形式，它们是两种独立的复用机制。

答案：D。

6 需求定义

严格定义法

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

原型法

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

例15
通常有两种常用的需求定义方法:严格定义方法和原型方法。下述的各种假设条件中，“(）”不适合使用严格定义方法进行需求定义。
A:所有需求都能够被预先定义
B:开发人员与用户之间能够准确而清晰地交流
C:需求不能在系统开发前被完全准确地说明
D:采用图形(或文字）充分体现最终系统

解析
严格定义法

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

答案：C。

7 需求验证

需求验证是软件开发过程中的一个关键步骤，它确保需求文档的正确性、完整性和一致性。需求验证通常包括以下几个方面：

1. 需求评审：

   • 正式评审：由项目团队、利益相关者和领域专家参与的正式会议，对需求文档进行详细的审查和讨论。
   • 非正式评审：由项目团队内部进行的非正式审查，通常在正式评审之前进行，以便提前发现和解决问题。

2. 需求测试：

   • 通过创建测试用例来验证需求是否正确实现。测试用例应覆盖所有功能需求和非功能需求。

3. 用户签字确认：

   • 需求验证的一个重要环节是获得用户的签字确认。用户签字确认意味着用户认可需求文档的内容，并将其作为验收标准之一。

7.1 需求验证的步骤

1. 需求评审：

   • 非正式评审：项目团队内部对需求文档进行初步审查，确保文档的格式、内容和一致性。
   • 正式评审：由项目团队、利益相关者和领域专家参与的正式会议，对需求文档进行详细的审查和讨论。

2. 需求测试：

   • 创建测试用例来验证需求是否正确实现。测试用例应覆盖所有功能需求和非功能需求。

3. 用户签字确认：

   • 获得用户的签字确认，确保用户认可需求文档的内容，并将其作为验收标准之一。

7.2 需求验证的重要性

• 确保需求正确性：通过评审和测试，确保需求文档的正确性。
• 确保需求完整性：确保所有功能需求和非功能需求都被覆盖。
• 确保需求一致性：确保需求文档内部和与其他文档之间的一致性。
• 用户认可：通过用户签字确认，确保用户认可需求文档的内容，并将其作为验收标准之一。

8 需求管理

8.1 需求跟踪

需求跟踪（Requirement Traceability）是软件开发过程中的一项重要活动，它确保每个需求在整个开发周期中都能被正确地跟踪和管理。需求跟踪的目的是确保每个需求都能在后续的设计、编码、测试和维护阶段被正确地实现和验证。

8.1.1 需求跟踪的目的

1. 确保需求的完整性：确保所有需求都被正确地实现和验证。
2. 确保需求的可追溯性：确保每个需求都能被追溯到其来源和实现。
3. 确保需求的变更管理：在需求变更时，能够快速定位受影响的模块和测试用例。
4. 确保需求的验证：确保每个需求都能在测试阶段被正确地验证。

8.1.2 需求跟踪的类型

1. 正向跟踪（Forward Traceability）：

   • 从需求到设计、编码和测试的跟踪。确保每个需求都被正确地实现和验证。
   • 例如：需求 -> 设计文档 -> 代码 -> 测试用例。

2. 反向跟踪（Backward Traceability）：

   • 从设计、编码和测试到需求的跟踪。确保每个设计、代码和测试用例都能追溯到其对应的需求。
   • 例如：测试用例 -> 代码 -> 设计文档 -> 需求。

3. 双向跟踪（Bi-directional Traceability）：

   • 结合正向跟踪和反向跟踪，确保需求、设计、代码和测试用例之间的双向关联。

8.1.3 需求跟踪矩阵

需求跟踪矩阵（Requirement Traceability Matrix, RTM）是实现需求跟踪的一种常用工具。它是一个表格，列出了每个需求及其对应的实现、测试用例和验证结果。

例16
某软件项目实施过程中产生的一个文档的主要内容如下所示，该文档的主要作用是（）

A:工作分解
B:测试说明
C:需求跟踪
D:设计验证

解析
该文档的主要作用是需求跟踪。
答案：C。

8.2 需求的状态

8.3 需求变更管理过程

需求变更管理过程是软件开发过程中的一项关键活动，它确保在项目进行中对需求的任何变更都能得到适当的评估、决策和实施。需求变更管理过程通常包括以下几个步骤：

8.3.1 变更申请

• 提出变更请求：任何利益相关者（如用户、开发人员、测试人员等）都可以提出需求变更请求。变更请求通常以书面形式提交，包含变更的详细描述、变更的原因和预期的影响。
• 记录变更请求：将变更请求记录在变更管理工具中，并为每个变更请求分配唯一的ID。

8.3.2 变更评估

• 影响分析：评估变更对项目进度、成本、资源和质量的影响。分析变更可能对现有功能、设计、代码和测试用例的影响。
• 风险评估：评估变更可能带来的风险，包括技术风险、业务风险和项目风险。
• 成本估算：估算变更的实施成本，包括开发成本、测试成本和维护成本。

8.3.3 变更决策

• CCB决策：变更控制委员会（Change Control Board, CCB）负责对变更请求进行决策。CCB通常由项目经理、技术负责人、业务代表和质量保证人员组成。
  • 批准变更：如果变更被批准，则进入变更实施阶段。
  • 拒绝变更：如果变更被拒绝，则记录拒绝原因，并通知变更请求提出者。
  • 推迟变更：如果变更被推迟，则记录推迟原因，并安排在后续版本或阶段中实施。

8.3.4 变更实施

• 设计变更：根据批准的变更请求，修改设计文档，确保设计方案符合新的需求。
• 代码变更：根据设计文档，修改代码，实现新的功能或修改现有功能。
• 测试用例变更：根据变更请求，修改或创建新的测试用例，确保变更的功能得到正确的测试。

8.3.5 变更验证

• 测试验证：执行修改后的测试用例，验证变更的功能是否符合预期。
• 用户验收测试：如果变更涉及用户需求，进行用户验收测试，确保变更符合用户的业务需求。

8.3.6 沟通存档

• 沟通变更：将变更的决策、实施和验证结果通知所有相关利益相关者，确保他们了解变更的影响。
• 存档变更：将变更请求、评估报告、决策记录、实施文档和验证结果存档，作为项目文档的一部分。

例17
一个大型软件系统的需求通常是会发生变化的。以下关于需求变更策略的叙述中，错误的是（ )。
A:所有需求变更必须遵循变更控制过程
B:对于未获得核准的变更，不应该做变更实现工作
C:完成了对某个需求的变更之后，就可以删除或者修改变更请求的原始文档
D:每一个集成的需求变更必须能追溯到一个经核准的变更请求

解析

• 变更请求的原始文档应该保留，作为项目文档的一部分，以便追溯和审计

答案：C。

例18
需求变更管理是需求管理的重要内容。需求变更管理的过程主要包括问题分析和变更描述、()、变更实现。具体来说，在关于需求变更管理的描述中，（）是不正确的。
A:变更调研
B:变更判定
C:变更定义
D:变更分析和成本计算

A:需求变更要进行控制，严格防止因失控而导致项目混乱，出现重大风险B:需求变更对软件项目开发有利无弊
C:需求变更通常按特定的流程进行
D:在需求变更中，变更审批由CCB负责

解析

• 需求变更管理的过程主要包括问题分析和变更描述、变更分析和成本计算、变更实现；
• 需求变更可能会带来项目进度、成本和质量方面的风险，因此并非总是有利无弊；

答案：D、B。

9 附录 思维导图