业务需求定义 — 功能性需求、非功能性需求与达成共识
標準约 25 分钟4 个术语过去问 17 题
本单元目标
- 能够说明业务需求定义的目的，以及逐步明确需求的先后顺序。
- 能够把对系统的需求分为功能性需求和非功能性需求。
- 能够说明需求要与谁确认、如何确定下来（需求的达成共识）。
术语总表（4 个）
术语
业务需求定义（業務要件定義）是指以分析现有业务时发现的问题为基础，明确新业务的理想形态（业务流程、角色与权限、业务规则等）以及系统化范围的工作。
在软件生命周期（从系统规划到开发、运维的整个过程）中，它属于紧接规划之后的需求定义流程（要件定義プロセス）中的工作。其目的在于把系统化的范围和其中所需的功能具体化，并与利害关系者（使用系统的部门、发包方等与该系统相关的人或组织）统一认识。
类比这就像搬家前先列出现在住处不方便的地方，再和家人商量好在新家怎么生活。画户型图则是之后的步骤。
考点
- 常考需求按照业务需求 → 系统需求 → 软件需求（業務要件 → システム要件 → ソフトウェア要件）的顺序，从贴近业务的一侧开始逐步明确。
- 常考业务需求（業務要件）表示业务上的目标以及实现该目标的业务做法。它与表示系统性能和方式的系统需求（システム要件）属于不同层次的需求。
- 常考系统要遵循的业务规则（業務ルール）应在定义业务需求的阶段弄清楚。这一步若不充分，系统就会在误解规则的状态下被做出来。
该术语的过去问 3 题 業務要件定義 →
功能性需求（機能要件）是为满足业务需求，规定系统做什么（接收的数据、执行的处理、输出的画面和报表）的需求。
例如登记订单、月末汇总应收金额这类处理内容，就属于功能性需求。可以说，它是把业务中由系统承担的部分，写成系统所做的工作。
类比以自动售货机为例，就相当于收钱、出货、找零这些机器本身要做的工作。
考点
- 常考系统接收什么数据、返回什么数据，即输入输出数据的种类（入出力データの種類），决定了处理的内容，因此属于功能性需求（機能要件）。
- 常考确定系统为支撑业务应具备的功能、具体划定系统化范围，是需求定义流程（要件定義プロセス）的工作。
该术语的过去问 3 题 機能要件 →
非功能性需求（非機能要件）是规定功能本身以外系统应满足的条件（性能、可靠性、安全性等质量水平，以及技术和运维方面的条件）的需求。
例如画面在几秒内响应、一年内允许停机多久、数据如何保护，都属于这一类。即使功能相同，要求的水平不同，所需的设备和费用也会随之改变。
类比同样是自动售货机，按下按钮后几秒出货、能连续几年不出故障、多久检修一次，这些就是机器本身工作以外的条件。
考点
- 常考非功能性需求（非機能要件）中的性能（性能）需求表示处理的速度，用操作后的应答时间（応答時間）或处理所需的时间来表示。
- 常考一年内允许停机时间的上限、从故障中恢复的目标时间，不是系统的功能而是质量条件，因此属于非功能性需求（非機能要件）。
- 常考应答时间目标、运行时间段这类非功能性需求（非機能要件）的数值，也和功能一样在需求定义（要件定義）阶段确定，并与用户部门商定。
该术语的过去问 3 题 非機能要件 →
需求的达成共识（要件の合意）是指与用户部门等利害关系者相互确认整理好的需求，双方同意按此内容推进，从而将需求确定下来。
达成共识的内容要记录在需求定义书（要件定義書）等文档中，后续工序以此为依据推进。如果没有达成共识就进入开发，完成后容易发现与实际业务不符之处，导致返工。
类比这就像定制住宅时，业主和施工方反复商谈、敲定规格书，最后业主认可内容并签字。签字之后，工程就按这份规格书进行。
记法「合意」的「合」意为对齐。开发方和使用方先把内容对齐，再由使用方的负责人批准确定。
考点
- 常考就业务需求达成共识时不可缺少的对象，是将要使用新系统的用户部门负责人（利用部門の責任者）。
- 常考即使由开发者定义系统需求，用户也要参与评审（レビュー），确认需求是否符合自己的需要。
- 常考达成共识的需求定义书（要件定義書）是确定开发到哪里、即开发对象范围的文档。
该术语的过去问 3 题 要件の合意 →
要点
- 业务需求定义以现状分析为基础确定业务的理想形态，并把系统化范围和所需功能具体化。
- 非功能性需求的目标多数可以用数值表示，应把响应速度、允许停机时间等写清楚。
- 需求要整理成文档，经用户部门负责人批准后确定。
- 需求含糊不清就进入开发，后续工序中的返工会增多。
查看这个领域的全部过去问 →