一、知识点

1. 1.业务分析要做的事情：

1） 确定业务问题和商业机会

2） 引导干系人的需要并分析制约因素

3） 分析干系人的需要以定义解决方案的需求

4） 分析和验证潜在和实际的解决方案

5） 管理“产品”和需求的范围。

1. 2.需求的核心组件：人、信息、流程、规则。

1. 3.项目发起的要素：

1） 方法或方法论

2） 工作目的说明

3） 项目目标

4） 问题和机会

5） 干系人

6） 业务风险

7） 范围之外的条目

8） 假设条件

9） 业务领域的范围

1. 4.流程与用例相比的好处？

流程可以复用。

1. 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. 1.了解项目

项目决策人是谁（一般是“老板”，他提供资金支持和项目目标）？了解项目为什么进行？企业为什么愿意花此项目费用？项目在企业的企业目标中占在一个什么样的位置？项目目标是什么？与其它与企业内其它哪些项目有什么关联？有什么样的关联？

1. 2.了解干系人

对相关人员做第一次访问，这些相关人员是：专家、项目经理、质量保证师、IT架构师、IT开发人员、数据管理员、供应商。 带着问题，第一次访问的目的与收集需求相比更偏向于了解相关人员的性格并一之建立良好的合作关系。注意如有可能尽量在拜访之前就收集一些相关人员的信息，以便于每一次见面时与之建立良好的关系。

1. 3.了解业务环境

1） 阅读公司材料

2） 回顾公司战略规则

3） 解读现有系统

4） 了解竞争情况

5） 根据干系人的时间情况按排访谈或组织会议。

6） 此时可结合后期的实施计划来考量。

1. 4.需求交付

项目矩阵的交付物

关键字p ＝ 要求的，O＝可选的。

  1 COTS,商用现货。

  2概念类图和逻辑数据模型可能或者不可能用于同一项目中记录数据需求。

  3数据仓库经常使用“ETL”概念：抽取数据，转换数据，然后在别处（数据仓库）装载数据。根据定义，过程转换数据，所以有些数据仓库项目需要把基本流程文档化。

受众矩阵的交付物

关键字：A=批准，C=创建，R=评审。

1 SDLC 阶段：1=规划，2＝确定范围，3＝引导和分析，4＝设计。

2 注意，质量保证应该在项目几乎所有阶段都有评审或创建的职责，因为创建测试用例和流程是一个与软件开发生命周期同步的过程。

1. 5.需求回溯：检查需求被完整实现的技巧

1） 对比数据库设计与ER实体图，检查字段是否齐全。

2） 建立需求与页面间的链接表格。

3） 集成测试和系统测试阶段检量是否能实现所有业务流程。

1. 附：表格模板

业务流程信息收集的样板表格

用例示例表格