今日完成的事：

需求分析的步骤

梳理各部门的职能

一个系统如果涉及到很多部门，那么梳理各部门的职能能帮助我们去理解他们提出需求的原因，甚至通过了解各部门的职能反过头去质疑其他部门提出的需求。

有时候用户提需求的时候只是出于自身考虑，并没有想到其他部门，所以当需求涉及多个部门的时候，需求分析人员在需求调研阶段把各部门的职能弄清楚。

梳理业务

没有人会无缘无故去购买一个系统，对于企业而言购买系统就是想将公司的业务放在系统上去做。不同类型的企业或不同部门，业务是不一样的，业务的复杂程度决定了系统的复杂程度，若一个复杂的业务能够被梳理的逻辑清晰条理清晰，系统也不会很复杂，但前提是你很懂很懂业务。

当一个业务小白如何快速的理解业务，可以搜集业务相关的名词解释，弄懂这些名词算四分之一理解业务。每种业务都会有其特定的术语，你需要理解透每一个业务以及业务与业务的差别。

梳理信息

这需要需求分析人员懂一些技术才能梳理清楚，对需求分析人员很高要求的一个层次。对于系统的底层数据，需要梳理数据与数据的流向，数据与数据的逻辑关系，这些都梳理清楚以后，对于现在的开发或是以后的迭代都能起到很大的作用。

梳理支撑环境

业务需求以及数据都弄清楚以后，还需要考虑非功能性的需求，比如系统的硬件环境和软件环境是什么，用谷歌浏览器还是IE浏览器等。

如何去实现上面，做到以下：

· 根据组织结构梳理职能域，比如机构／部门的职能，各岗位的工作职责

· 根据职能域梳理业务元素，包括业务术语、名词解释等

· 根据业务元素梳理业务活动，如业务流程、业务环节、状态、信息等

· 根据业务活动梳理业务等内外联系，如业务协作、信息流向

· 描绘业务架构、信息架构，如用户分类、业务分类、信息分类

问自己几个问题，看看是否真正的理解需求：

1. 业务对象清楚了没有？系统的用户以及各功能模块的用户是谁是否清楚。

2. 业务流程清楚了没有？各环节的处理人以及处理动作是否清楚。

3. 业务场景清楚了没有？每个需求的业务场景是否弄清楚，所有需求的业务场景是否能连接在一起，在脑海中完整的形成一个故事。

4. 业务事项数量清楚了没有？一共有多少个需求，一共有多少种角色，一共有多少张报表，一共有多少个前置条件……

5. 跨部门的业务关系清楚了没有？这个部门与那个部门的关系以及产生的哪些业务往来是否清楚。

业务场景

什么是业务场景？

场景是我们设计功能时的一个重要参考依据。

所谓场景，就是用户在进行这步操作时所处的周围环境。

这里的周围环境包含的维度很多，比如用户的属性，年龄、身份、工作等。

场景不仅指物理环境，比如在车上、飞机上、教室里，还指任务场景，比如开空调的业务场景是因为夏天很热，需求是身体凉快不热。

任何产品都是一种物质存在，要使其有意义，就应该置其于恰当的社会环境中，而且这种环境与其他工具或人密不可分。

用户在提需求的时候，多问几个为什么，为什么要提这个需求？目前是遇到什么困难？现在是怎么做的？如果涉及到业务数量的，还可以问下量大不大？

将用户提出的需求业务场景梳理清楚后，接下来就是需要过滤用户的需求，有时候客户提出的需求并不是“真”的需求。

很多时候因为客户自己本身对业务的不了解或者对行业知识不了解，基于某些情况，客户提出一些假需求，客户提出“假需求”的情况有：

· 客户对自己本身对业务或行业上的知识不是很了解；

· 客户基于“花少的钱获得更多的功能”心理提出很多个性化的需求；

· 客户在提需求的时候有时候也会撒谎；

· 客户不知道自己要什么导致假需求的产生。

识别客户的需求到底是不是真的需求，最重要的一条是识别客户提出需求的动机，知道为什么客户会提出这个需求？（又回到业务场景的问题了）

知道客户提出需求的动机以后，多问几个为什么，如果客户在回答问题的时候前后不连贯，或者没有逻辑，这类需求往往就是假的需求。

把需求当成一个情景剧，有人物、有业务场景、有目标、有故事背景、有做事的动机、有情节等，可以用语言或者图形的方式将故事描绘出来。

功能界面

将用户的需求理解清楚后，只是脑海中或者文字的说明，需要更形象，通常是除了文字说明还需要画原型图，很难理解的需求，画出系统界面后，开发人员能一下子看明白。

功能界面需要将每个功能按钮、查询条件、交互方式、以及界面上字段的类型、取数来源、排序等都需要细化。