这个系列是我对《七步掌握业务分析》的读书笔记，作者本人是极为资深的专家，也是IIBA协会的创立者之一。对业务分析领域感兴趣的人，如果不急着去考IIBA认证的话，强烈推荐大家先阅读本书。
第6章 了解你的分析技术
1. 分类和呈现需求
2. 核心需求组件
3. 分析技术和呈现格式
4. 打包需求
从业务干系人那里引导需求，给相关方评审需求，为开发执行方呈现需求，以上这些需求都是一个需求的不同加工方式，也使需求得以从业务层面，开发层面和人机交互层面分别得以展示。
经验丰富的分析师会发现图、模型、原型、仿真和表格，比纯粹的文字更有用。业务分析师必须学习这些可视化沟通技术。
1. 分类和呈现需求
- 收集和管理需求：需求来源的形式多种多样，有电子邮件、文档、表格、报告、文件和旧需求文档等，还有一些项目信息，如会议纪要、访谈记录、突出的问题和提问清单等。因此业务分析师需要一个规范的系统组织，存储和管理这些信息。虽然有些贵，但Atlassian总的来说是一个不错的选择。
- 什么是需求：需求是干系人为了解决某个问题或达到某个目的所需要的一个条件或能力。
- 需求分类：根据国际业务分析协会（IIBA）的业务分析知识体系（BOBOKR）的推荐，我们可以把需求分类为——
业务需求: 包括业务活动、业务规则和外部交互的详细描述，他们是要业务术语来描述的，业务需求只描述完成什么（what）工作，并不关注如何（how）完成工作。包含有业务需求的项目启动组件（目的陈述、目标、风险等），和数据、过程和业务规则等核心需求组件。有时候以上这些组织起来后，也叫做业务模型。
功能需求: 功能需求描述了怎么完成工作，怎么实施业务规则，怎么与人、组织或业务系统沟通。划重点：功能需求一般都会有一个设计领域的范围描述，这是为了说明要建设的软件的边界。范围经常通过用例图及一组相关过程、特性或文字来展现，当然也可以是用户故事。
非功能需求: 某些方法论也把非功能需求称为补充需求、约束需求或服务质量需求，业务分析师和IT团队一起引导和文档化以下这些非功能需求，一般有：
-- 可访问性
-- 审计和控制
--兼容性
--效能（由投入所产生的性能）
--效率（某个给定符合所消耗的资源）
--可延展性（在下一个主要版本升级中增加特性）
--法律和软件许可
--可维护性
--性能/响应时间
--质量（如发现的差错，交付的差错比率）
--可靠性
--资源约束（处理器速度、磁盘空间、网络带宽等等）
--安全
--可扩展性（水平、垂直）
--安全性
--稳定性
--系统可用性
--可用性和学习能力
技术需求: 技术需求包括——技术架构框架、数据库定义、业务规则引擎、编程逻辑、开发对象、应用系统接口、网络架构、安全组件和方案等许多技术规格说明书的详细描述。技术需求也被称为规格说明书，基于前述的业务需求，功能需求和非功能需求而开发。甚至还包括硬件描述、数据库设计、编程标准指南、要使用的软件开发工具名、与外部系统接口的实现方式等。
2. 核心需求组件
- 需求组件为业务分析师提供了一种从内部打开需求，分组件检视的观察方法。核心的需求组件包括数据（data），过程（process）、业务规则（business rule）和外部主体（external agent）。
- 核心需求组件概述：
--数据：数据是基本组件，可以使用实体和属性去定义；
--过程：过程是业务的活动或工作，每个真正的过程都在视野数据，可以使用用例去描述过程；
--外部主体：与业务领域有交互的人、组织或系统。我们也称之为角色。
--业务规则：业务运转的约束或指南。 - 核心需求组件：属性（数据）
对于实体（数据）来说，比较好的描述方法是使用实体关系图，该技术定义了三种数据组件：实体、属性和关系（业务规则）。 -
实体是业务要管理的最重要的事情，如客户，产品，订单等。在UML或OO中，被称为对象或者类。
一个实体表的模板 -
核心需求组件： 属性（数据）
属性是进一步描述实体的信息，比如之于客户，属性可以是名、姓、电话号码等。与实体一样，属性也是名词或名词组来命名的，表示一种事物。在UML或OO中，属性也被称为对象特征或类。属性可以是强制有或者可选的；属性对于实体来说可以是唯一的或者不唯一的，也就是说可以是只属于这个实体，也可以同时适用于多个实体；属性在数量上也可以是多个，多次出现的。
一个属性的模板 - 业务规则：典型的业务规则是用一两句话描述的，他们被命名和编号，从而链接或跟踪到其他需求组件。可以是概要，也可以是详细的。有些业务分析师把业务规则看成”需求“，有些则认为是组织的约束，其实现实中两种情况都存在。
3. 分析技术和呈现格式
- 词汇表：即使业务领域的术语对你来说如同天书或外语，你也要能使用它们，而词汇表就能为你实现。仔细聆听干系人使用的术语，当出现不一致时一定要暴露出来，达成一致的使用习惯或理解。
- 工作流图：也称流程图，UNL活动图或过程地图。 古老又常用的分析技术，无需赘述。
-
实体关系图： 数据需求是由实体关系图（ERD-Entity Relation Diagram）表示的。是数据模型和可视化的表达。
实体关系图示例
ERD这样的逻辑数据模型可以促进数据复用和共享，数据稳定，模型也相对稳定，可用于其他项目的模型组件，物理数据的共享。还可以帮助识别资源是否在组织范围内。COT（Commercial Off-The-Shelf ）商业现货也依赖于数据建模表示系统底层的数据结构。
- 分解图-对业务过程建模：分解图常用于公司从战略目标到低层部门目标的分解，也可用于显示项目工作分解结构。
-
用例图： 用于展示功能需求——软件系统是如何与它的用户（角色）交互的。常用于表现系统的未来视图。
用例图示例 - 原型和仿真： 可以是屏幕布局，报告布局或数据输入表。它是软件设计的一部分，主要用来向干系人说明软件”看起来将是什么样子的“。
-
其它技术：
--实体状态转换图和UML状态机图：状态是实体行为模式的一个阶段。考虑状态有助于发现过程、其他数据和业务规则。
--用户故事
--可回溯性指标：也成为链接。是找出各个需求组件之间的关系的技术和展现方法。有助于找出需求之间的相互关系并使需求完整。
回溯矩阵
链接最常见的是CRUD矩阵，表示数据和过程之间的链接。CRUD矩阵评估每个数据组件是如何受业务过程影响的。
CRUD矩阵 -
有选择何种技术的标准吗？
不同项目和不同受众的交付物指南
项目交付物矩阵
受众矩阵的交付物
4. 打包需求
- 什么是需求包？需求包是一种组织并呈现所有需求信息的方式。创建包的时候，要根据目标受众进行剪裁。
- 建议书邀请函需求包：RFP里应该有业务需求，如果是针对软件包的定制工作，则需要包含功能和非功能需求。
-
最后给大家看下一个优秀的需求是什么样子的：完整、正确、没有歧义、可验证的、必需的。
数据需求的例子
