【系统分析师】案例分析题-系统分析和需求工程

最新推荐文章于 2025-05-17 16:23:45 发布

夏高木杉

最新推荐文章于 2025-05-17 16:23:45 发布

阅读量1k

点赞数 27

CC 4.0 BY-SA版权

文章标签：软件工程软件需求需求分析

本文链接：https://blog.youkuaiyun.com/weixin_48713918/article/details/142926640

需求获取方法

用户访谈：1对1-3，有代表性的用户。其形式包括结构化和非结构化两种。结构化是指事先准备好一系列问题，有针对地进行;而非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。包括准备访谈、主持访谈和访谈的后续工作。优点是灵活，应用范围广:缺点是记录困难，时间有限，对系统分析师要求高。
问卷调查:用户多，无法一一访谈。关键在于制作好的调查表，优点是广撒网，代价小，信息真实，结果好统计:缺点是缺乏灵活性。
采样:从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。优点是提高了效率降低了成本，减少数据收集偏差:缺点是依赖系统分析师主管因素，要求高。样本数量=0.25*(可信度因子/错误率)
情节串联板:一系列图片，通过这些图片来讲故事。优点是给用户直观的演示，交互性强,生动:缺点是花费时间多，效率低。
联合需求计划(JRP):是一种相对来说成本较高的需求获取方法,但也是十分有效的一种。它通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。JRP将会起到群策群力的效果，对于一些问题最有岐义的时候、对需求最不清晰的领域都是十分有用的一种方法。优势:1、发挥用户和管理人员参与系统开发过程的积极性，提高系统开发效率;2、降低系统需求获取的时间成本，加速系统开发周期:3、采用原型确认系统需求并获取设计审批，具有原型化开发方法的优点。
需求记录技术:任务卡片、场景说明、用户故事、Volere 白卡。

需求分析的任务

绘制系统上下文范围关系图
创建用户界面原型
分析需求的可行性
确定需求的优先级
为需求建立模型
创建数据字典
使用QFD(质量功能部署)

需求分析的方法

结构化需求分析

特点

自顶向下，逐步分解，面问数据。

三大模型

数据字典（核心）

数据字典是在DFD 的基础上，对DFD中出现的所有命名元素都加以定义，使得每个图形元素的名字都有一个确切的解释。DFD 和数据字典等工具相配合，就可以从图形和文字两个方面对系统的逻辑模型进行完整的描述。
一般有6 类条目，分别是数据元素、数据结构、数据流、数据存储、加工逻辑和外部实体。不同类型的条目有不同的属性需要描述，

功能模型(数据流图/DFD)

在这里插入图片描述
可分层次，底层到顶层

元素

数据流
加工
数据存储（文件）
外部实体

异常现象

黑洞:一个加工只有输入数据流而无输出数据流。
奇迹:一个加工只有输出数据流而无输入数据流。
灰洞:若一个加工的输入数据流无法通过加工产生输出流。

行为模型(状态转换图/STD)

一般用于试试控制系统，使用与考察较少

数据模型(E-R图)

面向对象的分析

两大模型

用例模型

作用

识别参与者
合并需求获得用例
细化用例描述
- 用例名称
- 简要说明
- 事件流
- 非功能需求
- 前置条件
- 后置条件
- 扩展点优先级
调整用例模型

用例图

用例图描述一组用例、参与者及它们之间的关系。

功能

用户角度描述系统功能;
参与者是外部触发因素;
用例是功能单元。

在这里插入图片描述

建立流程

识别参与者【参与者:用户、组织、外部系统、时间】
合并需求获得用例
细化用例描述
调整用例模型(可选步骤)【关系包括:包含关系、扩展关系、泛化关系】

用例关系

包含关系【使用关系】:从多个用例中提取公共行为，提取出来的公共用例称为抽象用例，而把原始用例称为基本用例。
扩展关系:一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支则可以将这个用例分为一个基本用例和一个或多个扩展用例。
泛化关系:当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。子用例继承了父用例所有的结构、行为和关系。

分析模型

作用

定义概念类
识别类之间的关系
为类添加职责
建立交互图

建立流程

1. 定义概念类

阅读和理解需求文档或用例描述。
筛选出名词或名词短语，建立初始类清单(候选类)
将候选类分成三类，分别是显而易见的类、明显无意义的类和不确定类别的类。
舍弃明显无意义的类。
- 去除相同含义的
- 去除不属于系统范围内的
- 去除没有特定独立行为的
- 去除含义解释不清楚的
- 去除属于另一个类属性或行为的
小组讨论不确定类别的类，直到将它们都合并或调整到其他两个类别，并进行相应的操作。

2. 确定类之间的关系

依赖关系:一个事物发生变化影响另一个事物。
泛化关系:特殊/一般关系。
关联关系:描述了一组链，链是对象之间的连接。
- 聚合关系:整体与部分生命周期不同。
- 组合关系:整体与部分生命周期相同。
实现关系:接口与类之间的关系。

3. 为类添加职责

4. 建立交互图

5. 分析模型的详细程度问题

类图

在这里插入图片描述

交互图

顺序图(Sequence Diagram，序列图)。顺序图是一种交互图(InteractionDiagram)，它强调对象之间消息发送的顺序，同时显示对象之间的交互。

UML（统一建模语言）

静态图（结构图）

类图:一组类、接口、协作和它们之间的关系
对象图:一组对象及它们之间的关系
构件图:一个封装的类和它的接口
部署图:软硬件之间的映射
制品图:系统的物理结构
包图:由模型本身分解而成的组织单元，以及门之间的依赖关系组合结构图

