2011年8月02日星期二09:16

捕获隐含要求

Written by

介绍

典型的SDLC项目以需求采集练习开始,然后进行分析阶段。在需求分析阶段,进行详细的研究,以确定将通过将提供的软件解决的不同疼痛区域。我们经常遇到情况,或更适当,业务场景,其中所述要求没有明确记录。 它们含糊不清,并且不提供预期的任何清晰度。这导致歧义,最后,除了客户要求的内容之外,可以提供一切的软件!不幸的是,这一发现发生在用户验收阶段。确定缺陷,无意中指向未清楚捕获/记录的要求。业务用户的标准反应是,“我们认为这将被交付......这是一个隐含的要求!”一旦我们听到这个声明,就在IT部门和业务之间开始了一个典型的“通过巴克”的游戏。用户。

如果业务分析师采取措施来确定隐性要求,这种情况可能很容易避免这种情况。业务分析师的一个关键责任是定义将建立的系统的范围,并且在此过程中,确保清楚地记录了明确的和隐式要求。

了解隐含要求

让我们从理解显式和隐式要求之间的差异开始。通常,业务用户在不同的会议和访谈中所述的要求被分类为 明确的要求。 这些 要求是最容易捕获的。它们通常由负载文件支持,也是如此,即使是遗留系统屏幕截图也是如此!

隐含要求 是隐藏的或“假设”的要求。商业用户期望这些待售,因此可能没有觉得有必要在商务会议中明确提及它们。实际定义范围可能具有挑战性,因为没有明确的文档或边界可用。这里的关键字是'scope'。让我们尝试通过一个非常简单的例子来理解这个:

用户要求:  

屏幕捕获以下员工详细信息:

  1. 员工编号
  2. 员工姓名
  3. 部门

隐含要求: 

  1. 捕获指定也是如此

由于它是员工数据捕获屏幕,业务用户将假设也有一个字段捕获指定。这绝对是隐含的要求。但是真的是正确的,这是唯一的隐含要求吗?

例如,我可以添加一些其他隐含要求,例如:

  1. “员工编号”字段所需的复制检查
  2. 应该有设施来搜索现有员工

这是困境开始的地方。一些业务分析师将完全同意我的隐含要求的列表,但我相信商业分析师可能不同意的业务分析师世界会有许多其他人。例如,可以作为单独的屏幕提供搜索工具,因此这将是一个单独的要求。

这里的关键点是认识到捕获隐含要求的需要比奢侈品更多。

另一个例子将在数据处理中心中,其中数据输入运算符的性能由系统中完成的条目的数量来衡量。例如,考虑一个典型的航空公司场景,其中每天数百万乘客旅行。这种场景中的数据输入运算符必须在系统中输入数百个乘客优惠券,并且他的KRA或性能是根据他在系统中输入的优惠券的数量来衡量。在这样的场景中,业务需要一个系统,该系统将快速捕获数据,以高效的方式捕获。这里,隐含的需要是必须以这样的方式设计数据捕获形式,从而可以使用键盘而不是使用鼠标来输入表单上的最大数据/信息。换句话说,最大信息必须使用keystrokes而不是使用鼠标来进入。

如果错过了这种隐含要求,那么我们最终会发生数据进入运营商永远不会遇到他的KRA,并查看更大的画面,航空公司会错过它的 SLA. 。这可能导致航空公司的形象玷污,最终会影响其业务。

范围控制

如果记录良好,可以使用隐式要求作为控制范围的优秀工具,从而导致缺陷较小,最终满意的客户!但是,如果没有明确记录要求的界限,可以滥用并将导致范围蠕变,巨大的缺陷和不满意的客户。

 捕获

这导致我们得出结论,业务分析师社区必须使用某些经过验证的方法来定义和绑定范围。成本效益分析将是在这种情况下处理的理想方式。可能存在一个场景,其中隐式要求的无穷无尽的列表无意中增加了没有可见益处的成本。另一方面,通过决定融入最小的隐式要求,客户将获得巨大的福利。

简而言之,为了确保绝不会错过隐性的要求,我们需要退后一步,并始终试图了解商业用户正在寻找什么,如果我们真的明白这种需要。为了得出结论,我们的商业分析师确实发挥了“真相寻求者”的作用,因此需要解开下面的东西,在我们对理解业务要求的追求中!

别忘了留下你的评论。


阿鲁纳帕拉森瓦伦 :具有12年多年来经验的技术人员,他们选择了解了浮现的作用。用一个商业顾问工作 IT组织,并领导了地理位置,主要是亚洲 - PAC和英国的多个实施项目的要求阶段,并有一些接触美国地理。在过去的6年里,专门从事英国和亚洲 - PAC地区的人寿保险领域

最新来自Aruna Parameswaran

更多在此类别中: « Implementing Change UAT提示和模板»

©ba time.com 2021

MacGregor Logo White Web