A社は受注管理システムの再構築にあたり、要件定義を進めている。 非機能要件として定める内容として、最も適切なものはどれか。
正解：ウ
ア受注の登録や取消など、利用者がシステムで行える処理の内容と画面の項目
誤り。これは機能要件です。「システムに何ができるか」を書いたもので、 非機能要件と対になります。両方とも要件定義の成果ですが、機能要件が できることの一覧なのに対し、非機能要件はその実現の質を決めます。
イ受注から出荷までを誰がどの順で担当するかという、業務そのものの進め方
誤り。これは業務要件です。システムの話に入る前に、業務をどう回すかを 決めるものです。業務要件が固まって初めて、そのうちどこをシステムに 担わせるかが決まり、機能要件と非機能要件に分かれていきます。
ウ障害で停止してよい時間の上限や、同時に利用できる人数などの条件
正解。止まってよい時間、さばける人数、応答の速さ、守るべきセキュリティ水準。 どれも「何ができるか」ではなく「どの程度の質で動くか」を決めるもので、 これらをまとめて非機能要件と呼びます。
エ業務でやり取りされるデータの流れを図で表し、処理の関係を示したもの
誤り。これはDFDに代表される要件定義の手法であり、要件を整理して伝えるための 表現方法です。決定表やUMLも同じ位置付けになります。何を決めるかではなく、 どう書き表すかの話なので、要件の種類とは軸が違います。
「できること」と「どのくらいの質でできるか」
引っ越し業者に頼むとき、「家具を運ぶ」は当たり前の要求です。 差が出るのは「何時までに着くか」「壊さないか」「当日に人を増やせるか」のほう。 システムも同じで、できること（機能要件）だけを決めても、 どのくらいの質で動くか（非機能要件）を決めなければ、使えるものにはなりません。
非機能要件に含まれるもの
- 性能 — 検索が何秒で返るか、1時間に何件処理できるか
- 可用性 — 年間で止まってよい時間、障害からの復旧までの時間
- セキュリティ — 誰がどのデータを見られるか、記録をどう残すか
- 運用・保守性 — バックアップの頻度、障害対応の受付時間
これらは決めずに済ませてしまいがちですが、あいまいなまま開発すると、 完成後に「遅すぎて使えない」と分かって作り直しになります。 費用と工期に直結するので、要件定義の段階で数値にしておくことが重要です。
混同しやすいものとの違い
| 用語 | 決めること |
|---|---|
| 業務要件定義 | 業務をどう進めるか（システム化する前の業務の姿） |
| 機能要件定義 | システムに何をさせるか（処理、画面、帳票） |
| 非機能要件定義 | どの程度の質で動かすか（性能、可用性、セキュリティ） |
| 要件定義の手法 | 決めた内容をどう書き表すか（DFD、決定表、UML） |
試験では、選択肢に数値や「〜以内」「〜以上」が出てきたら非機能要件を疑います。 逆に「〜できる」と書いてあれば、たいてい機能要件です。