别忘了先定好「多少秒才算达标」── 用 IPA「非功能要求分级」梳理非功能需求

「客户反映画面切换太慢，但合同和规格书里都没有约定响应时间」

「夜间批处理开始无法在早上之前完成，但当初谁也没有估算过数据量会以多快的速度增长」

「服务器故障导致系统停摆半天，这时才意识到，当初下单时根本没有确认过『按现有架构，多少小时内能够恢复』」

提到系统开发中的纠纷，人们往往首先想到的是对功能的理解出现偏差，但实际上，系统投入运行之后真正引发纠纷的，往往正是这类功能以外的需求——也就是所谓非功能需求——被遗忘而没有事先确定。

为防止这种遗漏而存在的官方工具，就是 IPA（独立行政法人信息处理推进机构）的非功能要求分级。本文将用发包方也能理解的语言，梳理其具体内容，以及在中小企业业务系统中切实可行的使用方法。

1. 先说结论

• 非功能需求，指的不是「做什么」，而是「以怎样的品质与条件运行」的需求，可以归纳为可用性、性能、运维、迁移、安全性、安装环境这六大领域
• 非功能要求分级，是 IPA 提供的一套（免费）工具，它把这六大领域的需求项目穷尽式地列成清单，让发包方与开发方以分级的方式逐项达成一致
• 不需要填写全部项目。其设想的使用方式是：先选择与自身相近的「模型系统」，再从重要项目开始，依据自身实际情况依次进行调整
• 非功能需求的等级越高，费用也越高。不应「凭感觉要求高标准」，而应从业务影响倒推，选择合适的等级
• 把确定的结果写入需求定义文档。在这里确定的前提条件，既有助于比较报价，也能在系统投入运行后避免『各执一词』式的纠纷

2. 什么是非功能需求 ── 介于「能运行」与「好用」之间的东西

功能需求指的是「能够登记订单」「能够打印报表」这类关于系统做什么的需求。开发讨论会自然而然地集中在这类话题上。

另一方面，下面这些问题，不会出现在功能清单里。

• 这套系统需要从几点到几点保持运行？周末呢？夜间批处理期间呢？
• 发生故障停机时，必须在多少小时内恢复，业务才不会中断？数据恢复到哪个时间点为止是可以接受的？
• 会有多少人同时使用，一天要处理多少笔业务？五年后数据量会增长到多少？
• 由谁负责监控、备份，以及在故障发生时第一时间接到通知？
• 旧系统中的数据，要迁移到什么程度到新系统？

这些就是非功能需求。麻烦之处在于，即使不事先确定，系统也大体上「能够运行」。问题往往要等到系统投入运行、负载增加、发生故障之后才会暴露出来。而到了那个阶段，由于牵涉到服务器架构与设计的根本，修复起来往往需要付出很大的成本。

3. 什么是非功能要求分级

非功能要求分级，是 IPA 为防止发包方与开发方在非功能需求上出现认识偏差而公开的一套工具。初版发布于 2010 年 4 月，目前的最新版本是反映了安全性与虚拟化（云）相关变化的《非功能要求分级 2018》（2018 年 4 月发布）。目前它被收录在 IPA 网站的存档页面中，但作为检查非功能需求是否有遗漏的基准，在实务中至今仍是常用的标准做法。

其内容由以下这些工具组成。

每一项指标都定义了分阶段的等级选项，其特点在于，需求可以用「选择某个等级」的方式来表达，而不必依赖「高/低」这类含糊的说法。

三种模型系统

另一个特点是，按系统停机后对社会造成影响的大小，划分出的三种模型系统。

• 几乎没有社会影响的系统
• 社会影响有限的系统（如企业核心业务系统等）
• 社会影响极大的系统（如社会基础设施等）

分级表中已经预先填好了各模型对应的参考等级。也就是说，不必从零开始讨论，而是可以先大致判断「本公司接近哪种模型」，再依据实际情况进行上下调整。

4. 六大项目 ── 翻译成发包方的语言

把非功能要求分级的六大项目，转换成发包方能够回答的问题，大致如下。

这样看下来就会发现，六大项目中的大部分并不是技术问题，而是业务问题。能够回答「如果月末的账单处理延迟半天会发生什么」的，不是开发公司，而是发包方。非功能需求的主导权，其实掌握在发包方手中。

5. 切实可行的使用方法 ── 不要试图填满 238 个项目

项目一览表中共有 238 项指标，但对中小企业的项目而言，逐一讨论全部指标并不现实，使用指南本身也没有假定这样的用法。它设想的流程是这样的。

1. 选择模型系统
   （自身的系统更接近哪种影响程度）
        ↓
2. 针对分级表中的重要项目，
   以模型的参考等级为出发点，结合自身实际情况进行调整
        ↓
3. 只对必要的部分，用项目一览表做进一步细化

对于中小企业的业务应用而言，仅仅完成步骤 2 中「重要项目的达成一致」，就已经足够有效。根据经验，我们建议至少把以下几点写入需求定义文档。

