导图社区 系统分析师——软件需求工程
软件需求工程是系统分析师的重点章节，其中需求获取和需求分析是频繁出现论文的章节。
本图以概要的方式提取系统分析师教程中系统分析章节的脉络。内容实用，感兴趣的小伙伴可以收藏一下~
社区模板帮助中心，点此进入>>
互联网9大思维
组织架构-单商户商城webAPP 思维导图。
域控上线
python思维导图
css
CSS
计算机操作系统思维导图
计算机组成原理
IMX6UL(A7)
考试学情分析系统
软件需求工程
概述
需求层次
用户需求
业务需求
系统需求
质量功能部署（QFD）
常规需求
期望需求
意外需求
需求获取
用户访谈
准备访谈
确定访谈目的
确定访谈中包含的用户
准备访谈中的问题
开放式问题
封闭式问题
作出最终访谈的安排
访谈过程
限制访谈时间
寻找异常和错误的情况
深入调查细节
认真做好记录
访谈的后续工作
首要任务是吸收、理解、记录访谈获得的信息
对用户回答不上来的问题作记录，安排到下次访谈确认
发送访谈备忘录给用户，确认被访谈者的贡献，并确认回答错误的问题
用户访谈的优缺点
良好的灵活性，有宽广的应用范围
协调用户时间有困难
面谈信息量大，记录困难
足够沟通技巧
足够的领域知识
遇到机密问题和敏感话题
访谈形式
结构化（事先准备好一系列问题，有针对性进行）
非结构化（只列出粗略想法，全靠现场发挥）
实际上最有效的是两者结合
问卷调查
调查表的制作
确定问题及类型
编写问题
设计问卷调查表的格式
问卷调查的优缺点
短时间内以低廉代价从大量回答中收集数据
匿名填写有利于真实回答
整理和统计容易
提高问卷返还率的方法
解释问卷目的和使用方式
说明回答要求
拜托相关责任人督促填写和返还
参加客户会议回答问卷的信息处理方向
减少问卷回答时间
设置奖品
采样
样本大小
计算公式：启发式因子（α）*（可信度系数/可接受的错误）*（可信度系数/可接受的错误）
采样的优缺点
加快数据收集速度
取决于系统分析师的主观因素，依赖经验和能力
情节串联板
情节串联板的概念
使用工具向用户说明系统如何适合企业
情节串联板的类型
被动式
类似于图片、PPT
主动式
类似于电影样片，可播放
交互式
如仿真、模拟、原型
情节串联板的制作
静态工具，如纸笔、PPT、图片等
动态工具，如flash等动画工具等
情节串联板的优缺点
最生动需求获取技术，用户友好、交互性强
时间代价高、获取需求速度慢
联合需求计划（JRP）
联合应用开发（JAD）
JRP会议
主要原则
优缺点
对有歧义的问题、需求最不清楚的领域十分有效
会议组织难度大和相关人员的能力要求高
成本较高效果明显
需求记录技术
任务卡片
特别适合对业务活动级的信息收集与整理
场景说明
用户对工作场景和过程的详细描述
用户故事
描述对用户有价值的功能
内容
书面描述（用于计划和备忘）
交谈（细化故事）
测试用例（验证故事实现）
形式为手工书写的用户故事卡
基本属性
独立性
可协商性
对用户有价值
可预测性
短小精悍
可测试性
Volere白卡
类似任务卡片的需求记录工具
工具选择
用户故事和Volere白卡定位于最小需求项，适合敏捷方法中使用
选取原则
借鉴现有模板
根据需要进行扩展或重新定义
要基于团队、用户、系统分析的技能因素选择
需求分析
需求分析的任务
定义
提炼、分析、仔细审查已获取的需求，确保所有干系人都理解并找出其中 错误、遗漏、不足的地方
任务
绘制系统上下文范围关系图
创建用户原型界面
分析需求的可行性
确定需求的优先级
为需求建立模型
创建数据字典
使用QFD
需求分析的方法
结构化分析方法（SA）
ER图表示数据模型
DFD表示功能模型
DFD的主要作用
理解和表达用户需求的工具，是需求分析的手段
描述系统内部逻辑过程，是需求分析结果的表达工具，系统设计的起点
存档的文字材料，是进一步修改和充实开发计划的依据
DFD的基本符号
数据流，具有名字和流向的数据，以标有名字的箭头表示
加工，对数据流的变换，以圆圈表示
数据存储，可访问的存储信息，以直线段表示
外部实体，数据处理过程的数据来源及数据去向，以标有名字的方框表示
DFD的层次
顶层图
描述整个系统的输入、输出数据流和外部实体
逐层分解
如何画DFD
绘制过程
画系统的输入和输出
画DFD内部
为每一个数据流命名
为加工命名
检查和修改原则
所有DFD只允许有四种基本图形，每个图形必须有名字
每个加工至少有一个输入数据流和输出数据流
DFD中需按层给加工编号
任何一个DFD子图必须于它上一层一个加工对应， 两者的输入和输出数据流必须一致
在整套DFD中，每个数据存储必须既有读的数据流，又有写的数据流
可以在DFD中加入物质流帮助用户理解DFD，但不可以夹带控制流
STD表示行为模型
最适合描述事件驱动的实时控制系统
通过描述系统状态和引起状态转换的事件表示系统行为
核心是数据字典
数据字典的条目
数据元素，数据项，数据的最小组成单位
数据结构，描述数据元素之间的关系
数据流
数据存储
加工逻辑
外部实体
数据字典的作用
按各种要求列表
相互参照，便于修改
由描述内容检索名称
一致性检验和完整性检验
数据字典的管理
由DBA维护和管理
面向对象分析方法（OOA）
统一建模语言UML
UML结构
构造块
事物
结构事务
行为事务
分组事务
注释事务
关系
依赖
关联
泛化
实现
图
类图
对象图
构建图
组合结构图
用例图
顺序图
通信图
定时图
状态图
活动图
部署图
制品图
包图
交互概览图
公共机制
规格说明（详细说明）
公共分类（通用划分）
扩展机制
修饰
规则
构造块放在一起的规定
描述系统架构的视图
逻辑视图
进程视图
实现视图
部署视图
用例视图
用例模型
用例图的元素
参与者
用例
通信关联
识别参与者
人
其他系统
硬件设备，如IC卡
时钟
合并需求获得用例
注意用例命名
不能混淆用例和用例所包含的步骤
注意区分业务用例和系统用例
细化用例描述
用例名称
简要说明
事件流
非功能需求
前置条件和后置条件
扩展点
优先级
调整用例模型
包含关系
扩展关系
泛化关系
分析模型
定义概念类
确定类之间的关系
关联关系
依赖关系
共享聚集
组合聚集
实现关系
为类添加职责
属性
方法
建立交互图
分析模型的详细程度问题
模型是开发过程中的辅助工作
面向问题域的分析方法（PDOA）
强调多描述少建模
描述组成
关注问题域
关注解系统的待求行为
分析过程
收集基本信息并开发问题框架，以建立问题域的类型
在问题框架类型指导下进一步收集详细信息并给出一个 问题域相关特性的描述
收集并用文档说明新系统的需求
需求定义
需求定义方法
严格定义方法
基本假设
所有需求都能够被预先定义
开发人员与用户之间能够准确而清晰地交流
采用图形（或文字）可以充分体现最终系统
适合情况
仅能适合规模小功能简单的系统
原型方法
一种迭代的循环型开发方式
需要注意的问题
原型可以渐进式的完善需求
原型提供了克服交流困难的一个手段
原型提供了实际的、可供用户参与的系统模型
原型提供了合适的系统开发环境
通过原型得到明确的需求定义后，应采用严格方法完成系统开发
软件需求规格说明书
编写方法
用好的结构化和自然语言编写文本型文档
建立图形化模型
编写形式化规格说明
内容和格式
范围
引用文件
需求
合格性规定
需求可追踪性
尚未解决的问题
注解
附录
需求验证
需求评审
技术评审类型
评审
检查
走查
正式评审的过程
计划
准备
进行评审
对评审结果采取行动
如何做好需求评审
分层次评审
正式评审与非正式评审相结合
分阶段评审
精心挑选评审人员
对评审人员进行培训
建立标准的评审流程
做好评审后的跟踪工作
充分准备评审
需求测试
概念测试用例
需求测试的过程
需求管理
需求变更管理
需求基线
需求状态
需求变更
需求风险管理
带有风险的做法
无足够的用户参与
忽略了用户分类
用户需求的不断增加
模棱两可的需求
不必要的特性
过于精简的SSR
不准确的估算
与需求有关的风险
需求跟踪
需求跟踪的内容
需求跟踪的目的
需求跟踪矩阵
