需求分析ch聆听客户的需求PPT课件

第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寻找遗漏的需求,不可能彻底完成需求获取，下面给出的情况暗示了接近这样一个完成点，此时获取的需求不断减少。如果用户想不出更多的用例，工作差不多完成了用户提出新的用例，已经从其他用例中推导出了这一用例的相关功能性需求，工作已经接近完成了如果用户只是重复他们在以前的讨论中已经提出过的问题，工作也许完成了。如果提出的新特性、用户功能或功能性需求都在范围之外，也许工作就完成了如果提出的新需求优先级都很低