2007年7月31日,星期二,05:47

从讲故事到资产创造:应该开发什么需求

由基思·巴雷特(Keith Barrett)撰写
发生了什么?

以传达我们信息背景的方式说话和写作是我们的本性。无论是编写虚构的书还是描述业务伙伴的需求,我们在写作时都以讲故事的方式进行。所不同的是,没有人将虚构的书变成运行公司的软件。

我已经阅读了许多业务,用户和功能规范文档,其中大多数文档读起来像是故事,而不是开发人员可以轻松构建代码的内容。我已经听到您的声音了……“我们必须为系统提供适当的上下文,以便开发人员理解所有需要的内容。”是的,我同意,但是我不同意我们传达这些信息的方式。

多年来,我创造了两个与大多数需求文档有关的短语。它们是“ BTD –大文件”和“结块”。 BTD是大多数需求开发工作的典型成果。我们对BTD感到非常自豪,并使用它们为我们的项目提供资金并展示我们对业务需求的理解。为了实现这两个目的,BTD可以正常工作,但是BTD然后交给了​​架构师或开发人员,那时事情开始崩溃了。集群是我们在BTD中所做的事情。我们将采用多个需求,并将其合并为一个段落,然后将各个段落合并为一个页面,最终创建我们的BTD。

从业务角度讲,讲故事的方法效果很好,因为大多数商人都可以轻松地与之建立联系。它的编写方式可以根据他们的业务规则和流程进行情境描述,因此他们通常可以阅读并点头表示对我们的理解。反过来,这给了我们一种错误的安全感,我们已经很好地得出了要求。实际上,我们仅完成了完成需求的一半工作。

故事的其余部分是什么?

尽管我提倡完全不使用故事形式编写内容,但现在假设我们出于其他原因继续以这种方式编写需求文档,以便我们的业务人员可以轻松地与他们建立联系。 BTD完成并且故事已共享并达成共识(即已签字)后,我们必须开始将故事转换为结构化列表的过程,该结构化列表包含已分类和与层次相关的需求。这就是说,我们将BTD聚集在一起,并将其转变为开发人员可以清楚理解,在工具中有效管理并在以后的项目中重用的需求资产。通过这样做,我们将BTD的前期有限业务价值扩展为需求资产形式的长期业务价值。

这真的有必要吗?

让我们踏上开发者的脚步。开发人员正在利用编码技术,这些技术占用了系统的复杂性,并将其变成小型的模块化代码段。这些代码“对象”知道如何相互交谈,并且可以轻松互换和移动。为了以这种方式构建对象,开发人员必须专注于给定对象的功能的很小一部分。意味着他们编写代码来满足非常小的和特定的业务功能。然后,他们将多个对象连接在一起以创建处理更多复杂性的代码。这样想吧;如果系统所需要做的只是确保尝试登录的用户具有有效的用户ID,则只需执行一小段代码即可。但是,如果您想实际验证他们的密码,然后检索有关它们的一些信息,然后显示用户的主页等,则需要大量这些代码对象共同协作才能完成此任务。但是,如今编写代码的方式的基础在于满足一小部分特定需求的细小代码段。我们将其中许多连接在一起以构建“系统”。

将此与大多数需求文档的编写方式进行比较,然后很快就会出现问题。 BTD和大量需求与小型离散代码对象不太吻合。加上书面文本的自然主观性,当开发人员被要求挖掘BTD找出他需要构建的代码对象时,麻烦就来了。我们什至不用考虑我们遍布全球的开发团队可能遇到的语言问题。

实际上,以故事方式记录要求并不需要做笔记技能,而且我们的业务分析师已经被称为做笔记者已有多年了。需要业务分析师技能的地方是将具有需求群的BTD转换成架构师,开发人员可以从中构建系统的需求资产的结构化,分类化,层次化的列表。我意识到,除了笔记之外,还有许多启发技术和技能对于创建BTD来说是必不可少的,但是最后,如果我们交付的是BTD,那么我们就没有在开发过程中交付真正的业务价值。由于软件开发的目标是使用可用软件而不是BTD,因此,我们需要将注意力集中在转换过程上,而不仅仅是BTD过程。

