• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

获取客户需求的十大沟通技巧

发布: 2008-1-16 14:56 | 作者: 不详  | 来源: chinahrd | 查看: 74次 | 进入软件测试论坛讨论

领测软件测试网

 

为了建立合作关系通常采取一种组队的方式来获取需求,建立一个由用户代表和开发人员组成的联合小组作为需求获取的核心队伍。联合小组将负责识别需求、分析解决方案和协商分歧,小组成员可以采用会议、电子邮件、综合办公系统等方式进行交流,但交流时应注意以下原则:小组会议应该由中立方来组织和主持,用户和开发人员都要参加;交流预先要确定准备和参与的规则;议题要明确并覆盖所有关键点,但信息来源应该自由;交流目标要明确,并告知所有的成员。

  5、确定使用实例 

  从用户代表处收集他们将使用系统完成所需任务的描述,讨论用户与系统间的交互方式和对话要求,这就是使用实例,一个单一的使用实例可能包括完成某项任务的许多逻辑相关任务和交互顺序。使用实例方法给需求获取带来的好处来自于该方法是用以任务为中心和以用户为中心的观点,比起使用以功能为中心和以开发者为中心的方法,使用实例方法可以使用户更清楚地理解和认识到新系统允许他们做什么和怎么做。描写使用实例的时候要注意使用简洁直白的表述,尽量使用主动语态,系统或者用户作为主语,比如用户提交用户密码,系统验证用户密码是否正确,还有一点在描述中不要设计界面细节,比如用户从下拉框中选择产品类型。使用实例为以后写用例场景描述中的基本路径和扩展路径提供了素材。 

  6、召开联合会议 

  最常见的需求获取方法是召开会议或者面谈,联合会议是范围广的、简便的讨论会,也是核心队伍成员之间一种很好的沟通方法,该会议通过紧密而集中的讨论得以将用户代表与开发人员间的合作伙伴关系付诸于实践并能由此拟出需求文档的底稿。联合会议的第一个议题就是系统的必要性和合理性,必须所有成员都同意系统是必要的而且合理的。接下来就可以讨论使用实例清单,清单可以打印成大纸挂在墙上、写在黑板上或做成演示材料。对每个清单合并去掉重复项,加上补充内容就可以得到一份总的清单,注意避免采用负面的太差不可行去否定用户的想法,这些想法都应该保留下来作为被评议的清单项,这样保护了小组成员开放的思维。最后对清单进行讨论,会议成员必须检查每一个使用实例,在把它们纳入需求之前决定其是否在项目所定义的范围内,形成最终的需求报告。 

  在进行讨论时,也应该避免受不成熟的细节的影响,在对系统需求取得共识之前,用户能很容易地在一个报表或对话框中列出某些精确设计,如果这些细节都作为需求记录下来,他们会给随后的设计过程带来不必要的限制,应确保用户参与者将注意力集中在与所讨论的话题适合的抽象层上,重点就是讨论做什么而不是怎么做。这里有一点很重要就是要让用户理解对于某些功能的讨论并不意味着即将在系统中实现它,更不要做暗示或者承诺什么时候完成需求。在讨论之后,记下所讨论的条目,并请参与讨论的用户评论并更正,因为只有提供需求的人才能确定是否真正获取需求。当最后拿到了一份详细准确的需求报告书的时候,会议就算成功完成了。但是要清楚需求过程本身就是一个迭代的过程,在以后的过程活动中不可避免的将要修改和完善这份报告。 

  7、分析用户工作流程 

  分析用户工作流程观察用户执行业务任务的过程,通过分析使用实例得到系统的用例图。编制用例图文档将有助于明确系统的使用实例和功能需求,统一建模语言的使用有助于与用户进一步交流。每个用例的描述应包括:编号,为每个用例分配一个唯一的编号,为需求的追溯提供了方便;参与者,与这个用例交互的actor;前置条件,开始用例前所必须具备的系统状态;后置条件,用例完成后系统达到的状态;基本路径,用例完成的关键路径,也是用户期望的路径;扩展点,基本路径的分枝,表示意外情况;字段说明,路径中名称的进一步分解说明,对以后类属性的定义和数据库字段设计起作用;设计约束,实现用例的非功能约束。写基本路径时应该使用主动语句;句子以actor或者系统作为主语;一句表示一个actor动作,一句表示系统动作,交叉表现交互;不要涉及界面细节,比如用户在文本框输入名称,下拉框选择类型。 

  8、确定质量属性 

  在功能需求之外再考虑一下非功能的质量特点,以及确定由于特殊的商业应用环境对系统提出的功能或性能上的约束,这会使你的产品达到并超过客户的期望。对系统如何能很好地执行某些行为或让用户采取某一措施的陈述就是质量属性,这是一种非功能需求。听取那些描述合理特性的意见:快捷、简易、直觉性、用户友好、健壮性、可靠性安全性和高效性。你将要和用户一起商讨精确定义他们模糊的和主观言辞的真正含义,并且要将质量属性分配到每个用例的设计约束中去。 

  9、检查问题报告 

  通过检查当前已经运行系统的问题报告来进一步完善需求客户的问题报告及补充需求为新系统或新版本提供了大量丰富的改进及增加特性的想法,负责提供用户支持及帮助的人能为收集需求过程提供极有价值的信息。

  10、需求重用 

  如果客户要求的功能与已有的系统很相似,则可查看需求是否有足够的灵活性以允许重用一些已有的软件组件。业务建模和领域建模式需求重用的最好方法,像分析模式和设计模式一样,需求也有自己的模式。

文章来源于领测软件测试网 https://www.ltesting.net/

22/2<12

关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备2023014753号-2
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网