文章目录
软件需求工程是包括 创建和维护软件需求文档 所必须的一切活动的过程，可分为 需求开发和需求管理 两大工作。
什么是需求工程？
所有与需求直接相关的活动称为需求工程。
需求工程的活动可以分为两大类：
- 需求开发：通过调查与分析，获取用户需求并定义产品需求
- 需求管理：确保各方对需求的理解一致，管理和控制需求的变更，从需求到最终产品的双向跟踪
# 需求工程的工作大概可以细分为：
1、需求获取
2、需求分析与协商
3、系统建模
4、需求规约
5、需求验证
6、需求管理
# 需求和软件需求，不一样
软件需求和业务需求也是有区别的
1、软件需求
2、硬件需求
3、网络需求
1、软件需求概述
软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。
1.1 需求的层次
简单的讲，软件需求就是系统必须完成的事以及必须具备的品质。
需求是多层次的，包括：业务需求、用户需求和系统需求，这三个不同层次从目标到具体，从整体到局部，从概念到细节。
# 比较喜欢考选择
业务需求：比较笼统，比较概述，没有大概的细节，比如：我就想要一个***功能
用户需求：偏操作
系统需求：比较细节，
（1）功能
（2）非功能：比如像性能、安全、可靠性等
（3）设计约束：比如：限制开发人的学历、限制开发语言等
PIECES框架—描述 非功能需求
- 性能：Performance - 描述企业当前的运行效率，可以分析当前业务的处理速度
- 信息：Information
- 经济：Economics
- 控制：Control - 提高信息系统的安全和控制水平
- 效率：Efficiency - 人、财、物的使用效率
- 服务：Service - 提高对客户、供应商、合作伙伴、顾客等的服务质量
1.2 质量功能部署-QFD
- QFD-Quality Function Deployment
- 是一种将 用户要求 转化为 软件需求 的技术，其目的是最大限度地提升软件工程中用户的满意度。
为了达到这个目标，QFD将软件需求分为三类
- 常规需求：也称基本需求
- 期望需求
- 意外需求：也称兴奋需求
2、需求获取
# 补充说明
1、联合需求计划：很有用，很及时，但是成本高
2、看到 降低成本 ，选择抽样调查
3、对数据性的信息，选择阅读历史文档
4、流程复杂，选择现场观摩
5、发现问题的本质找到解决问题的办法，选择参加业务实践
2.1 用户访谈
2.2 问卷调查
提高问卷返还率的方法
2.3 采样
样本大小计算
2.4 情节串联板
情节串联板分类
情节串联板制作
最大的缺点！费时间！！！
2.5 联合需求计划-JRP
2.5.1 联合应用开发-JAD
2.5.2 JRP会议
2.5.3 JRP主要原则
2.6 需求记录技术
# 常用的需求记录工具具有
1、任务卡片
2、场景说明
3、用户故事
4、Volere白卡
1、任务卡片：适用业务活动级的信息收集与整理
2、场景说明
3、用户故事
4、Volere白卡：一般敏捷方法中用！！！
3、需求分析
在需求获取阶段，获得的需求是杂乱的，是用户对新系统的期望和要求.
这些需求有重复的地方，也有矛盾的地方，这样的要求不能作为软件设计的基础。
系统分析师需要把杂乱的用户要求转化为产品需求，这就是需求分析的工作。
# 下述是原题解析，此处做摘录
需求分析是一种软件工程活动，它在系统级软件分配和软件设计间起到桥梁的作用
需求分析使得系统工程师能1）刻画出软件的功能和性能；2）建立软件必须满足的约束；
需求分析允许系统分析师细化软件的分解，并建立将被软件处理的数据、功能和行为模型。
需求分析为软件设计师提供了被翻译成数据、架构、界面和过程设计的模型
最后，需求规约为开发者和客户提供了软件开发完成后质量评估的依据
需求分析是 发现、求精、建模和规约 的过程
包括
1）详细的细化由系统工程师建立并在软件项目计划中明确的项目范围
2）创建所需数据、信息和控制流及操作行为的模型
3）还要分析可选择的解决方案，并将它们分配到各软件元素中去
需要注意：在需求分析阶段，得到详细的规约是不可能的。客户可能并不能明确滴肯定需要什么
开发者可能不能肯定可用什么特定的方法来适当的完成功能和性能
主要有两种分析方法
1、结构化需求分析
2、面向对象需求分析
3.1 需求分析的任务
# Karl E.Wiegers 在《软件需求》一书中指出，需求分析的工作通常包括以下 7个方面：
1、绘制系统上下文 范围关系图
2、创建用户界面原型
3、分析需求的可行性
4、确定需求的优先级
5、为需求建立模型
6、创建数据字典
7、使用QFD
3.2 需求分析的方法
- SA方法
- OOA方法
- 面向问题域的分析方法 - PDOA
- 一些形式化的方法 - VDM 、 Z
之后的章节会详细介绍SA 和 OOA ，此处只介绍 PDOA
3.2.1 面向问题域的分析方法 - PDOA
非重点
- 与SA和OOA相比，PDOA更多的强调描述，更少的强调建模。
它的描述大致分为以下两个部分：
- 关注问题域。用一个文档对含有的问题域进行相关的描述，并列出需要在该域中求解的问题列表，也就是需求列表。只有这个文档是在分析时产生的。
- 关注解系统（即系统实现）的待求行为。用一个文档对解系统的待求行为进行描述。此文档在需求定义阶段完成。
在PDOA方法中，对整个过程有一个清晰的定义：
- 收集基本的信息并开发问题框架，以建立问题域的类型。
- 在问题框架类型的指导下，进一步收集详细信息，并给出一个问题域相关特性的描述。
- 基于以上两点，收集 并 用文档说明新系统的需求。
可以看出，问题框架是PDOA的核心元素。
3.2.2 SA、OOA、PDOA 方法对比
SA
- 关注于功能的分层和分解，非常符合人们自上而下、逐步分解问题直到可解决的自然思考。
- SA方法本身隐含几个基本假设：1.问题域是可以定义的；2.问题域是有限的；3.通过有限的步骤总可以将复杂问题分解到可解决的程度。
- SA方法应用的是科学方法中的 因果律、归纳法 和 逻辑法。
- 通过对现实世界中的问题域进行不断的"测量"和“分解”，直到得到问题域的逻辑模型。
OOA
- 基于抽象、信息隐藏、功能独立和模块化 这些基本理念对系统进行分析。
- OOA方法首先对问题域的事物的“外在表象”进行观测，然后再逻辑世界中模拟出一个对象的逻辑对象，“断定”该对象与现实事物是一直的。随后，观测到的对象被计入对象集合，观测到的行为和表象被记录入对象关系模型和对象行为模型。
- OOA方法建立的对象彼此之间通过接口来相互沟通，每传递一个消息即触发一个事件，并引起内部方法的执行。
- 只有观测 对象内部的时候，才能看到具体的属性和方法。否则，只能看到对象对外部开放的接口。
- 只承诺一种可以持续“观测并理解”的方法，以及 “观测后建立”的对象和现实世界的外在表象是一致的。
PDOA
- 将重点定位在问题域和需求上，通过对问题域的分类，向系统分析师提供具体问题的相关指南。
- 将规格说明作为另外的任务处理，它的成果只是一份问题域的全面描述和一份需求列表而已。
4、结构化分析方法-SA
Structured Analysis - SA
-
是一种面向数据流的需求分析方法
-
主要用于分析大型的数据处理系统，特别是企事业管理系统
-
其基本思想可以概括为“分解”和“抽象”
-
一般遵循“先全局后局部，先整体后细节，先抽象后具体”的原则。
-
通过逐层分解数据流图，可以获得系统的顶层、中间层和底层DFD图，从而更深入地了解系统的功能和数据流程
# 图片解释
在结构化需求分析中，主要完成功能模型、数据模型和行为模型的构建。
1、【核心】功能模型：通常用数据流图（DFD）进行建模，以展示系统内部的数据传递和变换关系，从而描绘出满足功能要求的软件模型。
2、数据模型：则关注数据的结构、属性和关系，确保数据的准确性和完整性。
3、行为模型：则描述系统的行为特征，包括系统的状态变化、事件响应等。
4、数据字典：是重要的文档，对加工的描述是数据字典的组成内容之一，常见的加工描述方法有：结构化语言、判定树、判定表！！！【区分：系统设计-业务流程表示工具】
4.1 SA-DFD- 数据流图（功能模型）
- DFD是SA方法中的重要工具，是表达系统内数据的流动并通过数据流描述系统功能的一种方法。 （即功能需求，而不是用户需求，也不是业务需求）
- DFD还可被认为是一个系统模型，在信息系统开发中，如果采用结构化方法，则一般将DFD作为需求规格说明书的一个组成部分。
4.1.1 DFD 基本组成
概念补充说明
- 数据项：DFD描述了系统的分解，但是它并没有给出图中各成分的说明，数据项就是数据流图的组成部分，不在数据流图中显示，但是在题目中会描述某条数据流的组成元素。
- 加工特点：对于每一个基本加工，必须有一个加工规格说明，加工规格说明必须描述 把输入数据流变换为输出数据流的加工规则；决策表可以用来表示加工规格说明。
- 四大模块
传入模块
传出模块
变换模块
协调模块
DFD 示例
4.1.2 数据流图设计原则
可能会考
- 数据守恒原则：对任何一个加工来说，其所有输出数据流中的数据必须能从该加工的输入数据流中直接获得，或者说是通过该加工能产生的数据。
- 守恒加工原则：对同一个加工来说，输入与输出的名字必须不相同，及时它们的组成成分相同。
- 对于每一个加工，必须既有输入数据流，又有输出数据流。
- 外部实体和外部实体之间不存在数据流。
- 外部实体与数据存储之间不存在数据流。
- 数据存储和数据存储之间不存在数据流。
- 父图与子图的平衡原则。
- 数据流与加工有关，且必须经过加工。
异常情况
- 黑洞：一个加工只有输入没有输出
- 奇迹：一个加工只有输出没有输入
- 灰洞：“输入皮鞋，产出酸奶”
补充真题：数据流图和流程图的区别？
4.2 SA-STD-状态转换图（行为模型）
- 大部分业务系统是数据驱动的，所以适合用DFD。
- 但是实时控制系统却主要是事件驱动的，因此行为模型是最有效的描述方式。
# State Transform Diagram - STD
它通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为，
并指明作为特定事件的结果系统将执行哪些动作。
实心圆：初态
同心圆（内圆为实心圆）：终态
中间状态用圆角矩形表示
4.3 SA-ER图-实体联系图（数据模型）
ER - entity relationship diagram
- 是一种用于描述现实世界概念模型的图形化表示方法。
4.3.1 ER 三要素
- 实体：用矩形表示，框内标注实体名称
- 属性：
（1）单值属性：用椭圆表示，用连线与实体连接起来
（2）多值属性: 双层椭圆，里面虚线，外面实线。如：学生的兴趣，可以有电影、音乐、烹饪等
（3）派生属性：用虚线椭圆表示。是从基本属性计算出来的属性。如：学生的总成绩和平均成绩等。 - 实体之间的联系：用菱形框表示，框内标注联系名称。
并用连线将菱形框分别与有关实体相连，并在连线上注明联系的类型。
4.4 数据字典-DD
- DFD描述了系统分解，但是对于数据的详细内容却无法在DFD中得到反馈。
- 数据字典是在DFD的基础上，对DFD中出现的所有命名元素都加以定义，使得每个图形元素的名字都有一个确切的解释。
- DFD和数据字典等工具相配合，就可以从图形和文字两个方面对系统的逻辑模型进行完整的描述。
4.4.1 数据字典的条目
数据字典中一般有6类条目
- 数据元素
- 数据结构
- 数据流
- 数据存储
- 加工逻辑
- 外部实体
1、数据元素
- 数据元素也称为数据项，是数据的最小组成单位。例如：例如，课程号、课程名等。
- 对数据元素的描述，应该包括数据元素的名称、编号、别名、类型、长度、取值范围和取值的含义等
2、数据结构
- 数据结构用于描述某些数据元素之间的关系，它是一个递归的概念
- 数据结构的描述重点是数据元素之间的组合关系，即说明数据结构包括哪些成分。
这些成分中有三种特殊情况，分别是任选项、必选项和重复项。
（1）任选项是可以出现也可以省略的项，用 “[]”表示；
（2）必选项是在两个或多个数据元素中，必须出现其中的一个。例如，任何一门课程是必修课或选修课，二者必居其一。必选项的表示是将候选的多个数据项用“（}”括起来；
（3）重复项是可以多次出现的数据项。例如，一张学员注册表可选择多门课程，“课程细节”可重复多次，表示成“课程细节*”。
3、数据流
- 数据流由一个或一组数据元素组成
- 对数据流的描述应包括数据流的名称、编号、简要说明、来源、去处、组成和流通量(含高峰时期的流通量）。
4、数据存储
-
数据存储的条目主要描写该数据存储的结构，以及有关的数据流和査询要求。
-
有些数据存储的结构吋能很复杂.
“学员”包括学员的基本情况、学员动态、在线模拟测试记录、论文成绩等，其中每一项又是一个数据结构，这些数据结构有各自的条目分别加以说明。因此，在 “学员”的条目中只需列出这些数据结构，而不要列出数据结构的内部构成。 -
DFD是分层的，下层图是上层图的具体化。同一个数据存储可能在不同层次的图中出现。描述这样的数据存储，应列出最底层图中的数据流。
5、加工逻辑
- 需要描述加工的编号、名称、功能的简要说明、有关的输入数据流和输出数据流。
- 对加工进行描述，目的在于使相关人员能有一个较明确的概念，了解加工的主要功能。
- 详细的加工逻辑则需要借助一些工具来描述，包括判定树、判定表和结构化语言等
6、外部实体
- 外部实体是数据的来源和去向.
- 对外部实体的描述应包括外部实体的名称、编号、简要说明、外部实体产生的数据流和系统传给该外部实体的数据流，以及该外部实体的数量。
- 外部实体的数量对于估计系统的业务量有参考作用，尤其是关系密切的主要外部实体。
4.4.2 数据字典的作用
- 数据字典实际上是 ”关于系统数据的数据库“。
- 在整个系统开发过程和系统运行与维护阶段，数据字典是必不可少的工具。
- 数据字典是所有人员 工作的依据，统一的标准，它可以确保数据在系统中的完整性和一致性。
具体来讲，数据字典具有以下作用：
- 按各种要求 列表。可以根据数据字典，把所有数据条目按一定顺序全部列出，保证系统设计时不会遗漏。
- 相互参照，便于系统修改。根据初步的DFD，建立相应的数据字典。在需求分析过程中，系统分析师会发现原来的DFD以及各种数据定义中有错误或遗漏，需要修改或补充。有了数据字典，这种修改就变得容易多了。
- 由描述内容检索名称。在一个稍微复杂的系统中，系统分析师可能没有把我断定某个数据元素在数据字典中是否已经定义，或者记不清其确切的名字，可以由内容查找其名称。
- 一致性检验和完整性检验。根据各类条目的规定格式，可以发现一些问题，例如：是否存在没有知名来源或去向的数据流，是否存在没有指明数据存储或所属数据流的数据元素，加工逻辑与输入的数据元素是否匹配，是否存在没有输入或输出的数据存储等。
4.4.3 数据字典的管理
- 为了保证数据的一致性，数据字典必须由专人管理，如：数据管理员。
- 任何人，如果要修改数据字典的内容，都必须通过数据管理员。
5、面向对象分析方法-OOA
- OOA 的基本任务是：运用OO方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反应问题域和系统功能的OOA模型及其详细说明。
- OOA模型独立于具体实现
- OOA的任务是 “做什么”
- OOD的任务是 “怎么做”
5.1 面向对象基本概念
# OOA
OOA基于用例模型，通过对象建模 记录
1）确定的对象、
2）对象封装的数据和行为、
3）以及对象之间的关系。
OOA包括三个活动
1、建模系统功能
2、发现并确定业务对象
3、组织对象 并 确定对象间的关系
一些个 面向对象 常见的概念！
1、对象：属性+方法+对象ID
2、类：是对象的抽象，定义了一组相似的对象结构，定义了 数据和行为。
（1）实体类：实体类映射需求中的每个实体，保存需要存储在永久存储体中的数据。
（2）边界类：边界类用于封装在用例内、外流动的信息或数据流。边界类位于系统与外界的交接处。
（3）控制类：控制类是用于控制用例工作的类，用于对一个或多个用例所特定的控制行为进行建模，控制对象通常控制其他对象，因此，它们的行为具有协调性。
【领域类模型】：会涉及描述类自身情况的属性与操作，还会有描述类与类之间的关联，但不会有对象层次的内容
3、消息：对象之间进行通信的一种构造
4、继承：父类和子类。共性的抽取，代码的复用。鲸鱼 is a 哺乳动物。
5、覆盖：方法名称和属性参数，需要一致，只是实现步骤不一样，如鸟和鱼的run()
6、重载：同一个类中，有多个重名的方法，每个方法可以有不同的参数和返回值
7、多态：子类必须要对父类中方法进行【重写】
8、封装
9、静态成员
10、静态类型
11、静态绑定
12、动态绑定
13、组合：如：汽车 has a 轮胎
参考文章
继承和多态 （详解）
5.2 统一建模语言
UML(Unified Modeling Language)的作用域不限于支持OOA和OOD，还支持从需求分析开始的软件开发全过程
UML不仅仅用于需求分析！！！本系列只在此处做介绍~
总体上看，UML包括：构造块、公共机制、规则
- 构造块：事物、关系和图。事物是UML的重要组成部分。关系把事物紧密的联系在一起。图是多个相互关联的事物的集合。
- 规则：定义了UML图中的元素如何组合、命名、关联以及它们之间如何相互作用的准则。这些规则确保了UML图的一致性和准确性。
- 公共机制：是一组共享的概念和语义，用于支持不同模型元素之间的交互和通信。这些公共机制使得UML图能够更简洁、协调和一致的表达系统的结构和行为。
UML对系统架构的定义是：系统的组织结构，包括 系统分解的组成部分，以及它们的关联性、交互机制和指导原则等 提供系统设计的信息。
具体来讲，就是指一下五个系统视图：
- 逻辑视图：也称设计视图。它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。
- 进程视图：是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。
- 实现视图：对组成系统物理代码的文件和构件进行建模
- 部署视图：把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构
- 用例视图：是最基本的需求分析模型。
5.2.1 OOA-UML-构造块-事物
事物主要是考选择
1. 结构事物
2. 行为事物
3. 分组事物：包、构件
包大于构件
包没有那么多限制
构件：限制比较多，限制组成部分之类
4. 注释事物
1、结构事物
- 结构事物 是模型中 最静态的部分，代表概念上或物理上的元素。
- UML有七种结构事物 Structural Things
- 类：类是描述具有相同属性、方法、关系和语义的对象的集合。
- 接口：是指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外的可见的动作。
- 协作：定义了交互的操作，是一些角色和其他事物一起工作，提供一些合作的动作，这些动作比事物的总和要大
- 用例：用例是描述一系列的动作，产生有价值的结果。在模型中用例通常用来组织行为事物。用例是通过协作来实现的。
- 活动类：活动类的对象有一个或多个进程或线程。活动类和类很相似，只是它的对象代表的事物的行为和其他事物是同时存在的。
- 构件：是物理上或可替换的系统部分，它实现了一个接口集合。一个构件集合一般来说位于一个节点，但有可能从一个节点转到另一个节点。
- 节点：节点是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。
2、行为事物
- 行为事物是UML模型中的动态部分，代表时间和空间的动作。
- UML有两种主要的行为事物
- 交互（内部活动）
交互是由一组对象之间在特定上下文中，为达到特定目的而进行的一系列消息交换而组成的动作。
交互中组成动作的对象的每个操作都要详细列出，包括消息、动作次序（消息产生的动作）、连接（对象之间的连接） - 状态机
状态机由一系列对象的状态组成
3、分组事物
- 分组事物是UML模型中组织的部分，可以把它们看成是个盒子，模型可以在其中进行分解。
- UML 中只有一种分组事物
- 包：包是一种将有组织的元素分组的机制。与构件不同的是，包纯粹是一种概念上的事物，只存在于幵发阶段，而构件可以存在于系统运行阶段。
4、注释事物
注释事物是 U M L 模型的解释部分。
5.2.2 OOA-UML-构造块-关系
UML用关系把事物结合在一起
主要有下列4 种关系
- 依赖-dependency：依赖是两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。
- 关联-association：关联描述一组对象之间连接的结构关系。一个事物的变化并不影响另一个事物。指针关系！
（1）组合：强-公司和部门
（2）聚合：不强 - 汽车和轮胎 - 泛化-generalization：泛化是一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象。子类和父类之间的关系。
- 实现-realization：实现是类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。
5.2.3 OOA-UML-构造块-图
重点！！！考点！！！
1、类图/对象图（Class Diagram / Object Diagram） 2、用例图（Use Case Diagram）
5.2.3.1 UML图-动态图-用例图
# 考点
用例图描述一组
（1）用例：功能模块
（2）参与者：外部触发因素（包括用户、组织、外部系统、时间、湿度等）
（3）和它们之间的关系
包含、扩展、泛化
1、包含关系：提取出来的公共部分
2、扩展关系：可发生、可不发生
3、泛化关系：衍生，理解为父子关系即可
举例
5.2.3.2 UML图-静态图-类图 / 对象图
类图/对象图 定义
# 类图：Class Diagram
描述一组 类、接口、协作和它们之间的关系
# 对象图：Object Diagram
描述一组对象和它们之间的关系
描述在类图中所建立的 事物实例 的静态快照
描述的是参与交互的各个对象在交互过程中某一时刻的状态。
对象图可以被看做是类图在某一时刻的实例。
在UML中，对象图使用的是与类图相同的符号和关系，因为对象就是类的实例
类图：展示一组类、接口、协作和它们之间的关系
对象图：展示某一时刻一组对象及它们之间的关系，为类图的某一快照。在没有类图的前提下，对象图就是静态设计视图
类与类之间的关系
四种，类属于结构事物的一种，事物的关系有四种：依赖、关联、泛化、实现。
所以类也是四种。
例题
5.2.3.3 UML图-动态图-交互图
1、UML图-动态图-交互图-顺序(时序)图
顺序图，也称序列图
强调消息发送的时间顺序
- 是一种动态图，是场景的图形化表示。
- 描述了 以时间顺序组织的对象之间的 交互活动。
- 强调对象之间 消息发送的顺序，同时显示对象之间的交互。
有三种消息类型：
- 同步消息：进行阻塞调用，调用者终止执行，等待控制权返回，需要等待返回消息，实心三角箭头
- 异步消息：发出消息后继续执行，不引起调用者阻塞，也不等待返回消息，空心箭头
- 返回消息：由从右到左的虚线箭头表示
2、UML图-动态图-交互图-定时(计时)图
强调 特定的时间点
- 用于展示交互过程中的真实时间信息
- 具体描述对象状态变化的时间点以及维持特定状态的时间段
3、UML图-动态图-交互图-通信(协作)图
即：协作图，强调参加交互的对象的组织
- 强调对象之间存在的消息收发关系，而不专门突出这些消息发送的时间顺序。
4、UML图-动态图-交互图-交互概览图
待补充~
5.2.3.4 UML图-动态图-状态图
- 也称 动态图
- 展现了一个状态机，描述单个对象在多个用例中的行为
- 包括：1）简单状态 和 2）组合状态
- 转换可以通过 事件触发器 触发，事件触发后相应的监护条件会进行检查。
- 状态图中的转换和状态是两个独立的概念。
- 核心：状态图是对类描述的补充，用于展现此类对象所具有的可能状态，以及某些事件发生时其状态转移情况。
5.2.3.5 UML图-动态图-活动图(泳道图)
非重点
类似程序流程图，【并发】，出现 并发 ，就选活动图
-
是一种特殊的状态图
-
展示了在系统内从一个活动到另一个活动的流程。
-
名词含义：并发分叉、并发汇合、监护表达式、分支、流 层 等。
-
活动图描述一个操作中 要进行的各项活动的执行流程。同时，也常被用来描述一个用例的处理流程或某种交互流程。
-
活动图将进程或其他计算机构 展示为计算内部一步步的 控制流和数据流，强制对象间的控制流程。
UML动态图-活动图的另一种形式：泳道图
状态图和活动图
5.2.3.6 UML图-静态图-构件图 / 包图
包 > 构件
5.2.3.7 UML图-静态图-部署图
# 部署图
是一种静态图，为系统静态部署视图，部署物理模块的节点分布。
它与构件图相关。
通常一个节点包含一个或多个构件。
其依赖关系类似于包依赖，因此部署组件之间的依赖是单向的类似于包含关系。
真题说明
面向对象分析的目的是为了获得对问题域的理解，以确定系统的功能、性能要求。
逻辑模型，也称概念模型，展示了系统是什么或者系统做什么，他们独立于任何技术实现来描述系统，说明了系统的本质。
1、在UML中，类图显示了一组类、接口、协作及它们之间的关系，类图用于对系统静态设计视图的建模。在面向对象分析过程中，用类模型表示概念模型。
2、用例图描述了一组用例和参与者以及它们之间的关系，它对于系统行为的组织和建模特别重要。
3、序列图和协作图统称为交互图。序列图强调消息时间顺序，协作图强调接收和发送消息的对象的结构组织。交互图主要观察传送消息的对象。
4、构件图显示了一组构件以及它们之间的关系。用构件图来说明系统的静态实现视图。
5、状态图和活动图用来描述对象的行为。活动图观察的是对象之间传送的操作
5.2.4 OOA-UML-规则
主要用于描述和定义一个结构良好的模型应该如何呈现。
5.2.5 OOA-UML-公共机制
- UML图中的公共机制是指一组共享的概念和语义，用于支持不同模型元素之间的交互和通信。这些公共机制使得UML图更为简单、协调和一致。
- 公共机制共同作用，使得UML图能够更清晰地表达系统的结构和行为，支持开发人员、利益相关者和其他相关人员之间的有效沟通。通过遵循这些公共机制，可以确保UML图的一致性和准确性，从而提高软件开发的效率和质量。
5.3 需求建模
- SA方法：系统功能被分解到各个功能模块中，比较容易混淆需求和设计的界限；分割了各项系统功能的应用环境，从各项功能项入手，很难了解到整体。
- 从用户的角度来看，ta们并不想了解系统的内部结构和设计，所关系的就是系统所能提供的服务。这就是用例方法的基本思想。
用例方法是一种需求合成技术，获取需求，记录下来，然后从这些零散的要求和期望中进行整理和提炼，从而建立用例模型。
一些很重要的说明
可能会疑惑：之前不是一直在讲需求分析，现在怎么突然又讲模型？
额，思考一下，需求分析的输出是什么呢？怎么更好的展示需求分析的结果嘞?
所以：需求分析 和 需求建模 ，这两个，基本是分不开的，也没有说哪个步骤一定在前，哪个步骤一定在后。
- 软件需求建模（modeling for software requirement）是在需求调查的基础上，在需求分析过程中采用软件建模工具建立软件需求模型的过程。
需求模型包括：
- 用例模型：也称功能模型。功能模型用来描述 软件的功能 【用例和功能不一定能画等号，往往一个用例需要系统的多个功能来协作完成】
UML通过一组用例图来描述 软件需求； - 非功能性模型：
需求建模不仅是 用例模型！！！！
补充说明：功能、用例、业务流程？
5.4 OOA-需求建模
OAA的建模过程包含两个步骤：建立用例模型、建立分析模型。
总述：用例模型和分析模型~
用例模型和分析模型在软件开发过程中相互关联，共同推动系统的设计和实现。用例模型为开发人员提供了系统的功能需求和行为描述，是分析模型的输入之一。开发人员可以根据用例模型来确定分析模型中的类和接口等元素。同时，分析模型也为用例模型提供了验证和补充，确保系统能够满足用户的需求。在分析模型的设计和实现过程中，开发人员需要不断与用例模型进行交互和迭代，以确保系统的正确性和完整性。
5.4.1 用例模型
在OOA中，构建用例模型，一般需要经历四个阶段
- 识别参与者【必须】
- 合并需求获得用例【必须】
- 细化用例描述【必须】
- 调整用例模型【非必须】
补充说明：Q:什么是用例？
Ans:描述系统需求的方法。可以简单理解为 功能模块。
一些 用例图 的说明~
一个用例图包括：
- 参与者
- 用例
- 通信关联
- 用例图是描述系统需求的方法，所谓系统需求，即站在系统外部，对系统提出的需求。因此，用例图并非是描述系统 内部需求 的方法。
- 如果需要描述系统内部的需求，需要把系统拆分成更小的模块和单元，然后对每个单元进行系统需求分析。
- 使用用例的方法来描述系统需求的过程就是用例建模。
5.4.1.1 识别参与者
参与者识别
参与者是与系统交互的所有事物，该角色不仅可以由人承担，还可以是其他系统和硬件设备，甚至是系统时钟。
- 其他系统：当系统需要与其他系统交互时，其他系统就是一个参与者。如：对某企业的在线教育平台系统而言，该企业的OA系统就是一个参与者；
- 硬件设备：如果系统需要与硬件设备交互，硬件设备就是一个参与者。如：在幵发集成电路IC卡门禁系统时，IC卡读写器就是一个参与者。
- 系统时钟：当系统需要定时触发时，时钟就是一个参与者。如：发在线测试系统中的“定时交卷”功能时，就需要引入时钟作为参与者。
注意：参与者一定在系统之外，不能是系统的一部分。
5.4.1.2 合并需求获得用例
将参与者都找到之后，接下来的工作就是仔细的检查参与者，为每一个参与者确定用例。
- 首先，将获取到的需求 分配 给其相关的参与者，以便可针对每个参与者进行工作，而无遗漏；
- 进行合并操作（合并前，明确为什么要合并）；
- 产生用例；
- 将识别到的参与者和合并生成的用例，通过用例图的形式整理出来，以获得用例模型的框架。
# 在确定用例的过程中，需要注意以下问题
1、用例命名：尽量采用“动词+名词”的形式，如：开通课程等；
而且，最好对用例进行标号，是实现 需求跟踪管理 的重要技巧，通过编号，可以将用户的需求落实到特定的用例中。
2、不能混淆用例和用例所包含的步骤【重点】
例如：“开通课程”功能要经过验证学员信息、检查学员权限、保存开通记录、修改课程选修人数等步骤才能完成，
在系统中这些步骤不能作为单独的功能对外提供，它们只是一个用例所包含的事件流，或是是用例的子功能。
3、注意区分业务用例和目标系统用例
（1）当针对整个业务领域建模时，需要使用业务用例，其中会涉及大景的人工活动，例如，在线教育平台系统中有一项重要工作是“编写教材”，这就是业务用例，是信息系统无法完成的。
（2）信息系统作为整个业务系统的一部分，只负责实现系统的部分功能，因此，只需要识别出系统用例，而不需考虑业务用例。
5.4.1.3 细化用例描述
用例建模的主要工作是书写用例规约 （use case specification )，而不是画图。
用例模板为一个给定项目的所有人员定义了用例规约的结果，其内容至少包括：
1、用例名：应该与用例图相符，并写上其相应的编号。
2、参与者
3、用例目标
4、前置条件：
5、事件流 （基本事件流和扩展事件流）：事件流是指当参与者和系统试图达到一个目标时所发生的一系列活动，也就是用例所完成的工作步骤。
对于一些事件流较为复杂的，可以在用例描述中引用顺序图、状态图和通信图等手段进行描述。
6、后置条件
7、其他的还可以包括非功能需求和用例优先级等。
一个较为复杂的系统会有较多的用例，为便于理解，可以为它们建立多张用例图。
更为复杂的情况将导致所有用例难以维持一种平面结构，这时吋以对用例进行分组。UML使用用例主题划分用例图 ，一组用例放置在以主题命名的方框中（类似于系统边界），每个主题中可以包含多个用例图。
用例的描述可以迭代完成，先对一些重要的用例编制相对细致的用例描述，对于些不重要的用例，可以留待以后再补充完成。
5.4.1.4 调整用例模型
在建立了初步的用例模型后，还可以利用用例之间的关系来调整用例模型。
用例之间的关系：
- 包含
- 扩展
- 泛化
利用这些关系，把一些公共的信息抽取出来，以便于复用，使得用例模型更易于维护。
用例关系—包含
用例关系—扩展
用例关系—泛化
# 用例关系总结
1、从UML事物关系的本质上来看，包含关系和扩展关系都属于依赖关系。
（1）对包含关系而言，抽象用例中的事件流是一定插入到基本用例中去的，并且插入点只有一个。
（2）扩展用例的事件流往往可以抽象为基本用例的备选事件流，在扩展关系中，可以根据一定的条件来决定是否将扩展用例的事件流插入到基本用例的亊件流中，并且插入点可以有多个。
2、在实际应用中，很少使用泛化关系，子用例的特殊行为都可以作为父用例中的备选事件流而存在。
5.4.2 分析模型 / 领域模型
简单来讲：分析模型就是来描述系统内部组成的 （ps：用例模型描述了系统和外部的交互）
- 从用户的观点对系统进行了用例建模，但捕获了用例并不意味着分析的结束，还要对需求进行深入分析，获取关于问题域本质内容的分析模型。
分析模型是做什么?
分析模型描述 系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及它们如何保持通信，实现系统的行为（动态模型）。
建立分析模型，四步：
- 定义概念类
- 确定类之间的关系
- 为类添加职责（即类自身的行为）
- 建立交互图（不同类之间的行为关系）
5.4.2.1 定义概念类==>类图
什么是概念类？概念类的定义？
- 类：是一组具有相同数据结构和相同操作的对象的集合。
- 概念类：是对具有相同属性和行为的一类事物的描述，可以用来抽象和表示现实世界的概念。
概念类和类的对比
5.4.2.2 确定类之间的关系
5.4.2.3 为类添加职责
类的职责包括两方面的内容
- 类所维护的知识：成员变量、属性
- 类能执行的行为：成员方法、责任
5.4.2.4 建立交互图
UML2.0提供四种交互图：
- 顺序图：最常用，几乎可以在任何系统使用
基本元素有：对象、参与者、生命线、激活框、消息、和消息路线等。其中，消息 是顺序图的灵魂 - 交互概览图
- 通信图
- 定时图
5.5 模型分析
在对实际应用问题建立数学模型并求得结果后，还需要根据建模的目的和要求，利用相关知识，结合研究对象的特点，进行模型分析。
模型分析的工作主要包括：
- 模型的合理性分析
- 模型的误差分析
- 参数的灵敏性分析
6、需求定义
在获取了用户需求，并进行了详细的分析后，接下来的工具就需要把这些需求形成文档，作为系统后续开发的基础，这就是需求定义。
6.1 需求定义的方法
6.1.1 严格定义法
- 所有需求都能被预先定义。
- 开发人员和用户之间能够准确而清晰的交流。
- 采用图形（或文字）可以充分体现最终系统。
6.1.2 原型法
原型法的需求定义过程是一个开发人员与用户通力合作的反复过程。
从一个能满足用户基本需求的原型系统开始，允许用户在开发过程中提出更好的要求，根据用户的要求不断对系统进行完善，它实质上是一种迭代的 循环型的开发方式。
- 并非所有的需求都能在系统开发前被准确的说明。
- 项目干系人之间通常都存在一些交流上的困难，原型提供了克服该困难的一个手段。
- 需要实际的、可供用户参与的系统模型。
- 有合适的系统开发环境。
- 反复是完全需要和值得提倡的。
6.2 软件需求规格说明书 - SRS
需求规格说明说！！！ = 需求基线！！！
6.2.1 SRS的编写方法
- 用好的结构化和自然语言编写文本型文档。【为主！】
- 建立图形化模型，这些模型可以描述转换过程、系统的状态及其变化、数据关系、逻辑流、对象类及其关系。【补充！】
- 编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。【基本不用！】
6.2.2 SRS的内容和格式
一般应该包括
- 范围：SRS适用的系统和软件的完整标识
- 引用文件
- 需求：主体部分，详细描述软件需求。所需的状态和方式、需求概述、需求规格、软件配置项能力需求、软件配置项外部接口需求、软件配置项内部接口需求、适应性需求、保密性和私密性需求、软件配置项环境需求、计算机资源需求、软件质量因素、设计与实现约束、数据、操作、故障处理、算法说明、有关人员需求、有关培训需求、有关后勤需求、包装需求和其他需求，以及需求的优先级次序和关键程度。
- 合格性规定
- 需求可追踪性
- 尚未解决的问题
- 注解
- 附录
7、需求验证
也称需求确认~
主要是为了确定一下内容：
- SRS 正确的描述了预期的、满足项目干系人需求的系统行为和特性。
- SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导来的。
- 需求是完整的和高质量的
- 需求的表示在所有地方都是一致的
- 需求为继续进行系统设计、实现和测试提供了足够的基础。
简述
目的是(1)与用户一起确认需求无误
(2)对 需求规格说明书SAS 进行评审和测试
包括两个步骤
（1）需求评审：正式评审和非正式评审
（2）需求测试：设计概念测试用例
***需求验证通过后，要请用户签字确认，作为验收标准之一
此时，这个【需求规格说明书】就是【需求基线】
不可以再随意更新，
如果需要更新，必须走需求变更流程。
7.1 需求评审
SRS的 评审是一项精益求精的技术，它可以发现那些二义性的或不确定性的需求，为项目干系人提供在需求问题上达成共识的方法。
7.1.1 技术评审的类型
- 评审
- 检查
- 走查
7.1.2 正式评审的过程
- 计划
- 准备
- 进行评审
- 对评审结果采取行动
7.1.3 如何做好需求评审
- 分层次评审
- 正式评审与非正式评审结合
- 分阶段评审
- 精心挑选评审人员
- 对评审人员进行培训
- 充分利用需求评审检查单
- 建立标准的评审流程
- 做好评审后的跟踪工作
- 充分准备评审
7.2 需求测试
概念测试用例~
8、需求管理
8.1 需求变更管理
8.1.1 需求基线
通过了评审的【需求规格说明书】就是需求基线。下次如果需要变更需求，则需要按照流程一步步进行。
8.1.2 需求的状态
8.2 需求风险管理
# 带有风险的做法：
1、无足够用户参与：获取的需求不明确
2、忽略了用户分类：可能存在权限控制的问题
3、用户需求的不断增加
4、模棱两可的需求
5、不必要的特性
6、过于精简的SRS
7、不准确的估算
# 变更产生的原因
1、外部环境的变化
2、需求和设计做的不够完整
3、新技术的出现
4、公司机构重组造成业务流程的变化
# 变更控制委员会 CCB ：也称为 配置控制委员会，
其任务时对建议的配置项变更项 做出评价、审批、以及监督已经批准变更的实施。
8.3需求跟踪
2955
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
