认识了管理软件后，再来看看什么是需求分析——本书特指面向管理软件的需求分析。本节是对全书内容的概括，可以让读者在准备阅读全书前对本书有个概要了解，内容有些抽象，读者在阅读过程中如果觉得有任何困难，都可以直接跳到下一节，在读完全书后再阅读本节的内容，或者，即使不再阅读也不会有什么影响。
软件开发一般包括可行性分析、需求分析、软件设计、软件开发、软件测试、软件实施、软件服务等步骤。需求分析是软件开发的一个步骤，主要作用是充当软件研发与客户之间的桥梁，主要包括对客户的信息化需求进行分析，将客户不规范的、随意的需求，转换成规范的、严谨的、结构化的需求，将客户不正确的需求转换成正确的需求，将客户不切实际的需求转换成可以实现的需求，将客户不必要的需求砍掉，将客户漏掉的需求补上，等等。
本书所说的需求分析包括需求获取、系统规划、软件开发设计、软件变更设计等工作，以下案例说明了需求分析工作的主要内容。
案例：需求分析工作的主要内容
小王是某软件公司的需求分析师（小王运气不错，接下来，他会成为本书所有案例中的首席需求分析师）。最近公司刚签了一份软件开发合同，需要给一家企业开发一套库存管理系统用以管理该企业原材料、半成品、成品三个仓库的储存物料，小王负责这个项目的需求分析工作。
在到企业现场之前，他先准备了一份需求调查问卷发给各个仓库保管员与仓库会计，获得答卷后他做了仔细研究，觉得自己对这几个仓库的管理已经有了初步理解。然后他来到企业工作现场，收集了仓库用到的所有单据，如入库单、出库单、验收单等，分析这些单据后他搞清了仓库目前的信息处理情况，然后跟分管仓库的企业副总、物流经理、保管员、仓库会计做了单独的访谈，获得了他们对信息化管理的想法。
需求调研完成后，小王进行了系统规划。有些需求明显超出了项目范围，需要做控制，如副总提出能否在系统中管理生产任务，明显超出了这个库存系统的范围；有些需求，没有人提出来，但为了仓库的信息化管理是必需的，小王建议加进去，如仓库每个月给财务的结存报表，有了系统后明显不应该再由人工做这件事了。经过整理、讨论、沟通、说服等过程后，小王最终跟客户确定了需求。根据确定的需求，小王跟客户讨论确定了未来在信息化管理系统下的管理方式，包括相关人员应该如何工作，各岗位与信息化系统相关的工作职责，使用者的计算机终端如何布置，在什么情况下需要使用软件，等等。
然后小王开始进行软件设计。他先根据软件需要处理的信息，以及信息流动的过程，设计了数据模型，确定本系统需要哪些业务实体，每个实体包括哪些属性，各个实体之间的关系等；然后，他进行功能建模，确定需要提供哪些功能点，每个功能点包括哪些子功能，每个功能的业务规则等；接下来，他使用一款原型设计工具进行软件功能界面的设计，在设计的过程中，他安排时间给相关用户讲解自己的设计思想，告诉用户在工作过程中需要如何使用本软件，一边听取用户的意见，一边修改；另外，遇到一些技术上不容易实现的地方，还会征求开发人员的意见，经过几次外部、内部评审会后定稿了；最后，他根据设计成果撰写了原型说明书。
小王将数据模型、界面原型、原型说明书交给研发部门据以开发。
软件开发完成上线后，用户提出有些功能不符合管理要求，需要修改，提出了需求变更要求，小王根据用户要求设计了需求变更解决方案，撰写了需求变更说明书，交给研发部门修改软件。
需求获取就是通过需求调研获取用户对信息化的需求。常用的需求调研方式包括观察法、体验法、问卷调查法、访谈法、单据分析法、报表分析法、需求调研会法。这些方法在实际工作过程中需要灵活运用，不同的企业、不同的部门、不同的岗位、不同的业务都有可能导致调研方法的变化，不可生搬硬套。
1.观察法
通过观察用户的工作过程，理解用户业务，从而获取用户关于信息化的需求。例如，可以通过观察仓库保管员的入库、出库过程理解仓库物料的出入流程。
2.体验法
调研者亲自参与工作，通过体验用户的工作，理解用户业务，从而获取用户关于信息化的需求。所谓体验，就是去学习用户的工作，然后独立或者在指导下真正参与用户所从事的工作。例如，可以通过参与收银工作理解商店收银员的收银流程。体验法可以非常深刻地理解用户业务，但代价较大。
3.问卷调查法
通过发布调查问卷，由用户填写问卷的方法获取需求。这种方法由于需要较高的问卷编写水平，而回答的人也很少会在认真仔细思考后作答，效果并不好，用得不多。当需要快速、概略性地了解某业务时，可以考虑使用这种方式。
4.访谈法
通过与用户面对面的交谈理解用户业务，获得用户需求。访谈可以非常正式，有访谈稿，有预约，有精心准备好的会议室等；也可以非常随便，在餐桌边，在电梯上，在电话中，都可以进行一次访谈。这是使用得最普遍的需求调研方式。
5.单据分析法
通过分析用户现有纸质单据获得需求。由于我们开发的软件主要就是用来管理企业信息的，而在没有信息化系统时，单据体系本身就是企业的信息系统，只是没有电子化而已，所以分析单据相当重要，如果设计的软件承载不了这些单据所承载的信息，往往就意味着在软件使用过程中会有大量的麻烦在等着你。
6.报表分析法
通过分析用户当前使用的报表获取需求。报表往往是信息的集大成者，在电子化的信息系统中如此，在非电子化的信息系统中也是如此。报表一般都是管理层用的，理解报表就是理解管理者的管理思想，通过刨根问底地研究当前报表中的每一个数据项的来源，可以深刻理解管理层对信息的要求。
7.需求调研会法
通过召开需求会议获取需求。当需要讨论的需求问题牵涉到的相关人员较多时可以组织需求调研会，可以在会议上理清流程、确定分工、调和利益等。由于牵涉的人员较多，并且可能有企业高层领导参加，在召开需求调研会时需要认真组织，认真准备，否则不但可能搞砸，还有可能让自己威信扫地，给后面的工作带来不便。
获得需求之后，需要根据需求进行系统规划，系统规划的过程就是根据用户的需求规划企业的信息化管理体系的过程。
1.需求确定
系统规划的第一步是对用户的需求进行校正。要知道用户的需求并不总是正确的，我们做软件追求的是“实现用户正确的需求”，对于不正确的需求要坚决剔除。不正确的需求包括很多方面，例如，用户的需求技术上实现不了，用户的需求没有必要，用户的需求重复，用户的需求超出项目范围，等等。另外，在很多时候，由于用户对信息化工作并不了解，根本不知道如何提需求，或者好多工作中必不可少的需求都想不到，这时候还要引导用户提出他想不到的需求。
2.整理需求
需求确定后需要将需求用文档整理清楚，本书主要介绍了需求调研报告的编制方法以及业务流程图的绘制方法。
3.系统蓝图
在进行软件开发或选型之前，需要对未来的信息化管理工作有个总策划，我们称之为系统蓝图，这个“系统”并不仅仅指软件系统，而是指相关业务的整个信息化管理体系。需要策划企业在未来有了软件系统后相关人员如何工作，业务如何运转，流程如何推动，管理如何进行，等等。不可能所有的工作都经过软件系统，需要确定哪些人使用软件系统，哪些工作经过软件系统。需要决定企业人员在工作过程中如何在软件内外切换，每个岗位跟软件相关的工作场景是什么，确定每个人在什么情况下使用软件处理业务，怎么处理，对每种异常情况是不是有处理预案，等等。
系统蓝图策划后要决定使用什么方式实施，如果是在甲方工作，那么有两种方式可供选择，一是内部开发，二是采购；如果在软件公司工作，一般实施方式在售前阶段已经确定，是使用现成的软件产品，还是根据客户要求开发，等等。本书主要讲述如何根据要求开发。
我们使用的是关系型数据库，数据建模就是设计数据库的表结构，这项工作可以在功能设计之前，也可以在功能设计之后，也可以同时进行，不同的团队有不同的工作方式。一般来说，越是复杂、大型的系统，数据建模工作越重要，也越应该尽早进行。良好的数据库结构可以让数据流清晰，可以降低功能设计与开发的难度，特别是一旦发生了需求变更，可以灵活应对。对软件开发有点儿经验的人都知道，一旦软件投入使用，修改数据库结构是非常致命的。
1.实体关系
所谓实体，可以理解为可以看得见摸得着的事物的种类，如员工、供应商、原料等。注意，数据库设计所说的实体是事物的种类，不是个体，“员工”是一种实体，而“张三”只是这种实体下的一个实例。每一种实体都有若干属性信息，如“员工”实体，包含工号、身份证号码、生日等各种属性。
在进行数据库设计之前，首先要分析好本系统需要管理哪些实体，这些实体的关系如何。相信大部分读者都知道实体关系图（E-R图），这个工具就是用来分析实体关系的，本书以实战为宗旨，不会在这方面说得太多，但并不表示这方面的知识不重要，相反，在进行数据库设计时，它应该始终在脑中盘旋。
现实世界中实体之间的关系一般有三种：一对一，一对多，多对多。
一对一的关系：如果实体A与实体B是一对一的关系，那么表示实体A中的一个实例，在实体B中或者没有实例，或者只有唯一一个实例可以与之对应，并且，实体B中的一个实例，在实体A中也是或者没有实例，或者只有唯一一个实例可以与之对应。
一对多的关系：如果实体A与实体B是一对多的关系，那么表示实体A中的一个实例，在实体B中可以对应多个实例，而实体B中的一个实例，在实体A中只能对应一个实例。
多对多的关系：如果实体A与实体B是多对多的关系，那么表示实体A中的一个实例，在实体B中可以对应多个实例，而实体B中的一个实例，在实体A中也可以对应多个实例。
在现实业务中，一对一的关系其实非常少，一对多的关系也不多见，大部分情况下都是多对多的关系。
2.范式
所谓范式，是指数据库中的表满足的准则。
第一范式，所有表的属性（在数据库中，属性就是字段，这两者是同义词）不可分。这个大概是历史遗留问题，对于关系型数据库管理系统来说，表的属性都是不可分的。
第二范式，所有表的非主属性依赖于主属性。这个可以理解成所有表都需要有个关键字，只要有关键字自然就满足了第二范式。
第三范式，所有表的非主属性只依赖于主属性。这个可以理解成，所有非主属性不会依赖于其他非主属性。假设有个订单表管理销售订单，在这个表里面存储客户信息时（订单号为主属性，客户依赖于订单号），只要存储客户代号就可以了，不要把客户名称也存储在这里。
BC范式，这是第三范式的补充，针对那种主属性有多个字段的表，所有非主属性依赖于主属性，但不能只依赖于主属性的一部分字段。
在设计数据库时，一个重要的思想是，不能违反范式，如果违反范式，那么要有这么做的充足理由，并且对后果有清醒的认识。
3.数据库设计
数据库设计就是设计本软件在数据库中需要哪些表，这些表有什么关系，每个表包括哪些字段等。
表：表是根据实体设计的，但要知道，数据库中的表跟实体之间是有本质区别的，现实世界中的同一实体，在数据库设计时可能会根据业务要求设计多个表来表达它，因为在不同的业务场景中，需要处理、保存的属性信息区别很大；也有可能在现实世界中的多个实体，在数据库设计时只设计一个表来表达它，因为虽然这些实体牵涉到不同的业务场景，但需要处理、保存的属性信息相同。
表的关系：数据库中表的关系有两种，一对一与一对多。数据库中的表是没有多对多的直接关系的，一般情况下，现实业务中一个多对多的关系会被转换成数据库中的两个一对多的关系。数据库中表跟表之间的关系绝大部分都是一对多的关系，在数据库中通过在“多”表中建立外键（Foreign Key）来建立这种关系。一对一关系在数据库设计中出现得不多。
字段：对字段的处理比对表、关系的处理要简单得多，无非就是根据业务上需要处理的信息决定在表中设计哪些字段，根据信息的内容决定使用什么数据类型，需要的字段长度等。另外，即使字段设计出了问题，对未来工作的影响面也会小得多，一般不会像表与表关系出问题那样伤筋动骨。
数据字典：数据建模完成后，需要有文档对这个数据模型进行详细说明，这就是数据字典应该充当的角色。数据字典需要描述的内容主要包括：这个数据模型中有哪些表，每个表包括哪些字段，每个字段的类型、长度、取值范围是什么，哪些字段是外键关联字段，对字段值有没有什么特殊要求，等等。
软件的功能，从本质上说就是对数据进行输入、加工、输出的过程。对于面向数据库的软件，由于是以数据库为核心的，可以理解为两个方面，一是数据的收集与处理；二是围绕数据库对其中的数据进行的4大操作，即增加、删除、修改、查询，简称增删改查。
1.需求用例
需求用例是指用户通过软件解决特定问题、完成指定任务的方式与步骤，以及用到的各种约束、规则等。一个用例，往往对应着用户需要完成的某个明确而具体的任务。一个完整的用例，一般包括用户、前置条件、后置条件、主场景、扩展场景、规则等方面。在实际工作中，不同的团队有不同的要求，有些团队，对需求用例的编写要求非常高，需要仔细描写每一个应用场景，而有些团队或项目的要求就非常简单，甚至根本不需要进行需求用例的分析、编写就直接进入了功能点设计工作。
2.功能建模
所谓功能建模，指根据系统规划的要求设计功能构成模型，确定系统由哪些功能构成，每个功能应该输入什么，经过功能处理后应该输出什么，每个功能又包括哪些子功能，不断分解下去，直到最底层。
功能点：本书所谓的“功能点”，指可以提供给用户完成某一特定任务的功能组合，例如“客户档案维护”、“物料基本信息管理”等，跟研发人员所说的某某类可以提供某某功能是完全不同的两个概念。可以将其看成是传统的功能菜单，大部分情况下可以简单粗暴地认为一个菜单算是一个功能点，当然，并不是所有的功能点都是有功能菜单对应的，例如某些固定时间触发的调度功能，某些给第三方调用的接口等。
原子功能：一个典型的原子功能包括从数据库或界面获得数据，经过加工处理后提交到数据库，再将处理结果反馈到界面这样一个过程。一般来说，原子功能在执行过程中包括获得数据，处理数据，提交结果三个方面。当然，并不是每个原子功能都包括这三个方面，有些功能只要从界面获得数据，不需要经过数据库，有些功能将处理结果直接保存到数据库，不需要反馈到界面，有些简单功能几乎没有任何运算处理的过程。
划分功能：进行功能设计首先要做的事情是进行功能划分，即设计者试图通过哪些功能组合，来解决用户的问题，从而达成企业信息化管理的目标。在这个阶段主要考虑这个软件系统会包括哪些功模块，功能模块由哪些功能点组成，每个功能点包括哪些子功能，每个子功能包括哪些原子功能，每个功能需要输入什么数据、如何处理、输出什么数据，哪些用户使用这些功能，使用这些功能是为了解决什么问题，怎么使用这些功能等。
3.功能优化
可以从灵活性、可重用性、高效性三个方面考虑如何对功能进行优化。
灵活性的优化，可以从这几个方面着手：能不写死的地方不要写死；能不用的规则就不用；尽量兼容一些不明确的需求；慎重对待变化可能性大的需求；抓住业务核心；不偏离业务现实。
可重用性的优化，可以从这几个方面着手：尽量减少功能之间的关联性；注意数据的流动方向；建立团队的通用规范与通用功能。
高效性的优化，可以从这几个方面着手：使用率不同的数据采用不同的保存方式；利用中转数据；外键必填；优先使用客户端资源。
软件界面就是用户可以在电子设备的终端（如显示器、PAD、手机等）上看到、听到，甚至摸到的内容。用户可以通过界面录入信息，也可以通过界面获得信息，也可以通过界面把自己的要求提供给软件系统，界面是人与软件系统交互的通道。最常见的软件界面包括软件的窗口或网页。另外需要注意的是，有些不常看到的信息也是界面不可或缺的组成部分，如对话确认框、提醒消息、出错提示、日志信息等。所谓界面设计，就是设计系统通过什么方式接收用户输入的信息、发送的指令，通过什么方式将处理过程与处理结果反馈到输出设备上。好的软件界面以人为本，不会让用户难以学习，不会让用户感到厌烦，不会让用户感到恐惧，不会让用户感到难以捉摸。
设计界面一般需要先进行原型设计。所谓原型设计，就是设计软件运行的模拟界面，设计系统如何接受用户录入信息以及发布的指令，指令在执行过程中如何与用户沟通，处理结果如何在界面上反馈。原型设计一般包括手画法、Office工具设计法、原型工具设计法以及开发工具设计法。
1.界面设计过程
界面设计一般包括入口、功能主界面、表单布局、操作、消息5个方面的设计。
入口：用户登录进入系统后，如何才能打开自己需要的功能界面，这是入口设计需要考虑的问题。入口一般包括功能菜单、工作台、九宫格、弹出菜单、快捷方式等。
功能主界面：指用户通过菜单或其他入口方式打开某功能点后，系统加载的让用户可以使用该功能点的主界面，功能主界面提供了各种子功能的入口。功能主界面一般会被分成各种区域，如菜单区域、功能按钮区域、查询条件区域、记录显示区域、详情展现区域等，各种组件就放置在这些区域中。这些区域的布局方式，本书称之为界面结构。常用的界面结构有：上边查询条件，下边查询结果；左边大项，右边查询结果；左边树状结构，右边查询结果；上边主表，下边子表；左边主表，右边子表；树状列表；分级列表；日历等。
表单布局：表单上的组件可以分成三大类，一类是用以接收或显示数据的，如文本框、标签、单选框、复选框之类的；一类是用以响应用户的要求而执行某种操作，如按钮、链接、图标之类的；还有一类跟数据、操作都没有关系，只是用于界面布局、标注或美观等，如分隔线、矩形框之类的。表单布局设计，就是思考如何排放这些组件，使界面达到易学、易用、美观的效果。常用的表单布局结构包括平铺、分组、动态加载、表格、Tab页、混合等。
操作：表单上的操作大体可以分成两大类，一类是面向数据库的写操作（包括Insert、Update、Delete）；另一类是不改变数据库中数据的操作，可能仅仅是从数据库读取数据（Select），甚至跟数据库中的数据毫无关系，这种操作不会导致数据库中保存的数据发生任何变化。
消息：当用户在界面上操作时，一个友好的系统会将执行情况根据需要反馈给用户，这就是所谓的“消息”——是系统给用户带来的关于计算机的消息。有些消息只是告诉用户一段程序执行的状态，而有些消息是用于接受用户额外指令的。常见的反馈消息的方式包括消息弹出框、消息区、日志等。
2.界面优化
可以从易学性、易用性、健壮性、交互性4个方面考虑如何对界面进行优化。
易学性的优化，可以从这几个方面着手：提炼核心功能；追随主流软件；贴近业务流程；统一操作习惯；减少用户干预；倡导边干边学。
易用性的优化，可以从这几个方面着手：让功能方便调用；让工作容易处理；减少用户录入；减少击键次数；减少在键盘与鼠标之间的切换。
健壮性的优化，可以从这几个方面着手：不让用户犯错误；让用户少犯错误；让用户容易发现错误；允许用户纠正错误；降低用户错误的影响面。
交互性的优化，可以从这几个方面着手：重要操作需要确认；不要让用户有石沉大海的感觉；消息措辞需要容易理解；消息需要精准；交互要适可而止；不要滥用弹出框。
采用快速原型开发模型，由于在开发之前已经设计出了完备的软件原型界面，通过原型界面可以将界面层的需求表达得非常清楚，开发者也好，用户也好，看着原型都容易理解软件将会被开发成什么样子，但对于软件来说，所包含的需求当然远不止这些，在原型界面背后还有大量用户看不到的东西。有些功能点逻辑简单，看着原型就能够把需求理解得差不多；而有些功能点逻辑复杂，没有文档辅助说明，根本不可能理解需求。不同的团队会用不同的方式来表达这种逻辑，或者在某种规范的文档体系下描述，或者用各种凌乱的文字片段描述，本书推荐一种围绕原型描写逻辑规则的文档——原型说明书。
原型说明书是针对设计好的软件原型撰写的一种偏向于说明功能与操作逻辑的文档，主要描述每个功能点的主要用户，用户使用该原型的操作场景，有什么权限控制要求，每个操作背后是怎么运算的（从用户确认执行某操作，到系统反馈执行结果之间，系统会做什么处理，有哪些业务逻辑），对数据有什么要求，等等。
在软件的各个阶段都有可能产生需求变更。例如，在调研阶段，用户刚确定了某个问题的处理方式，过了几天可能又觉得换一种方式好；在设计阶段，设计者可能在设计过程中会发现需求问题，从而向用户提出变更建议，或者，用户参与设计评审后，可能会提出来需要增加、修改功能；在开发阶段，开发者可能会发现设计问题，用户也可能提出追加功能、改变功能，设计者也可能觉得有些设计不尽如人意，从而提出需求变更；在试用阶段，用户可能会发现开发出来的软件很多地方并不能真正满足信息化管理的要求，不能不提出需求变更；在正式使用阶段，用户的业务可能会发生变化，用户的管理思想也可能会发生变化，从而提出需求变更，等等。
产生需求变更的原因很多，常见的包括调研不充分、沟通有歧义、异常没考虑、规划不到位、设计有瑕疵、实现欠灵活、实施不熟练、业务会变化、管理在改善、想法在改变、软件要发展。
软件团队常用的控制需求变更的手段包括技术手段、沟通说服、成本约束等。有些控制方式并不是仅靠需求人员就能做到的，需要发挥团队的力量。
不同的需求变更差别巨大，有些需求变更处理起来很容易，有些需求变更处理起来相当麻烦。本书将需求变更分成4种：改变界面的需求变更，改变功能逻辑的需求变更，改变数据库结构的需求变更，改变历史数据的需求变更。这4种需求变更的处理难易程度是递增的。
处理需求变更，要尽量从根本上解决问题。从根本上解决问题，核心思想是从整个系统的角度出发考虑问题，而不是仅仅从一次需求变更的角度考虑。假如现在还处在调研阶段，如何处理这个需求呢？自然会将其跟别的需求一起进行系统性规划，会考虑软件的灵活性、健壮性、易学性、易用性等，绝对不能容忍那种看上去简直是胡搞的开发方式。
虽然大部分情况下，软件团队谈到需求变更都是惊慌失措、咬牙切齿的，但不能不承认，“塞翁失马焉知非福”的古谚在处理需求变更的过程中同样有效。有些需求变更，可以提高客户的黏性；有些需求变更，可以直接给团队带来商务收益，带来利润；还有些需求变更，虽然看上去是“坏事”，但只要处理好了就能推动软件的发展，虽然不敢说“多多益善”，但至少没有看上去那么糟糕。