一、知识点
1.业务分析要做的事情：
1） 确定业务问题和商业机会
2） 引导干系人的需要并分析制约因素
3） 分析干系人的需要以定义解决方案的需求
4） 分析和验证潜在和实际的解决方案
5） 管理“产品”和需求的范围。
2.需求的核心组件：人、信息、流程、规则。
3.项目发起的要素：
1） 方法或方法论
2） 工作目的说明
3） 项目目标
4） 问题和机会
5） 干系人
6） 业务风险
7） 范围之外的条目
8） 假设条件
9） 业务领域的范围
4.流程与用例相比的好处？
流程可以复用。
5.关于软件测试的知识
1） 单元测试：开发人员完成，可以是软件可被测试的小单元。
2） 集成测试：发现元件或系统一起工作时的问题。开发团队或质量保证团队进行，业务分析师帮助确定测试用例并检查测试结果。通常来说，由于在开发过程中等待太久而没有进行足够的集成测试是导致项目失败的一个主要原因。
3） 系统测试：团队把产品交给用户检查之前验证产品的最后一个机会。业务分析师参与系统测试以确认软件满足业务需求。
3.1）需求验证
3.2）性能测试：衡量反应速度。
3.3）压力测试：把软件推向用户数目与输入数的极限。
3.4）容量测试：使用大容量交易，确认软件可以处理预计的增长。
3.5）安全测试：确认未授权用户不能存取保密数据，而授权用户可以有效完成他们请求的任务。
3.6）安装测试
3.7）配置测试：确定软件如何运行在不同类型的硬件、操作系统上，并与相同系统上的其他软件包如何共同工作。
3.8）可用性测试：验证软件依照用户的可用性原则进行设计。
4）回归测试：进行任何软件变更之后，对于软件没有改变的功能重新测试。
5）用户验收测试
6）实施后用户评估
6. 推荐的需求分类
1）业务需求：完在业务使命所需要的信息、业务活动、业务规则和外部交互的详细描述。业务需求不描述怎么工作，只描述 什么工作，即不需在此体现软件现实方法。
2）功能需求：功能需求描述了怎么完成工作。怎么实施业务规则？人、组织、系统如何交流？每个业务需求，可能需要多个功能需求的支持。分析师撰写功能需求，设计解决方案由业务人员和技术团队共同参与。
3）非功能需求：可访问性、兼容性、可维护性、安全性等等。
4）技术需求：技术架构框架、数据库定义、业务规则、网络架构、应用系统接口、安全组件等许多技术规格说明书的详细描述。由IT架构师或系统架构师编写。
6. 需求书里可能出现的图：工作流图、实体关系图（ERD）、分解图、用例示意图、数据流图、原型图。
二、开始工作
1.了解项目
项目决策人是谁（一般是“老板”，他提供资金支持和项目目标）？了解项目为什么进行？企业为什么愿意花此项目费用？项目在企业的企业目标中占在一个什么样的位置？项目目标是什么？与其它与企业内其它哪些项目有什么关联？有什么样的关联？
2.了解干系人
对相关人员做第一次访问，这些相关人员是：专家、项目经理、质量保证师、IT架构师、IT开发人员、数据管理员、供应商。 带着问题，第一次访问的目的与收集需求相比更偏向于了解相关人员的性格并一之建立良好的合作关系。注意如有可能尽量在拜访之前就收集一些相关人员的信息，以便于每一次见面时与之建立良好的关系。
3.了解业务环境
1） 阅读公司材料
2） 回顾公司战略规则
3） 解读现有系统
4） 了解竞争情况
5） 根据干系人的时间情况按排访谈或组织会议。
6） 此时可结合后期的实施计划来考量。
4.需求交付
项目矩阵的交付物
可交付产品
项目类型
新系统开发
软件维护
COTS采购
流程再造
数据仓库
业务建模
投资/收益分析
O
O
p
p
O
项目启动
p
p
p
p
p
p
业务（逻辑）数据模型
p
O
p
p
p
概念类图
p
O
p
p
p
基础流程模型
p
O
p
p
3
p
当前工作流
O
O
p
p
p
未来工作流
O
p
O
用例模型
p
p
O
用户接口布局
p
O
测试用例和流程
p
p
p
安全需求
p
p
性能需求
p
p
p
质量需求
p
物理数据模型
p
O
p
关键字p ＝ 要求的，O＝可选的。
1 COTS,商用现货。
2概念类图和逻辑数据模型可能或者不可能用于同一项目中记录数据需求。
3数据仓库经常使用“ETL”概念：抽取数据，转换数据，然后在别处（数据仓库）装载数据。根据定义，过程转换数据，所以有些数据仓库项目需要把基本流程文档化。
受众矩阵的交付物
种类
SDL
C阶段
受众成员
领域专家
高管发起人
质量保证
网络架构
管理机构
IT系统架构师
IT开发人员
IT安全架构师
数据库架构师
法律
业务分析师
项目经理
外部客户
可交付产品
业务
1
投资/收益分析
R
A
C
A
R
2
项目启动
A
A
R
R
R
C
C
R
3
业务（逻辑）数据模型
R
R
R
A
C
A
R
概念类图
R
R
R
A
C
A
基础流程模型
A
R
R
R
C
A
R
当前工作流
A
R
R
R
C
A
功能
4
未来工作流
R
R
A
R
C
A
用例模型
A
R
R
A
R
R
R
C
A
R
用户接口布局
A
R
A
R
R
R
C
A
R
测试用例和流程
C
R
R
A
非功能
4
安全需求
R
R
R
R
C
A
R
R
C
A
性能需求
R
R
R
R
R
R
C
A
质量需求
R
R
R
R
CR
A
T
4
物理数据模型
R
R
R
R
A
A
关键字：A=批准，C=创建，R=评审。
1 SDLC 阶段：1=规划，2＝确定范围，3＝引导和分析，4＝设计。
2 注意，质量保证应该在项目几乎所有阶段都有评审或创建的职责，因为创建测试用例和流程是一个与软件开发生命周期同步的过程。
5.需求回溯：检查需求被完整实现的技巧
1） 对比数据库设计与ER实体图，检查字段是否齐全。
2） 建立需求与页面间的链接表格。
3） 集成测试和系统测试阶段检量是否能实现所有业务流程。
附：表格模板
业务流程信息收集的样板表格
流程号：
1.a.1
流程名：
增加/更新客户信息
详细描述：
这个流程接受客户信息并在我们的业务范围内记录
涉及的外部机构：
客户
什么触发这个流程？
客户联络客户服务部门，提出创建订单、变更订单、取消订单、索取产品目录或者其他任何请求
这个流程结束后发生什么？
如果增加一个新客户，立即送出一个产品目录
业务规则
如果客户不在数据库中，就增加所有客户信息。
如果客户在数据库中，核实信息是否正确并做需要的修改。
如果客户是一个机构，必须留下联系人姓名。
数据（属性）
CRUD
来源
客户名
CRU
外部客户
客户编号
C
内部生成
客户电话
CRU
客户
其他注释：
信息来源：
Mary smith
功能需求－现状
列出现在处理流程的部门
客户服务部门
流程现状如何处理
进入客户数据库的一个在线查询/更新屏幕
谁使用这个结果？
订单执行，运输，应收帐款，市场
指标
（只有需要重建的候选流程才需要）
目前这个流程多久执行一次（每日、每周、每月）
每日
上面时间段内流程出现多少次
100
当前环境下实施这个流程需要多长时间？（精确到小时或分钟）
1分钟
效率（1－5）1最低
4
功能需求－对未来建议
希望未来的改变？
客户应该可以通过网站更新自己的信息
需要从事这个流程的部门
网络客户
完成流程需要的时间（精确到小时或分钟）
1分钟
预计未来的业务量
每天100-200
完成的用例号
用例示例表格
系统用例描述------维护指导老师信息
用例ID
UC-2
用例名
维护指导老师信息
创建人
Catherine
创建日期
2008/1/5/
角色
培训管理员
描述
这个用例允许培训管理部门增加新的指导老师、去掉指导老师、并更新指导老师信息
前置条件
指导老理由必须经过培训管理的批准才能被加入到指导老师名单中
后置条件
指导老师的信息是正确的
优先级
中
使用频率
每周2-3次
主要路径
角色动作
系统响应
1.培训管理员从主菜单中选择 指导老师
1.系统显示 指导老师屏，并有一个空表。
2.培训管理员从 指导老师的下拉菜单中选择指导老师的名字
2.在屏幕的各个字段显示该指导老师的信息 新增和 更新按钮被禁止 只有 删除按钮是允许的
3.培训管理员检查指导老师的名字和当前课程证书
3.系统没有响应
4.培训管理员在该指导老师当前可以教授的课程前面的小框中做标记
4.系统允许 更新按钮
本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请
点击举报。
