《七步掌握业务分析》读书笔记五

了解你的分析技术

需求分析：从业务干系人那里引导需求、分析需求、把需求呈现给业务干系人评审、把需求呈现给方案团队执行。

分类和呈现需求

收集和管理需求

什么是需求？

需求是干系人为了解决某个问题或达到某个目的所需要的一个条件或能力。

为什么要需求分类？

• 使需求更有条理，易于查找
• 根据受众的不同把需求分别存放，正式文档化和呈现需求的唯一理由是为了沟通和确认理解。
• 复用性

为组织需求开发一个系统

• 是否把不同类型的需求分开？
• 按照什么顺序收集需求？
• 谁将评审需求？
• 每条需求将如何使用？
• 需求之间相互关系如何？
• 是否要为不同干系人以不同方式呈现同一需求？
• 哪条需求可以复用？

推荐的分类系统

业务需求

业务需求是为了完成业务使命所需要的信息、业务活动、业务规则和外部交互的详细描述。
业务需求关注业务问题、业务需要和业务目标，不关心它们将被怎么解决和实现。
业务需求包括项目启动组件（目的陈述、目标、风险等）和数据、过程和业务规则等核心需求组件。它们共同组成了业务的全景图，或称为业务模型。

功能需求

功能需求描述了怎么完成工作。怎么实施业务规则？怎么与人、组织或系统沟通？当软件来支持业务需求时，功能需求描述了最终用户所看到的系统是“什么样子的”。
对于没有软件支持的业务需求，功能需求包括员工的流程、表格、工作流、策略文档和指南，这些描述了工作是怎么完成的。

非功能需求

方案需求一般被分为功能需求和非功能需求。某些方法论也把其称为补充需求、约束需求或服务质量需求。这些需求只在开发软件系统时创建，它们是软件的需求，不一定要和特定业务需要、功能或行为有直接关系。这些需求是系统为了满足用户需要必须满足的需求。例如：

• 可访问性
• 审计和控制
• 兼容性
• 效能（由投入所产生的性能）
• 效率（某个给定负荷所消耗的资源）
• 可延展性（在下一个主要版本升级中增加特性或继续定制）
• 法律和软件许可问题
• 可维护性
• 性能/响应时间
• 质量（发现的差错，交付的差错）
• 可靠性
• 资源约束
• 安全
• 可扩展性
• 安全性
• 稳定性
• 系统可用性

技术需求

技术需求包括技术架构框架、数据库定义、业务规则引擎、编程逻辑、开发对象、应用系统接口、网络架构、安全组件和方案等许多技术规格说明书（技术需求）的详细描述。

核心需求组件

核心需求组件概述

数据（实体和属性）

数据时业务完成工作所使用的信息，它是构建系统的基本组件。

过程（用例）

过程是业务所完成的活动或工作。它们是构建系统的第二个基本组件。每个真正的过程都使用数据，每个重要数据都至少被一个过程所使用。

外部主体（角色）

外部主体是与所讨论的业务领域有交互的人、组织或系统。他们是客户、政府、厂家、供应商、其他部门或者外部软件硬件系统。

业务规则

业务规则是业务运转的约束或指南。
当你确认、命名并定义数据、过程和外部主体后，你可以使用相关的组件名来撰写业务规则。

核心需求组件：实体（数据）

实体关系图技术经常用于分析数据需求。该技术定义了三种数据组件：实体、属性和关系（业务规则）。
实体表的模板

 

核心需求组件：属性（数据）

属性的模板
属性是否具有唯一性：是否可用来查询、搜索并找出特定数据集合。客户号的唯一性。
属性是否强制：客户电子邮件是否是强制的？是否有多条业务规则来搜集数据。
属性是否重复：某个属性会多次出现吗？客户的多个电话号码？围绕重复属性引导需求。

 

核心需求组件：业务规则

   业务规则是主导工作完成形式的一个条件。分析师通过提问把规则明确地提炼出来并形成清晰的书面文字。

业务规则是一个关系需求组件，因为它们常常把其他需求组件联结到一起。当规则“超过50美元的订单可以免费送货”被提炼出来时，它就把几个其他需求组件联系起来了：数据（订单总量、送货费用）、过程（计算送货费用）和外部主体（客户、送货人）。
是否把业务规则看成“需求”并不重要，重要的是在业务分析中要引导、文档化并确认业务规则。它们必须包含在需求包或一个单独文档中。

找出业务规则：定义了业务的约束或规则，所以可把它们看成决策点。每条规则都帮业务干系人作出决策。规则要被清晰地表达出来，确保决策的一致性。（昨天那位售货员告诉我可以退回这个货品）
在需求研讨会中，常常出现两位业务干系人认识到他们对同一条规则有不同理解。把这些未知的差异展现出来时分析的价值，业务领域也因此随即改进了沟通并提高了一致性。
通常，业务规则实在围绕过程和数据的需求引导过程中暴露出来的。