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