聆听客户的需求.ppt

*第7章理解用户的需要需求工程的核心任务是需求获取，即确定软件系统涉众的需要及限制条件的过程。*计划应该针对下面这些内容来制定：

需求获取的目的。需求获取的策略和过程。需求获取工作取得的成果。进度和资源评估。需求获取的风险。有效而直接的用户访谈技巧要求访谈者准备一个问题列表，目的是了解真实的问题和潜在的解决方案。专题讨论会可以减少一部分需求冲突，绕开纷繁的情况得到需求列表，以此作为进一步分析的基础。制作情节串联板就是使用工具向用户说明系统如何适应组织的需要，并表明系统将如何运转。情节串联板的类型包括被动式、主动式和交互式，其复杂度依次递增。用户访谈*有效而直接的用户访谈技巧要求访谈者准备一个问题列表，目的是了解真实的问题和潜在的解决方案。为了尽可能获得没有偏见的答案，需要确保提出的问题与背景无关。用户访谈的五个阶段*准备访谈计划和安排访谈日程访谈开始和结束引导访谈后续的访谈整理工作某出租车公司拟在公司收费环节中实现微机收费替代原有的手工开票,避免财务漏洞.作为软件开发公司项目组人员,你将如何获取用户需求.开放性问题与封闭性问题*在开始一个议题时，一般会用开放性的问题（什么，为什么，多么），便于被访谈者展开思路。01随着讨论的深入，渐渐转为提供结论的封闭性问题，这样能帮助证实你的理解。02太多的封闭性问题会导致收集的信息不完整，太多的开放性问题可能导致需求分析者的理解失误。03调查问卷*使问卷表尽可能的简短。通常，一个问卷表包含的问题不超过10-15个。估计回答问题需要的时间。确保问题是前后一致的，没有让人含混的理解为了保证不会理解含混，让与回答者关系密切的人员来进行问卷调查，并保证他们对问题的理解是正确的。在制订问题前，先确定你需要得到怎样的答案分别列出所有可能的答案确保所有的需求能被问题覆盖。最后，剔除掉与需求无关的问题。专题讨论会*常见的专题讨论会需求获取*指导需求获取讨论的技能来自于经验，并建立于在面谈、小组讨论、解决冲突和其他类似活动等方面所受培训的基础上。除了简单地记录下客户所叙述的内容以外，有创造性的分析员在需求获取期间还能为用户提出一些建议和可供选择的方案。无论是对商业产品还是对信息系统，获取需求信息的传统来源都是与潜在用户(个人或小组)进行面谈。需求获取讨论会*需求分析员要经常主持和协调需求获取讨论会。协调性、合作性好的讨论会是将用户和开发人员联系起来的一种非常有效的技术。下面这些提示可用来指导有效的需求获取会议。建立基本规则与会者应该对他们所参加的讨论会的基本运作规则达成一致。不超出范围根据前景和范围文档来验证所提议的用户需求是否在当前的项目范围之内。注意： 要避免过早地讨论不必要的需求细节。需求获取讨论会*使用活动挂图(flipchart)来捕获以后再考虑的一些条目在需求获取讨论会中将会随机出现一批重要信息：质量属性、业务规则、用户界面等方面的想法、受到的限制以及其他信息。时间盒(timebox)讨论在最初的用例研究期间，协调人可能需要为每一个讨论主题分配一个固定的时间段。保持较小的团队规模并找到合适的参与者较小的团队比较大的团队工作效率要高得

多。确保每个人都积极地参与讨论有时参与者会停止参与讨论，这是因为他们对系统随时都可能出现意外感到灰心丧气。注意： 在需求讨论期间，要防止讨论跑题。情节串联板*情节串联板的复杂程度与成本将客户的意见归类*需求分析员必须将所听到的大量需求信息分门别类，以方便编档和使用。图列出了9种需求类别。业务需求业务需求描述客户和开发组织希望从产品中获得的商业利益。将客户的意见归类*用例或场景用例是对用户目标或用户需要执行的业务工作的一般性描述；使用场景(usagescenario)则是某个用例的一条特定路径。业务规则当客户说只有特定用户在特定条件下才能执行某一动作时，他也许是在描述一条业务规则。质量属性质量属性是对系统实施某种行为时，或者让用户执行某种操作时，系统表现如何的陈述。功能性需求功能性需求描述了系统在特定条件下表现的可观察的行为，以及系统允许用户执行的操作。