このページでは，基本情報技術者試験をはじめとする情報処理技術者試験で必須となる，ソフトウェア要件定義・ソフトウェア方式設計・ソフトウェア詳細設計について，シンプルにまとめています。ソフトウェア要件定義（外部設計）では，DFDや状態遷移図，画面・帳票設計，コード設計など，利用者視点での設計内容を整理します。ソフトウェア方式設計（内部設計）では，機能分割や階層構造化，物理データ設計などを解説し，さらにソフトウェア詳細設計では，モジュール分割やモジュールの独立性といった詳細な設計技法を確認します。まずは全体像をつかみ，その後，気になる項目を繰り返し確認して理解を深めていきましょう。
このページの内容は，システム開発の全体像を理解した上で読んだ方が理解が深まると思いますので，先に次のページを読むことをお勧めします。
ソフトウェア要件定義（外部設計）とは
ソフトウェア要件定義では，システムを構成する各ソフトウェアに求められる機能などを定義します。
※ 外部設計…利用者の視点から設計を行うプロセス
ソフトウェア要件の確立とは（外部設計の全体）
ソフトウェア要件の確立では，業務モデルや論理モデルなどを作成して，ソフトウェアに求められる機能，能力，インタフェースなどを決定します。
業務モデルの作成とは
業務モデルの作成には，DFDや状態遷移図などが用いられます。
DFD（Data Flow Diagram）とは
DFDは，（プロセスを中心に）データの流れ（入力→処理→記憶→出力）に着目して，業務データの流れと処理の関係を図で表します。
※ システムと利用者（または，他のシステムなど）のデータの流れを図にしたり，システム内の構成要素間のデータの流れを図にしたりする
※ 現物理モデル→現論理モデル→新論理モデル→新物理モデルの順に作成する
※ 全体的なレベルから段階的に詳細化していくという手法を用いることが多い
 | プロセス | データの加工などを表す |
 | 源泉と吸収 | データの発生源，または，データの行き先を表す |
 | データフロー | データの流れを表す。名前を付ける |
 | データストア | データが一時的に保管される場所を表す |
状態遷移図とは
状態遷移図は，条件やイベントにより状態が変わるようなシステムの動作を図で表します。
※ 参考「情報に関する理論の基礎まとめ（オートマトンとは）」
 | 状態 | 非受理状態 |
 | 状態 | 受理（終了）状態 ※受理状態は2つ以上あってもよいし，なくてもよい |
 | 遷移 | 状態から状態への変化を表す。「入力/出力＋α」を付ける ※出力がない場合は「＊」を付ける |
 | 初期状態 | 初期状態 |