问题在于,大多数业务分析人员和项目管理人员仍然相信,在交付BTD后,他们的工作就完成了。多年来,我们一直在这样做,我们不必太近看业务分析师的声誉以及我们的BTD对开发过程的影响是不理想的。如果您不相信我,请问大多数业务合作伙伴,他们对收到的软件与期望得到的软件相比有多满意。

我们如何创建需求资产?

无论我们是否需要BTD都可以争论,但是对于本文,我们将假定它们是已知的。就是说,转换过程需要业务分析师分解BTD并开发描述业务的小范围和特定方面的需求,同时保持需求之间的必要关系,以便保留适当的上下文。

为此,我建议至少四个类别的需求:业务,用户,功能和非功能需求,或者我称为核心四项。几乎所有需求书(包括Karl Wiegers的书)中都对这些需求类别进行了很好的定义和记录 软件需求。在大多数组织中,BTD已在某种程度上围绕“核心四大”进行了分类,但是由于它们具有类似故事的性质,即使它是业务需求BTD,它仍将包含其他类别的需求。因此,您不能假设标有“业务需求”的BTD仅细分为“业务需求”类别。

简而言之,核心四的定义如下:

  • 业务需求–定义业务需求并回答以下问题:“我们为什么要这样做?”
  • 用户需求–从用户的角度描述系统,并回答以下问题:“用户需要执行哪些任务才能满足业务需求?”
  • 功能需求–定义系统需要执行的任务并回答以下问题:“系统必须如何运行才能使用户能够完成其任务?”
  • 非功能需求–定义系统的质量方面,并回答以下问题:它应运行多快?应该是什么颜色?它必须处理多少个用户?它必须使用什么安全性?

此时,需求管理工具变得必要。市场上有很多优点和缺点。最长的三个或四个是:Requisite Pro – IBM,DOOR – Telelogic,CaliberRM – Borland,Optimal Trace – Compuware。市场上一些较新的产品包括:MKS Integrity for RM – MKS,Accept360 –接受软件,蓝图需求中心–蓝图软件系统,ContourRM – Xeau,iRise Studio – iRise。其中许多是基于当前技术并基于浏览器的。选择并实施工具后,您可以将BTD转换为“核心四核”,并利用该工具的可追溯性功能显示每个需求之间的关系。这样可以保留类似故事的上下文,同时在整个项目中提供有价值的功能,如影响和覆盖范围分析。

将BTD转换成定义明确且具体的需求列表,在“核心四核”中正确分类并通过可追溯性彼此关联的过程是将需求开发与软件开发相结合所需的核心和灵魂。

 


基思·巴雷特(Keith Barrett),ProcessExchange,Inc.专业服务总监是软件开发行业的17年资深人士。在加入ProcessExchange之前,Keith曾担任CSX Railroad的开发经理,Technical Builders(引入CaliberRM的公司),可重用对象的需求管理实践的实践经理。&美国银行组件经理,曾在AT担任多个职务&T Universal Card Services,包括开发人员,业务分析师,数据建模人员和项目经理。

Keith在软件开发,重用和RDM方面的背景使他成为基于重用的需求开发的行业领先倡导者,具有独特的地位&管理(RBRDM)。他在美国银行领导实施基于组件的开发(CBD)和重用的工作经验,再加上他对RDM的重视,使他能够解决在RDM中实施基于重用的方法的技术,文化和流程方面的综合问题。

Keith在美国银行(Bank of America)进行的CBD和再利用方面的工作已在《应用程序开发趋势》,《计算机世界》和《对象杂志》上发表。他曾在美国和国际会议上发表演讲。

©BA Times.com 2020

麦格雷戈徽标白色网站