2012年5月7日星期一11:53

如何定义软件开发项目的范围:功能和非功能要求

撰写者

A2LL的故事

A2LL –德国的社会服务和失业软件系统,是由T-Systems(国家电信公司的软件部门)与ProSoz共同开发的。 赫滕 .

最终产品于2004年最后一个季度交付,并于2005年1月1日投入使用。该系统由Web浏览器前端组成,而后端则基于16台服务器,每台服务器具有4个处理器。

在德国几个大城市部署系统后,包括 科隆, 汉堡,法兰克福和 柏林 ,福利办公室的用户开始报告该软件的严重问题。遇到的一些问题在图表1中列出。

展览1

系统错误说明

需求类型

如果输入表单的数据不完整(例如,有人错过了许多问题之一),系统会在大约三到四周后自动删除记录

功能性

长度少于十位数的帐号在字符串的末尾而不是开头用零填充(例如3225223变为3225223000而不是0003225223)。

功能性

系统无法生成“方差分析”报告

功能性

系统无法生成“收到太多钱的人”报告

功能性

系统未包含处理小工作收入扣除额的功能

功能性

系统无法应付一次性付款(例如,学童购买书籍)

功能性

系统未向其保险公司正确注册人员

功能性

系统无法正确计算保险费率,导致每月向保险公司多付2500万欧元

功能性

该软件的响应时间极慢

无功能

极慢的数据输入时间

无功能

文档打印与许多本地站点不兼容

无功能

由于上述缺陷,德国政府任命的专家委员会得出结论认为该系统不足,并在A2LL启用仅九个月后就开始考虑新的软件系统。

从这个项目中可以学到什么教训?这项工作的失败似乎源于项目团队无法提取和记录适当的系统要求(包括功能性和非功能性)。毕竟(至少在作者的拙见中)不太可能正确地捕获了需求并将其包含在“需求规格”文档中,但被开发人员忽略了。

不幸的是,无法正确定义IT和软件开发项目的详细级别范围已成为高科技行业中许多失败的根本原因。根据Standish Group的说法,项目失败的八个主要原因中的五个与需求有关:

  • 要求不完整
  • 缺乏用户参与
  • 客户期望不切实际
  • 变化的要求和规格
  • 客户不再需要提供的功能

此外,软件开发中50-60%的错误源于需求
阶段。消除需求错误所需的返工可能占软件开发项目的50%。最后,需求错误是返工成本的70-85%的根本原因。

因此,由于正确的范围定义已成为项目成功的关键因素之一,因此本文致力于系统功能和非功能需求的提取和文档编制。

需求规格模板

图2

展览2-贾马尔

在各种教科书,Internet站点和其他来源中都有大量的软件规范模板。它们包括用户类别,操作环境,约束,假设,依赖性,各种接口等。

但是,本文的目的是专注于这些文档的两个主要部分,通常占总需求量的80-90%(功能需求和非功能需求)(参见图2)。

功能要求

功能需求敏捷指南

我所咨询的许多公司都在问我:“现在我们已经改用敏捷方法了,我们现在不确定如何处理我们的需求流程。例如,我们是否仍需要记录它们?那么需求管理呢?”

我对此类问题的回答是,无论使用哪种项目管理方法,传统的瀑布式方法或敏捷变种之一,项目团队中都必须存在合理的要求工程实践。这是一个愚蠢的示例,我曾经在与一位年轻且过于热情的业务分析师进行对话时使用过:

BA:传统瀑布需求工程的所有规则是否都适用于敏捷项目?

我:如果您不介意,我想问您几个问题。假设您正在从事一个非常保守的瀑布项目,并在需求规格说明文件中记录了以下声明:“主页应快速加载”。您认为会发生什么?

BA:开发人员可能会坚持要求我指定“快速”部分。他们可能想知道页面加载的速度。

我:完美!现在,假设您正在开发一个非常敏捷的项目,并在白板上编写了此要求,甚至只是以相同的格式向一位程序员提到了这一要求。他的反应是什么?您认为他会接受吗?

BA:嗯...我不这么认为。他仍然需要知道页面加载的速度。

我:啊哈,项目管理方法的敏捷性决定的是需求工程的形式而不是需求的广泛性!

在开始描述需求方法的形式化之前,让我们首先定义三个广泛的项目类别(参见图3)。

展览3

项目类型

项目属性

敏捷项目

  • 最高的敏捷度
  • 较小的项目
  • 利益相关者的密切参与
  • 利益相关者数量较少

传统项目

  • 利益相关者的规模和数量非常大
  • 很复杂
  • 合同义务

“中间事物”项目

  • 尝试尽可能敏捷
  • 施加约束
    按项目和/或组织
  • 可能比敏捷项目大,但比传统项目小
  • 利益相关者可能比敏捷项目多,但比传统项目少

那么,记录各种类型的项目的功能要求的准则是什么(参见图4)?

图4

项目类型

形式水平

敏捷项目

  • 通常避免写正式要求
  • 但是,在了解需求之前急于找到解决方案将导致工作浪费

传统项目

  • 有需要正式写下他们的要求
  • 可以使用方案和/或用例来传达需求

“中间事物”项目

  • 尝试尽可能敏捷
  • 施加约束
    按项目和/或组织
  • 可能比敏捷项目大,但比传统项目小
  • 利益相关者可能比敏捷项目多,但比传统项目少

需求编写准则是什么?

