软考笔记（五）高级系统架构师/分析师：系统需求工程 需求分析

目录

软考官网 报名通道

软考架构师笔记（一）：计算机系统基础

软考架构师笔记（二）：计算机网络基础与信息安全

软考架构师笔记（三）：操作系统基础

软考架构师笔记（四）：企业信息化与系统规划

软考架构师笔记（五）：系统需求工程 需求分析

软考架构师笔记（六）：数据库

软考架构师笔记（七）：系统分析 系统设计

软考架构师笔记（八）：系统架构

软考架构师笔记（九）：软件工程与项目管理

软考架构师笔记（十）：系统测试 维护 稳定性

需求工程

软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。
软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。

需求开发：

• 需求获取
• 需求分析
• 需求定义（需求规格说明书）
• 需求验证

需求管理:

• 变更控制
• 版本控制
• 需求跟踪
• 需求状态跟踪

需求分类：

• 业务需求(整体全局)
• 用户需求(用户视角)
• 系统需求(计算机化)
•  
• 基本需求(明示，常规需求)
• 期望需求(隐含)
• 兴奋需求(多余)

需求获取

用户访谈：用户访谈是最基本的一种需求获取手段，其形式包括结构化和非结构化两种。用户访谈是通过1对1（或1对2，1对3）的形式与用户面对面进行沟通，以获取用户需求。用户访谈具有良好的灵活性，有较宽广的应用范围。但是，也存在着许多困难，例如，用户经常较忙，难以安排时间；面谈时信息量大，记录较为困难；沟通需要很多技巧，同时需要系统分析师具有足够的领域知识等。另外，在访谈时，还可能会遇到一些对于企业来说比较机密和敏感的话题。因此，这看似简单的技术，也需要系统分析师具有丰富的经验和较强的沟通能力。

采样是指从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。对于信息系统的开发而言，现有系统的文档（文件）就是采样种群。当开始对一个系统做需求分析时，查看现有系统的文档是对系统有初步了解的最好方法。但是，系统分析师应该查看哪些类型的文档，当文档的数据庞大，法——研究时，就需要使用采样技术选出有代表性的数据。采样技术不仅可以用于收集数据，还可以用于采集访谈用户或者是采集观察用户。在对人员进行采样时，上面介绍的采样技术同样适用。通过采样技术，选择部分而不是选择种群的全部，不仅加快了数据收集的过程，而且提高了效率，从而降低了开发成本。另外，采样技术使用了数理统计原理，能减少数据收集的偏差。但是，由于采样技术基于统计学原理，样本规模的确定依赖于期望的可信度和已有的先验知识，很大程度上取决于系统分析师的主观因素，对系统分析师个人的经验和能力依赖性很强，要求系统分析师具有较高的水平和丰富的经验。

联合需求计划：为了提高需求获取的效率，越来越多的企业倾向于使用小组工作会议来代替大量独立的访谈。联合需求计划（Joint Requirement Planning，JRP）是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，它是联合应用开发（Joint Application Development，JAD）的一部分。

需求分析 SA

需求分析是一种软件工程活动，它在系统级软件分配和软件设计间起到桥梁的作用，需求分析使得系统工程师能够刻画出软件的功能和性能，指明软件和其他系统元素的接口，并建立软件必须满足的约束。
需求分析允许系统分析师细化软件的分解，并建立将被软件处理的数据、功能和行为模型。最后，需求规约为开发者和客户提供了软件开发完成后质量评估的依据。
需求分析为软件设计师提供了可被翻译成数据、架构、界面和过程设计的模型，
需求分析的任务是发现、求精、建模和规约的过程，包括详细地细化由系统工程师建立并在软件项目计划中明确的软件范围，创建所需数据、信息和控制流及操作行为的模型，此外，还要分析可选择的解决方案，并将它们分配到各软件元素中去。
需要注意的是，在需求分析阶段要得到详细的规约是不可能的。客户可能并不能精确地肯定需要什么，开发者可能不能肯定可用什么特定的方法来适当地完成功能和性能。

 

DFD 数据流图

数据流图DFD是SA方法中的重要工具，是表达系统内部数据的流动并通过数据流描述系统功能的一种方法。 
DFD还可被认为是一个系统模型，在信息系统开发中，如果采用结构化方法，则一般将DFD作为需求规格说明书的一个组成部分。用例模型描述了一组用例、参与者及它们之间的关系。
通常使用数据字典作为该工具的补充说明。

（1）DFD是理解和表达用户需求的工具，是需求分析的手段。由于DFD简明易懂，不需要任何计算机专业知识就可以理解它，因此，系统分析师可以通过DFD与用户进行交流。
（2）DFD概括地描述了系统的内部逻辑过程，是需求分析结果的表达工具，也是系统设计的重要参考资料，是系统设计的起点。
（3）DFD作为一个存档的文字材料，是进一步修改和充实开发计划的依据。