• 运行时间段，以及停机时对业务造成的影响（可用性）
• 备份的获取间隔，以及故障发生时「恢复到哪个时间点的数据」「需要多少小时」（可用性・运维）
• 当前的数据量・数据条数，以及数年后的预期增长（性能・扩展性）
• 响应时间与批处理时间的目标值。即使是「不低于现有系统」也可以，重要的是先定下基准（性能）
• 监控・备份・故障初步应对的责任分工（运维・维护性）

此时不能忘记的是等级与成本之间的权衡。例如，如果追求「绝对不会停机的系统」，服务器的冗余化与监控体系会让费用急剧上升。而如果能够判断出「只要业务能撑到第二天早上，当天之内恢复即可」，就可以把这部分预算用到别处。非功能要求分级的等级，不应被当作提高要求的工具，而应作为讨论业务影响与成本平衡的共通语言来使用，这才是恰当的距离感。

6. 与合同・报价的关系

非功能需求，与合同也直接相关。

首先是报价的比较。如果没有先统一非功能方面的前提，就向多家公司询价，A 公司可能按冗余架构报价，B 公司则可能只按一台服务器报价。这样一来，发包方就无法判断价格差异究竟来自架构上的不同，还是估算过于乐观。

其次是验收以及投入运行之后。如果响应时间与备份方面的约定已经写入文档，那么「太慢了」「没想到会这样」之类各执一词的争论，就会转变为对照基准进行事实确认。

IPA 的《信息系统模型交易・合同》中，也把非功能需求作为需求定义阶段的交付物加以文档化。在「需求定义以准委托方式进行，待内容确定后再以承揽合同方式签订开发合同」这种多阶段合同流程中，非功能要求分级可以很自然地融入其中。关于合同的具体形式，请参见IPA《模型交易・合同》解说文章。

总结

整理一下 IPA「非功能要求分级」的要点。

• 非功能需求是关于「以怎样的品质与条件运行」的需求。不确定也能运行，但会在投入运行后暴露出来并引发纠纷
• 非功能要求分级，是 IPA 提供的免费工具，用分阶段的等级，帮助就可用性、性能・扩展性、运维・维护性、迁移性、安全性、系统环境这六大项目・238 项指标达成一致
• 以三种模型系统的参考等级为出发点，从重要项目开始调整，不需要填满全部项目
• 六大项目的内容大多是业务问题，掌握答案的是发包方
• 等级越高，费用也越高。应从业务影响倒推，选择合适的平衡点，并把结果写入需求定义文档

事先确定「要以怎样的品质持续运行」，其重要程度不亚于确定「要做什么」。这是防止出现能运行却不好用的系统、以及后续纠纷的最省钱的方法。

致为业务系统需求梳理而困扰的您

梳理非功能需求，需要在业务的实际情况（高峰时期、数据量、停机时的影响）与实现这些要求的系统架构之间反复权衡。

合同会社小村软件（合同会社小村ソフト）在接受 Windows 业务应用与 Web 系统的委托开发・改造咨询时，会按照本文介绍的思路，在需求阶段就一起梳理性能、运维以及故障时的行为表现。即使您目前还处于「现有系统的处理速度正在逐渐变慢」「想借更新的机会重新审视运维方面的约定」这样的阶段，也欢迎随时咨询。

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

什么是非功能需求？

这是系统「做什么」（功能需求）以外，关于「以怎样的品质与条件运行」的需求。例如，系统何时能够使用（可用性）、多少人使用、多少秒内响应（性能・扩展性）、由谁如何运维・维护（运维・维护性）、如何从旧系统继承数据（迁移性）、需要哪些防护（安全性）、安装在什么环境中（系统环境）等都属于此类。如果忘记确定这些，往往会导致系统「能运行却不好用」。

非功能要求分级可以免费使用吗？在哪里可以获取？

可以从 IPA 网站免费下载。套装内容包括分级表、项目一览表、树状图、活用表以及使用指南（分为解说篇・使用篇・活用篇），最新版本是 2018 年 4 月发布的《非功能要求分级 2018》。目前该内容被收录在 IPA 网站的存档页面中，但作为检查非功能需求有无遗漏的基准，在实务中如今依然被广泛使用。

必须把全部 238 个项目都确定下来吗？

不需要。使用指南本身也并未假定要逐一讨论全部指标。它给出的是一种分阶段的使用方法：先选择与自身相近的模型系统，确定整体的大致标准，再以分级表中的重要项目为中心，结合自身实际情况进行调整，只在必要范围内才用项目一览表做进一步细化。对于中小企业的业务系统而言，仅仅就重要项目达成一致，就能避免大部分「因忘记确定而引发的纠纷」。

非功能需求应该什么时候确定？

应当在需求定义阶段确定。可用性与性能方面的目标，关系到服务器架构与设计的根本，一旦开发进行到一定阶段后再变更，会给费用和工期带来很大影响。IPA 的《信息系统模型交易・合同》中，也把非功能需求（而不仅仅是功能需求）作为需求定义阶段的交付物加以文档化。如果在比较报价的阶段没有先统一非功能方面的前提条件，就无法判断价格差异究竟来自架构上的不同，还是估算过于乐观。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。