需求分析-ch07-聆听客户的需求

10.,*,2007 by Prentice Hall,第,7,章,聆听客户的需求,“,Maria,，早上好！我是,Phil,，是你们的雇员信息新系统的需求分析员。感谢你同意担任这一任务的用户代言人，你给我们提出的信息帮了我们很多忙，能不能告诉我你想要的具体是什么？,”,“,嗯,我想要的是什么？,”,，,Maria,想了一会说。,“,我都不知道该从何说起，新系统应该比旧系统快的多。要知道，如果雇员的名字很长，旧系统就会崩溃，我们只好找技术支持部门，要求他们替我们输入，你知道这是什么原因吗？所以呢，新的系统应该能接受比较长的名字而不会崩溃。还有，根据一部新的法律，不能再将社保号用作雇员的,ID,了，这样在启用新系统时，我们必须更改所有的雇员,ID,。新的,ID,是由,6,位数字组成的号码。对了，如果能够得到一张统计报表，显示每个雇员在今年到目前为止接受了多少个小时的培训时间，那就太好了。另外，还要求即使某人的婚姻没有发生变化，也能够修改他的名字。,”,Phil,忠实地记录了,Maria,所说的内容，但他的脑子却不停地在活动。他不能确信所有这些信息能用来做什么，也不清楚该告诉开发人员哪些信息。他想，,“,如果这就是,Maria,想要的，那么我们最好照着做。,”,需求分析,第,7,章：,聆听客户的需求,案例,需求分析,第,7,章：,聆听客户的需求,7.1,需求获取规划,7.2,需求获取面谈,7.3,需求获取讨论会,7.4,客户需求类别,7.5,需求获取的注意事项,7.6,寻找遗漏的需求,7.7,如何判断需求获取是否已完成,用户需求包括用户要求系统完成什么任务和用户对性能、易用性和其他质量属性的期望,需求活动应先制定规划,需求获取的目的,需求获取的策略和过程,需求获取的结果,进度和资源评估,需求获取的风险,需求分析,第,7,章：,聆听客户的需求,7.1,需求获取规划,在软件开发中，需求获取也许是最困难、最关键、最容易出错和最需要沟通的一个环节。,需求获取的传统来源是与潜在用户进行面谈。每一次面谈之后，都要将讨论的条目编写成文档。,使用用户的术语，而不是计算机术语,问一些没有标准答案的问题，帮助理解用户当前的业务过程，并了解系统如何能改进这些过程的性能,扮演学徒的角色，用户是师傅,研究一些例外的情况,如果开发的是取代一个现有系统，询问,“,对现有系统最让你感到烦恼的,3,件事情是什么？,”,需求分析,第,7,章：,聆听客户的需求,7.2,需求获取面谈,建立基本原则,不超出范围，避免过早地讨论不必要的需求细节,使用活动挂图来捕获以后再考虑的一些条目,时间盒讨论,保持较小的团队规模并找到合适的参与者,确保每个人都积极地参与讨论,需求分析,第,7,章：,聆听客户的需求,7.3,有效的需求讨论会,不要指望客户会给你一份简洁、全面、条理清晰的需求清单。需求分析员必须将所听到的大量需求信息分门别类，以方便编档和使用。,需求分析,第,7,章：,聆听客户的需求,7.4,客户需求类别,不能归入上述类别的信息可能属于下列情形之一,与软件开发无关的需求,项目所受的限制条件,假设,对数据的需求,关于历史、背景或用于描述的附加信息,需求分析,第,7,章：,聆听客户的需求,7.4,客户需求类别,需求获取的参与者在理解问题之前要抵制住诱惑，不要急于设计系统，否则，当以后需求定义变得完善时，可能需要大量的返工设计。,要强调用户任务，而不是用户界面，要强调根本需要，而不是用户表达出来的期望，这样有助于项目团队避免过早地制定设计的细节。,如果没有一个有条理的组织方案，将来自众多用户的需求意见合并起来相当困难。,只向很少的用户代表收集意见，或只听声音最大、最固执己见的客户的意见，容易导致遗漏某些用户类很重要的意见。,当心可怕的分析麻痹症，及花费大量时间进行需求获取，企图避免遗漏任何需求。事实上，根本不可能预先发现所有的需求。,需求分析,第,7,章：,聆听客户的需求,7.5,需求获取的注意事项,找出未曾发现需求的方法,将高层的需求分解的足够细，让真正的需求显露出来,务必让所有的用户类都提出他们的意见，确保每个用例都至少有一个确定的执行者,跟踪系统需求、用例、事件,-,响应表以及业务规则，直至其详细的功能性需求，确保需求分析员推导出了所有必须的功能。,检查边界值，查找被遗漏的需求,用多种方法表达需求信息,包含复杂的不二逻辑（与、或、非）的需求常常是不完整的,需求分析,第,7,章：,聆听客户的需求,7.6,寻找遗漏的需求,一种查找被遗漏需求的精确方法是,CRUD(Create,Read,Update,Delete,),矩阵,CRUD,矩阵将系统行为与数据实体联系起来，确保清楚每个数据项在何处及如何被创建、读取、修改和删除，也可以增加,L(List,),生成,CRUDL,矩阵后，可以检查这,5,个字母是否有哪一个在同一列的所有单元格中都没有出现。,需求分析,第,7,章：,聆听客户的需求,7.6,寻找遗漏的需求,订单,化学品,申领人,厂商目录,设置订单,C,R,R,R,L,改变订单,U,D,R,R,L,管理化学品目录,C,U,D,订单报告,R,R,L,R,L,编辑申请人,C,U,L,不可能彻底完成需求获取，下面给出的情况暗示了接近这样一个完成点，此时获取的需求不断减少。,如果用户想不出更多的用例，工作差不多完成了,用户提出新的用例，已经从其他用例中推导出了这一用例的相关功能性需求，工作已经接近完成了,如果用户只是重复他们在以前的讨论中已经提出过的问题，工作也许完成了。,如果提出的新特性、用户功能或功能性需求都在范围之外，也许工作就完成了,如果提出的新需求优先级都很低，也许工作已经完成了,如果用户提出的新功能都是可以,“,在产品生命周期的某个时刻,”,加入，而不,“,属于当前正在讨论的特定产品,”,，工作也许已经完成了。,需求分析,第,7,章：,聆听客户的需求,7.7,如何判断需求获取是否已完成,