通过FURPS +实现CMMI 2.0的业务分析方法（上）

作为过程和行为模型，许多公司已经在实践能力成熟度模型集成（CMMI）以改进内部纪律，同时将行业领先的实践引入公司的每个部门。 FURPS / FURPS +是识别软件质量属性的模型，是行业公认的实践，它专门为业务分析师设计，以便在基于CMMI实践环境中收集和分析要求时遵循该实践。因此，本文的主要目的是介绍CMMI，并对在业务分析实践中采用FURPS / FURPS +进行详细说明。

什么是CMMI 2.0？

CMMI由一组“过程域”组成。每个过程域都旨在适应公司的文化和行为。CMMI不是一个过程，它是一本关于“CMMI是什么（whats）”的书，而不是一本关于“如何做CMMI（hows）”的书，它并且没有定义公司的行为方式。更准确地说，它明确了哪些行为需要定义。这样，CMMI既是“行为模型”又是“过程模型”。

CMMI还可以帮助我们确定并实现可衡量的业务目标、制造更好的产品、让客户满意，并确保我们尽可能高效地工作。通过五个“成熟度级别”或三个“能力级别”，CMMI定义了构建优质产品或提供优质服务所需的最重要要素，并将它们全部封装在一个综合模型中。

由于本文的目的是在FURPS / FURPS +上进行讨论，因此不会深入研究CMMI成熟度模型。

FURPS / FURPS +

FURPS是一种在了解客户要求和必要性之后验证优先要求的技术。这个概念的主要焦点是识别非功能性要求，并在要求文档中可以获取，它与功能性要求同等重要。

FURPS缩写代表的是
1.Functionality功能性
2.Usability易用性
3.Reliability可靠性
4.Performance性能
5.Supportability可支持性

与利益相关者沟通时，您可以使用此缩写作为指南，确保在要求收集会议上所有主题都有涉及。 确保利益相关者了解做出选择的成本，不要最终要求的东西不在列表之中。

功能性

功能性作为列表的第一条，描述了在要求收集会议上业务分析师必须关注的常规的系统功能点。突出强调了以下几点，以便在要求收集期间更加集中精力推动业务分析师完成整个功能要求。

• 功能集和功能：陈述系统的功能列表以及每个功能所需的能力。
• 审核：是否需要跟踪谁使用了系统以及何时使用了系统？陈述在运行系统时提供审计跟踪的要求。
• 身份验证：是否可以控制对系统的访问？声明身份验证的要求。
• 许可：系统或系统的一部分会被许可吗？如果系统中使用了开源软件，是否遵守所有开源协议？声明获取、安装、跟踪和监视许可证的要求。
• 打印：是否需要打印功能？规定印刷要求。
• 报告：是否需要报告功能？陈述报告的要求。
• 计划：是否需要计划某些系统操作？陈述调度能力的要求。
• 安全性：系统元素或系统数据是否需要安全？陈述保护访问某些资源或信息的要求。

1.是否确定了影响多个用例的功能要求？ 例如，所有用例都可能受到访问控制、审计跟踪、对异常情况（溢出，通信设施，错误处理和恢复等）的一般响应。
2.对于这些要求中的每一个，它们是否具有行为性，并且可以在常见的用例中更好地获取？
3.对于每个功能，是否都清楚输入和共享数据如何生成输出和共享数据？

易用性

可用性的要求对于任何系统的成功都至关重要。不幸的是，可用性的要求通常是最不明确。设想一下这个常见的要求：系统应易于使用。这种要求无济于事，因为无法验证。

在获取可用性要求的同时，最好先确定问题和疑虑，然后再将其细化为可验证的要求。根据传统定义，可用性由五个因素组成：

• 易于学习：具有指定经验水平的用户必须能够在指定时间内学习如何使用系统。
• 任务效率：用户应能够在指定的时间内（或单击鼠标的次数）完成指定的任务。
• 易于记忆：用户在指定的时间内不使用系统后，应该能够记住如何完成指定的任务。
• 可理解性：用户必须能够理解系统提示和消息以及系统的功能。
• 主观满意度：一定比例的社区用户必须对使用该系统表示满意。

您可能要使用以下方法来识别和指定可用性要求：

1.通过查看关键任务、用户配置文件、系统目标和以前的可用性问题，确定关键的可用性问题。
2.选择适当的样式来表达要求，包括

