怎样挖掘用户需求
需求分析在数据库生命周期中至关重要，通常也是涉及人员最多的步骤。数据库设计师在这个阶段必须走访最终用户，与他们进行访谈，从而确定用户想在系 统中存储什么数据以及想怎样使用这些数据。
我们将需求分析分为两个步骤：1.理解用户需求；2.提取业务规则。这次我们先讨论“理解用户需求”。
设计定制化产品——无论是一个数据库、一幅平面广告或一个玩具，都是一个“翻译”的过程。我们需要把浮现在客户脑海中的模糊想法、愿望挖掘出来，并“翻译”成满足他们需求的现实产品。
这个“翻译”过程的第一步就是理解用户的需求。设计最好的订单处理系统对于需要一个电路设计工具的客户来说毫无意义。对客户需求理解的不完全会造成错误或无用的设计与开发，这浪费了你、你的团队还有客户的时间与金钱。(牢记数据库是整个应用开发的根基)
制定一个计划
我们首先制定了一个计划，其中包含挖掘客户需求的一系列步骤。遵循这些步骤能更好地理解客户需求，但在一些项目中我们不需要遵循所有的步骤。举例来 说，如果客户是单个人且需求很明确时，我们就不需要进行“搞清谁是谁”与“头脑风暴”了。当客户的数据需要保密时，我们就不能“尝试客户的工作”了。在另 一些项目中，调整这些步骤的顺序会更为合适。例如我们可能在去拜访客户和观察他们工作之前先进行“头脑风暴”。
以下按照最普遍的顺序列出了各个步骤。大家根据不同项目的情况可进行灵活调整，目标只有一个就是更好地理解用户需求。
列出问题清单 拜访客户 搞清谁是谁 挖掘客户大脑 尝试客户的工作 学习现有操作 头脑风暴 展望未来 理解客户的质疑 弄清客户的真正需求 优先级 确认你的理解 撰写需求文档
下面我们将一一解释每一个步骤。
我们需要思考，向客户问些什么问题可以帮助我们了解项目的目标和范畴（scope）。以下几个方面的问题可以作为起始点。
功能：
以下问题主要涉及系统应完成的功能与目标。
系统应该做些什么? 为什么你想建这个系统? 系统看上去应该是怎样的? 需要些什么报表? 用户需要自己定义新报表吗? 系统的操作者会是谁?
数据需求：
这些问题是为了弄清项目的数据需求。了解需要些什么数据能帮助我们定义数据库表。
系统界面上需要展现哪些数据? 这些数据应该由谁来提供? 这些数据是如何关联的? 这些工作现在是如何处理的?数据来自哪里?
数据完整性：
这些问题能帮助我们在构建数据库时定义完整性约束。
哪些数据是必须填写的?(eg: 一条客户记录必须有电话信息吗?) 数据的有效域是什么?(eg: 电话号码是否有格式规定?地址数据应有多长?) 系统是否需要根据邮编来检验城市的有效性? 系统中是否必须在定义了客户之后才能下订单? 系统要求多高的可用性等级?(系统需要7×24的可用性吗?数据的备份频率要多高?)
安全性：
这些问题能帮助我们了解客户对权限控制与审计方面的需求。
是否每个用户都需要一个不同的密码? 是否需要控制不同的用户所能访问的数据?(eg: 销售代表有权限看到客户的信用卡账号，但订单录入专员却不能) 存储在数据库中的数据是否需要加密? 谁做了什么操作是否需要记录以便于审计?(eg: 记录销售代表提高客户级别的操作，在需要时可以追溯操作的原因) 系统中的客户分成几个级别?每个级别的客户有多少? 是否已有文档记录了用户的工作与权责?
环境：
这些问题能帮助我们了解当前项目将代替其他什么系统或流程，以及项目将与其他哪些系统进行交互。
1.当前项目是要代替或升级现有的某系统吗?
•是否有描述现有系统的文档?
•现有系统的哪些功能是需要的?哪些是不需要的?
•现有系统处理些什么数据?这些数据是如何存储的?数据之间是如何关联的?
•是否有关于现有系统数据的文档?
2.当前项目必须与其他哪些系统交互?
•项目与其他系统之间如何交互?
•新项目是否需要向现有系统提供数据?如何提供?
•新项目是否需要接收现有系统的数据?如何接收?
•是否有关于其他系统的文档?
3.客户的整个业务流程是怎样的?(了解在整个业务流程中当前项目的作用)
拜访客户
了解我们要设计和搭建的系统的最好方式是询问客户。拿着我们在上一步中准备的问题清单安排与客户进行会面。这不会像闲聊那么轻松，向客户了解需求是一个冗长且折磨人的过程。
有时我们的穷追猛问会使客户筋疲力竭感到不快。在这些时候我们必须更为耐心，可以分几次多次会议来了解需求，每次针对几个问题或流程。我们的目标是对我们要解决的问题有一个完全且彻底的理解。
即使我们的项目只是去解决整个业务中的一小部分问题，我们也要试图去了解客户的整体业务流程，这可能会给我们带来意想不到的收获。
搞清谁是谁
意识到不同的客户可能对项目有不同的愿景。我们需要分辨出谁是领导，谁是积极支持者需求挖掘，谁是旁观者，谁是唱反调者。
以下列出了一些常见的客户角色：
项目发起人——一般是管理层的某位领导，他是项目的最高推动者。他会为项目协调资源，解决项目遇到的一些障碍，但他不会参与到项目每天的事务中。 项目执行负责人——他对于客户的需求和整个业务最为了解。他是了解用户需求阶段最重要的人，他必须有足够的时间来帮助我们定义项目目标以及回答我们的问题。当别人对某业务环节迟疑不决时，我们需要向他请教。 客户代表——客户代表是回答我们问题的人，他们也可能成为系统的最终用户。他们可能是某一部分业务的专家，我们需要与多个客户代表进行访谈来了解业务全貌。 利益相关者——这是项目将影响到的人，其中某些人可能同时也是客户代表。这些人可能对项目也有兴趣，但未必对系统都有发言权。我们在进行系统设计时也需要考虑对这些人的影响(特别是附带损害)。 唱反调者——这是我们需要关注的一些人。如果唱反调者只是让其他人理性或现实地来看待项目，而并不是彻底反对这个项目的话，他将是我们非 常好的资源，他将帮助我们说服其他对项目抱有不切实幻想的客户。而如果唱反调者对整个项目抱有抵触时，我们就必须非常小心，有时需要项目执行负责人出面来 协调这些人。
挖掘客户大脑
一旦搞清楚谁是谁之后，我们就要与项目执行负责人讨论客户需要什么。客户希望的解决方案是怎样的，需要包含什么数据，怎样呈现，以及不同数据之间如何关联。
与尽可能多的利益相关者进行交流，我们需要考虑每个人的意见，但心中要牢记项目执行负责人最为理解客户的需求并具有最终决定权。
根据项目的规模，这一过程短则几个小时，长则需要几周才能完成。
尝试客户的工作
观察客户每日的工作能帮助我们更好的理解业务。如果我们能做一会儿客户的工作来了解其中包括的内容那就最好了。
即使我们不能实际尝试客户的工作，一般我们还是可以坐在他们身边近距离观察。告诉客户我们将稍稍降低他们的工作效率并问一些愚蠢且恼人的问题，之后 我们就可以开问了。在这个过程中要进行记录，学习尽可能多的东西。有些时候外行者的一些看法可能转化为客户怎么也不会想到的好主意。
学习现有操作
在尝试客户的工作之后，我们还可以看一下是否有其他途径能了解现有流程。通常公司有描述客户角色和职责的操作手册或文档。
寻找客户现在使用的数据存储方式，可能是关系型数据库系统或是电子表格或是纸质的单据等等。了解这些数据是怎样使用的，之间是如何关联的。一般物理数据库之间是通过包含冗余信息来相互关联的，如：客户ID。
头脑风暴
此刻我们已经对客户的业务和需求较为了解了。为了确认没有什么遗漏，我们需要安排头脑风暴。召集项目执行负责人和尽可能多的客户代表与利益相关者，向他们描述前期了解到的需求情况，之后让他们畅所欲言谈谈其中有什么问题或还缺什么。
在这个过程中我们不急于答应或排除任何客户的要求，我们先把客户说到的东西记录下来，并确定这些方面我们已经考虑到了。在正式开发前，我们会与项目执行负责人一起根据项目的规模与交付期限确定需求的优先级。
展望未来
在头脑风暴过程中思考一下将来的需求。问问客户他们的业务在将来是否会变化或他们希望系统将来能包含什么功能。
我们可以把他们的一些想法放入当前的项目中，即使不能也可以使我们知道将来可能会有些什么扩展，在设计数据库时我们能预先留有余地。
理解客户的质疑
一些热心且懂些技术的用户会跑来建议我们如何设计系统，应该创建怎样结构的数据表。我们可能觉得这些建议毫无意义甚至可笑。但在忽视这些建议之前我 们应谨慎思考用户提出这些建议或质疑的深层原因是什么。客户比我们更了解业务，他们的建议或质疑中可能蕴含着我们还未了解到的业务变化点或某些特殊业务情 况。
弄清客户的真正需求
有时客户并不了解自己的真正需求。他们能看到问题的表象，但未必清楚其根源。我们需要帮助客户寻找到问题的根源并针对问题的源头提出解决方案。
有时客户认为数据库或新系统能神奇般的提高销售，减少成本。事实上一个设计精良的数据库能减少输入差错，提高操作效率，提供数据报表，帮助客户管理数据等等。我们在与客户沟通的过程中需要告诉他们新系统能做些什么，不能做些什么，让客户建立起正确的预期。
优先级
经过先前的步骤，我们已列出一张长长的期望功能列表。其中的某些功能可能不切实际或超出了当前项目的范畴。为了使项目规模可控，我们要与客户一起定义功能的优先级。
一般我们可以把功能分为三个等级。第一优先级是在本期开发中必须包含的功能，没有完成这些功能意味着项目的失败。第二优先级是可以放到下一期开发的 功能，当第一优先级的功能完成后，我们可以把第二优先级的部分功能提到当期开发。第三优先级是那些相对不重要或超出项目范畴的功能，我们可以忽略这些功 能。
有些情况下优先级是可能转化的。当第一优先级的某功能非常难实现时，我们可以与客户进行沟通，确认该功能是否如此重要，是否能移到第二优先级中以避 免影响项目进度。当第二优先级中的某些功能很容易实现，我们可以把该功能调整到第一优先级列表中。但做这些调整之前必须与客户沟通，得到客户的认可。
验证你的理解
梳理我们对业务和需求的理解，并一一与客户进行确认。当客户说“但是”、“除了”、“有时”等词时，我们要特别当心，确认客户只是强调了我们已经知道的东西，而没有出现新的情况。在这个阶段客户可能会想到他们之前没有考虑到的例外情况。
例外情况是数据库设计的大害。在需求分析阶段把例外情况挖掘出来，我们才能在数据库设计时有所准备。例如，我们向客户确认退货流程说：“到这里收货 员会输入RMA号并点击完成按钮是吗?”客户可能会说：“嗯…这是大多数情况，但有时没有RMA号，收货员会填入None。”这就是一个客户之前没有告诉 我们的重要例外情况，我们必须立刻记录下来。再有一个例子，假设客户使用的纸质订单有配送地址与账单地址两个栏目。我们向客户确认时说：“订单需要有一个 配送地址和一个账单地址。”客户打断说：“有时我们需要两个配送地址，因为订单不同部分可能要送到不同的地方。”，并找出一张订单，第二个配送地址被标注 在订单的边沿处。这是一个重大例外，在纸上可以很容易的进行标注，但在数据库的一个表单元中增加一个地址是不可能的。只有知道这一例外，我们才能用设计的 方法解决这一需求。
撰写需求文档
需求文档描述了我们要构建的系统，该文档也被称为需求规格说明。需求文档要讲清楚我们将构建怎样的系统，该系统会完成什么工作，包含哪些功能点需求挖掘，并描述客户如何使用该系统来解决他们的问题。需求文档明确了项目将完成的功能，这也避免了系统交付时出现争执的情况。
需求文档中应定义可交付成果，即里程碑。里程碑是可直观展现并能验证的中间成果。客户通过里程碑能衡量项目的进度。在需求文档中还需定义最终交付成果，这也是确定项目是否完成的标准。
用例图是一种非常好的需求分析工具，可以作为需求文档的一部分。用例图的最主要功能就是用来表达系统的功能性需求或行为。用例图从业务角度上体现谁 来使用系统、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，也便于软件开发人员最终实现这些功能。在官方文档中用例图包含六个元素，分别 是：参与者(Actor)、用例(Use Case)、关联关系()、包含关系()、扩展关系()以及泛化关系 ()。但是有些UML的绘图工具多提供了一种直接关联关系( )。
参与者：是指用户在系统中扮演的角色 用例：是指外部可见的系统功能，对系统提供的服务进行描述 关联关系：连接参与者和用例，表示该参与者代表的外部系统实体与该用例描述的系统需求有关 包含关系：是来自于用例的抽象，即从数个不同的Use Case中，分离出公共的部分，而成为可以复用的用例 扩展关系：表示某一个用例的对话流程中，可能会根据条件临时插入另外一个用例，而前者称为基础用例后者称为扩展用例 泛化关系：一个用例可以被特别列举为一个或多个用例，这被称为用例泛化
eg：用户管理的用例图如下所示，图中人形图标表示参与者，椭圆表示用例（图的出处请参见“总结与参考”）
主要内容回顾
1. 搞清哪个客户扮演哪个角色
2. 从客户的脑海中挖掘信息
3. 寻找关于用户角色、职责、现有流程和现有数据的文档
4. 观察客户的工作，学习他们的业务操作
5. 进行头脑风暴，把收集到的功能需求点按优先级分成第一、第二和第三级
6. 确认对客户需求的理解
7. 撰写需求文档，包含可验证的里程碑和用例
参考：
以上为用户投稿陆作网整理发布，希望对大家有所帮助！
- 上一篇： 分销系统管理
- 下一篇： 税务机关是否对办理留抵退税纳税人进行审核确认？如何审核？
