商业分析师 需求启发与分析
2022-05-05 11:36:56 0 举报AI智能生成
商业分析师能根据业务的需求，从数据中生成相应的报表，为决策提供支撑。相比其他的业务人员，他能更高，更广，更深入并且更数据化地对业务进行分析。他的思路一定不能陷入在日常业务当中，必须超脱出来，并且要具有一定的抽象能力，同时能熟练运用分析工具，学会用数据说话。
作者其他创作
大纲/内容
需求启发/发觉 elicit
启发不仅仅是需求的的收集与汇总
需求并非现成
干系人可能不了解需要
分析
4.1 本章目的
4.2 启发信息意味什么
4.3 启发计划
4.4 启发准备
4.5 开展启发活动
4.6 记录启发活动的输出
4.7 完成启发
4.8 启发的问题和挑战
4.9 分析需求
4.10 建模与细化需求
模型描述
模型目的
模型选择
使用模型细化需求
建模语言
模型分类
4.10.7 范围模型
目的模型
4.10.8 过程模型
过程流
用例
用户故事
4.10.9 规则模型
商业规则目录
决策树和决策表
4.10.10 数据模型
实体关系图 erd
业务数据图
显示基数
数据模型的不同层级
概念数据模型-高层级
逻辑数据模型
logical data model
物理数据模型
physical data model
实施领域专家使用，
描述数据库的物理组织
数据流图
data flow diagrams
表现系统、涉众数据的关系
数据的存储，数据与系统的数据转移，不含顺序
通过业务数据对象与流程与需求相关联
环境？系统交互图context diagram 是最高层级的数据流图
数据字典
data dictionary
与业务规则相互验证
状态表和状态图
stats table and state diagram
起始状态与目标状态，因其状态转换的操作
状态图与活动图很相似
crud 矩阵
交叉检验数据与流程，保证每个都有
创建 create
读取 read
更新 update
删除 delete
4.10.11 接口/界面模型
interface models
描述解决方案与外部存在接口
接口分析
识别准备
了解需要识别的接口
识别主要问题
进行接口识别
定义接口
名称，范围，交互方式，信息格式，交互
输出物：系统接口表
协同性
原型法
水平 垂直
低保证 高保真
抛弃型 演进型
报告表
report table
单个报告获取详细层级需求的模型
系统接口表
用户界面流
线框图和显示-操作-响应
display-action-response
用于屏幕模拟
其他方法
事件-业务事件分析
依赖图 图示系统需求
4.11记录解决方案需求
solution requirements
文档的重要性
确认干系人需要的基准
解决方案的基准定义
设计、开发、测试、质量保证团队的输入
用户手册与其他文档的基础
提供合同协议的细节
形成解决方案的起始点
重用的基础
受监管行业与高风险审计的基准
业务需求文档
business requirements specification
业务需求可以使用业务需求规格
业务专家关注业务方面描述的需求
解决方案文档
一组用户故事
一组用例，及相关非功能性需求
产品未完项表中的事项
业务需求文档 business requirements document
包含不同需求类型，以不同详细层次编写
功能需求规格 functional requierements specification
软件需求规格 software requirements specification
可以定义方案中可能发生的所有环境，条件，行为，反应与报错条件
是对所有包含需求的文档的通用称呼
敏捷，精益方法项目中，正式的需求规格说明书通常偏轻量级
分类有助于对文档中的需求进行分组
范围筛选
功能筛选
优先级筛选
可测试性筛选
记录假设
assumptions
BA 为每一个登记的假设设定预案，假设不成立，采取相应行动
假设是被认为正确，真实，或确定的，未经证明的因素
记录限制条件
constraints
影响项目执行的制约因素
解决方案限制条件
需求和限制条件的区别
归入文档的独立部分进行描述
编写需求的指导方针
条件
主体
起使语
主动词
对象
业务规则
结果
点选新建账号按钮时（条件），系统（主体）应（祈使语）显示（主动词）新账号输入界面（对象），允许创建一个新账号
高质量的需求特征
明确
unambiguous
精确
precise
一致
consistent
正确
correct
完整
complete
可衡量
measurable
可行
feasible
可跟踪
traceable
可测试
testable
划分需求的优先级
划分优先级的方式，应该在商业分析计划中规划
优先级划分中遇到的挑战
不可协商的要求
non-negotiable demand
用户要求所有需求作为最高等级
用户
不实际的取舍
unrealistic tradeoffs
实施人员高估实施的复杂性或难度，误导优先级划分
实施人员
moscow
将需求分为4类
must 项目成功的基本要求
should 很重要但项目成功不依赖于此
could 可以舍弃而不会对项目造成影响
won't 本阶段不交付
多重投票
multivoting
假设每个干系人有450预算，购买对应功能的金额
时间盒
time-boxing
子主题 1
4.12 确认需求
4.13 核实需求 审查需求
verify requirements
高质量需求的标准
审查是核查需求错误与质量的过程
由谁来做：解决方案团队，推荐测试人员，测试用例，
由业务领域的干系人
同行审阅 peer review
核查 inspection
准备审阅内容清单
需求之间的交叉引用是否正确
需求是否以一致和恰当的详细程度编写
是否包含优先级
外部的接口
内在逻辑
可能出现的异常条件，相关的期望行为
其他方法
走读 walk though
与干系人一起审阅需求，确认有效性
桌上检查 desk checking
测试 test
4.14 批准会议
需求经过确认以后，BA获取针对需求的签字
需要签字的人
业务负责人 business owner
我同意这些需求完成
解决方案团队需求接收人 solution team recipient
可以被实现，并被实现了
商业分析师
这是工作成果，我对此负责
4.15 解决和需求有关的冲突
通过讨论不同之处，理解干系人的观点
不能达成一致，则将问题升级汇报
软技巧
方法
德尔菲 delphi
专家匿名提供意见
多重投票 multivoting
加权排序 weighted ranking
0 条评论
下一页
