实战需求分析

1. 时刻抓住主线路，客户介绍的一个集合，你需要过滤把握对你有用的子集。

客户再给你讲系统的时候很可能是洋洋洒洒，介绍自己熟悉的东西，但是我们做需求的人一定要明确自己需要获取业务信息。做需求分析一定要时刻抓住主线路，可以让对方讲一些拓展的东西，但是自己一定要清楚关心的是核心业务+核心对象是什么，用户的对于核心业务+对象的意图如何，现实中又是如何操作的。

在和某航空公司的信息以及生产部门负责人谈需求的时候，他们介绍自己的业务头头是道，我们的项目经理一般都会等对方介绍完毕问道：这些业务中那些是和我们的XXX业务相关？如何相关？你们又是在现状中如何使用的？

在上图中重叠的部分是客户提供的实现范围内的需求，真实需求范围中没有重叠的部分这需要分析人员去引导客户讲出来

2. 核心问题

    a. 跟此次分析业务相关的部分，现在是如何来实现的？（已有系统，手工，还是其他方式）
    b. 数据量多大？（这里包括需要导入的历史数据，性能相关）
    c. 并发量多大？（性能相关）
    d. 系统是否要放到公网（外网）上面？（安全性相关）
    e. 对于需求分析的提交文档是否有什么要求？
    f. 对于开发过程中使用的技术，页面风格是否有什么要求，以及某些功能有约束（比如权限模块必须使用公司已有的系统的API）？
    g. 现有的系统中是否有一些功能的接口可以提供，避免二次开发（比如工作流，权限，消息机制等）。

    以上的问题不需要一次性的，或者在第一次商谈中就确认，可以找一个适当的时机，在谈到确认应该考虑到这个层面的时候来谈

3. 核心概念和核心数据的掌握

前文中我们提到了抓住核心实体对象，还有核心的概念的理解。对于比较专业的需求他都会有一些比较核心的概念，比如我们在做某航空公司的成本管理项目，这里有就有成本要素，成本项目这些概念，因为这个是和会计学相关，那么最后他们应该和科目挂钩，那么这些核心概念又是如何和科目挂钩的呢？所谓的理解概念，就是要使用我们已经理解的概念来解释核心概念，所以在捕获需求，阅读理解需求的时候一定要理解这些核心概念，不要想当然，要和客户去讨论这些需求概念，确认理解的角度是正确的。

核心概念之下的是核心数据，核心数据是指很多业务貌似纷繁复杂，其实只不过是对某一类数据信息的处理，那么这一类核心数据的识别就显得尤为重要。比如在成本系统中，发票的数据，指令对应的发料、工时以及外系统过来的财务数据，这些就是核心数据，不论怎么核算，成本怎么统计其实都是对这些数据的处理罢了。识别出这类数据对于理解系统很重要。但是能够抽象出这些数据是基于对于业务的了解，所以可以不必急于下结论，但是要不断地尝试发现。

其实需求分析的一条主线就是识别核心概念和核心数据，这两者，是要用心体会的。

4. 关于原型设计

系统的原型设计，包括UI设计一定要和系统设计的实现分开。因为真实用户其实并不关心你的实现机制，作为系统的输入设计一定尽量符合显示工作的数据原型。比如在成本项目设计中，系统的输入就是发票和出厂清单，但是实际上我们系统的设计是从项目的设计理念来出发通盘考虑系统，而且出厂清单的作用只是用来和AMICOS的系统发包计划作比较核对而已。所以系统原型/页面的设计越友好（接近实际工作环境）越好，不要把系统设计和它混淆。

5. 理解输入的用途

除了了解各个功能输入的数据的来源，还要了解输入数据的作用，有助于对于需求和设计的深入理解，甚至发现客户可能遗留和自己考虑不确定的的问题。比如在成本管理项目中工作清单的作用是什么？惊讶的发现除了比对之外没有别的作用。这个结论有些问题，后来和小组以及客户讨论，其实导入的清单还是有计算和统计的功能。这样我们的设计就需要做这样的准备。

6. 明确分析对象粒度和口径

在讨论业务的时候，粒度指的是分析实体的层级关系，比如项目-》工作包-》指令-》工卡（Task），这的工卡的粒度就是最小的，口径其实和粒度有关系，但也不完全相同，口径代表某个粒度，也可能代表的是某个内容，比如维修成本，国外的同行业计算的成本内容和机制就是国外的口径，国内计算内容和机制就是国内的口径，这种口径一致，比较才有意义。所以粒度用来描述对象实体，口径多用于比较。

7. 对象间的关系的识别

这也是我此次做分析做的最需要改进的地方。我在总结PCC的表结构的过程中明明通过CldFrmOrderClassCostType窗体已经总结到了
“记录各种Order对应那些成本项目”
但是非常遗憾的是我们没有注意到这个窗体对应的表其实是在描述对象间的关系（Order和成本项目），结果导致对于系统的理解和认识出现了偏差。

做需求分析第一步是识别对象，理解对象，第二步就是搞清各个对象间已经存在的关系，是直接关系还是间接关系。有对象关系的意识之后，你再去看各种信息，就会有收获。

8. 对于核心概念的理解

要有意识的对于概念进行识别，比如开会讲述的“现金流，成本流”的概念，就被我忽略，结果导致需求理解的不够透彻，甚至导致了我认为预提不属于成本流，其实发票是现金流，预提就是成本流。

 9. 明确需求分析的方向

了解现在的流程，需求分析的结果不是将部分实现信息化，而是尽量采用信息化的方式重构工作方式，如此理解和分析才不至于偏差。--有感于曾经误解预算审批流程是一批人提交了一个版本，然后预算管理员打个电话，告诉他们那些需要改，完事了。但是如果信息化的结果是使得整个系统的数据准确性，完整性更不稳定，则不要将其信息化，比如预算申报到财务系统，因为需要通过数据中转站中转，而且还需要提交人到财务系统再去确认，其过程和自己手动填报财务系统其实没什么区别，而且数据的准确性还很难保证，这种情况下就不要将其信息化。