系分 - （软件）需求工程
个人总结，仅供参考，欢迎加好友一起讨论
文章目录
- 系分 - (软件)需求工程
- 考点摘要
- 需求工程
- 需求开发（主线，目标）
-
- 需求分类
- 基于领域工程的需求分析
- PIECES框架
- 需求获取
- 需求记录技术
- 需求分析
- 结构化分析方法 - SA
-
- SA - 数据字典
- SA - 数据流图DFD
- SA - 状态转换图STD
- SA - E-R图/实体联系图
- SA - 例题
- 面向对象的分析方法 - OOA
-
- OOA - UML
- OOA - UML 4+1视图
- OOA - 用例模型与分析模型
- 需求分析工具
-
- 使用用例建模系统需求
- 数据建模与分析
- 过程建模
- 面向对象分析与建模
- OOA - 例题
- 需求定义
- 需求验证/需求确认
- 需求管理（支持，保障）
-
-
- 定义需求基线
- 需求的状态
- 需求变更管理
- 需求风险
- 需求跟踪
-
系分 - (软件)需求工程
考点摘要
- 软件工程概述（★★★）
- 需求获取（★★★★★）
- 需求分析（★★★★★）
- 需求定义（★★）
- 需求验证（★★★）
- 需求管理（★★★）
需求工程
需求工程，需求开发（含需求分析）和需求管理。
系统分析，软件需求分析、硬件需求分析、网络需求分析。
例题1：
例题1解析与答案：
答案：D
解析：略
例题2：
例题2解析与答案：
答案：D
解析：略
需求开发（主线，目标）
需求分类
需求分类
- 业务需求，业务需求是指反映企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围。
- 用户需求，用户需求描述的是用户的具体目标，或用户要求系统必须能完成的任务。也就是说，用户需求描述了用户能使用系统来做些什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景（scenarios）进行整理，从而建立用户需求
- 系统需求，系统需求是从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。
质量功能部署QFD
它是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD将软件需求分为三类，分别是常规需求、期望需求和意外需求。
- 基本需求，也叫常规需求，用户认为系统应该做到的功能或性能，实现越多用户会越满意。
- 期望需求，用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。
- 意外需求，意外需求也称为兴奋需求，是用户要求范围外的功能或性能（但通常是软件开发人员很乐意赋予系统的技术特性），实现这些需求用户会更高兴，但不实现也不影响其购买的决策。
例题3：
例题3解析与答案：
答案：B
解析：题目描述清晰“用户”字眼
基于领域工程的需求分析
领域工程是在构造一个特定领域内的系统或者系统的某些部分时，以可重用方面的形式（也就是说，可重用的工作产物），收集、组织并保存过去的经验的活动，以及在构造新系统时，提供一种充分的方法来重用这些资源（也就是说，获取、限定、改造、装配等等）。
运用领域工程的思想，提出了基于领域模型的系统需求获取方法，该方法可识别应用系统中的共同特征，并抽象这些特征形成领域模型，通过领域模型引导用户给出完整的系统需求。
领域工程一般可以分为领域分析、领域设计和领域实现三个阶段：
- 领域分析，这个阶段通过对领域的边界、对象、现存相应的系统进行分析，抽取出领域系统中的共同特征和可变特征，形成领域分析模型。
- 领域设计，通过领域分析得到的领域分析模型，领域开发人员设计出适应所有领域系统的共同构架DSSA。DSSA（特定领域软件架构）是一个高层次设计，需满足领域所有系统的需求，但因领域需求具有可变性，因此DSSA需要具有一定的可扩展性
- 领域实现，在领域分析和领域实现基础上，领域实现主要是通过领域分析模型和DSSA去提取、设计、实现领域中可复用资源，这些资源可以是领域框架、领域特定设计和代码构件等。
领域系统开发主要经过以上三个阶段，但在开发过程中，当在某一阶段发现前一个阶段所得到的结果需要进行调整，则要返回前一阶段进行重新调整后再回到当前阶段继续开发设计。因此这种系统开发过程并不是流水线式的过程，而是需要经过一个不断反复、逐渐求精的过程。
从领域工程中的三个阶段中抽取：
- 领域分析阶段。领域分析是领域工程的重要组成部分，在这个阶段主要是收集、分析、组织、描述领域中的所有相关信息，并在定义领域边界、明确分析对象、识别信息源等基础上，确定哪些资源可被领域系统共享，形成相应的领域需求模型，从而抽取相应的构件。
- 领域设计阶段。领域设计阶段主要是获得特定领域软件架构（DSSA），适应领域中的所有应用系统需求和领域构件划分，形成特地领域的系统设计。
- 领域实现阶段。此阶段主要是对以上两个阶段中获取的领域构件进行实现以及管理。构件的实现可以通过现有的系统中提取得到，也可以通过自行编码开发得到。此阶段抽取的构件主要包含领域框架构件、领域描述构件（用特定的语言描述）和代码构件等。
经过以上三个阶段后，当需要开发一个领域的新应用系统时，就可以象组装产品一样，根据具体的需求，将需要的构件按照应用系统设计去组装形成，而无需从零开始。
PIECES框架
PIECES框架是系统非功能性需求分类的技术。
| 概念描述 | 示例关键字 | |
|---|---|---|
| 性能 Performance |
描述企业当前的运行效率，业务的处理速度 | 响应时间,吞吐量 |
| 信息 Information |
描述业务数据的输入、输出以及处理方面存在的各种问题 | 无法捕获数据,或数据不精准 |
| 经济 Economics |
从成本和收益的角度分析企业当前存在的问题 | 订单数减少 |
| 控制 Control |
提高信息系统的安全和控制水平 | 身份鉴别 |
| 效率 Efficiency |
提高企业的人、财、物等的使用效率 | 浪费时间/材料/资源 |
| 服务 Service |
提高企业对客户、供应商、合作伙伴、顾客等的服务质量 | 系统结果不准、使用困难、与其它系统不兼容 |
需求获取
| 需求获取方法 | |
|---|---|
| 方法 | 特点 |
| 收集资料 | 把与系统有关的、对系统开发有益的信息收集起来。 |
| 阅读历史文档 | 对收集数据性的信息较为有用。 |
| 用户访谈 | 1对1-3，有代表性的用户，了解主观想法，交互好。成本高，要有领域知识支撑。 |
| 问卷调查 | 用户多，无法—一访谈，成本低。 |
| 现场观摩 | 针对较为复杂的流程和操作。 |
| 参加业务实践 | 有效地发现问题的本质和寻找解决问题的办法。 |
| 联合需求计划(JRP) | 高度组织的群体会议，各方参与，了解想法，消除分歧，交互好，成本高。 |
| 情节串联板(原型法) | 一系列图片，通过这些图片来讲故事。 |
| 抽样调查/采样 | 基于数理统计，降低成本，快速获取。 样本大小=a*(可信度系数/可接受的错误)2注:a一般取0.25 |
-
用户访谈是最基本的一种需求获取手段，其形式包括结构化和非结构化两种。结构化是指事先准备好一系列问题，有针对地进行；而非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。最有效的访谈是结合这两种方法进行，毕竟不可能把什么都一一计划清楚，应该保持良好的灵活性。
用户访谈具有良好的灵活性，有较宽广的应用范围。但是，也存在着许多困难，例如，用户经常较忙，难以安排时间；面谈时信息量大，记录较为困难；沟通需要很多技巧，同时需要系统分析师具有足够的领域知识等。另外，在访谈时，还可能会遇到一些对于企业来说比较机密和敏感的话题。因此，这看似简单的技术，也需要系统分析师具有丰富的经验和较强的沟通能力。 -
问卷调查与用户访谈相比，问卷调查可以在短时间内，以低廉的代价从大量的回答中收集数据；问卷调查允许回答者匿名填写，大多数用户可能会提供真实信息；问卷调查的结果比较好整理和统计。但是问卷调查最大的不足就是缺乏灵活性，其他缺点还有：
① 双方未见面，系统分析师无法从用户的表情等其他动作来获取一些更隐性的信息，用户也没有机会立即澄清对问题有含糊或错误的回答。
② 用户有可能在心理上会不重视一张小小的表格，不认真对待，从而使得反馈的信息不全面。
③ 调查表不利于对问题进行展开的回答，无法了解一些细节问题。
④ 回答者的数量往往比预期的要少，无法保证用户会回答问题或进一步说明所有问题。
-
抽样调查/采样是指从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。对于信息系统的开发而言，现有系统的文档（文件）就是采样种群。当开始对一个系统做需求分析时，查看现有系统的文档是对系统有初步了解的最好方法。但是，系统分析师应该查看哪些类型的文档，当文档的数据庞大，无法一一研究时，就需要使用采样技术选出有代表性的数据。采样技术不仅可以用于收集数据，还可以用于采集访谈用户或者是采集观察用户。在对人员进行采样时，上面介绍的采样技术同样适用。通过采样技术，选择部分而不是选择种群的全部，不仅加快了数据收集的过程，而且提高了效率，从而降低了开发成本。另外，采样技术使用了数理统计原理，能减少数据收集的偏差。
但是，由于采样技术基于统计学原理，样本规模的确定依赖于期望的可信度和已有的先验知识，很大程度上取决于系统分析师的主观因素，对系统分析师个人的经验和能力依赖性很强，要求系统分析师具有较高的水平和丰富的经验。 -
联合需求计划（JRP）
JRP是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。它通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。通常该会议的参与人数为6～18人，召开时间为1～5小时。
JRP的主要意图是收集需求，而不是对需求进行分析和验证。实施JRP时应把握以下主要原则：① 在JRP实施之前，应制订详细的议程，并严格遵照议程进行。
②按照既定的时间安排进行。
③尽量完整地记录会议期间的内容。
④在讨论期间尽量避免使用专业术语。
⑤充分运用解决冲突的技能。
⑥会议期间应设置充分的间歇时间。
⑦鼓励团队取得一致意见。
⑧保证参加JRP的所有人员能够遵守事先约定的规则。
例题4：
例题4解析与答案：
答案：C D
解析：开调查会的方式会强调需求分析人员与用户之间的交互，过程中可以获取用户对系统的想法和建议
对于一些较为复杂的流程和操作而言，是比较难以用语言和文字进行表达的，可以采用到客户的工作现场
需求记录技术
常用的需求记录工具有任务卡片、场景说明、用户故事和Volere白卡等。
个人认为这部分按照以往的考察内容，不是很重要，如果需要了解可自行搜索网络经验贴。
需求分析
关于“结构法方法”和“面向对象的方法”请参考如下文章：
- 结构化方法：https://blog.csdn.net/lili40342/article/details/128517358
- 面向对象的方法：https://blog.csdn.net/lili40342/article/details/128517374
结构化分析方法 - SA
结构化分析方法SA的核心是数据字典。围绕这个核心有三个层次的模型，分别是数据模型，功能模型，行为模型（状态模型）。
结构化分析方法SA是数据流和控制流。
SA - 数据字典
数据字典是需求分析建立模型的核心。包括了数据元素，数据结构，数据流，加工逻辑和外部实体。如下图：
SA - 数据流图DFD
数据流图DFD是用数据流图表示功能模型，DFD说明系统所完成功能，从数据传递和加工的角度，利用图形符号通过逐层细分描述系统的各个部件的功能和数据在他们之间传递的情况，来说明系统所完成的功能。如下图：
如上图，有如下几种“图元”描述：
SA - 状态转换图STD
用状态转换图表示行为模型，STD通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，指出做为特定事件的结果将执行哪些动作。如下图：
SA - E-R图/实体联系图
ER图主要描述实体属性，以及实体之间的关系。另外，ER模型是结构化时代的模型与产物，在面向对象和UML中是没有的。如下图：
SA - 例题
例题5：
例题5解析与答案：
答案：C D
解析：略
例题6：
例题6解析与答案：
答案：A A
解析：略
什么是弱实体？
举例说明：在人事管理系统中，职工子女的信息就是以职工的存在为前提的，子女实体是弱实体，子女与职工的联系是一种依赖联系。所以，职工是实体，也可以成为强实体。
强实体与弱实体的联系只能是1：1或1：N。
面向对象的分析方法 - OOA
| 相关的几个概念 | |
|---|---|
| 对象 | 属性[数据] + 方法[操作] + 对象ID/标识ID |
| 类[详细见下] | 实体类/控制类/边界类 实体类：往往和数据库有对应的关系，是不是数据类型 控制类：衔接实体类和边界类的类 边界类：在一个系统的边界上和外部进行沟通的类 这三个类似于MVC模型之间的关系，它们的思想是一样的 |
| 继承与泛化 | 复用机制，它是一种紧耦合。因为当父类变的时候子类不得不变。继承是对已有实例的特征稍作改变就生成其他的实例。 |
| 封装 | 隐藏对象的属性和实现细节仅对外公开接口 |
| 多态 | 不同对象收到同样的信息产生不同的结果 |
| 接口 | 一种特殊的类，它只有方法定义没有对方法的实现 |
| 重载 | 一个类可以有多个同名的参数类型不同的方法。函数同名但参数不一样是其特点 |
| 消息和消息通信 | 消息是异步通信的 |
| 覆盖与重写 | 子类的同名方法覆盖父类的同名方法 |
| 组合与聚合 | 聚合关系：汽车部件和整车的关系（整体与部分生命周期不同） 组合关系：部门与公司的关系。公司倒闭的话部门也完完（整体与部分生命周期相同） |
类的分类，如下图：
对象问的关系有：组合，聚合，继承等
Use-A依赖关系
IS-A继承关系
IS-PART-OF聚合（组合一种），聚合对应的语义是“is a member of”
OOA - UML
OOA需求分析的UML（统一建模语言，与平台和语言无关）由基本构造块，规则和公共机制构成。
| UML基本构造块之事物【重要组成部分】 | |
|---|---|
| 结构事物 | 最静态的部分，包括类，接口，协作用例，活动类，构件和节点 |
| 行为事物 | 代表时间和空间上的动作，包括消息，动作次序，连接 |
| 分组事物 | 看成是个盒子，如包和构件 |
| 注释事物 | UML模型的解释部分。描述，说明，和标注模型的元素 |
| UML基本构造块之关系【把事物紧密联系在一起】 | |
|---|---|
| 依赖关系 | 一个事物发生变化影响另一个事物，包含关系和扩展关系都属于依赖 |
| 泛化关系 | 特殊一般关系，特殊元素的对象可替换一般元素的对象 |
| 关联关系 | 描述了一个链，链是对象之间的连接 |
| 实现关系 | 接口与类之间的关系，一个类指定了由另一个类保证执行的契约 |
| UML基本构造块之图【多个相互关联的事物的集合】 | |
|---|---|
| 静态图（结构图） | |
| 类图 | 描述一组类，接口协作和它们之间的关系。 |
| 对象图 | 描述一组对象以及它们之间的关系。对象图往往只在需要描述复杂算法时才会使用，画出来的对象图往往不会只有一个对象。 |
| 构件图 | 也叫组件图，是描述软件内部物理组成的一种图。系统里有哪些构件 构件之间有啥联系。描述一个封装的类和它的接口，端口，以及由内嵌的构件和连接件构成的内部结构。强调由小的部件构件大的系统。 |
| 部署图 | 表示为软件和硬件之间的映射。为了完成系统需要什么样配置的操作系统，内存，CPU等不在它范畴内，它只解决开发的系统如何去部署的问题。 |
| 制品图 | 描述计算机中一个系统的物理结构。制品包括文件，数据库，和类似的物理比特集合。 |
| 包图 | 将某些类放入“包”中，通过包图来组织业务概念图。 |
| 组合结构图 | 展示该部分内容“内部”参与者的配置情况。这个图不常用。 |
| 动态图（行为图） | |
| 用例图 | 系统与外部参与者的交互。描述一组用例，参与者及他们之间的关系的图。 |
| 顺序图 | 强调按时间顺序。顺序图和通信图我们又称其为交互图。顺序图能够表达用户与系统的复杂交互过程。 |
| 通信图 | 也叫协作图，它强调的是相互之间关系，是顺序图的另外一种表达。 |
| 定时图 | 消息跨越不同对象或角色的实际时间。交互图的一种。 |
| 交互概览图 | 活动图与顺序图的结合。这个图不常用。 |
| 活动图 | 类似程序流程图，表示流程性的东西和并行的行为。它将进程或其他计算结构展示为计算内部一步步的控制流和数据流，它专注于系统的动态视图，它对系统功能建模和业务流程建模特别重要；并强调对象间的控制流程。 |
| 状态图 | 从某个物品的状态是如何变化的角度来展示流程。 |
| UML规则 |
|---|
| 是构造块如何放在一起的规定，包括为构造块命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行。 |
| UML公共机制 |
|---|
| 是指达到特定H标的公共UML方法，主要包括规格说明（详细说明）、修饰、公共分类（通用划分）和扩展机制4种。规格说明是事物语义的细节描述，它是模型真正的核心：UML为每个事物设置了一个简单的记号，还可以通过修饰来表达更多的信息；UML包括两组公共分类：类与对象（类表示概念，而对象表示具体的实体)、接门与实现（接口用来定义契约，而实现就是具体的内容)；扩展机制包括约束（扩展了UML构造块的语义，允许增加新的规则或修改现有的规则）、构造型（扩展UML的词汇，用于定义新的构造块）和标记值（扩展了UML构造块的特性，允许创建新的特殊信息来扩展事物的规格说明）。 |
UML中的概念
- 类是描述具有相同属性、方法、关系和语义的对象的集合，一个类实现一个或多个接口。
- 接口是指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外的可见的动作。
- 构件是物理上或可替换的系统部分，它实现了一个接口集合。提供一组接口的实现，是组成事物的元素。
- 包是用于把元素组织成组的通用机制，它一个构件的抽象化的概念，是把类元按照一定的规则分成组（或称为模块）。
- 用例是描述一系列的动作，产生有价值的结果。
- 协作定义了交互的操作，是一些角色和其它事物一起工作，提供一些合作的动作，这些动作比事物的总和要大。
- 节点是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。
OOA - UML 4+1视图
现有的UML，再有的UML视图
UML采用4+1视图来描述软件和软件的开发过程，其中进程视图绘制了所设计的并发与同步结构；部署视图表示软件到硬件的映射和分布结构；UML中的类图可以用来表示4+1视图中逻辑视图；最终形成用例视图，用来得到需求分析模型。
“4+1”视图模型是从不同的视角、使用多个并发的视图来组织软件架构的描述。
“4+1”视图模型具有普遍适用性，实践证明能在许多大型项目中成功运用。
OOA - 用例模型与分析模型
在OOA的需求分析中，图的应用是经常被用到的。大部分的以用例模型和分析模型的建立为主线，其中用例模型采用用例图来构建，分析模型用类型表示。其它细节情况，也可以建立其它交互图。
案例分析中，用例图和类图，经常考到
需求分析工具
使用用例建模系统需求
用例建模来源于面向对象建模技术，但该技术也在非对象开发环境中比较流行，用例建模技术对传统的系统分析和设计工具进行了补充，例如数据建模和过程建模， 也提供了架构决策和用户界面设计决策的基础。
用例建模促进并鼓励了用户参与，具有如下优点：
- 提供了捕捉功能需求的工具。
- 有助于将系统分解为更易于管理的小块。
- 提供了与用户以及其他关心系统的关联人员进行交流的工具。
- 辅助估计项目范围、投入和进度。
- 提供了需求跟踪的工具。
- 提供了确定数据对象或实体的起点。
- 提供了设计用户和系统接口的功能规格说明。
为了决定用例的重要性，项目经理或者系统分析员将填写用例分级和评估矩阵，并使用来自关联人员和开发团队的输入构造用例依赖关系图。
1、项目经理使用称为用例分级和评估矩阵，决定用例的优先级。该矩阵使用6个标准按1 ~ 5级评估用例。6个标准是：
- 对架构设计的重要影响。
- 容易实现但包含重要功能。
- 包含有风险、时间紧迫或复杂的功能。
- 需要大量的研究或者新的、有风险的技术。
- 包含主要的业务功能。
- 将增加或者减少费用。
2、有些用例依赖于其他用例，其中一个用例使系统处于一种状态，该状态是另一个用例的前置条件。我们使用用例依赖关系图建模这种依赖关系。用例依赖关系图具有以下优点：
- 系统事件及其状态的图形化表述有利于对系统功能的理解。
- 有助于确定遗漏的用例。
- 通过描述哪个用例更关键并需要最高优先权，有助于推动项目管理。
数据建模与分析
数据建模是一种为数据库定义业务需要的技术，因为数据模型最终要实现成数据库，所以数据建模有时称为数据库建模。下图是一个简单的数据模型，称为实体关系图。
数据建模的系统概念：
- 实体
- 属性（数据类型、域、默认值）（键）
- 关系
如何构造数据模型？
- 获取实体。
- 构造上下文数据模型：包含基本业务实体及它们之间的自然关系。
- 基于键的数据模型：确定每个实体的键。
- 泛化层次体系：父实体、子实体。
- 具有完整属性的数据模型。
- 分析数据模型：规范化（第一范式、第二范式、第三范式）。
- 将数据需求映射到地点：数据–地点–CRUD矩阵。
过程建模
过程建模源自传统的软件工程方法，可能的过程模型包括程序结构图、逻辑流程图或决策表。本节重点介绍系统分析的过程模型，即数据流图。 数据流图是一种描述通过系统的数据流以及系统实施的工作或处理过程的工具。同义词包括泡式图、转换图和过程模型。
过程建模的系统概念：
- 外部代理：常见的同义词包括外部实体。
- 数据存储：是一个数据的“仓库”，同义词包括文件和数据库。
- 过程：即处理，是在输入数据流或条件上执行，或者对输入数据流或条件做出响应的工作，同义词是转换。分解图、层次图。注意避免过程中三种常见的错误：1）有输入没有输出，黑洞；2)有输出但没有输入，奇迹；3)输入不足以产生输出，灰洞（如输入一个雇员地址，输出一张财务报表）。
- 数据流：所有的过程至少都有一个输入流和一个输出流。数据流是过程与系统环境之间的通信。在数据流图中，有时需要描述分支的数据流或合并的数据流。分支的数据流是一个分成多个数据流的数据流，表示一个数据流的所有或者部分路由到不同目的地。合并的数据流是多个数据流合并成一个数据流后的数据流。合并的数据流指示了不同来源的数据流可以合并成一个报文供后续处理。
如何构造过程模型：
- 构造上下文数据流图：0号数据流图。
- 构造系统功能分解图。
- 事件响应或用例清单：构建分解图后，下一步是确定系统必须响应什么业务事件，（外部事件、时序事件、状态事件）。发现并确定事件和响应的更成功的方法之一是用例的技术。用例分析是确定并建模业务事件、谁触发事件以及系统如何响应事件的过程。
- 事件分解图：把事件处理过程增加到分解图中。
- 事件图：以分解图为提纲，可以为每个事件过程绘制一个事件图。
- 构造系统图：从原始的上下文图中的单个过程“爆炸”出来，在单张图中显示了系统的所有事件，显示了子系统的所有事件。 构造基本图：具有较复杂的事件图的事件过程应该扩展成一个更详细的基本数据流图，每个基本过程都是内聚的，也就是说仅完成一件事。
- 完成规格说明：对以上完成的数据流图中的每个数据流、数据存储和基本过程进行描述，并写进资料库中。对于过程内部的逻辑描述，我们可以使用结构化英语（自然英语+编程逻辑），用于说明过程模型中的基本过程的内部逻辑。但许多过程是由复杂的条件组合的（即业务策略），使用结构化英语不容易表达，此时可以使用决策表。
面向对象分析与建模
面向对象分析涉及到定义信息系统的静态和动态行为模型，而非定义数据和过程模型（这是传统开发方法的特点）。对象的标识，对象的数据部分（属性），对象的行为。
OOA - 例题
例题7：
例题7解析与答案：
答案：A
解析：略
例题8：
例题8解析与答案：
答案：C
解析：继承是父类和子类之间共享数据和方法的机制。在定义和实现一个类(子类)的时候
可以在一个已经存在的类（父类）的基础上进行，把这个已经存在的类所定义的内容作为自己的内容
并加入若干新的内容
例题9：
例题9解析与答案：
答案：A B
解析：略
例题10：
例题10解析与答案：
答案：A D
解析：略
例题11：
例题11解析与答案：
答案：D
解析：用例图表现在交互，系统与外部参与者的交互
例题12：
例题12解析与答案：
答案：A C
解析：略
例题13：
例题13解析与答案：
答案：C D A
解析：略
例题14：
例题14解析与答案：
答案：C
解析：面向对象的分析，建立面向分析的宏观概念
面向对象分析基于用例模型，通过对象建模记录确定的对象、对象封装的数据和行为以及对象之间的关系
面向对象分析包括3个活动：建模系统功能，发现并且确定业务对象，组织对象并确定其关系
对象的状态应该是在设计阶段实现
面向对象分析和设计，两个阶段并不是很明显
例题15：
例题15解析与答案：
答案：B
解析：在OOA中，并不是所有的名词都表示了问题域内有用的业务对象
通过删除对象的同义词、系统范围之外的名词、不具有独特行为的名词
不清楚的名词、另一个对象的行动或属性的名词，做到最终清理候选对象列表
事件会触发某些动作，通过事件可以设计下一步系统的操作
例题16：
例题16解析与答案：
答案：A D
解析：课本上纯概念题
另外，需求分析可被划分成：①问题分析；②问题评估和方案综合；③建模；④规约；⑤复审等工作阶段
例题17：
例题17解析与答案：
答案：D
解析：复用的概念，面向对象中，经常性的会使用构件化开发，也就是构件复用的过程
类库，典型C++中的MFC类库，类库是可以被调用的类的组装，概念衍生出构件库的概念
框架，开发过程中，框架的应用是非常广泛，比如mybatis免除了我们对数据库的连接
框架是在类库的基础上，衍生出来的
需求定义
需求定义的过程也就是形成需求规格说明书SRS的过程，通常有两种需求定义的方法，分别是严格定义方法和原型方法。
严格定义法的特点：所有需求都能够被严格定义；开发人员和用户之间能够准确而清晰的交流；采用图形文字能够充分体现最终系统。
原型法：并非所有的需求都能在开发前被准确的说明；项目参加者之间通常存在交流上的困难；需要实际的可供用户参与的系统模型；有合适的系统开发环境；反复是完全需要和值得提倡的，需求一旦确定就应该遵从严格的方法。
例题18：
例题18解析与答案：
答案：C
解析：略
需求验证/需求确认
需求规格说明书SRS的需求验证也称为需求确认，其活动是为了确定以下几个方面的内容：
- SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。
- SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
- 需求是完整的和高质量的。
- 需求的表示在所有地方都是一致的。
- 需求为继续进行系统设计、实现和测试提供了足够的基础。
需求验证包括了需求评审和需求测试。
需求评审包括了：正式评审和非正式评审。需求验证是需要做用户签字确认，但往往实施起来比较困难，因为需求验证时签字就要负责任，它是验收的标准之一。需求的评审需要用户的参与。
需求测试，不是运行类的测试而是设计测试用例进行测试，比如告诉你输入是什么输出是什么，所以更加接近于想像性测试，它是验证方向对不对该不该做的过程。需求测试仅仅是基于文本需求进行“概念”上的测试。然而，以功能需求为基础（SA方法）或者从用例派生出来（OO方法）的测试用例，可以使项目干系人更清楚地了解系统的行为。虽然没有在系统上执行测试用例，但是涉及测试用例的简单动作可以解释需求的许多问题。这种测试用例通常称为概念测试用例，即不是真正执行的测试用例，它们可以发现SRS中的错误、二义性和遗漏，还可以进行模型分析，以及作为用户验收测试的基础。在正式的系统测试中，还可以将它们细化成测试用例。
需求管理（支持，保障）
在软件需求工程中，需求管理贯穿于整个过程中，它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。另外，还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。
需求管理是可重复级的一个关键过程域，其目标是为软件需求建立一个基线，供软件开发及其管理使用，使软件计划、产品和活动与软件需求保持一致。从软件需求工程的角度来看，需求管理包括在软件开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。
定义需求基线
需求开发的结果应该有项目视图和范围文档、用例文档和SRS，以及相关的分析模型。经评审批准，这些文档就定义了开发工作的需求基线。这个基线在用户和开发人员之间就构成了软件需求的一个约定，它是需求开发和需求管理之间的桥梁。
基线是一个软件配置管理的概念，它帮助开发人员在不严重阻碍合理变化的情况下来控制变化。根据IEEE的定义，基线是指已经通过正式评审和批准的规约或产品，它可以作为进一步开发的基础，并且只能通过正式的变更控制系统进行变化。在软件工程范围内，基线是软件开发中的里程碑，其标志是有一个或多个软件配置项的交付，且已经经过正式技术评审而获得认可。例如，SRS文档通过评审，其中的错误已经被发现并纠正，则就变成了一个基线。根据国家标准《计算机软件配置管理计划规范》（GB/T 12505-1990）的规定，基线可以分为功能基线、指派基线和产品基线三种，通过评审后的SRS（软件需求规格说明书）属于指派基线。
需求的状态
在需求状态的变化中，项目管理人员首先需要关注的是那些被拒绝和被丢弃的需求。因为这些需求有可能是应该被接受和并被实现的需求，如果不是通过有管理的处理过程，就有可能因为疏忽而被遗漏。同时，也应关注被交付的需求，因为可交付物是项目的成果体现，而可交付物的主要内容就是对需求的实现。
需求变更管理
CCB，变更控制委员会
要让变更有序进行，首先需要有一个统一的单位来负责，这个单位一般叫变更控制委员会（Change
Control Board），也叫配置控制委员会（Configuration Control
Board）。CCB由项目干系人中有代表性的人员组成，人数没有限制，一个人也可以。CCB有能力在管理上做出承诺，对建议的配置项变更做出评价、审批及监督已批准变更的实施。CCB是决策机构，一般不参与具体的变更执行工作。
执行项目变更时，一般流程如下：
-
变更申请
记录变更的提出人、日期、申请变更的内容等信息。
-
变更评估
对变更的影响范围、严重程度、经济和技术可行性进行系统分析。
-
变更决策
由具有相应权限的人员或机构决定是否实施变更。
-
变更实施
由管理者指定的工作人员在受控状态下实施变更。 -
变更验证
由配置管理人员或受到变更影响的人对变更结果进行评价，确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。
需求变更可能来自解决方案提供商、用户或产品供应商等外部因素，也可能来源于项目团队内部。对于项目团队而言，无法阻止需求发生变更，他们只能正确地对待变更，按照既定流程管理变更，尽量降低变更对项目成本、进度和质量的负面影响。
需求变更通常意味着新需求的增加和对已有需求的修改，一般不会减少需求，而且减少需求的问题也比较容易处理。需求变更是需要代价的，包括时间、人力、资源等方面。既然需求变更是不可避免的，那么，项目管理人员就应该采取规范的流程去管理变更，而不是一味地避免变更和拒绝变更。
有了控制负责单位和控制流程，要做好项目变更控制，还需要注意如下几点。
-
做好事前预测
在项目评估阶段，就应当对项目中可能出现的变更进行预测，以便及时应对。变更可能来自如下几个方面，一、客户需求的变更，二、服务商可能出现的变更，三、第三方缺货或者产品升级导致的变更。
-
遵守变更流程
有了流程，还需要严格遵守。项目成员必须注意涉及变更不能随便答应，一定要上报项目经理。项目经理要时刻关注变更问题，每次会议与交流时，都要特别讨论变更问题。及时发现，防范于未然。
-
以客户为中心
与客户良好的沟通、融洽的关系往往是项目变更出现时的润滑剂。客户总是希望少花钱多办事，这就需要项目经理具备良好的客户关系管理能力，学会从专业角度给客户信服的意见，让客户看到你的优势，给客户以信心。
例题19：
例题19解析与答案：
答案：C
解析：略
例题20：
例题20解析与答案：
答案：D B
解析：略
需求风险
带有风险的做法有：①无足够用户参与。②忽略了用户分类。③用户需求的不断增加。④模凌两可的需求。⑤不必要的特征。⑥过于精简的SRS。⑦不准确的估算。
需求跟踪
SRS中的每个软件配置项的需求到其涉及的系统（或子系统）需求都要具有双向可追踪性。所谓双向跟踪，包括正向跟踪和反向跟踪，正向跟踪是指检查SRS中的每个需求是否都能在后继工作成果中找到对应点；反向跟踪也称为逆向跟踪，是指检查设计文档、代码、测试用例等工作成果是否都能在SRS中找到出处。