需求分析之面向对象 OOA

类封装组成

在系统设计过程中，类可以分为三种类型，分别是实体类、边界类和控制类。

1、实体类实体类的主要职责是存储和管理系统内部的信息，它也可以有行为，甚至很复杂的行为，但这些行为必须与它所代表的实体对象密切相关。实体类映射需求中的每个实体，实体类保存需要存储在永久存储体中的信息，例如，在线教育平台系统可以提取出学员类和课程类，它们都属于实体类。实体类通常都是永久性的，它们所具有的属性和关系是长期需要的，有时甚至在系统的整个生存期都需要。

2.控制类控制类用于描述一个用例所具有的事件流控制行为，控制一个用例中的事件顺序。
例如，用例“身份验证”可以对应于一个控制类“身份验证器”，它提供了与身份验证相关的所有操作。控制类用于对一个或几个用例所特有的控制行为进行建模，控制对象（控制类的实例）通常控制其他对象，因此，它们的行为具有协调性。通常情况下，控制类没有属性，但一定有方法。

3.边界类边界类用于描述外部参与者与系统之间的交互，它位于系统与外界的交接处，包括所有窗体、报表、打印机和扫描仪等硬件的接口，以及与其他系统的接口。
要寻找和定义边界类，可以检查用例模型，每个参与者和用例交互至少要有一个边界类，边界类使参与者能与系统交互。
边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。
常见的边界类有窗口、通信协议、打印机接囗、传感器和终端等。实际上，在系统设计时，产生的报表都可以作为边界类来处理。

用例建模 描述系统需求

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

用例是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。
在用例图中，主要包括参与者、用例和通信关联三种元素，如上图所示。
通信关联
用例
参与者
（1）参与者。参与者是指存在于系统外部并与系统进行交互的任何事物，既可以是使用系统的用户，也可以是其他外部系统和设备等外部实体。
（2）用例。用例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。也就是说，用例表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
（3）通信关联。通信关联表示的是参与者和用例之间的关系，或用例与用例之间的关系。箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者，箭尾所指方是对话的主动发起者。如果不想强调对话中的主动与被动关系，可以使用不带箭头的关联实线。在用例模型中，信息流不是由通信关联来表示的，该信息流是黑默以存在的，并且是双向的，它与箭头所指的方向没有关系。

使用UML建模

（引用博客 UML是什么？  原文链接：https://blog.csdn.net/Ellen5203/article/details/83268630）

统一建模语言（Unified Modeling Language——UML）是一种面向对象的建模语言，它可以实现大型复杂系统各种成分描述的可视化、说明并构造系统模型，以及建立各种所需的文档，是一种定义良好、易于表达、功能强大且普遍适用的建模语言。

UML组成：

                      

UML基本内容详述
（1）视图
视图是表达系统的某一方面特征的UML建模元素的子集；视图并不是图，它是由一个或多个图组成的对系统某个角度的抽象。

• 用例视图： 核心视图强调从用户的角度看到的或需要的系统功能。
• 逻辑视图： 该视图用于描述系统内实现的逻辑功能，展现系统的静态或结构组成及特征。
• 组件视图： 该视图从系统实现的角度来描述模型对象间的关系。
• 配置视图： 该视图用于说明系统的物理配置。

（2）图表
图表是描述视图内容的图。
1）用例图：用于描述外部项与系统提供的使用事件之间的联系, 用例图描述一组用例、参与者及它们之间的关系。用户角度描述系统功能；参与者是外部触发因素；（包括用户、组织、外部系统，时间）用例是功能单元。

2）类图： 用于描述系统的静态结构。类可以用不同方式连接，主要包括联合、依赖、独立和包装。一个系统一般有多张类图，一个类可在不同的视图中出现。

3）对象图：用于表述系统在某个时刻的静态结构。对象图也可作为协作图的一部分，说明一组对象之间的动态协作关系。
对象图与类图的区别：对象图表示的是类中的许多对象实例，而不是类本身。

4）状态图：用于说明类中的对象可能具有的状态，以及由时间引起的状态的改变。
简单理解：描述了系统元素的状态条件和响应。

5）顺序图（时序图）：用于描述对象间的动态协作关系。表达了对象间发行消息的时序，同时也表达出对象间的相互作用，以及当系统执行到某个特定位置时可能会发生的事。
简单理解：按时间顺序描述系统元素间的交互。

 

6）协作图（通信图）：按照时间和空间顺序描述系统元素间的交互和它们之间的关系。是一种交互图，它强调收发消息的对象或参与的组织结构。

与顺序图的区别：顺序图强调的是时序通信图强调的是对象之间的组织结构（关系）

