软件需求全景图
1. 业务驱动需求思想
要做好软件需求工作，业务驱动需求思想是核心，不应该从技术视角展开，技术视角关注的是“方案级需求”；业务驱动的需求思想是站在用户视角关注的是“问题级需求”。需求分析师是“问题解决者”，而不是简单的需求传递者。
1.1 方案非需求
方案级需求是指直接提出解决方案的需求，没有明确需求背后的真实问题，容易出现需求设计方面的局限性，容易忽视解决问题的目的性。客户是问题专家，而非解决方案专家，他提出的方案，不一定能很好解决问题。
1.2 变更/优化型需求分析任务执行指引
一般用户提出的变更/优化型需求直接提出“方案级需求”，因此我们需要还原出“问题级需求”。分析过程如下图所示：
image.png
1.2.1 澄清问题
用户的原始需求分为方案级、问题级，如果需求是问题级直接进入下一步（了解背景），如果是方案级需求进行问题的澄清。
image.png
1.2.2 了解背景
根据实际需要细化一下内容: 场景（功能）、术语（数据）、环境（质量）。
场景（功能）
image.png
术语（数据）
image.png
环境（质量）
image.png
1.2.3 建议并确定解决方案
image.png
需求挖掘是只挖掘问题，不挖掘方案。在问题级的探讨，客户是理性的；而在方案级的探讨，客户是感性的。
1.3 变更/优化型需求分析任务产物
1.3.1 变更/优化型需求分析模板
image.png
2. 组织应用类软件系统需求全景图
从宏观角度看，组织应用类软件系统需求可以分为价值需求和详细需求两部分。
2.1 价值需求
价值需求包括目标场景、干系人关注点、干系人阻力点。
2.2 详细需求
详细需求则由行为需求（也称功能需求）、数据需求、非功能需求三条主线组成。
3. 价值需求主线
价值需求分析关键在于执行好目标分析、干系人识别、干系人分析三个任务，如下图所示：
image.png
4. 详细需求
详细需求从灰盒子视角分析：“为了给客户提供业务、管理、维护支持，需要提供哪些功能？”、“系统所涉及的问题域中有哪些数据，之间是何关系？”、“所处的业务环境会带来哪些约束和质量要求？”，即功能需求、数据需求、非功能需求三条主线。梳理详细需求可以先沿着三条主线理清脉络、识别出最小粒度的需求单元，然后为识别出的需求单元填充具体的需求细节描述。
4.1 子问题域分解
为了控制复杂度，我们应该先从业务角度，按系统涉及的不同子问题域进行分解，然后再逐一分析。
image.png
4.2 功能主线
系统功能的存在包括以下几个方面：
- （1）通过系统固化、优化业务流程，提升流程执行效率、节约成本、降低风险等。
- （2）通过系统拓展业务的渠道，使其延伸到电话、互联网、移动互联网等通道上。
- （3）通过系统将个人知识、能力转化为组织知识、能力。
- （4）通过系统实现数据的信息化，辅助管理、决策。
功能主线的梳理可以从业务支持、管理支持、维护支持三个角度展开，如上（1）、（2）、（3）属于业务支持，（4）属于管理支持。
4.2.1 业务支持
梳理业务需要的功能需要回答4个问题:
- (1) 根据目标和干系人关注点，系统涉及哪些业务流程？
- (2) 这些业务流程是如何定义的，需要优化吗？
- (3) 系统对流程中所有业务场景都要支持吗？还是只支持一部分？
-
(4) 有哪些业务场景的工作经验需要模型化？
image.png
4.2.2 管理支持
软件系统对管理的支持体现在以下几个方面：
- (1) 事前风险避免，通过增加管理流程；
- (2) 事中风险控制，通过“规则”和“审批”；
- (3) 事后总结优化，通过“数据分析”；
前两种通常会在业务支持分析中统一处理；第三种则应该独立进行分析。
要梳理管理支持需要的功能需要回答如下问题：
- (1) 管理层用户希望通过系统来实现哪些管理、控制需求？
- (2) 希望通过系统做哪些辅助决策？
-
(3) 要实现这些管理、控制、决策支持，需要哪些信息？用什么方法获取它们？
image.png
4.2.3 维护支持
维护支持需求需要回答的两个问题：
- (1) 有谁会需要对系统进行维护？
-
(2) 他们需要执行哪些维护任务？
image.png
从维护场景的角度进行分析，如不是“日志”功能，而是“排错”场景。
4.3 数据主线
需要回答的问题如下：
- (1) 系统相关的问题域中有哪些业务数据？
- (2) 它们之间是什么样的关系？
-
(3) 每个业务数据的具体构成是怎么样的？
image.png
4.4 非功能主线
需要回答的问题：系统相关的外部环境会带来什么样的约束和质量要求？
对于非功能需求的分析，最核心的是逆向思维，从威胁入手。基于《关键质量树》中的每种质量类型，识别出业务环境中可能产生的破坏力大、出现概率高的威胁场景，使用《目标-场景-决策表》描述出来。
image.png
4.5 补充性内容
补充性内容关注的是约束和规则，需要单独进行更加详细的分析，如下图所示：
image.png
当系统有大量的约束时，需要强化约束分析。当系统是一个强规则，规则大、规则很复杂时，就可以考虑单独作为一个主题来分析，否则只可以在流程分析、业务功能分析、领域建模时附带对规则进行分析即可。
