Glossary：术语表

interface analysis:接口/界面分析

non-functional requirements analysis

数据字典

data flow diagrams 数据流图种类

Gane-Sarson notation: process,data flow,data store

yourdon notation: externals,process,data flow data store

data modeling: entity relationship diagram

CLASS DIAGRAM

概念数据模型/逻辑数据模型/物理数据模型

definition rules

业务规则目录

backlog management：在敏捷项目中，backlog就是需求管理的工具；需求是以用户故事的方式呈现

敏捷项目中优先级划分：MoSCow原则

1、Mo=must实现

2、S =should应该要是实现，但不一定是必须

3、C=could 可有可无

4、W=would不在当前阶段实现，可先记录下来

跟踪需求：量大可以使用需求管理工具

reuquirements traceability matrix(手工表）

brainstorming:无中生有，产生大量想法

focus group:针对某个事物的想法，定性研究

workshop：达成一致意见

focus group焦点小组

pre-quelified participants 使用产品的用户或者专家，可以是同一背景也可以是不同背景，不同于头脑风暴可以是没有条件限制的成员

prepare-run-after

interviews:opening 

business case 成本效益分析，不一定是客观的

dominated alternatives 劣势选择

context diagram 数据流图 项目早期确定的范围包括接口

用例之间的关系：include多个用例之间是重用的

extend是在某个用例上扩展功能

governance 流程、批转、决策依据。流程管理

personas 虚拟人物画像

6.1现状分析

目标：

BA要了解现有的组织架构，现有的

输入：Needs和4.3信息搜集的结果

过程：定义商业需求（定义问题）

BA要回答的问题是What，但是定义What之前要清楚Why

Supervised: 输入大量规则、依据，然后做出判断

Unsupervised：无监督，从数据本身出发，发现趋势等等，不需要输入大量规则

diagnostic：针对问题寻找潜在原因

predictive：根据关联关系建立模型进行预测

data minging use consideration：了解

8.1 Measure Solution Performance：搜集和business objectives相关的数据

Qualities Measure：can be implemented through focus grop, obtainging users's feedback and suggestion related to product

Currency: current 时效性

Defining acceptance criteria can be viewed as defining requirements.as solution must meet acceptance criteria. So acceptance criteria also can be viewed as one type of R.

介绍各种收集信息的方式

1、协作的方式，需要不同的干系人进行接触，收集不同信息

2、做研究，独立进行对数据分析和挖掘，不一定需要和干系人进行沟通

3、观察、验证，

在收集信息过程当中，可能一种方法可能不够，需要多种信息收集方式

输入：

4.1需求收集的互动计划

需求收集活动指导

1、在需求收集过程当中，应该围绕主题展开

2、在过程中要做一些记录，录音或者笔记

指导方针和工具

1、之前的需求工作计划

2、已有的需求信息

3、干系人的沟通计划

4、支持的材料

目标：

文档分析：

目标：L对现有客户文档进行分析和收集，，步骤

1、目前该领域的文档、白皮书、功能介绍，组织内部的流程、规范和要求

2、文档的回顾和分析，关注根据具体需要，把问题记录下来，把不同的收集信息进行比对，

3、把文档进行汇总

文档的要注意的内容和注意事项、局限性

1、文档分析的有点：获取成本较低，文档

2、可以和现有状态进行验证

3、要保证现有文档不过时

4、文档的作者可能不在组织中，要确认可能找不到人了，可以在访谈过程中再确认文档的内容

5、通常是来评估现有的制度、流程，评估现有的状态

6、文档比较花时间和枯燥

技术：4.2在做详细介绍

干系人：

1、在准备阶段，可以询问领域专家得到一些信息

2、项目经理，该活动也是项目过程中的重要活动

3、发起人，从发起人火气一些资源，获得一些批准

输出

信息收集活动当中的时间、如何进行、目的、范围是什么，期望收集到的信息是什么，可以提前准备一些问题的列表，后勤的准备。为后续4.2具体执行收集信息做准备

内容：

1、过程：搜集和需求相关的信息4.1、4.2、4.3，内容不多，但是会涉及到很多

2、沟通：沟通相关的信息和干系人相关的活动，前提是3.2范锡仁的沟通计划和写作计划，以及沟通过程发现的问题，以及改进

Elicitarion：意在挖掘潜在的需求，或者引导除需求的信息和反馈，主意在于需要引入干系人，发掘干系人需要什么，需要BA帮助他们徐思考和梳理

3.5 分析工作的效果：有的组织有定期的绩效考核，还有一些非正式的评估绩效，包括书面、口头的形式

收集定量的评估定义，包括一些已经存在的考核定量内容，也包括定性的考核内容，可以通过和BA有交集的干系人，灵粮的内容可以使用报告的统计内容，考虑内容有：

1、工作的准确性、完整性

2、专业知识的撞我成都

3、工作的有效性

4、组织的支持程度

5、重要性

6、战略性

7、时效性

根据收集的指标进行分析：可能会有老板进行分析，也有可能有专门的组织进行分析

基于分析的结果，发现一些问题，基于根本原因需求改进措施：

1、预防性的措施，再评估和预测过程中发现的问题

2、修正型的措施，当问题发生时，需要进行的问题修正

3、改进型的措施，当问题需要完善

在制定计划刚开始的阶段，问题不太可能进行修正和改进，但是随着需求的进行，那么需要进行进一步的改进和修正

3.5识别在BA工作当中的一些绩效，并且寻求一些改进，要考虑计划和实际的一些偏差，在组织层面制定一些考核工作的标准，有一写外部的输入，作为绩效考核的目标Performance Ojectives

输入
1、Performance Ojectives绩效目标（外部）
2、商业分析方案

哪些信息需要做管理的：

需求、需求的评估结果、设计，可选的方案都是一些信息，需要进行有效管理的，在管理过程中需要考虑的因素有：

1、信息本身的种类/量级

2、需要哪些干系人访问这些哪些信息

3、信息的变化程度和规模

4、内在的关联关系，对关系进行一个保存和维护

抽象程度/详细程度：比如需求文档的详细程度，比如需求把用例的详细程度有什么样的要求，如果过于详细，考虑是否进行拆分，和进一步细化，在过程中要考虑一下因素：

1、干系人的需要

2、分析内容本身的复杂程度

3、变化本身的重要程度，可能重要的内容可能要更详细一点

计划可追溯到方法：跟踪需求之间的关联关系，例如变更会和其他一些内容有一些关联，所以考虑要不要做，做到什么程度，有以下因素要考虑：

1、业务领域的复杂程度

2、去了解需求的数量，方式方法的选择

3、风险、价值有多大

4、成本

计划需求重用：可能会参考之前的所写的一些需求，或许可能会给其他团队作为参考，给一个比较通用好理解的明明方式，所以要为重用做一些准备，根据名称就能了解内容，使用专门的保存、分享方式，i有哪次要考虑：

1、有些需求要持续得到满足的，比如在线率的需求，可能在整个解决方案中要考察是否得到满足

2、一般的的功能，比如登陆页面，是很多场景都要用到的，可以和其他团队进行分享

保存和访问的机制（仓库）：例如在服务器上存放一个共享文件夹，翻遍信息的查看，要注意以下问题

1、谁需要访问这些信息

2、什么样的频率访问这些需求

3、在什么情况下需要进行访问，可能是内部团队进行访问，但是外部团队是没有办法访问的，因此可能要导出来进行分享

4、组织标准，使用安歇工具进行保存和分享

定义需求的属性：比如有识别号、作者、复杂程度、优先级、复杂程度、来源、风险、目前的状态是否得到批准，紧急程度等等

3.4计划BA信息管理，相比3.3来说。3.3是与决策相关的方法，3.4更多的对常规性的需求管理的工作，确保所有BA相关的信息进行保存、分享，在这些信息的生命周期中，得到有效的保存维护和分享

输入：3.1计划有哪些活动、3.2干系人计划（对干系人进行沟通需要那些干系人掌握i哪些信息）.3.3（需要对信息进行审查和批准）