功能性需求（機能要件）是规定系统做什么的需求，也就是为了业务要提供哪些处理和功能。
需求定义阶段要分析业务流程和使用方式，梳理出要交给系统完成的处理。以图书借阅系统为例，「用会员号登记借书」「列出超过归还期限的书」就属于功能性需求。在把工序划分得更细的叫法中，有决定整个系统需求的系统需求定义（システム要件定義），以及决定其中软件部分的软件需求定义（ソフトウェア要件定義）等工序。
类比就像餐厅菜单上列出的菜品。它决定了这家店能上哪些菜，但还没写怎么做。
考点
非功能性需求（非機能要件）规定以何种水平和条件提供功能，例如响应速度、不易中断、安全性、便于运维等。
| 角度 | 需求的写法示例 |
|---|---|
| 性能 | 月末结账处理在夜间 4 小时内完成 |
| 可靠性・可用性 | 除计划停机外，营业时间内不停止运行 |
| 信息安全性 | 负责人员以外的人不能查看客户信息 |
| 运维 | 能从记录中追查故障原因 |
非功能性需求也和功能性需求一样，在需求定义阶段确定目标。目标尽量写成数值等可以检验的形式，之后就容易判定是否达成。
类比相当于店家「接单后 10 分钟内上菜」这样的承诺。它规定的不是菜的种类，而是上菜的水平。
记法「非」不是否定功能，而是指「功能以外」的条件。可以理解为在功能齐备之后再附加上的条件。
考点
| 比较点 | 功能性需求 | 非功能性需求 |
|---|---|---|
| 关键决定的内容 | 系统做什么（处理、功能） | 以何种水平和条件提供功能（速度、不易中断、安全性、便于运维等） |
| 写法示例 | 「能够登记订单」 | 「每天最多能处理 5 万件订单登记」 |
| 遗漏时的后果 | 根本无法完成必要的处理 | 能处理，但慢、会停、守不住 |
质量特性（品質特性）是把软件质量按「是否好用」「是否不易出故障」等角度分类而成的。
| 特性 (JIS X 25010:2013) | 考察角度 |
|---|---|
| 功能适合性 | 是否具备必要的功能，并给出正确结果 |
| 性能效率性 | 响应速度和资源使用是否恰当 |
| 兼容性 | 能否与其他系统共存并交换信息 |
| 易用性 | 用户是否容易学会、容易操作 |
| 可靠性 | 发生异常时能否继续正常运行并恢复 |
| 信息安全性 | 能否保护信息不被未经许可地使用 |
| 维护性 | 是否容易修改和变更 |
| 可移植性 | 移到其他环境后能否运行 |
JIS X 25010:2013 标准把质量分为 8 项特性，更早的标准则分为 6 项。旧标准中的功能性，大致相当于 JIS X 25010 的功能适合性。把笼统的「质量好」拆成多个角度后，确定需求时更容易设定目标，成品也能按角度逐项评价。
类比就像给汽车按油耗、乘坐舒适度、故障少、保养方便等项目分别打分的评价表。
考点
功能设计（機能設計）是根据需求定义的结果，决定画面、报表等用户可见规格的设计工序，也称为外部设计。
编程：用编程语言写出已决定的处理步骤。
功能设计要决定用户操作的画面项目和布局、输出报表的格式以及用户的操作流程等。这里决定的规格用户能亲眼确认，所以容易在这个阶段发现与要求之间的偏差。
类比相当于盖房子时，根据业主的要求画出平面图和外观图的阶段。这些是住户一看就能确认是否好用的图纸。
考点
详细设计（詳細設計）是把此前设计中决定的规格，具体化到可以编写程序的内部规格的设计工序。
在细分工序的叫法中，到了软件详细设计（ソフトウェア詳細設計）阶段，要为每一个需要编码的程序决定处理步骤和数据的处理方式。决定的内容整理成设计书，作为编程的依据。
类比就像在平面图的基础上，连柱子位置和电线、管道走向都画进去的施工图。细到工匠拿到后就能直接开工。
考点
| 比较点 | 功能设计 | 详细设计 |
|---|---|---|
| 关键从谁的视角 | 用户看得到的外侧 | 开发者构建的内侧 |
| 决定内容的示例 | 画面的项目与布局、报表格式 | 每个程序的处理步骤、数据的处理方式 |
| 前后工序 | 需求定义之后、详细设计之前 | 设计的最后一步，下一步是编程 |
从本单元的过去问中选 5 题
开始做确认题