动态图（行为图）

用例图:系统与外部参与者的交互
顺序图:强调按时间顺序
通信图(协作图)
定时图:强调实际时间
交互概览图
活动图:类似程序流程图，并行行为
状态图:状态转换变迁

注：顺序图、通信图、定时图、交互概览图都属于交互图

PDOA方法（面向问题域的分析）

过程

收集基本的信息并开发问题框架，以建立问题域的类型。
在问题框架类型的指导下，进一步收集详细信息，并给出一个问题域相关特性的描述。
基于以上两点，收集并用文档说明新系统的需求。

方法对比

SA 方法关注于功能的分层和分解，这非常符合人们自上而下、逐步分解问题直到可解决的自然思考方式。SA方法本身隐含着几个基本假设，即问题域是可定义的、问题域是有限的、通过有限的步骤总可以将复杂问题分解到可解决的程度。
OOA 方法则遵循完全不同的思维方式，它基于抽象、信息隐藏、功能独立和模块化这些基本理念对系统进行分析。OOA 方法首先对问题域的事物的“外在表象”进行观测，然后在逻辑世界中模拟出一个对应的逻辑对象,“断定”该对象和现实事物是一致的。随后，观测到的对象被记录入对象集合,观测到的行为和表象被记录入对象关系模型和对象行为模型。
PDOA 的特点是重新将重点定位在问题域和需求上，通过对问题域的分类，向系统分析师提供具体问题的相关指南。并且它将规格说明作为另外的任务处理，它的成果只是一份问题域的全面描述和一份需求列表而已。PDOA丰富和完善了SA和OOA方法。

需求定义方法

严格定义也称为预先定义，需求的严格定义建立在以下的基本假设之上:所有需求都能够被预先定义。开发人员与用户之间能够准确而清晰地交流。采用图形(或文字)可以充分体现最终系统。
原型方法，迭代的循环型开发方式，需要注意的问题:并非所有的需求都能在系统开发前被准确地说明。项目干系人之间通常都存在交流上的困难，原型提供了克该服困难的一个手段。特点:需要实际的、可供用户参与的系统模型。有合适的系统开发环境。反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。

需求规格说明书

内容:范围;引用文件;需求;合格性规定;需求可追踪性;尚未解决的问题;注解;附录。
通俗答法:系统应该提供的功能和服务;非功能需求，包括系统的特征、特点和属性;限制系统开发或者系统运行必须遵守的约束条件;系统必须连接的其他系统的信息。
作用:系统所有者和用户使用需求定义文档来确认需求以及任何可能产生的变化，并作为验收依据;系统分析人员、设计人员和构造人员使用它来理解需要什么以及处理需求变更，开发用于验证系统的测试用例;项目经理使用它作为制定项目计划、处理变更及验收的依据。

需求管理

包含：需求基线、需求变更、需求跟踪

软件过程管理

软件产品线

软件产品线是一个产品集合，这些产品共享一个公共的、可管理的特征集，这个特征集能满足特定领域的特定需求。软件产品线是一个十分适合专业的开发组织的软件开发方法，能有效地提高软件生产率和质量，缩短开发时间，降低总开发成本。

核心资源:包括所有产品所共用的软件架构，通用的构件、文档等。
产品集合:产品线中的各种产品。

建立方式

基于现有产品基于现有产品架构设计产品线的架构，经演化现有构件核心资源的开发基于现有产品集的需求和可预测的、将来需求的超集
全新产品线开发产品线构件产品线核心资源能产品新成员的需求而演化开发满足所有预期产品线成员的需求的核心资源

软件复用

次件复用是将已有软件的各种有关知识用于建立新的软件，以缩减软件开发和维护的花费。软件复用是提高软件生产力和质量的一种重要技术。早期的软件复用主要是代码级复用，被复用的知识专指程序，后来扩大到包括领域知识、开发经验、设计决定、体系结构、需求、设计、代码和文档等一切有关方面。

逆向工程

级别分类

完备性递增，抽象级别递减

实现级:包括程序的抽象语法树、符号表、过程的设计表示。
结构级：包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图、程序和数据结构
功能级:包括反映程序段功能及程序段之间关系的信息，例如数据和控制流模型。
领域级:包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息，例如E-R模型。

软件能力成熟度模型CMM

将软件过程改进的步骤组织成5个成熟度模型。

初始级。
- 初始级是未加定义的随意过程，软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和步骤可循的状态,软件产品所取得的成功往往依赖于极个别人的努力和机遇。
可重复级。
- 可重复级是规则化和纪律化的过程，软件过程已建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。对类似的应用项目,有章可循并能重复以往所取得的成功。
- 过程域的阶段式分组：需求管理、项目计划、配置管理、项目监督与控制、供应商合同管理、度量和分析、过程和产品质量保证
已定义级。
- 已定义级是标准的和一致的过程，用于管理的和工程的软件过程均已文档化、标准化，并形成了整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。
- 过程域的阶段式分组：需求开发、技术解决方案、产品集成、验证、确认、组织级过程焦点、组织级过程定义、组织级培训、集成项目管理、风险管理、集成化的团队、决策分析和解决方案、组织级集成环境
已管理级。
- 已管理级是可预测的过程，软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。
- 过程域的阶段式分组：组织级过程性能、定量项目管理
优化级。
- 优化级是持续改进的过程，通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续性地对过程进行改进。
- 过程域的阶段式分组：组织级改革与实施、因果分析和解决方案