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