SWEBOKやISO/JISの区分においては、「ソフトウェア要求」ないし「ソフトウェア要求分析」の中に「外部設計」も含められているようだ。いっぽう私はと言えば、「システム要件定義（脚注①、②）」と「外部設計」を別のアクティビティと考える方が好きだ。その方が人間の思考プロセスに合っていると思うからだ。
ひとつにまとめようが二つに分けようが、目的地は変わらない。ソフトウェアが「外から見て」どう機能するかを定義することだ(脚注③)。だから、後工程である設計／開発の立場からいえば「どうだろうと、好きなようにやってくれ」ということになるのかもしれない。しかし、要件定義/外部設計を実際に行う立場からすると、二つに分けて考えた方がスムーズに仕事が運ぶと思う。
では、二つに分けるとすると、それぞれはどんな内容になるのか。
たとえば伝票入力画面の設計を例にすると、両者の違いは以下のようになる。
- システム要件定義 … どれだけの項目が入力データとして必要か、たとえば、伝票のヘッダ・各明細行にそれぞれどんな項目があるのかを決定する。
- 外部設計 … どういった手段で入力するのか、すなわち、レイアウトや画面遷移、さらには、たとえば勘定科目欄にはコード値を直接入力するのか、プルダウンリストによる選択にするのかといったことを決定する。
まず必要項目や要件(What)を洗い出し、次に手段(How)を検討する。この二つのアクティビティを「フェーズ」にしてウォーターフォール式に逐次実行する、ということではなくて、たとえば一日ごとに、今日は要件定義をやった、明日は今日の分について外部設計しよう、といったことを繰り返しても良いのである。いちどきにはどちらか一方に集中した方が検討の焦点がブレないと思う。両方並行してすすめると、マルチプロセッサ対応していない私の頭は混乱してくるのだ。
もっとも、プロジェクトが短納期化している昨今では、ここで言っている意味での外部設計はそれほどフォーマルにはおこなっていないことが多いかもしれない。そうなると、あえて二つに分ける意味も無いのだろうか。
しかし、システム要件定義では深入りしたくないが、外部設計では片づけて置かなければならない仕事がもうひとつある。「コントロールデータ」の設計だ。コントロールデータとは、処理を制御するためのデータのことだ。たとえば、部門のタイプによって使用可能な勘定科目に制限があるとすれば「部門×勘定科目組み合わせテーブル」が必要になるかもしれない。また伝票の種類ごとに入力締め日を変えるという運用をしたければ、「伝票締め日制御テーブル」が必要かもしれない。これらが「コントロールデータ」だ。
コントロールデータは、データモデリング（これはシステム要件定義でおこなうべきである）時には見えづらい。というのは、コントロールデータと処理ロジックには代替的関係があって、処理ロジックが確定しないとデータも確定しないからだ。例えば、上述した「伝票締め日制御テーブル」にしても、こんなテーブルを設けるかわりにプログラム中に締め日（稼動日ベース）をハードコードしてしまう、という選択肢だってある。コントロールデータの設計は、どの程度の柔軟性をシステムに組み込むかという判断に左右されるわけだ。
だから、システム要件定義時にコントロールデータをいきなり定義するのではなしに、具体的に想定される制約や運用をまず決める。伝票締め日の例でいえば、伝票種類ごとの締め日を表にしてみるわけだ。その上で、外部設計段階で、柔軟性がじっさいどの程度必要とされるのかも考慮して、コントロールデータを設計する。
このようにすれば、柔軟性を盛り込むべきポイントを見過ごすリスクや、逆に、必要も無いのに過度に柔軟につくりすぎる無駄を抑えることができる。
こう考えるとやはり、「ソフトウェア要求分析」は、システム要件定義と外部設計の二つのアクティビティに分けた方が、効率よく進むように思う。
昨今のソフトウェアエンジニアリングでの「ソフトウェア要求分析」の取り扱いようをみると、要求の完全性とか検証可能性といった、要求分析の結果を受けて作業をする立場からの問題認識が前面にでて、要求分析をおこなう立場からの関心は後景に押しやられているように感じる。その意味で、じっさいにプロジェクトを推進するわれわれとしては、要件定義について、ソフトウェアエンジニアリングの文献だけに頼らず理解を深めていく必要がある。
なお、以前に書いた「要件定義について」と本稿で説明した「要件」および「外部設計」の概念構造を図示したものを以下にあげておく。
矢印は依存の方向を示している。たとえば、「業務プロセス定義」は「業務要件」に依存している。すなわち、業務要件を変更すると業務プロセス定義が影響を受ける可能性がある。依存関係は決定順序をあらわすものではない。たとえば、業務プロセスを定義するさいに、業務要件を修正してもかまわない。
こうした概念構造は開発プロセスから独立している。すなわち開発プロセスとしてウォーターフォール型を採ろうが繰り返し型を採ろうが、概念構造じたいは変わらない。その意味で、こうした構造はソフトウェアエンジニアリングにおける安定的要素であるといえる。いろいろな開発プロセスの適否について議論するのもだいじだが、このような普遍的（と思われる）概念構造を整理していくことも必要と思う。
（脚注①）「システム」ということばを使っているが「ソフトウェア」と読み替えて頂いてかまわない。
（脚注②）「要求」と「要件」という用語が混在しているが、両方とも英語の "requirement" の訳であり、同じ意味である。SWEBOK/JIS では「要求」という訳語を使用しているので、これらから引用した場合は「要求」とし、私自身のことばとして使う場合は「要件」としている。「要求」というと「要求者」「被要求者」という「人、対、人」のイメージが強いのでいやなのである。いっぽう「要件」だと「人、対、これからつくろうとしているモノ」というニュアンスがまさる。こちらの方が客観性のにおいがするので、私には好ましく思われる。システム開発プロジェクトではただでさえ人対人の対立が激しくなりがちなのに、何もそれを煽るような言葉を使わなくともよいのではないか。
（脚注③）SWEBOKでは、ソフトウェア要求を「プロダクトパラメータ」と「プロセスパラメータ」に分けているが、ここでは「プロダクトパラメータ」についてのみ考慮している。「プロセスパラメータ」とはシステム開発に関する制約条件であり、たとえば、「開発言語はJavaとする」といった種類の条件のことである。
