菡萏如佳人需求分析概述
本篇主要介绍的是如何进行需求分析。主要介绍需求分析的大致步骤和结构，大致包含18个需求分析过程中要完成的任务。
本篇不会细致的讲解具体的操作，主要是介绍整体结构，后续会对每个类型进行专题的详细分析
业务驱动需求思想
要做好软件需求工作，业务驱动需求思想是核心。传统的需求分析是站在技术视角展开的，关注的是方案级需求；而业务驱动的需求思想则是站在用户视角展开的，关注的是问题级需求。
- 方案不是需求
- 优化型需求分析任务执行指引
- 优化型需求分析任务产物
软件需求全景图
组织应用类软件
对于变更／优化型需求，我们需要澄清问题（Why）、了解背景（场景——功能，术语——数据，环境——质量）；这样的逻辑对于一个项目、产品的需求也是类似的。
从宏观角度来看，组织应用类软件系统需求可以分为价值需求（目标场景、干系人关注点、干系人阻力点）、详细需求两大部分
价值需求主线包括目标场景，干系人关注点、阻力点两个角度；而详细需求则由行为需求（也称功能需求）、数据需求、非功能需求三条主线组成。
价值需求主线
简单来说，就是从黑盒子视角回答：
- 整个软件系统为客户解决了什么问题、创造了什么机会
- 对于系统而言，最关键的干系人有哪些，各个重要干系人对系统的关注点是什么？
- 有哪些担心（阻力点）
价值需求是组织应用类软件系统需求的灵魂和方向,但是实际情况是做的都很薄弱。
在目标分析方面，经常会看到很多放之四海而皆准的、定性的描述，如“打造一套先进的信息化系统，有效地推进管理的提升……”
目标分析方面只是做得不到位，那么在干系人识别与分析方面则经常是干脆直接省略了
详细需求
价值需求是方向，是成功的标准。那么什么是详细需求呢？
简单来说，就是从灰盒子视角完成三个主题的分析：
- 为了给客户提供业务、管理、维护支持，需要提供哪些功能？（功能需求）
- 系统所涉及的问题域中有哪些数据，之间是何关系？（数据需求）
- 所处的业务环境会带来哪些约束和质量要求？（非功能需求）
一般比较复杂系统不会直接从整个系统角度来进行功能、数据、非功能主线的梳理，需要先进行系统分解，划分成问题子域，逐个分解。
功能主线
在整理功能主线的时候，我们需要站在更宏观的角度看，一个组织应用系统无外乎包含如下几个方面：
- 通过系统固化、优化业务流程，提升流程执行效率、节约成本、降低风险等
- 通过系统拓展业务的渠道，使其延伸到电话、互联网、移动互联网等通道上
- 通过系统将个人知识、能力转化为组织知识、能力
- 通过系统实现数据的信息化，辅助管理、决策
前3种实际上可以归结为一类，用于业务支持；而第4种则是另外一类，用于管理支持；
业务梳理过程中，应该以业务流程为主线作为分析入手点，而不是从人做过角度，因为系统要支持的是业务，而在业务领域中通常是先有业务，再明确岗位及岗位职责
软件系统对管理的支持，主要可以体现在三个方面：
- 1 事前风险避免，通过增加管理流程
- 2 事中风险控制，通过规则和审批
- 3 事后总结优化，通过数据分析
系统投入使用之后，还需要对其进行维护，最典型的包括初始化、配置、排错等，而这些运营维护场景也需要有相应的功能来支持。
数据主线
在一个组织中有四个最核心的流：工作流、信息流、资金流、物流。而在一个组织应用类软件系统中，资金流和物流是不会真实出现的，而是以信息流的形式呈现.
功能主线代表的是工作流，数据数主线代表的就是信息流
数据主线的关键任务有两个：一个是“领域建模”，也就是用领域类图的形式刻画出问题域中所有业务数据实体之间的关系；另一个是对每个业务数据实体进行“业务数据分析”，详细定义数据构成与推演过程。
非功能主线
由于系统部署、应用的环境不同，会带来不同的约束、不同的质量要求
这部分的需求分析，在很多实践中存在很大的缺陷，大部分产品不懂技术，很难写出恰到好处，普遍存在下列问题：
- 定性描述，直接写“高可靠、高易用、高灵活……”之类的要求，而实际上并没有传递出任何有效的信
- 盲目定量，拍脑袋写出量化指标，写出一些客户、需求人员、开发人员都无法清晰理解的似是而非的量化要求
- 以偏概全，诸如“所有查询都在7秒内响应”之类的全局性描述，这种描述缺乏实际有效的落地性
实际上我们可以根据系统的特点，决定非功能需求的分析深度。也就是通过质量树梳理的任务，找出最为重要的质量类型，并以一张关键质量列表呈现
对于非功能需求的分析工作，最核心的是逆向思维，从威胁入手
需求分析小结
需求分析一般包含了18项任务，有任务就有输出，它们关系如下：
在实际的需求分析实践中，应该根据实际的产品、项目特点，明确出关键的需求主线，以对其进行合理的剪裁
最后上个以上任务的全景图，每个产品再做需求分析的时候，脑海中都应该有这样的一个结构：