• 绩效样式：指定用户可以以多快的速度学习各种任务以及在训练后可以以多快的速度执行任务。
• 缺陷样式：识别可用性缺陷并指定可能发生的频率，而不是测量任务时间。
• 准则样式：参照公认且定义明确的标准，指定用户界面的通用外观和响应时间。

1.写下实际要求，包括性能标准。
2.是否以一种可验证的方式（包括度量标准和目标值）指定了要求？
3.是否考虑了用户任务的效率和可用性因素？
4.是否考虑过新手和专家用户？

可靠性

可靠性包括系统在压力和不利条件下继续运行的能力。 在应用程序中，可靠性与软件可用和运行的时间相对于不可用的时间有关。 指定可靠性的接受水平，以及如何对其进行评估。 用可衡量的术语描述可靠性标准。通常将其表示为两次故障之间的允许时间或总允许故障率。 其它关于可靠性的重要考虑因素包括：

• 精确度：指定对执行的任何计算或系统输出中所需的准确度（分辨率）和（通过某些已知标准验证的）精度的要求。
• 可用性：指定对系统可用时间百分比、使用时间、维护访问权限以及降级模式操作的要求。可用性通常是根据平均故障间隔时间（MTBF）来指定的。
• 可恢复性：指定从故障中恢复的要求。通常根据平均修复时间（MTTR）进行指定。
• 故障的频率和严重性：指定最大缺陷率（通常表示为缺陷/ KSLOC或缺陷/功能点）和严重性。严重程度可以按次要、重大和严重缺陷进行分类。要求必须明确定义每个术语。例如，严重缺陷可以定义为导致数据丢失或完全无法使用系统某些功能的缺陷。

1.是否已将可靠性要求指定为可衡量的要求或优先的设计目标？
2.是否需要进行错误检查和恢复？
3.是否考虑了不希望的事件并指定了所需的响应？
4.是否考虑了初始或特殊状态（例如冷启动或异常终止）？

性能

• 响应时间：指定系统可用于完成指定任务和事务的时间（平均值，最大值）。使用计量单位。例子：

用户与系统之间的任何接口的最大响应时间应为2秒。
产品应在更改后的5分钟内下载新的状态参数。

• 吞吐量：指定系统支持给定信息流（例如，每秒事务处理）的能力。
• 容量：在产品必须能够处理的指定产品所存储的数据量。确保要求描述已量化，并因此可以进行测试。使用度量单位，如：系统可容纳的客户或交换量，资源使用情况（内存，磁盘等）或降级模式（当系统以某种方式降级时可接受的操作模式。）例子：

该产品应在9:00 AM至11 AM之间同时容纳300位用户。
其他时段的最大负载为150。
启动：系统启动的时间。
关机：系统关机的时间。

是否规定了资源和性能边际要求（例如，速度、响应时间、各种软件功能的恢复时间）？

可支持性

• 适应性：关于软件的适应性（包括升级）是否有特殊要求？列出系统轻松适应新环境的要求。
• 兼容性：是否有关于此系统及其与以前版本的系统或提供相同功能的旧系统的兼容性的任何要求？
• 可配置性：产品在部署后会进行配置吗？系统将以哪种方式进行配置？
• 安装：说明有关系统安装的任何特殊要求。
• 支持级别：产品需要什么级别的支持？通常是通过Help Desk完成的。如果有人为产品提供支持，该支持是否被视为您提供给客户的产品的一部分？该支持有什么要求吗？您也可以在产品本身中建立支持，在这种情况下，需要编写这些要求。想想您期望提供的支持水平以及采用何种形式。
• 可维护性：关于系统维护是否有特殊要求？产品预期的发布周期以及发布的形式有什么要求？量化对产品进行特定更改所需的时间。对于可维护性也可能有特殊要求，例如要求产品必须能够由您的开发团队外的最终用户或开发人员维护。这会影响产品的开发方式，并且可能对文档或培训有其他要求。描述维护类型和所需的工作量。

例如：

必须能够在一夜之间将新的气象站添加到系统中。
维护版本将一年提供给最终用户一次。

• 可扩展性：系统将支持多少用户和数据？这指定了产品必须能够处理的预期大小增长，随着业务的增长（或预计的增长），软件产品必须增加容量以应对增长量。可表示为随时间变化的概况。
• 可测试性：关于系统的可测试性是否有特殊要求？
• 本地化：系统是否有本地化要求？
• 是否有任何可以增强所构建系统的可支持性或可维护性的要求？