【系统分析师】软件需求工程——第11章学习笔记（下）

11.5 面向对象分析方法

运用OO方法，对问题进行分析和理解，找出描述问题域和系统功能所需的类和对象，定义他们的属性和职责，以及他们之间形成的各种联系。

OOA模型独立于具体实现，即不考虑与系统具体实现有关的因素，这也是OOA和面向对象的设计(Object-Oriented Design，OOD)的区别所在。OOA的任务是“做什么”，OOD的任务是“怎么做”

11.5.1用例模型

在OOA方法中，构建用例模型一般需要经历4个阶段，分别是识别参与者、合并需求获得用例、细化用例描述和调整用例模型，其中前三个阶段是必需的。

用例图的元素

用例是一种描述系统需求的方法， 使用用例的方法来描述系统需求的过程就是用例建模。主要包括：

• 参与者
• 用例
• 通信关联（箭头方向不代表信息流，只表示主动被动关系）

识别参与者

参与者是与系统交互的所有事物，该角色不仅可以由人承担，还可以是其他系统和硬件设备，甚至是系统时钟。

• 其他系统。当系统需要与其他系统交互时，其他系统就是一个参与者。例如，对某企业的在线教育平台系统而言，该企业的OA系统就是一个参与者。
• 硬件设备。如果系统需要与硬件设备交互，硬件设备就是一个参与者。例如，在开发集成电路(Integrated Circuit，IC)卡门禁系统时，IC卡读写器就是一个参与者。
• 时钟。当系统需要定时触发时，时钟就是一个参与者。例如，开发在线测试系统中的“定时交卷”功能时，就需要引入时钟作为参与者。

合并需求获得用例

注意以下问题：

• 用例命名
  • 注意采用“动词（短语）+名词（短语）”的形式
• 不能混淆用例和用例所包含的步骤
  • 例如,“开通课程”功能要经过验证学员信息、检查学员权限、保存开通记录、修改课程选修人数等步骤才能完成，在系统中这些步骤不能作为单独的功能对外提供，它们只是一个用例所包含的事件流，或是用例的子功能。
• 注意区分业务用例和系统用例
  • 当针对整个业务领域建模时，需要用到业务用例，涉及到大量的人工活动。这些是信息系统无法完成的，不要考虑这些，比如“编写教材”

细化用例描述

用例建模的主要工作是书写用例规约（Use Case Specfication）,而不是画图，用例模版为一个给定项目的所有人员定义了用例规约的结果。

用例描述通常包括以下几个部分：

• 用例名称
  • 写上相应编号
• 简要说明
  • 对用例为参与者所传递的价值结果进行描述
• 事件流
  • 当参与者与系统试图达到一个目标时所发生的一些列活动，也就是用例所完成的工作步骤。
  • 主事件流是指能够满足目标的典型的成功路径
  • 备选事件流（扩展事件流）是完成用例可能失败的情况，分支路径或扩展路径。
• 非功能需求
  • 因为用例所涉及的非功能需水通常很难在事件流中进行表达，因此单外为一小节进行描述。在非功能需求的描述方面，一定要注意使其可度量和可验证。否则，就容易流于形式，形同摆设。
• 前置条件和后置条件
  •  前置条件就是执行用例之前必须存在的系统状态
  • 后置条件是执行完毕系统可能处于的一组状态
• 扩展点
  • 如果包括扩展（包含）用例，则写出扩展用例名，并说明在什么情况下使用。
• 优先级
  • 说明用户对该用例的期望值，为以后的开发工作确定先后顺序，可以采用满意度指标进行说明，比如，设置为1-5的数值

调整用例模型

还可以利用用例之间的关系来调整用例模型：

• 包含关系。
  • 当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。其中这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例。
• 扩展关系。
  • 如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰。
• 泛化关系。
  • 当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。

11.5.2 分析模型

分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统(静态模型)，以及它们如何保持通信，实现系统行为(动态模型)。

建立分析模型的过程大致包括定义概念类、确定类之间的关系、为类添加职责、建立交互图等，其中有学者将前三个步骤统称为类-责任-协作者(Class-Responsibity-Collaborator,CRC)建模。

定义概念类

OOA的中心任务找到系统中的对象或类，这些类将反映到系统设计中的软件类和系统实现中某个OOP语言声明的类。