状態遷移表とは
状態遷移表は，条件やイベントにより状態が変わるようなシステムの動作を表で表します。
※ 状態遷移図から状態遷移表を作成できる（逆も可能）
画面・帳票設計とは
画面・帳票設計では，ユーザービリティ（使用性）を考慮したヒューマンインタフェースを設計します。
GUIの部品とは（設計視点例）
GUIの部品には，次のようなものがあります。
※ GUI…Graphical User Interface。画面にアイコンなどを表示して情報を提示し，それをマウスなどで操作するユーザーインタフェース
※ CUI…Character-based User Interface。画面の表示や操作を文字だけで行うユーザーインタフェース
| ラベル | テキストを表示する部品 |
| プッシュボタン | 何らかの処理を引き受けるための部品 |
| エディットボックス | テキストを入力・表示する部品。複数行入力に設定することも可能 |
| グループボックス | ラベル付きの枠を表示する部品。グループ分けのために使用する |
| チェックボックス | オン／オフを選択するための部品 |
| ラジオボタン | 複数の部品の中で，どれか1つだけを選択するための部品 |
| リストボックス | いくつかの項目を表示し，その中から1つ（または複数）を選択するための部品 |
| コンボボックス | ドロップダウン形式のリストボックスで，項目を1つだけ選択するための部品。ボックス内に直接入力するように設定することも可能 |
| スクロールバー | 表示内容をスクロールするための部品 |
| トラックバー | （指定した範囲の）数値を選択し，設定するための部品 |
| プログレスバー | 処理の進捗状況を表示する部品 |
ヒューマンインタフェースとは
システムを利用しやすくするために，ヒューマンインタフェースに関する要件も定義します。
アクセシビリティとは
アクセシビリティとは，システムやソフトウェアなどを障がい者や高齢者などが利用する場合に，どの程度支障なく利用できるかという度合いのことをいいます。
マウス操作が難しい場合 ⇒ 音声認識などで操作できるようにする
など
ユーザービリティ（使用性）とは
ユーザービリティとは，システムやソフトウェアなどの使いやすさのことをいいます。
※ 利用者が，戸惑うことなく使用できること
コード設計とは
コード設計では，入出力データとして使用するコードを適切に設計します。
コードに要求される機能とは（設計要件）
| 識別機能 | データを区別する機能 例）同音異字の識別 101 麻友美 102 真由美 |
| 分類機能 | データを分類する機能 例）科目の識別（数学はM，英語はE） M01 数学Ⅰ M02 数学Ⅱ E01 英語Ⅰ |
| 配列機能 | データの並びを決める機能 例）年月順 Jくん 19630217（1963年2月17日） Pくん 19650925（1965年9月25日） |
| チェック機能 | 入力されたデータが正しいかをチェックする機能 |
主なコード体系とは（コード設計の型）
順番コード（連番コード，シーケンスコード）とは
順番コードは，データを一定の順に並べて番号を割り当てる方式です。
例）学生番号
101 Aくん
102 Bくん
区分コードとは
区分コードは，データを幾つかのグループに分割して番号を与え，その中で順に番号を割り当てる方式です。
例）装備（剣は10番台，盾は20番台…）
11 木の剣
12 鉄の剣
21 木の盾
けた別コードとは
けた別コードは，データを大分類・中分類・小分類などに分け，それぞれの分類の中で順に番号を割り当てる方式です。
例）クラス分け（大分類：一般にはG，学生にはS，中分類：初級クラスには1，中級クラスには2，小分類：登録順（2桁））
G101 Aくん （一般初級クラス）
G102 Bくん （一般初級クラス）
S201 Cさん （学生中級クラス）
表意コード（ニーモニックコード）とは
表意コードは，コード化するデータの名称や略称，記号などをコードとし，その中で順に番号を割り当てる方式です。
例）テレビ
LTV32 32型液晶テレビ
LTV40 40型液晶テレビ
OTV40 40型有機ELテレビ
コード設計の留意点
- コードは標準化，拡張性，運用性を考えて設計する（システムの内部に合わせて設計しない）
- コードの利用期間を考えて設計する（保守方法も考慮する）
- コードの付番は，実際の利用者が担当する
- コードの入力ミスを防ぎたい場合は，検査文字（チェックディジットなど）を付加する
チェック方法とは（各種チェック）
チェックディジットとは
チェックディジットは，検査対象のコード（基本コード）と，そのコードから算出したチェック用のコード（チェックディジット）を用いて，誤りを検出する方法です。
例）商品コードのチェックディジットを求める
その他のチェック方法とは
| フォーマットチェック | データが指定されたフォーマット形式に沿っているかを検査する 例）09-0123456-56（電話番号？） |
| ニューメリックチェック | データに数字以外が入っていないかを検査する |
| リミットチェック | データの値が指定された上限値より小さいか，または，指定された下限値より大きいかを検査する |
| レンジチェック | データの値が指定された範囲内であるかを検査する |
| 重複チェック | データが重複していないかを検査する |
| 照合チェック | 入力されたデータが，ファイルに存在するかを検査する |
| シーケンスチェック | キー項目として定義した項目の並び順や，抜けを検査する |
| 論理チェック | データの内容が論理的に正しいかを検査する 例）13月32日（不適切な日付） |
論理設計とは
論理設計では，画面・帳票設計やコード設計を基に，使用するデータを，ファイルやデータベースにする方法を決定します。
※ 詳細は，「関係モデルの基礎まとめ」を参照
ソフトウェア適格性要件とは
ソフトウェア適格性要件も作成します。
ソフトウェア要件の評価及びレビューとは（目的と成果物）
ソフトウェア要件の評価及びレビューでは，ソフトウェア要件が，システム要件やシステム方式を満たしていることを評価し，ソフトウェア要件定義書について（システムの取得者と供給者で）レビューを行います。
※ レビューの詳細は，「レビューの基礎まとめ」を参照
広告
ソフトウェア方式設計（内部設計）とは
ソフトウェア方式設計では，ソフトウェア要件を実現するために，ソフトウェアをプログラム（ソフトウェアコンポーネント）に分割し，各プログラムに必要な機能やプログラム間の関係などを明確にします。
※ 内部設計…開発者の視点から設計を行うプロセス
機能分割と階層構造化とは
機能分割とは
機能分割では，ソフトウェア要件定義で作成したDFDなどを基に，各機能を詳細な機能（プログラム）に分割します。
階層構造化とは
階層構造化では，分割した各機能（プログラム）を階層構造にします。また，各機能（プログラム）間の入出力インタフェースも決定します。
※ 同系列の機能をまとめながら階層構造化する
また，プログラムの実行順序をプロセスフロー（流れ図など）で明らかにします。
物理データ設計とは
物理データ設計では，論理設計で決定した論理データについて，より具体的な方法を決定します。
- データ量や，データの追加・更新・削除の度合い，オンライン処理かバッチ処理かなどを分析し明確にする
- 処理形態や，処理速度，ファイルの特性などからファイル編成を決定する
- 格納媒体（磁気ディスクや，磁気テープ，光ディスクなど）を決定する
- レコード内のデータ項目の属性（文字，数字など）や，文字数・桁数などを決定する
※ 拡張性も考慮する
※ 参考「データベース管理システム（DBMS）の基礎まとめ」
入出力詳細設計とは
入出力詳細設計では，画面・帳票設計で設計した内容から，より具体的な設計を行います。
画面設計
入出力に使用する画面イメージを設計する（メニュー項目や，入力可否，色，表示するメッセージなど）
帳票設計
出力する帳票類を設計する（用紙サイズや，文字の大きさ，各項目の配置など）
ソフトウェア結合テストのためのテスト要件の定義とは（目的と内容）
ソフトウェア結合テストのためのテスト要件の定義では，ソフトウェア要件をすべて満たしているかを確認するために，テスト範囲やテスト計画，テスト方法を定義します。
ソフトウェア方式設計の評価及びレビューとは（観点と方法）
ソフトウェア方式設計の評価及びレビューでは，ソフトウェア設計がソフトウェア要件を満たしていることを評価し，ソフトウェア方式設計書についてレビューを行います。
※ レビューの詳細は，「レビューの基礎まとめ」を参照
広告
ソフトウェア詳細設計とは
ソフトウェア詳細設計では，各プログラム（ソフトウェアコンポーネント）をモジュール（ソフトウェアユニット）にまで分割して，より詳細化します。
※ 作成したモジュールは，部品化することで再利用できるようになる
ソフトウェアコンポーネントの詳細設計，ソフトウェアインタフェースの詳細設計とは（詳細化のポイント）
ソフトウェアコンポーネントの詳細設計，ソフトウェアインタフェースの詳細設計では，各プログラムをモジュール（ソフトウェアユニット）のレベルにまで詳細化し，モジュール間のインタフェースなどを設計します。
モジュール分割とは
モジュールを分割する技法については，次のようなものがあります。
流れ重視のモジュール分割とは
STS分割とは
STS分割は，プログラムを入力処理機能（源泉；Source），変換処理機能（変換；Transform），出力処理機能（吸収；Sink）の3つのモジュールに分割する技法です。
TR（トランザクション）分割とは
TR分割は，データの種類によって（トランザクション）処理が複数に分かれる場合に適した技法です。
共通機能分割とは
共通機能分割は，プログラム中で共通して行われる機能をモジュールとして分割する技法です。
※ エラー処理などがある
構造重視のモジュール分割とは
ジャクソン法とは
ジャクソン法は，入力データと出力データの構造からプログラムの構造は決まるという考えのもとに，主に，出力データの構造からプログラム構造を作成する技法です。
ワーニエ法とは
ワーニエ法は，入力データの構造を基にプログラム構造を作成する技法です。
モジュールの独立性の評価とは（強度と結合度）
分割後のモジュールは，独立性が高い方が良いとされています。
※ モジュールの独立性が高いと，他への影響が少ないため保守性が上がる。また，別のソフトウェアでも利用しやすくなるので再利用性も上がる
モジュール強度とは
モジュール強度とは，モジュール間の結び付きの強さを表すもので，モジュール強度が高いほど独立性が高いモジュールとなります。
モジュール結合度とは
モジュール結合度とは，モジュール間の関係性の強さを表すもので，モジュール結合度が低いほど独立性が高いモジュールとなります。
ソフトウェアユニットテストのためのテスト要件の定義とは（目的と方法）
ソフトウェアユニットテストのためのテスト要件の定義では，ソフトウェア詳細設計の要件をすべて満たしているかを確認するために，テスト範囲とテスト計画，テスト方式を定義します。
ソフトウェア詳細設計及び要求事項の評価とレビューとは（観点と成果）
ソフトウェア詳細設計及び要求事項の評価とレビューでは，ソフトウェア詳細設計を評価し，ソフトウェア詳細設計書についてレビューを行います。
※ レビューの詳細は，「レビューの基礎まとめ」を参照
まとめ
今回は，ソフトウェア要件定義・ソフトウェア方式設計・ソフトウェア詳細設計について，シンプルにまとめてみました。内容は多いですが，一度にすべて理解する必要はありません。試験対策や復習の際に，何度でも読み返してみてください。試験で頻出のため，少しずつ確実に身に付けていきましょう。
理解が進んだら，過去問題等にもチャレンジしてみてください。
