2016年6月29日星期三07:23

上下文第5部分中的要求:构建或购买的详细要求

撰写者

本系列的上一篇文章是关于将高层需求(HLR)的内容保持在较高水平的。本文是关于细节要求的内容,其中包含适当数量的细节。我们首先讨论四个交付上下文,其中两个涉及内部构建解决方案,另外两个涉及购买解决方案。需求示例使用两个 形式 -用户故事和传统的Shall陈述。但是不管形式如何,归根结底, 内容 是国王。

建立或购买上下文

主题专家(SME)的可用性是为详细要求采购内容的关键因素。出于本文的目的,我们将假定有这样的人。对于这些可交付成果而言,满足这些需求的消费者同样重要-这些需求负责根据细节交付(即设计,开发和测试)解决方案。考虑以下 交付上下文:

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

注意:建立/购买决策过程本身不在本文的讨论范围之内。

相关文章: 上下文中的需求第4部分:保持高层需求高层

使用嵌入式SME进行内部构建

作为开发团队的专职成员,比拥有详细要求的来源(SME)更好的是什么?不仅如此,而且还在可以逐步实现的业务信息系统上工作。就个人而言,我只经历过类似敏捷的发展。但是根据同事的报告,有些组织存在这些情况。

在完整的敏捷环境中,无论用户故事消除了对详细需求的需求,还是只是被视为一种改进的需求形式,每个用户故事仍需要包括 内容 从需求的角度来看,真正的改进是,开发不需要在工作开始之前就等待全套的需求。同样,结果表达到生产中的时间不长于表达要求之后。

此交付上下文和驱动它的敏捷用户案例形式的完整标记。但是开发和测试必须包含所需内容的完整内容,因此最终需要将内容记录在某个位置(请参见下面的示例)。

没有嵌入式SME的内部构建

我刚开始使用类似敏捷开发的项目。我们得到了传统的业务需求。有些是高级的,有些是低级的。作为一名学士学位,我在一个Scrum团队中的角色是“伪”产品负责人。我的工作是解释选定的需求,并编写相应的用户案例和接受标准。如果需求不清楚或没有足够的细节,则有必要返回要求澄清的业务。

除了需求内容的问题之外,整个项目都不适合增量实施。在每次冲刺结束时,团队都可以演示已完成故事的结果,但是这些元素需要等待数月才能主要发布该系统。

每个主要版本中提供的功能都必须经过集成测试和用户验收测试(UAT)。用户故事中的接受标准对于更广泛的测试工作很有用,但是端到端测试必须单独开发。而且由于业务用户没有参与用户案例,因此他们不得不提出自己的UAT测试用例。

根据这一经验,我的结论是,类似敏捷的上下文将从包含尽可能完整内容的详细需求中受益。 “应”或“用户故事”形式的要求可以并且应该包括接受标准。这将支持所需的任何级别的测试。

购买定制的解决方案

我最熟悉的定制解决方案模型涉及以下步骤:

  1. 该业务部门对要交付的产品提出要求,并选择供应商。
  2. 供应商根据需求生成工作清单(SOW),并指定他们同意交付的内容。
  3. 供应商提供用于UAT和错误修复的解决方案。
  4. 供应商期望“最终”付款并支持保修期。

我最近与供应商有关的经验是从业务角度来看的。供应商使用的开发形式是敏捷。但是,鉴于它们依赖客户提供的需求而不是嵌入式SME,因此它们实际上只是敏捷的。用户故事格式的SOW中的细节也没有。关于此上下文的关键点是,无论供应商形式如何,都必须在供应商承诺以合同成本交付的时间点上完整且详细地描述需求内容。

购买包装解决方案

打包解决方案几乎总是在要求定制以支持收单组织的当前业务流程与调整组织的当前业务流程以使其与“开箱即用”打包所支持的内容保持一致之间的折衷。包装供应商。如果需要自定义,则该工作的要求属于上述“购买”上下文。即使没有必要进行功能定制,也可能会存在需要开发或定制的界面和/或报告。所有这些都需要详细的要求以支持该开发。同样,关键的是细节的内容,而不是形式。

因此,基本上无论构建或购买环境如何,都涉及一种或另一种形式的详细要求-理想情况下提供明确的内容。因此,让我们看一下应为不同类型的需求提供哪些详细程度。

报告要求的内容明细

在上一篇文章中,提供了以下高级报告要求的示例:

该系统应支持向在线客户提供刚刚下达的订单的详细信息,包括电子邮件中已购买商品的清单,收费金额和预计交货日期,以便他们可以离线记录自己的订单。在线购买。

报告HLR的目的是充分描述它,以便根据其目的和对整个业务信息系统的价值来理解它。在详细信息需求期间,诀窍不是将详细信息记录为一系列单独的详细信息需求。理想情况下,应在 报告模板.