发现类的方法有很多种，其中应用最广泛的是名词短语法。

它的主要规则是先识别有关问题域文本描述中的名词或名词短语，然后将它们作为候选的概念类或属性，其具体步骤如下:

• 阅读和理解需求文档或用例描述。
• 筛选出名词或名词短语，建立初始类清单(候选类)。
• 将候选类分成三类，分别是显而易见的类、明显无意义的类和不确定类别的类。
• 舍弃明显无意义的类。
• 小组讨论不确定类别的类，直到将它们都合并或调整到其他两个类别，并进行相应的操作。

例如，根据表11-2所描述的“开通课程”用例的事件流，可以获得候选概念类的清单，如表 11-3 所示。

确定类之间的关系

类之间的关系主要有：

• 关联
  • 提供了不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。
  • 体现对象实例之间的关系，而不是两个类之间的关系
  • 
  • 关联名称反映该关系的目的，并且应该是一个动词
  • 
  • 图中的数字和“*“ 都表示关联，“*”等价于“0..*”
• 依赖
  • 两个类A和B，如果B的变化可能会引起A的变化，则称类A依赖于类B。依赖可以由各种原因引起，例如，一个类向另一个类发送消息、一个类是另一个类的数据成一个类是另一个类的某个操作参数等。
  • 
• 泛化
  • 泛化关系描述了般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说，子类继承了父类，而父类则是子类的泛化。
  • 
• 聚合
  • 共享聚集关系通常简称为聚合关系，它表示类之间的整体与部分的关系,其含义是“部分”可能同时属于多个“整体”,“部分”与“整体”的生命周期可以不相同。例如，汽车和车轮就是聚合关系，车子坏了，车轮还可以用:车轮坏了，可以再换一个。
  • 
• 组合
  • 组合聚集。组合聚集关系通常简称为组合关系，它也是表示类之间的整体与部分的关系。与聚合关系的区别在于，组合关系中的“部分”只能属于一个“整体”,“部分”与“整体”的生命周期相同,“部分”随着“整体”的创建而创建，也随着“整体”的消亡而消亡。
  • 例如,一个公司包含多个部门，它们之间的关系就是组合关系。公司一旦倒闭，也就无所谓部门了。
  • 
• 实现
  • 实现关系将说明和实现联系起来。接口是对行为而非实现的说明，而类中则包含了实现的结构。
  • 一个或多个类可以实现一个接口，而每个类分别实现接口中的操作。确定了类之间的关系之后，通过 UML的类图将这些关系记录下来，形成领域模型
  • 

图11-12就是在线教育平台有关的一个简单的领域模型：

为类添加职责

类的职责包括两个方面的内容，一个是类所维护的知识，即成员变量或属性;另一个是类能够执行的行为，即成员方法或责任。

属性是描述类静态特征的一个数据项。

对于类的责任的确定，可以根据用例描述中的动词来进行判断，然后再进行选。这个过程与类的识别过程是类似的，此处不再赘述。系统分析师应该通用性地描述类的成员方法，例如，“交费”和“组卷”等。另外，根据封装性原则，信息和与其相关的行为应该存在于同一个类中。关于一个事物的信息应该包含在单个类中，而不是分布在多个类中。但是，在适当的时候，可以在相关的类之间分享责任。

这个阶段只是找一些主要的，明显的。

建立交互图

多个对象的行为通常采用对象交互来表示，UML2.0提供的交互图有顺序图、交互概览图、通信图和定时图。

每种图出于不同视点对行为有不同的表现能力，其中最常用的是顺序图，几乎可以用在任何系统的场合。顺序图的基本元素有对象、参与者、生命线、激活框、消息和消息路线，其中消息是顺序图的灵魂。当对象行为复杂并存在多种不同状态转换时，还要用到反映对象状态变化的状态图。

分析模型的详细程度问题

没有明确的详细程度标准，根据实际情况辅助开发即可。

11.6 需求定义

系统分析师在获取了用户的需求，并进行了详细分析之后，接下来的工作就需要把这些软件需求形成文档，作为系统后续开发的基础，这就是需求定义。

11.6.1 需求定义的方法

需求定义的过程也就是形成需求规格说明书的过程，通常有两种定义方法：