记录功能需求时,必须遵循几个简单的规则。

首先,让我们研究一下简洁的书写规则。此规则包含几个子类别。声明应简短明了。他们应该专注于系统必须做什么,而不是应该如何做。同样,最难实现的方面之一-声明不应留有任何解释的空间。如果作者尝试用动词记录每个语句或段落的一项要求,则完成此任务将变得更加容易。

遵循的另一个良好传统是始终使用“必须”一词,而不是混合使用“必须”,“将要”,“可能”和“可能”来表示优先级和/或造成语义混淆。

这是一个对读者进行分析并尝试正确重写的错误要求的示例:

如果可能,将根据SKU主列表验证客户输入的产品SKU,并将结果以表格格式显示给用户

一个好的需求专家会注意到有关此声明的一些问题:

  • 用“将”代替“应”
  • “将被验证” –由谁或什么来验证?
  • “如果可能的话” –如果“不可能”怎么办?
  • “结果” –什么样的“结果”?
  • “表格格式” –强制解决方案
  • 没有唯一标识符
  • 使用“客户”一词代替“用户”

相同要求的可能改进版本可能如下所示:

FR 1.3

ABC系统应对照SKU主清单验证用户输入的产品SKU

如果输入的SKU可以位于SKU主列表中,则ABC系统应告知用户已找到产品,并提示用户将产品添加到购物篮中

如果输入的SKU不能位于SKU主列表中,则ABC系统应告知客户未找到产品

图表5-7列出了质量要求的其他属性。

展览5

展览5-贾马尔

图6

展览6-贾马尔

图7

展览7-贾马尔

 

需求与设计讨论

我在众多IT和软件开发项目中目睹的关键问题之一是,项目利益相关者(包括技术团队成员和客户)都过于渴望在所有产品发布之前就深入讨论最终产品的细化设计方面的问题。已经定义了功能和非功能需求。

有时,经验丰富的团队成员经常提到“提交”按钮的位置和颜色应推迟到以后再说以下几点:

“好吧,我们现在知道这一点;为什么将讨论推迟到以后?”

将功能和设计讨论区分开的主要原因有两个。第一个是定义任何软件产品的功能是一个复杂而繁琐的过程,许多IT专业人员尚未完全掌握。将与设计相关的讨论添加到组合中会使事情变得更加复杂,并使团队成员和客户从更重要的方面分散注意力。

其次,人们应该永远记住,技术团队成员(例如开发人员,架构师等)通常对团队可用的各种设计选项有更好的了解。因此,期望开发人员,架构师和UI设计人员能够提出更有效和创新的解决方案是合乎逻辑的。此外,在许多情况下,这些解决方案可能是客户甚至不知道可行的解决方案。

在进一步探讨该主题之前,让我们看一下需求和技术设计的各自定义。

需求描述了客户的需求–他们传达解决业务问题或实现业务目标所需的业务能力.

技术设计描述了如何满足要求以及哪些系统组件将提供新功能。

如何区分功能需求和设计级解决方案?清除规范文档中的设计元素的最简单方法之一是查找如下短语:

“系统(或客户)应在…之前做X。”

请参见表8,了解一些设计潜入需求的示例。

图8

系统(或客户)应通过…做X

…从下拉菜单中选择一个选项

为什么必须一定是下拉菜单?

…按下“提交”按钮

可以改为“继续结帐”按钮吗?

…单击复选框

为什么不选择单选按钮?

停车场

在需求讨论会议期间,经常发生的事情是,出色,酷炫和令人难以置信的创新设计解决方案出乎意料地“弹出”了整个会议室。当时很明显的问题是:“如果我们现在不冒险解决设计问题,那么这些好主意将如何处理?”

解决方案是创建一个“停车场”,以便捕获这些“为时过早”的项目,以便在项目的适当时间对其进行重新访问。停车场可以采用多种形式,具体取决于项目的复杂性和形式。例如,更多的敏捷项目团队可能决定使用白板或活动挂图来捕获设计思想。

另一方面,建议更复杂的项目在“系统需求规格”文档(SRS)的特殊部分中捕获此信息。

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


参考书目

  1. Karl E. Wiegers撰写的“软件要求,第二版(最佳实践)”
  2. Ralph R. Young撰写的“有效需求实践”(Addison-Wesley信息技术丛书)
  3. Donald C. Gause和Gerald M. Weinberg的“探索需求:设计之前的质量”
  4. Ellen Gottesdiener撰写的“协作需求:定义需求的工作坊”(Kindle版-2009年2月17日)
  5. Suzanne Robertson和James C. Robertson精通需求流程(第二版)(精装)
  6. 项目管理协会(PMI)的“项目管理知识体系(PMBOK)”
  7. http://en.wikipedia.org/wiki/A2LL
贾马尔·穆斯塔法耶夫(Jamal Moustafaev)

贾马尔·穆斯塔法耶夫(Jamal Moustafaev),MBA,PMP –总裁兼创始人 Thinktank咨询,是在项目/项目组合管理,范围定义,需求分析,过程改进和公司培训领域的国际知名专家。他曾为私营企业和政府组织做过工作 加拿大 我们 .

穆斯塔法耶夫先生是一本非常受欢迎的书的作者 “提供出色的项目成果:项目选择,范围界定,估算和管理的实用指南”

此类别中的更多内容: «建模松耦合的用例 敏捷商业智能»

©BA Times.com 2020

麦格雷戈徽标白色网站