2018年1月25日,星期四08:06

在需求收集会议中评估需求

撰写者

对于项目来说,从需求收集或引出需求(用于描述此任务的流行术语)开始。

研讨会,访谈和集思广益会议–业务分析师执行这些需求收集方法的次数越多,给他/她带来的画面就越清晰。在这些练习中,业务分析师同时分析需求或权衡需求有多重要?换句话说,需求有多必要?

尽管一旦收集了所有需求便进行了全面的分析,但如果在收集需求时评估了某些需求,则确实有帮助。

在我最近的一次会议中,讨论了某些高级要求。这些要求是针对要求为内部销售团队开发的应用程序的。发布概述开始需求收集。我已经准备好一系列问题,并一次处理了一个模块。在会议开始后的几分钟,正当我要记下一项要求时,一位利益相关者发表了意见。与该组织有大约15年合作关系且是金融技术领域的SME的经验丰富的IT专业人员恳请对此要求有所不同。他提出了一些非常重要的问题:

  • 要求的功能真的需要吗?
  • 如果有其他选择怎么办?如果使用功能稍有不同的形式可以解决目的,该怎么办?
  • 如果满足此要求,则需要进行时间和成本分析,如果开发了替代方法,则需要进行时间和成本分析。

现在,中小企业需要一些扎实的想法来说服利益相关者改变需求。所有利益相关者都深入分析了此“要求”的实际“要求”。

总结一个替代方案。此替代方法可满足业务利益相关者的目的,在经济上可行,并且可以在更短的时间内开发出来,而不会影响应用程序的质量和功能的目的。

并非所有提出的要求都具有相同的性质。但是有时候,业务用户可能会全神贯注地在应用程序中拥有复杂的功能,或者他们可能只是因为碰巧在竞争对手的应用程序中遇到了精美的功能,而希望在现有应用程序上实现模块。尽管某些要求可能对业务非常有帮助,但可能需要对某些要求进行最佳更改。

  • 需求收集不仅仅只是记录需求 -可能根本不需要某些要求,或者可能有更好的选择。此类替代方案应放在桌面上进行讨论。可以提出以下问题:
    • 功能/要求的目的是什么?
    • 如果要求是必不可少的,但是要花很多时间才能开发出替代方案?
  • 利益相关者可能来自技术背景或非技术背景 -其中有些人可能来自非技术背景,但可能具有扎实的技术知识。但是,如果利益相关者来自非技术背景并且不完全了解开发过程,那么业务分析师很有可能必须更详细地讨论需求。他们可能不完全了解开发过程。但你做了。您知道开发最小的应用程序模块需要花费多少精力。

广告

利益相关者可能不完全了解开发时间或进行模块开发和进行更改所涉及的成本。在这种情况下,业务分析师必须更深入地研究并确保需求符合所有人的目的。

  • 在大多数项目中,需求经常变化 -利益相关者期望将产品与他们提出的几乎所有要求一起使用;甚至是变化。但是,考虑到诸如成本时间分析,项目开发时间范围,项目的优先级以及所部署资源的可用性等因素,可能无法在启动过程中包含所有功能。因此,需要考虑所有利益相关者的利益,优先考虑这些要求。尽管可以在第一阶段中满足主要需求,但其余需求可以进入后续阶段。
  • 需求收集和同步分析有助于节省文档编制过程中的时间,从而节省项目计划的时间 -如果随后讨论了一个令人怀疑的要求,然后权衡其他方案,则利益相关者可以达成共识,因此可以将要求明确记录在案并予以解决。这样可以避免业​​务分析师进行后续的后续工作,以确保需求明确或讨论更改。
  • 一开始一个项目似乎很简单 但是,只有对这些要求进行了彻底的分析,才能理解开发的复杂性。因此,为了项目开发的利益对需求提出质疑很重要。

称量需求与收集需求一样重要。如果在最初的需求收集会中完成,则后续过程–需求文档,签署和计划可以顺利完成。

 Poorti Mehta

Poorti Mehta 是拥有超过4.5年工作经验的业务分析师。她从事过跨领域的项目,例如教育,出版,金融产品和制造业。她来自印度新德里,可以通过电子邮件或Linked In与她联系。

©BA Times.com 2020

麦格雷戈徽标白色网站