• 严格定义法-预先定义
  • 所有需求都能够被定义-规模小，功能简单的系统
  • 开发人员与用户之间能够准确且清晰的交流
  • 采用图形（或文字）可以充分体现最终该系统。
• 原型方法
  • 迭代循环的开发方法
  • 注意以下问题：
    • 并非所有的需求都能在系统开发前被准确说明
    • 项目干系人之间通常存在交流困难
    • 需要实际，可提供用户参与的模型
    • 有合适的系统开发环境
    • 反复是完全被需要和值得提倡的

11.6.2 软件需求规格说明书

软件需求规格说明书(Software Requirement Specifcation，SRS)是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少。

SRS编写方法

通常有三种方法编写SRS，分别列举如下:

• 用好的结构化和自然语言编写文本型文档。
• 建立图形化模型，这些模型可以描述转换过程、系统状态及其变化、数据关系、逻辑流、对象类及其关系。
• 编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。

尽管形式化规格说明具有很强的严密性和精确度，但由于其所使用的形式化语言只有极少数专业人员才熟悉，所以，这一方法一直没有在实际应用中得到普遍使用。虽然文本型文档具有许多缺点，但在大多数软件工程中，它仍是编写SRS最现实的方法。

包含了功能和非功能需求的基于文本的 SRS 已经为大多数项目所接受。图形化模型通过提供另一种需求视图，增强了SRS，一般作为文本型文档的补充或附加描述功能

SRS的内容和格式

• 范围。
  • 本部分包括SRS适用的系统和软件的完整标识，(若适用)包括标识号、标题缩略词语、版本号和发行号;
  • 简述 SRS适用的系统和软件的用途，描述系统和软件的一般特性概述系统开发、运行和维护的历史;标识项目的投资方、需方、用户、承建方和支持机构;标识当前和计划的运行现场;列出其他有关的文档:概述SRS的用途和内容，并描述与其使用有关的保密性和私密性的要求;说明编写SRS所依据的基线。
• 引用文件。
  • 列出SRS中引用的所有文档的编号、标题、修订版本和日期，还应标识不能通过正常的供货渠道获得的所有文档的来源。
• 需求。
  • 这一部分是 SRS的主体部分，详细描述软件需求，可以分为以下项目:所需的状态和方式、需求概述、需求规格、软件配置项能力需求、软件配置项外部接口需求、软件配置项内部接口需求、适应性需求、保密性和私密性需求、软件配置项环境需求、计算机资源需求(包括硬件需求、硬件资源利用需求、软件需求和通信需求)、软件质量因素、设计和实现丝束、数据、操作、故障处理、算法说明、有关人员需求、有关培训需求、有关后勤需求、包装需求和其他需求，以及需求的优先次序和关键程度。
• 合格性规定。
  • 这一部分定义一组合格性的方法，对于]每个需求，指定所使用的方法，以确保需求得到满足。合格性方法包括演示、测试、分析、审查和特殊的合格性方法(例如，专用工具、技术、过程、设施和验收限制等)。)需求可追踪性。这一部分包括从SRS中每个软件配置项的需求到其涉及的系统(或子系统)需求的双向可追踪性。
• 尚未解决的问题。
  • 如果有必要，可以在这一部分说明软件需求中的尚未解决的遗问题。
• 注解。
  • 这一部分包含有助于理解 SRS的一般信息，例如，背景信息、词汇表、原理等。这一部分应包含为理解 SRS 需要的术语和定义，所有缩略语和它们在 SRS 中的含义的字母序列表。
• 附录。
  • 提供那些为便于维护 SRS而单独编排的信息(例如，图表、分类数据等)。为便于处理，附录可以单独装订成册，按字母顺序编排。

11.7 需求验证

资深软件工程师都知道，当以 SRS为基础进行后续开发工作，如果在开发后期或在交付系统之后才发现需求存在问题，这时修补需求错误就需要做大量的工作。相对而言，在系统分析阶段，检测 SRS中的错误所采取的任何措施都将节省相当多的时间和资金。因此，有必要对于SRS的正确性进行验证，以确保需求符合良好特征。需求验证也称为需求确认，其活动是为了确定以下几个方面的内容:

• SRS 正确地描述了预期的、满足项目千系人需求的系统行为和特征。
• SRS 中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
• 需求是完整的和高质量的。
• 需求的表示在所有地方都是一致的。
• 需求为继续进行系统设计、实现和测试提供了足够的基础