适当的报告模板可用于捕获所需的信息,例如频率,交付方式和选择标准。应该规定包括报告的布局,以显示标题和标签的相对位置。最后,模板应适合于记录有关布局中看到的字段的支持信息。 “客户编号”,“交易日期/时间”和“汇总总数”等字段将几乎不需要解释。但是应该描述需要特殊查找或从其他字段派生的值的字段,最好包括示例。

通过将报告详细信息记录在基于模板的规范中,详细信息要求本身实际上可以非常简单。以下示例说明了将详细内容降级为规范时,报告详细信息要求有多简单:

用户故事格式:

作为客户,我想收到一封电子邮件,其中包含我刚刚在网上订购的详细信息,以便获得脱机购买记录。

应声明格式:

系统应在提交每个订单后向在线客户发送电子邮件。

两项要求均应包括接受标准:

验收标准

  • 给定一个在线客户
  • 当客户下订单时
  • 然后,客户会收到一封符合附录C中“客户订单确认电子邮件”规范的电子邮件。

尽管“给定/何时/那么”格式的接受标准起源于敏捷,但没有理由不能将其包含在Shall语句中。

假设报告的所有方面都具有相同的优先级,业务原理,并且需要一起进行测试,那么将不同方面表示为单独的详细要求几乎没有或没有优势。

数据要求的内容明细

当已知一个项目的范围包括新的数据类型(记录和/或字段)时,最好将它们作为详细数据需求包括在内。上一篇文章有​​此示例数据HLR:

该系统应支持建立新客户,包括捕获诸如姓名,地址和联系信息之类的详细信息,以确保每个客户都是唯一可识别的。例如。 Fred Smith分配了客户编号555123,Carter Foundation分配了客户编号654287。

从详细的需求角度来看,应该命名和定义业务信息系统中所需的新记录类型。与数量相关的估计是很好的。对于新字段(包括到其他表的链接),再次使用业务名称和定义。对于字段,应指定其数据类型和大小的详细信息。

根据信息的复杂性,在解决方案的途中可能需要进行一些数据库设计。对于任何新的表和/或字段,设计人员和数据库管理员仍然需要仅来自SME的特定信息。与报告一样,有关数据所需的信息类型是常见的,并且可以由 数据定义模板。

这再次意味着,所需的只是一种形式或另一种形式的单个详细信息要求。 Shall格式示例如下所示:

如附录D中的客户数据规范中所述,系统应提供有关客户信息的存储。

同样,虽然上述要求并未详细列出,但所提供的总体信息(大部分在模板规范中)提供了完成工作所需的条件。就像详细报告要求一样,如果未提供全部内容,则在设计和/或构建数据解决方案时需要咨询SME。

接口要求的内容详细信息

系统界面要么导入业务信息系统所需的数据,要么导出其他系统所需的可用数据。如果项目范围确定了信息需要在系统之间传递,则应该有一个代表该需求的高层需求。 HLR文章的示例为:

当在线客户使用与产品供应商不同的货币交易时,该系统应支持每天从欧洲中央银行获取外汇汇率以支持货币转换。

从详细的需求角度来看,SME应该知道其他系统预期的数据项。应该有可能基于现有(或正在开发)的业务信息系统列出这些数据项。

如果数据项的数量很少,则可以在详细要求中列出它们。如果涉及较大或复杂的数据结构,则可以分别描述细节(我敢说使用 界面模板?)。用户故事形式的示例,其中包含接口数据项的独立列表:

作为系统,我希望从欧洲中央银行接收每日货币汇率数据,以便将购买金额从供应商货币转换为客户的首选货币。

验收标准

  • 可以使用欧洲中央银行提供的基本汇率
  • ECB兑换服务提供新汇率时
  • 然后,将记录以下有关每种货币的详细信息,并可供在货币对之间转换使用:
    • 到货币例如美元
    • 生效日期
    • 欧元汇率,例如0.89
    • 费率类型,例如中端市场

接口列表中的数据项应包括详细信息,例如属性名称,描述和示例。目的是在界面开发阶段支持随后在界面的每一侧上“映射”对应项,在此可以解决尺寸和类型的字段详细信息。这种技术映射是由熟悉业务信息系统的数据库架构的人员完成的。该人员还需要访问外部系统的接口规范。

Upcoming 文章

本文包括有关报表,数据和接口要求的内容的讨论。未解决的两个需求类型是功能性和非功能性。非功能性需求的类型各不相同,详细内容将不在本系列中介绍。但是细节功能需求是如此重要,以至于接下来的两篇文章专门针对它们(包括将用例添加到代表细节的可能形式中)。敬请关注。

丹·塔斯克

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

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

©BA Times.com 2020

麦格雷戈徽标白色网站