7）活动图：用于描述系统活动的流程。活动图由活动状态组成，它包含将完成的活动的说明。当一个动作完成时，激发一个明确的事件并转到一个新的状态。它可以描述并行执行的活动。另外，它还包括了当动作部分完成时收到或发出的消息的说明。
简单理解：本质上是流程图，描述系统的执行顺序。

8）构建图，组件图：用于描述组件代码的物理结构。它建立了一个从逻辑视图到物理视图的映射。同时，它还描述了组件的依赖关系，可以用来分析一个组件的变化对另一个组件所产生的影响。

9）配置图
  用于描述系统中软件和硬件的物理结构。

10）状态图

11）定时图

定时图是一种新增的、特别适合实时和嵌入式系统建模的交互图，也称为计时图，计时图关注沿着线性时间轴、生命线内部和生命线之间的条件改变。它描述对象状态随着时间改变的情况，很像示波器，适合分析周期和非周期性任务。
定时图强调消息跨越不同对象或参与者的实际时间，而不仅仅关心消息的相对顺序。

12）4+1 视图
     需求分析模型：  逻辑视图（类与对象） -> 实现视图（物理代码与文件） -> 部署视图（软件到硬件的映射） -> 进程视图（线程，进程，并发）    围绕 用例视图 

    软件体系结构。“4+1”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。

 

 

模型元素
  模型元素代表面向对象中的类、对象、接口、消息和关系等概念。UML中的模型元素包括事物和事物之间的联系，常见的联系包括关联关系、依赖关系、泛化关系、实现关系和聚合关系。
基本机制
  UML的基本机制表现为各种图标上的附加信息，用于描述那些模型元素无法表达的内容。
1）修饰
  通过特定的修饰把一些语义加到模型元素上。
2）注释
  UML提供增加注释的方式以表达那些模型元素无法表示的信息。
3）说明
  用于增加无法正式在图中表示的元素实例的附加说明，可以由文本的形式对图中相应部分的责任和权限加以说明。

规则是构造块如何放在一起的规定，包括为构造块命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行。
公共机制是指达到特定目标的公共UML方法，主要包括规格说明（详细说明）、修饰、公共分类（通用划分）和扩展机制4种。规格说明是事物语义的细节描述，它是模型真正的核心。

UML在需求分析中的使用：

UML有三种基本的构造块，分别是事物（thing）、关系（relationship）和图（diagram）。事物是UML的重要组成部分，关系把事物紧密联系在一起，图是多个相互关联的事物的集合。

UML用关系把事物结合在一起，主要有下列四种关系：

1. 依赖（Dependency）。依赖是两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。
2. 关联（Association）。关联描述一组对象之间连接的结构关系。泛化（Generalization）。
3. 泛化是一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象。
4. 实现（Realization）。实现是类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。

 

UML2.0

（1）组合结构图描述结构化类（例如，构件或类）的内部结构，包括结构化类与系统其余部分的交互点。组合结构图用于画出结构化类的内部内容。
（2）定时图也称计时图，定时图也是一种交互图，它强调消息跨越不同对象或参与者的实际时问，而不仅仅只是关心消息的相对顺序。
（3）制品图描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品图通常与部署图一起使用。制品也给出了它们实现的类和构件。
（4）交互概览图是活动图和顺序图的混合物。它是活动图的变体，描述业务过程中的控制流概览，软件过程中的详细逻辑概览，以及将多个图进行连接，抽象掉了消息和生命线。
  

软件需求

简单地说，软件需求就是系统必须完成的事以及必须具备的品质。需求是多层次的，包括业务需求、用户需求和系统需求，这三个不同层次从目标到具体，从整体到局部，从概念到细节。
（1）业务需求。业务需求是指反映企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围。
（2）用户需求。用户需求描述的是用户的具体目标，或用户要求系统必须能完成的任务。也就是说，用户需求描述了用户能使用系统来做些什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景（scenarios）进行整理，从而建立用户需求
（3）系统需求。系统需求是从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。

 

需求变更

一个大型软件系统的需求通常是会发生变化的。在进行需求变更时，可以参考以下的需求变更策：

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

 

需求管理

需求管理是一个对系统需求变更、了解和控制的过程。需求管理过程与需求开发过程相互关联，当初始需求导出的同时就启动了需求管理计划，一旦形成了需求文档的初稿，需求管理活动就开始了。关于需求管理过程域内的原则和策，可以参考：①需求管理的关键过程领域不涉及收集和分析项目需求，而是假定己收集了软件需求，或者已由更高一级的系统给定了需求。②开发人员在向客户以及有关部门承诺某些需求之前，应该确认需求和约束条件、风险、偶然因素、假定条件等。③关键处理领域同样建议通过版本控制和变更控制来管理需求文档。