【读书笔记】《有效需求分析》

---

---

一、软件需求全景图

1.业务驱动的需求思想

• 抛开具体的技术实现，站在用户的视角审视用户想要解决的问题、想要达成的业务目的。
• 要做好软件需求工作，业务驱动需求思想是核心。传统的需求分析是站在技术视角展开的，关注的是“方案级需求”；而业务驱动的需求思想则是站在用户视角展开的，关注的是“问题级需求”。

案例一：

在这个例子中，小孩提出“要吃饼干”，这实际上是一个 方案级需求。由于家里没有饼干，因此妈妈认为孩子提出了一个不合理的需求，于是想办法让小孩放弃这个需求。而老余则快速意识到了这个方案级需求背后真实的 问题级需求 是“饿了”，因此找到了可行的解决方案——吃面包，小孩的需求也得到了满足。——挖掘根本需求

---

$$变更／优化型需求分析任务执行指引$$

如果基于一个目的不清晰、实现方案相当明确的需求进行开发，一旦开发成本比较大，就极易出现执行变形，严重的时候甚至还会使客户关系恶化……

• 客户是问题专家，而非解决方案专家，他提出的方案未必能够完美地解决他遇到的问题

模糊 => 清晰

1. 头脑风暴法分析需求
2. 结合背景，整合现有需求（不论模糊还是清晰）
3. 澄清需求中的模糊点，深层次挖掘需求——避免未来需求不断以“挤牙膏”的形式提出

• 明确业务术语的定义，是做好数据需求的基础。
• 在建议解决方案时应该站在用户的立场，说明这种方案的优点
• 需求分析师是“问题解决者”，而不是简单的需求传递者。
• 只挖掘问题，不挖掘方案——因为在问题级的探讨，客户是理性的；而在方案级的探讨，客户是感性的。——挖掘需求的同时要注意避免需求蔓延——防止 客户从中获得的利益与价值不容易呈现，从而导致客户满意度难以有效提升。

---

2.组织应用类软件系统需求全景图

3.价值需求主线

价值需求

• 整个软件系统为客户解决了什么问题、创造了什么机会
• 对于系统而言，最关键的干系人有哪些
• 各个重要干系人对系统的关注点是什么？有哪些担心（阻力点）

详细需求

• 为了给客户提供业务、管理、维护支持，需要提供哪些功能？
• 系统所涉及的问题域中有哪些数据，之间是何关系？
• 所处的业务环境会带来哪些约束和质量要求？

子问题域分解

• 分解的目的在于控制复杂度
• 哪里有分解，哪里就有接口
  

功能主线

• 避免陷入树木而忽略森林

• （1）通过系统固化、优化业务流程，提升流程执行效率、节约成本、降低风险等。

• （2）通过系统拓展业务的渠道，使其延伸到电话、互联网、移动互联网等通道上。

• （3）通过系统将个人知识、能力转化为组织知识、能力。

• （4）通过系统实现数据的信息化，辅助管理、决策。

业务支持

首先是固化、优化业务流程，因此业务流程是核心；
其次是业务延伸到新的通道（诸如手机端），这从本质来说也是一种流程的重构，核心还是业务流程；
最后是将个人能力转化为组织能力，而这种能力存在于具体的业务场景中，因此“专家场景”是核心。

从灰盒子视角回答四个问题：

• 根据目标和干系人关注点，系统涉及哪些业务流程？
• 这些业务流程是如何定义的，需要优化吗？
• 系统对流程中所有业务场景都要支持吗？还是只支持一部分？
• 有哪些业务场景的工作经验需要模型化？

梳理业务支持需求关键是四个任务：

• （1）业务流程识别，为各子问题域生成一个《业务流程列表》，列出系统涉及的业务流程；
• （2）对各业务流程进行分析与优化，绘制一组《流程图模型》；
• （3）业务功能识别，识别各流程中系统需支持的业务功能模型；（当涉及专家系统需求时，需要抽象出“专家场景”，也就是要通过系统模型化，以便新员工能够“复制”执行该任务的经验。）
• （4）业务功能分析，描述各业务功能的具体需求。
  

管理支持

软件系统对管理的支持，主要可以体现在三个方面：

• （1）事前风险避免，通过增加管理流程；
• （2）事中风险控制，通过“规则”和“审批”；
• （3）事后总结优化，通过“数据分析”。

前两种通常会在业务支持分析中统一处理；第三种则应该独立进行分析。

---

管理支持所需的功能——从灰盒子视角回答三个问题：

• 管理层用户希望通过系统来实现哪些管理、控制需求？
• 希望通过系统做哪些辅助决策？
• 要实现这些管理、控制、决策支持，需要哪些信息？用什么方法获得它们？
  

维护支持

维护需求——从灰盒子视角回答两个问题：

• 有谁会需要对系统进行维护？
• 他们需要执行哪些维护任务？

首先识别未来的维护用户，可能是客户自己的维护团队，也可能是开发团队自己。然后根据不同的维护用户列举出未来维护、运营相关的场景，整理成一张《维护场景列表》

数据主线

一个组织中有四个最核心的“流”：工作流、信息流、资金流、物流——数据主线，重点就在于厘清组织中的“信息流”
数据主线——从灰盒子的角度回答三个问题：

• 系统相关的问题域中有哪些业务数据？
• 它们之间是什么样的关系？
• 每个业务数据的具体构成是怎么样的？
  

非功能主线

*需求分析模板

$$表0-1变更／优化型需求分析模板$$

该模板中主要包括原始需求、问题澄清、业务环境描述、业务场景描述、业务术语说明、解决方案概述6个部分。

• （1）原始需求：说明需求是谁提出的（提出人，必填）、他属于哪个部门（客户信息，建议填）、原话是什么（原始描述，必填）；如果有需要，还可以对其进行编号（编号）。
• （2）问题澄清：这个原始需求背后的问题级需求是什么（要解决的问题，必填）、现在如何应对该问题（现状，选填）、问题描述中有需要澄清的定义吗（概念澄清，选填），以及还有相关的其他需求吗（相似问题场景挖掘，选填）。
• （3）业务环境描述：该需求未实现对谁产生直接影响（不做谁生气，建议填），这种影响的频率如何（多久生气一次，建议填），有哪些对非功能要求产生影响的因素（其他非功能需求，选填）。
• （4）业务场景描述：当需求人员或开发人员不理解该问题发生在什么样的业务场景中时，可以选填本部分。它主要包括：该需求发生在哪个业务场景中（场景名称），这个场景是怎么样的（建议采用子任务、任务变体的形式整理）。
• （5）业务术语说明：如果需求人员或开发人员对该需求中相关的业务术语有理解歧义，那么建议选填本部分。也就是列出易有理解歧义的术语名称，以及术语意义、构成等说明信息。
• （6）解决方案概述：必填，针对该问题可以有哪几种解决方案，各有什么优缺点，推荐哪种？为什么？

---

读书过程中有些地方没有读明白，期待再刷后的完善！