需求工程之需求获取的困难及解决方法

本文探讨了需求方、需求获取方及业务本身在需求沟通中遇到的问题与解决方案,包括描述不完整、用语不准确、知识能力有限、用户参与不足等方面,提出了有效需求提炼、用户选择、专业能力提升等策略。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >


从需求方、需求获取方、业务本身三个方面阐述。

需求方(客户方):

产生的问题:

  • 描述不完整:描述的时候只考虑到正常情况下的需求,对一些自认为是常识的需求忽略不提
    解决办法:需求获取方能够适当的引导和挖掘
  • 用语不准确,可能内心清楚但是表达能力欠缺
    解决办法:尽量理解用户用于表述他们需求的思维过程。充分研究用户执行任务时做出的决策过程,并提取出潜在的逻辑关系。流程图和决策树是描述这些逻辑决策途径的好方法。
  • 知识能力有限:隔行如隔山,知识局限,导致提出的需求不完整、不统一
    解决办法:尝试多问客户一些问题,更好的获取需求。
  • 用户参与不足:实际用户太多,无法有效选择客户;用户不配合需求获取;没有明确用户
    解决办法:需求获取方应对用户进行有效的选择,展开需求获取,或者尝试多种获取方法获取需求。
需求获取方:

产生的问题:

  • 专业能力强弱:需求获取方要了解需求获取的多种方法(如面谈、问卷调查、原型法、模拟情境观察、文档审查等)
    解决办法:配备专业能力强的人组成需求获取方,或团队中至少有一名比较有经验的软件需求工程师
  • 理解客户方需求困难
    解决办法:尽量把客户所持有的假设等解释清楚,特别是那些发生冲突的部分
  • 总是站在技术角度,无法理解客户的业务需求
    解决办法:需求获取方了解软件实现技术,但软件的前提是满足客户需要,而不是复兴局限于技术。技术服从需求,应尽力解决客户提出来的需求
  • 需求获取时的有效需求提炼
    解决办法:在需求获取过程中分析模型,屏幕图形和原型可以使概念表达更加清晰,然后提供一个寻找错误和遗漏的办法
  • 对用户的有效选择
    解决办法:需求获取时,讨论会的团队人数控制5到7人最好
  • 需求获取时工具携带、人员安排不足,不能及时获取和处理需求
  • 对项目范围的定义过小或过大
  • 需求收集不可能全面
业务本身:
  • 实际的业务比想象中的要复杂
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值