2016年8月23日星期二08:58

业务需求问题:系列总结

撰写者

有高层次的需求,有详细的需求,然后这就是所谓的业务需求。

业务需求的问题是允许它们是高级别的,详细的或介于两者之间的任何内容。只要某些业务用户说他们需要它,业务分析师就有义务记录它。我认为,如果没有业务需求,那么这个世界(以及业务信息系统项目)将是一个更好的地方。

在我多年的指导中,我发现许多BA都在区分高级需求和详细需求方面遇到麻烦。的主要目标 上下文中的需求 我刚刚完成的系列旨在帮助区分这种情况。本文旨在对本系列的要点进行总结。其中两点是:

  • 高级别需求应始终具有业务(和项目)环境
  • 当关注HLR上下文时,最容易发现详细要求。

Part 1 该系列中的第2部分介绍了对改进需求的需求,并展示了经典的“ Swings”动画片作为证据,表明在交付业务信息系统方面,多年来情况似乎没有太大改善。 Part 2 谈到业务功能作为高层需求的背景。呈现了组织10,000英尺远的通用功能视图,将其作为最终的业务环境。此通用业务模型由管理功能,支持功能和业务范围组成。高层业务功能被视为该功能中许多业务流程的上下文。反过来,每个流程都被视为是一组业务活动的上下文。

高级别要求准则

Part 3 本系列的讨论了项目范围,以及范围声明和上下文图如何成为HLR的绝佳来源。给出了将范围声明直接转换为高级需求的示例。 Part 4 提供了保持较高级别需求的指南。它建议业务分析师和项目经理将此练习视为“需求计划”,而不是“收集高级需求”。您绝对不希望发生的是将HLR收集会话退化为业务需求收集会话。

在深入研究详细要求之前, Part 5 系列文章中,讨论了四个“构建或购买”交付环境(即外卖点):

  • 构建-具有嵌入式SME的内部(例如完全敏捷)
  • 构建-内部没有嵌入式SME(例如类似敏捷,瀑布式)的内部
  • 购买-定制解决方案(外包开发)
  • 购买-打包解决方案(具有可选的自定义功能)

事实证明,只有上述上下文中的第一个允许在没有详细记录的详细要求的情况下进行。这是可能的,因为在拥有完全敏捷的情况下,Scrum团队包括一名专职的业务主题专家。作为产品负责人,此人及时为每个冲刺提供必要的详细信息。

详细要求表–用户故事还是应声明?

在本系列文章中,我竭尽所能避免出现关于最佳形式的需求陈述的辩论– 用户故事 要么 应声明。归根结底,我相信 内容 最重要的是,不是 形成。同时,我会说我喜欢用户故事。主要原因是它们具有明确定义的结构-包含元素的单个句子 who, what 和 why。相反,Shall语句只是用“系统应...”来使球滚动。在那之后,它几乎是免费的。 Shall语句形式的需求可以是一个句子,也可以在多个页面上运行。而且不要让我开始“应”。实际上,我从未见过喜欢这种情况的业务分析师。唯一糟糕的是(我认为)是用一个隐含需求优先级的术语代替它。例如“系统 必须 ...”。

详细需求内容–七个加减两个

详细要求可以是关于单个属性的,例如更改订单状态的能力。也可以是一长串打算包含在屏幕或报告中的属性。如果涉及的字段很少(我一直偏爱的规则是“七个正负两个”),那么需求的内容可以包含在用户故事中或必须声明。以下示例取自 Part 5:

作为系统,我希望从欧洲中央银行接收每日货币汇率数据,以便将购买金额从供应商货币转换为客户的首选货币。
验收标准
  • 可以使用欧洲中央银行提供的基本汇率
  • ECB兑换服务提供新汇率时
  • 然后,将记录以下有关每种货币的详细信息,并可供在货币对之间转换使用:
    • 货币等美元
    • 生效日期
    • 欧元汇率,例如0.89
    • 费率类型,例如中端市场

请注意,在以上示例中,所涉及的属性最终出现在接受条件中。我认为这是要求的一部分。如果有人在用户故事“句子”本身中有处理用户细节的良好示例,请在下面的附加评论中分享或描述它。
相反,我强烈建议不要在详细要求中尝试命名较长的属性列表。相反,应该可以使用 特定于上下文的模板。建议使用以下上下文作为模板候选者:

上面的每种上下文类型都包括一个指向讨论该系列文章的链接以及该上下文的示例详细要求。这是一个这样的例子 Part 7。同样,我们将接受标准视为包含已记录适当的完整/完整需求详细信息的位置的位置:

系统应显示客户响应已提交的订单在线下达的订单的详细信息。
验收标准–订单成功完成
  • 给定客户在线下订单
  • 客户完成订单处理后,包括确认订单
  • 然后按照附录C中的“客户订单确认屏幕”规范显示该订单的详细信息。

本系列的最后内容是 衍生数据。在中讨论 Part 8。与上面列出的上下文类型一样,简单的派生可能会包含在需求本身中,而更复杂的派生可能会受益于需求声明中引用的支持文档中的描述。

为什么这么多细节?

如开头所提到的,仅包含“道路中间”细节的业务需求没有什么作用。设计师,开发人员和测试人员没有足够的信息来完成所列四种交付环境中的三种。当需要更多细节时(肯定会),将需要与商业SME联系,否则该项目最终将成为另一个受害者。 秋千。’

利用特定于上下文的模板,可以帮助BA识别足够的详细信息,以便根据识别项目的HLR来为项目“在上下文中”交付每个项目。借助这种详细级别的信息,可以构建(希望)满足业务需求的业务信息系统。
因此,正如所承诺的-上下文中需求系列的要点:

  • 高层需求可以(部分)来自项目范围和上下文图
  • 保持高水平的要求高水平
  • 在HLR上下文中最容易找到详细要求
  • 应在需要时使用特定于上下文的模板来详细说明详细要求(而不只是列出)

在此摘要文章中介绍了一个奖励外卖点:

  • 避免生产 业务需求
丹·塔斯克

Dan撰写了两本书,撰写了许多文章,最近在IT行业工作和咨询了48年,最近退休了。他最初的十年是在美国和加拿大作为开发人员(当时称为“程序员”)工作的。随后是两年的计算机编程,数据库设计和数据建模教学。他职业生涯的其余时间都曾在加拿大,澳大利亚和新西兰担任业务分析师。

他继续对质量要求充满热情,并帮助业务分析师制定这些要求。可以通过以下方式与他联系 [email protected]

©BA Times.com 2020

麦格雷戈徽标白色网站