Software Requirementsに関するQ&A
2026年度で閉講になるソフトウェア工学概論のSoftware Requirementsに関するQ&Aから、AIの支援により、いくつか抜き出しました。
なお、この授業では2025年度からSWEBOK v4.0を教材として用いています。
1
テストを終えた証明がないとソフトとして採用されないのでしょうか
AIが取り上げた理由
テスト完了を「正しさの証明」や「採用可否の絶対条件」と捉えている可能性があります。SWEBOKでは、テストは有限個のテストケースによる動的な妥当性確認であり、現実的なソフトウェアでは網羅的テストは不可能に近いとされています。また、テストはバグの存在を示せても、不在を証明するものではありません。したがって、「テスト完了証明」ではなく、要求・受入基準・リスク・規制/標準への適合を示す証拠として整理する必要があります。
山崎進のコメント
とはいえ、極めて高い証明性を求めるようなシステムも存在していています。たとえば、ディペンダブル・システムとか、ミッション・クリティカル・システムとか、セイフティ・クリティカル・システムとか、そういったものです。
そのようなシステムでの「正しさの証明」として、形式手法(formal method)を取り入れることが長年試みられてきています。理想的には、数学的に完全に正しさを証明されたようなシステムを作り上げられそうなインパクトがあります。
また、物理世界との相互作用における安全性等を追求するような試みとして、Model-Based System Engineering (MBSE)というような取り組みもされています。
この2つを結びつけることで、実用上問題が生じることがほとんどないようなシステム開発を行えるようにしようという取り組みもされています。
2
要件は設計上の決定ではなく、問題の定義として扱うべきである
AIが取り上げた理由
「要求と設計を安易に混同しない」という趣旨なら妥当ですが、「設計上の決定は要求ではない」と絶対化すると誤りです。SWEBOKでは、要求は文脈や視点に依存し、アーキテクトの設計判断が、下位チームにとっては“派生要求”になる場合があると説明されています。フォローアップでは、「外部ステークホルダー要求」「設計判断」「派生要求」を視点ごとに区別する必要があります。
山崎進のコメント
なので、工程を行ったり来たりしながら進めるということなんじゃないでしょうかね。
3
機能要求は顧客が要求するものでありシステム全体を俯瞰する視点、非機能要求は技術者が機能要求を達成するためにどうシステムを構築するかという細かい視点という理解をした
AIが取り上げた理由
機能要求と非機能要求の分類軸を、「顧客 vs 技術者」や「全体視点 vs 細部視点」として捉えている点が大きな誤りです。SWEBOKでは、機能要求はソフトウェアが提供すべき観測可能な振る舞い、方針、プロセスを表し、非機能要求は技術制約やサービス品質制約を表すものです。非機能要求も顧客・規制当局・運用部門などから出ることがあり、単なる技術者内部の実装方針ではありません。
山崎進のコメント
非機能要件の多くは、システム全体にかかる大きな設計上の問題になることが多いです。たとえば、(非機能要件の1つである)性能を上げようと思ってアルゴリズムを変えるということになったら、システムで行う処理全体に波及する可能性が割とよくあります。
4
要求は『欠けてはいけない』ではなく、取捨選択やスコープ調整の対象になる
AIが取り上げた理由
候補要求や希望要求を優先順位付け・スコープ調整の対象にすること自体は正しいですが、「合意済み要求も欠けてよい」と読める点が危険です。SWEBOKでは、要求開発は「何を作るかの合意形成」、要求管理は「その合意を時間とともに維持すること」と説明されています。要求の削除・変更は、スコープ調整、影響分析、ステークホルダー合意、変更管理を伴うべきで、単なる取捨選択として扱うと契約・品質・受入の前提を壊します。
山崎進のコメント
実務上は、合意済み要求を落としたくなるような状況も生じると思いますが、実際に落とすとなると、とても大きな労力を払って合意形成をやり直す必要があるという認識をしています。
5
要件をカテゴリ毎に分けることで各カテゴリの専門となるstakeholderから要求の抽出を行うことができ、不完全な要求を防ぐことができる
AIが取り上げた理由
要求カテゴリ分けは、不完全性を“防ぐ”ものではなく、不完全性を“低減しやすくする”手段です。SWEBOKでは、要求カテゴリ分けにより、要求源、抽出技法、分析技法、仕様化技法、妥当性確認の権限者を整理しやすくなると説明されていますが、同時に、要求集合の完全性を保証する方法はなく、よく実施された要求抽出でも不完全性を最小化するにとどまるとされています。カテゴリ分けだけで安心せず、ステークホルダー分析、レビュー、シミュレーション、プロトタイピング等を組み合わせる必要があります
山崎進のコメント
ソフトウェア工学の原則の1つですが、分割と統合という考え方があります。問題を分割して、解析しやすくした後で、統合を図って、問題の全体を解決できるようになったかを確認するという考え方です。分けるだけではなく、統合して全体として解決できたかを確認することが重要だということかと思います。