# ソフトウェア要件工学 ## 定義 ソフトウェア製品が「何をするか(what)」を——「どのようにするか(how)」ではなく——完全・一貫・明確に記述した仕様を、全関係者の合意の基礎となる形で開発する規律(Boehm 1976)。 > Software requirements engineering is the discipline for developing a complete, consistent, unambiguous specification—which can serve as a basis for common agreement among all parties concerned—describing *what* the software product will do (but not *how* it will do it; this is to be done in the design specification). (Source: [[@1976__IEEE-TC__Software Engineering]], p.1227) ## 重要性 要件仕様の欠如が引き起こす問題(Boehm 1976, [6]): 1. トップダウン設計が不可能: 「トップ」が明確でないため 2. テストが不可能: テスト対象がないため 3. ユーザーが排除される: 何を作るかが不明なため 4. 管理が効かない: プロジェクトが何を生産するかが不明なため さらに、要件仕様書のレビューでは 1 ページあたり 1〜4 件の重大エラーが発見されると報告されている(Bell and Thayer 1976, [7])。 ## 主要アプローチ(1976 年時点) | システム | 開発者 | 特徴 | |---|---|---| | ISDOS/PSL/PSA | Teichroew ら(Michigan 大) | ビジネス系向け。商用採用実績。リアルタイム要件・設定管理には限界 | | SREP/RSL/REVS | TRW / US Army BMDATC | リアルタイム向け。R-Net・自動シミュレーション・トレーサビリティ。汎用性課題あり | | 自動プログラミング(DARPA) | Balzer(USC-ISI), Martin(MIT) | 自然言語処理または領域特化で仕様から実装を生成 | ## 要件/設計のジレンマ 要件が完全に検証されてから設計を始めたいが、要件を検証するためには設計が必要というジレンマが存在する。1970 年代の設計の自由度爆発(CPU・OS・プログラミング言語の選択肢急増)がこのジレンマを悪化させた(Source: [[@1976__IEEE-TC__Software Engineering]], Table I)。 ## 横断的知見 - 1976 年時点で最前線技術として挙げられた ISDOS/SREP の「機械解析可能な要件仕様」というアイデアは、40 年後の形式手法・モデル駆動開発・ドメイン特化言語(DSL)へと系譜がつながる。自動プログラミングへの楽観的期待は LLM の登場で再び議論されている。(Source: [[@1976__IEEE-TC__Software Engineering]]) ## 未解決の問い - Boehm が提唱した「要件仕様言語の汎用化と領域特化のトレードオフ」は今日の DSL 設計でも同様の緊張を示しているか? - LLM による自然言語からのコード生成は Balzer(1975)の「不完全仕様からのプログラム自動合成」研究の現代的実現と見なせるか? ## 関連 - [[ソフトウェアライフサイクル]] - [[ソフトウェア保守]] - [[@1976__IEEE-TC__Software Engineering]] ## 出典 - Boehm, B. W. (1976). Software Engineering. *IEEE Transactions on Computers*, C-25(12), 1226–1241.