2012年4月15日,星期日,00:00

分类客户输入,第1部分

撰写者

专题Apr17 35919235 XS当您从各种来源获得需求输入时,这些信息就一起被搅动了。人们不仅会整洁地告诉您,“这是我所有的业务规则,这是我所有的用例”,依此类推。取而代之的是,业务分析师受到或多或少随机信息的轰炸。因此,需求确定和分析的重要部分是捕获输入的数组,对其进行理解,然后开始将其分类为不同的类别,以便您可以将信息存储在最合适的位置并在项目中有效地使用它。

图1说明了您可能会遇到的九种常见需求类别。当然,您还会听到其他类型的信息,包括大量无关或说明性的信息。这九个存储桶之一无法容纳的信息可能是以下之一:

 

  • 与软件开发无关的需求,例如需要在新系统上培训用户。
  • 项目约束,例如成本或进度约束(与本系列第二篇文章中描述的设计或实现约束相对)。
  • 一个假设,即关于我们在没有明确知识的情况下认为是真实的项目的陈述 真正。
  • 数据需求,通常可以与某些系统功能相关联(您只能将数据存储在计算机中,以便以后可以再次使用它)。
  • 具有历史,上下文设置或描述性的其他信息。卡尔·菲格1

图1.分类客户的声音。

这个由两部分组成的系列文章的其余部分建议听一些短语,以帮助BA努力理解客户的输入并相应地对其进行分类。

业务需求

描述客户或开发组织希望从产品中获得的财务,市场或其他业务收益的任何内容都是业务需求。业务需求回答问题“我们为什么要从事这个项目?”我喜欢在远景和范围文档或项目章程中记录业务需求。

最好是量化这些业务目标。不要仅仅说“增加市场份额”,而是尝试设定特定的目标,以便您可以追踪这些目标并采取您认为有助于实现这些目标的行动。因为提供意见的人员可能不习惯于如此精确地陈述其业务需求,所以广管局将不得不帮助他们将最初的意见组织成高质量的要求。收听有关软件购买者或用户将获得的价值的陈述,例如:

  • “将市场份额提高X%。”
  • “现在因低效的装置而浪费的电费每年可节省Y元。”
  • “每年节省$ Z的旧系统W所消耗的维护成本。”

用例或场景

用例是用户需要执行的用户目标或业务任务的一般说明;用例的单个特定路径就是使用场景。与客户合作,将特定方案推广到更抽象的用例中。您通常可以通过要求用户描述他们的业务工作流来收集用例。发现用例的另一种方法是要求用户陈述他们坐下来使用系统时要考虑的目标。一位说“我需要<do something>”可能描述了一个用例,如以下示例所示:

  • “我需要为包裹打印邮寄标签。”
  • “我需要管理等待分析的化学样品队列。”
  • “我需要校准泵控制器。”

在敏捷开发领域中使用的用户故事听起来很像用例目标。用户故事通常以以下形式表达:“作为<user role>, I want <实现一些目标> so that <我可以得到一些好处>。”这与用例的想法相同,尽管当您在项目中达到这一点时,您可能选择以不同的详细程度记录两者。

商业规则。

当客户说只有某些用户类别可以在特定条件下执行活动时,他可能正在描述业务规则。化学品跟踪系统的示例业务规则可能是:“化学家只有在其有害化学培训之前,才可以在1级危害清单上订购某种化学。”您可能会得出一些软件功能要求以执行规则,例如使培训记录数据库可用于化学跟踪系统。如上所述,业务规则不是功能要求。以下是一些其他短语,建议用户描述业务规则:

  • “必须遵守<一些法律或公司政策>“
  • “必须符合”<some standard>“
  • “如果<有些条件是真的>, then <something happens>“
  • “必须根据<some formula>“

从上面的最后一个示例中您可以看到,即使它们被称为业务规则,它们也可能包含您认为更技术化的信息,例如用于执行某些计算的公式。

功能要求

功能需求描述了系统在特定条件下将表现出的可观察到的行为以及系统将允许用户采取的行动。从系统需求,用户需求,业务规则和其他来源派生的功能需求构成了典型软件需求规范的大部分。以下是一些功能要求的示例,您可能会听到用户的要求:

  • “如果储罐中的压力超过40 psi,则高压警告灯应亮起。”
  • “用户必须能够按正反字母顺序对项目列表进行排序。”
  • “只要有人提交新想法,系统就会向想法协调员发送电子邮件。”

这些陈述说明了用户通常如何提出功能要求,但不一定代表编写功能要求的好方法。例如,在第一种情况下,我们将替换 应该 明确指出,照亮警告灯至关重要。我们还希望确保除了照亮警告灯外,没有其他方法可以指示高压状态。警告灯可能只是演讲者的想法或假设,也可能代表合法的身体限制。第二个示例是用户的需求,而不是系统的需求。系统的要求是允许用户进行分类。您不能指望用户一开始就为您提供精心设计的功能要求。您必须了解他们正在尝试交流的想法,并通过对话将其转变为重点明确的需求陈述。

在本系列的最后一部分中,我将描述一些提示,可以用来检测何时听到客户的信息,这些信息可以分为质量属性,外部接口要求,约束,数据定义或解决方案思想。

不要忘记在下面留下您的评论。 

卡尔·威格斯

卡尔·威格斯是Process Impact的首席顾问,该公司是俄勒冈州波特兰市的软件开发咨询和教育公司。他拥有有机化学博士学位。卡尔(Karl)是许多有关软件开发的书的作者,最近的书是与乔伊·比蒂(Joy Beatty)合着的《软件需求,第三版》。他还是《成功的业务分析咨询:独自完成业务的策略和技巧》一书,一本生活课的回忆录和一本名为《重建》的法医学小说。此外,卡尔还撰写了17首歌曲,并撰写了近200篇有关软件,化学和军事历史的文章。您可以通过ProcessImpact.com或KarlWiegers.com与他联系。

此类别中的更多内容: «分类客户输入,第2部分 开放式问题»

©BA Times.com 2020

麦格雷戈徽标白色网站