11.7.1 需求评审

在软件开发的每个阶段结束前，都需要进行技术评审。所谓技术评审，是指对工作产品进行检查以发现产品中所存在的问题，其中的工作产品也称为工件，它不一定是最终的系统，也可以是一个文档、一个原型或一段代码等。

技术评审的类型

根据 IEEE的词汇表，技术评审可以分为以下三种类型:

• 评审。
  • 评审是指一次正式的会议，在会议上向用户或其他项目干系人介绍一个或一组工作产品，以征求对方的意见和批准。
  • 有正式评审和非正式评审
• 检查。
  • 检查是一种正式的评估方法，将由非制作者本人的个人或小组详细检查工作产品，以验证是否有错误、是否违反开发标准、是否存在其他问题。
• 走查。
  • 走查是一个评审过程，由某个开发人员领导一个或多个开发团队成员对其工作产品进行检查，由其他成员针对技术、风格、可能的错误、是否违反开发标准和是否存在其他问题提出意见。

如何做好需求评审

• 分层次评审
  • 根据用户需求不同的层次，对应不同的描述形式，参与人员也不同
• 正式评审与非正式评审相结合
• 分阶段评审
  • 在需求形成的过程中进行
• 精心挑选评审人员
  • 保证不同类型的人员参与进来
  • 对系统足够高了解，有真正关系的人
• 对评审人员进行培训
• 充分利用需求评审检查单
  • 需求形式的检查单，需求内容的检查单
• 建立标注的评审流程
• 做好评审后的跟踪工作
• 充分准备评审

11.7.2 需求测试

概念测试用例

实际上，需求开发阶段不可能有真正意义上的测试进行，因为还没有可执行的系统，需求测试仅仅是基于文本需求进行“概念”上的测试。然而，以功能需求为基础(SA方法)或者从用例派生出来(OO方法)的测试用例，可以使项目干系人更清楚地了解系统的行为。虽然没有在系统上执行测试用例，但是涉及测试用例的简单动作可以解释需求的许多问题。

需求测试的过程

基于概念测试用例进行需求测试的基本过程如下：

(1)需求测试人员根据概念测试用例所描述的若干可能的过程，进行“概念上”的执行,期望发现遗漏的、错误的和不必要的需求。

(2)根据测试结果快速修改对应的需求文档，完成一轮完整的需求测试过程。

基于该过程，需求测试人员应用概念测试用例来进行需求测试，直至概念测试覆盖所有的用例和功能需求条目为止。需求测试人员和系统分析师根据需求测试的结果，进一步讨论修订SRS 的内容和版本。至此，整个需求测试过程结束。
在实际工作中，可以将需求测试人员作为测试人员中的特殊类型来培养，使他们能够对需求是否正确进行检查。

11.8 需求管理

需求管理包括需求文档的追踪管理、变更控制、版本控制等管理性活动。软件需求开发的最终文档经过评审批准后，就定义了开发工作的需求基线(Baseline)。

11.8.1 需求变更

软件需求文档应该精确描述要交付的产品，这是一个基本的原则。为了使开发组织能够严格控制软件项目，应该确保以下事项:

• 仔细评估已建议的变更。
• 挑选合适的人选对变更做出判定
• 变更应及时通知所有相关人员。
• 项目要按一定的程序来采纳需求变更，对变更的过程和状态进行控制。

变更控制过程

变更控制过程用来跟踪已建议变更的状态，使已建议的变更确保不会丢失或疏忽，一旦确定了需求基线，应该使所有已建议的变更都遵循变更控制过程：

• 问题分析和变更描述:
  • 当提出一份变更提议后，需要对该提议做进一步的问题分析，检查它的有效性，从而产生一个更明确的需求变更提议。
• 变更分析和成本计算:
  • 当接受该变更提议后，需要对需求变更提议进行影响分析和评估。变更成本计算应该包括对该变更所引起的所有改动的成本，例如修改需求文档、相应的设计、实现等工作成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。
• 变更实现:
  • 当确定执行该变更后，需要根据该变更的影响范围，按照开发的过程模型执行相应的变更。在计划驱动过程模型中，往往需要回溯到需求分析阶段开始，重新作对应的需求分析、设计和实现等步骤;在敏捷开发模型中，往往会将需求变更纳入到下一次迭代的执行过程中。

常见的需求变更策略:

1. 所有需求变更必须遵循变更控制过程。
2. 对于未获得批准的变更，不应该做设计和实现工作。
3. 变更应该由项目变更控制委员会决定实现哪些变更。
4. 项目风险承担者应该能够了解变更的内容。
5. 绝不能从项目配置库中删除或者修改变更请求的原始文档。
6. 每一个集成的需求变更必须能跟踪到一个经核准的变更请求，以保持水平可追踪性。

目前存在很多需求变更跟踪工具，这些工具用来收集、存储和管理需求变更。问题跟踪工具也可以随时按变更状态分类报告变更请求的数目。

变更控制委员会

变更控制委员会(ChangeControlBoard，CCB)是项目所有者权益代表，负责裁定接受哪些变更。CCB由项目所涉及的多方成员共同组成，通常包括用户和实施方的决策人员。CCB是决策机构，不是作业机构，通常CCB的工作是通过评审手段来决定项目是否能变更，但不提出变更方案。
变更控制委员会可能包括如下方面的代表。

• 产品或计划管理部门。
• 项目管理部门。
• 开发部门。
• 测试或质量保证部门
• 市场部或客户代表
• 制作用户文档的部门。
• 技术支持部门。
• 帮助桌面或用户支持热线部门。
• 配置管理部门。

变更控制委员会应该有一个总则，用于描述变更控制委员会的目的、授权范围、成员构成、做出决策的过程及操作步骤。总则也应该说明举行会议的频度和事由。管理范围描述该委员会能做什么样的决策，以及有哪一类决策应上报到高一级的委员会。过程及操作步骤如下:

• 制定决策。
  • 制定决策过程的描述应确认:
    • 变更控制委员会必须到会的人数或做出有效决定必须出席的人数。
    • 决策的方法(例如投票、一致通过或其他机制)。
    • 变更控制委员会主席是否可以否决该集体的决定。
  • 变更控制委员会应该对每个变更权衡利弊后做出决定。“利”包括节省的资金或额外的收入、增强的客户满意度、竞争优势、减少上市时间;“弊”是指接受变更后产生的负面影响，包括增加的开发费用、推迟的交付日期、产品质量的下降、减少的功能、用户不满意度
• 交流情况。
  • 一旦变更控制委员会做出决策，指派的人员应及时更新请求的状态。
• 重新协商约定。
  • 变更总是有代价的，即使拒绝的变更也会因为决策行为(提交、评估、决策)而耗费资源。当项目接受了重要的需求变更时，为了适应变更情况要与管理部门和客户重新协商约定。协商的内容可能包括推迟交货时间、要求增加人手、推迟实现尚未实现的较低优先级的需求，或者质量上进行折中。

11.8.2 需求跟踪

需求跟踪包括编制每个需求同系统元素之间的联系文档，这些元素包括其他需求、体系结构、其他设计部件、源代码模块、测试、帮助文件和文档等，这是为了在整个项目的工件之间形成水平可追踪性。跟踪能力信息使变更影响分析十分便利，有利于确认和评估实现某个建议的需求变更所必需的工作。
需求跟踪提供了由需求到产品实现整个过程范围的明确查阅能力。

需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性，确保所有的工作成果符合用户需求。
需求跟踪有两种方式:

• 正向跟踪。
  • 检查产品需求规格说明书中的每个需求是否都能在后继工作成果中找到对应点。
• 逆向跟踪。
  • 检查设计文档、代码、测试用例等工作成果是否都能在产品需求规格说明书中找到出处。

正向跟踪和逆向跟踪合称为双向跟踪。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵(即表格)。需求跟踪矩阵保存了需求与后继工作成果的对应关系。跟踪能力是优秀需求规格说明书的一个特征，为了实现可跟踪能力，必须统一地标识出每一个需求，以便能明确地进行查阅。

---

PS: 一转眼间，下半年的软考也要开始报名了, 由于我现在没什么时间来看书了， 工作内容也不是和系分考试十分有关，这个学习笔记系列可能要暂时放一段时间了，但我还是想把所有章节更完的，有始有终嘛，后续可能更新频率会十分不稳定了，没法保证一周一篇。但也说不定会更新一些我在学的新的科目的笔记，祝大家软考都能顺利通过吧！一起加油！一起进步！